# Архитектурное безумие: почему лидер рынка терпит неудачу при внедрении передовых технологий
**Category:** [Блог](https://discuss.rabkesov.ru/c/blog/9)
**Created:** 2025-12-22 00:10 UTC
**Views:** 23
**Replies:** 0
**URL:** https://discuss.rabkesov.ru/t/arhitekturnoe-bezumie-pochemu-lider-rynka-terpit-neudachu-pri-vnedrenii-peredovyh-tehnologij/304
---
## Post #1 by @break_room
> Пришла коробочка... но через три месяца доставки забыл, зачем заказывал.
## Потому что ею сейчас не потушить пожар
## Профессиональная деформация: когда работа формирует плохие привычки
> Я уже писал, что в ИТ-сфере с сотнями переключений в день не домашние привычки определяют подход к работе, а наоборот — работа вырабатывает у нас привычку к немедленному решению проблем, часто без должного анализа последствий.
Отыскал для вас несколько примеров, как люди поддаются соблазну мгновенного результата на примере импульсивной покупки. Бедолаги, в момент заказа думали, что покупка в один клик это единственный шаг к решению проблемы.
## А кто это сделал?
Представьте себе, CTO и PM крупных компаний делают точно так же. Они заказывают у DevOps-команд "решение на скорую руку". Получив долгожданную «коробочку» с новейшими технологиями (Apache Kafka, объектное хранилище S3, шардированная СУБД, семантический поиск), они даже не обнаруживают неприятную правду: к товару не прилагаются инструкции по установке, настройке и эксплуатации. Нет скриптов развертывания и возможности масштабирования, мониторинга производительности. **И самое главное — никто не предупредил команду DevOps о том, что эти технологии вообще будут внедрены.**
Проходит три месяца с момента заказа, но вместо долгожданного облегчения руководитель сталкивается с новым кругом проблем. Его разочарование можно выразить словами: *«Пришла коробочка… но через три месяца доставки забыл, зачем заказывал»*. Стремление к быстрым победам оборачивается операционным хаосом, а отсутствие стратегического планирования превращает технологии в источник бесконечных трудностей.
## Нам нужна Kafka к следующему релизу
Кто-то из техлидов почитал статью на Хабре о «потоковой передаче событий в реальном времени», кивнул и сказал, что нам нужна Kafka. Без запроса предложений. Без обзора архитектуры. Без участия DevOps. Знакомо?
Да, Kafka с открытым исходным кодом. Да, она масштабируется. Но спросите любую команду, которая эксплуатировала её в кластерах: зрелость Kafka нелинейна - это ступенчатая функция.
* 0–6 месяцев: "Все работает!" - Скрытый дисбаланс разделов, неравномерная нагрузка на брокеры, неконтролируемая задержка
* 6–12 месяцев: "Почему растут задержки?" - Ручное перераспределение, тушение пожаров, фрагментированная ответственность
* 12+ месяцев: "Кто за это отвечает? Как нам это вообще отключить?" - "порождение зомби" с неучтенными затратами на внешнюю поддержку
Без DevOps‑ready автоматизации, наблюдаемости и управления жизненным циклом всей экосистемы Kafka дает не потоки данных, а потоки оповещений в телеграм.
## S3‑совместимое хранилище? Отлично. Теперь защитите его
Команда Ozon потратила месяцы на [перестройку](https://highload.ru/spb/2025/abstracts/14487) Lusca на S3‑совместимом хранилище — не потому, что S3 сложен, а потому, что реализация сильной согласованности поверх событийной, управление фоновыми процессами базы данных и восстановление терабайтов данных — это задачи, требующие глубокой экспертизы и времени.
Хуже того: если вы развернете это за контейнерами без гигиены DevSecOps - без сканирования образов, без хранилища секретов, без политик сети L7 - вы не создадите хранилище. Вы создадите вектор уязвимости и технический долг поджог.
## Шардирование БД: точка невозврата
Шардируем только после того, как исчерпали вертикальное масштабирование, оптимизацию запросов, уровни кэширования и реплики для чтения. Это последнее средство.
Сделаем это неправильно - получим "горячие" шарды, задержку репликации и сбои запросов между шардами. **Особенно если ключ шардинга выбран некорректно.** Сделаем это без DevOps‑инструментов для резервного копирования, мониторинга и перераспределения - обменяем масштабируемость на живучесть.
Суть в том, что мы не сможем "разшардировать". Однажды внедрив такое решение, с него нельзя спрыгнуть без стократного гемора.
## А теперь настоящая проблема - не техническая, а организационная
Ни один бенчмарк не скажет, что самое узкое место в современном DevOps это не умственные ресурсы, память или скорость выполнения операций. Потому что это - задержка принятия решений из-за проблем с дорожной картой.
В некоторых компаниях отсутствует roadmap DevOps. А в некоторых не существует вообще. Потому что стратегия отдается демо-продажам коленочных решений.
К чему приводит культура реактивного исполнения?
* После того, как CTO подписывает заказ на разработку, инженеры вместо спецификаций получают пинок "Автоматизируйте это на 100 серверах" - без документации, без понятной архитектуры, без тестового покрытия
* А через три месяца: "Почему так медленно? И зачем мы это вообще строили?"
Это не лидерство. Это уклонение от ответственности.
Команды DevOps в реактивных организациях сжигают добрую волю, гоняясь за призраками в логах и графиках, **исправляя то, что они никогда не проектировали, и защищая то, чем они никогда не владели**.
А когда что‑то ломается? Вина ложится на людей, а не на процессы. Это не DevOps, а команда ясновидящих YasnoOps. **Зрелая культура DevOps не спрашивает, кто ошибся. Она спрашивает, что дало сбой и исправляет систему, а не ищет виноватого. В вашем случае система — это отсутствие дорожной карты и отсутствие вовлечения DevOps на этапе принятия решения.**
## Российский контекст: скорость против стабильности
В 2023-2024 годах рынок SaaS в России вырос до нескольких трлн.руб, но это не стабильный предсказуемый рынок, а скороварка. Гонка за тем, чтобы выглядеть современно, разрушает основы, необходимые для того, чтобы быть современным.
Мы вроде должны двигаться в направлении, заданным [ГосТех](https://platform.gov.ru/news/chto-takoe-gosteh-i-zachem-on-nuzhen-intervyu-tadviser-s-glavoj-fku-gosteh-vasiliem-slyshkinym/). К унифицированному логированию, сертифицированным API, мониторингу, соответствующим требованиям ФСТЭК и целостности цепочки поставок. **Но как встроить стандарты в архитектуру, построенную на спешке и импульсивных решениях? Как обеспечить безопасность, если DevOps-команды не были вовлечены в проектирование?**
**Такая компания все еще относится к инфраструктуре как к второстепенному вопросу**. Это не провал инженерии. Это провал управления ожиданиями.
## Как изменить ситуацию?
Решение в смене позиции:
* От "Построим это сейчас для продажи" → "Готовы ли мы владеть этим в обозримом будущем?"
* От скорости внедрения функций → к устойчивости платформы
* От DevOps как пожарной команды → к DevOps как со‑архитектору
Крупные компании прошли этот путь. Они публикуют свои roadmap. Они откладывают запуски ради стабильности. Они измеряют операционную готовность, а не только даты релиза.
Они понимают простую истину - скорость без контроля это не гибкость. Это дрейф. И он особенно недопустим в корпоративном ПО, где на кону государственные секреты.
## Для выхода из кризиса требуется переход
1. **От реактивного управления к проактивному планированию** - разработка дорожной карты DevOps, вовлечение всех заинтересованных сторон на ранних этапах.
2. **От исполнителей к стратегическим партнёрам** - признание DevOps как неотъемлемой части продуктового развития.
3. **От хаотичных внедрений к планомерной трансформации** - поэтапное внедрение технологий с пилотированием и итеративным выявлением пробелов.
4. И тогда кнопка "Купить" перестанет нажиматься автоматически :)
**Потому что в современных реалиях, особенно в условиях ГосТеха, игнорирование операционной зрелости — это не просто риск, а стратегическая ошибка.**
---
**Canonical:** https://discuss.rabkesov.ru/t/arhitekturnoe-bezumie-pochemu-lider-rynka-terpit-neudachu-pri-vnedrenii-peredovyh-tehnologij/304
**Original content:** https://discuss.rabkesov.ru/t/arhitekturnoe-bezumie-pochemu-lider-rynka-terpit-neudachu-pri-vnedrenii-peredovyh-tehnologij/304