Пришла коробочка… но через три месяца доставки забыл, зачем заказывал.
Потому что ею сейчас не потушить пожар
Профессиональная деформация: когда работа формирует плохие привычки
Я уже писал, что в ИТ-сфере с сотнями переключений в день не домашние привычки определяют подход к работе, а наоборот — работа вырабатывает у нас привычку к немедленному решению проблем, часто без должного анализа последствий.
Отыскал для вас несколько примеров, как люди поддаются соблазну мгновенного результата на примере импульсивной покупки. Бедолаги, в момент заказа думали, что покупка в один клик это единственный шаг к решению проблемы.
А кто это сделал?
Представьте себе, CTO и PM крупных компаний делают точно так же. Они заказывают у DevOps-команд “решение на скорую руку”. Получив долгожданную «коробочку» с новейшими технологиями (Apache Kafka, объектное хранилище S3, шардированная СУБД, семантический поиск), они даже не обнаруживают неприятную правду: к товару не прилагаются инструкции по установке, настройке и эксплуатации. Нет скриптов развертывания и возможности масштабирования, мониторинга производительности. И самое главное — никто не предупредил команду DevOps о том, что эти технологии вообще будут внедрены.
Проходит три месяца с момента заказа, но вместо долгожданного облегчения руководитель сталкивается с новым кругом проблем. Его разочарование можно выразить словами: «Пришла коробочка… но через три месяца доставки забыл, зачем заказывал». Стремление к быстрым победам оборачивается операционным хаосом, а отсутствие стратегического планирования превращает технологии в источник бесконечных трудностей.
Нам нужна Kafka к следующему релизу
Кто-то из техлидов почитал статью на Хабре о «потоковой передаче событий в реальном времени», кивнул и сказал, что нам нужна Kafka. Без запроса предложений. Без обзора архитектуры. Без участия DevOps. Знакомо?
Да, Kafka с открытым исходным кодом. Да, она масштабируется. Но спросите любую команду, которая эксплуатировала её в кластерах: зрелость Kafka нелинейна - это ступенчатая функция.
- 0–6 месяцев: “Все работает!” - Скрытый дисбаланс разделов, неравномерная нагрузка на брокеры, неконтролируемая задержка
- 6–12 месяцев: “Почему растут задержки?” - Ручное перераспределение, тушение пожаров, фрагментированная ответственность
- 12+ месяцев: “Кто за это отвечает? Как нам это вообще отключить?” - “порождение зомби” с неучтенными затратами на внешнюю поддержку
Без DevOps‑ready автоматизации, наблюдаемости и управления жизненным циклом всей экосистемы Kafka дает не потоки данных, а потоки оповещений в телеграм.
S3‑совместимое хранилище? Отлично. Теперь защитите его
Команда Ozon потратила месяцы на перестройку Lusca на S3‑совместимом хранилище — не потому, что S3 сложен, а потому, что реализация сильной согласованности поверх событийной, управление фоновыми процессами базы данных и восстановление терабайтов данных — это задачи, требующие глубокой экспертизы и времени.
Хуже того: если вы развернете это за контейнерами без гигиены DevSecOps - без сканирования образов, без хранилища секретов, без политик сети L7 - вы не создадите хранилище. Вы создадите вектор уязвимости и технический долг поджог.
Шардирование БД: точка невозврата
Шардируем только после того, как исчерпали вертикальное масштабирование, оптимизацию запросов, уровни кэширования и реплики для чтения. Это последнее средство.
Сделаем это неправильно - получим “горячие” шарды, задержку репликации и сбои запросов между шардами. Особенно если ключ шардинга выбран некорректно. Сделаем это без DevOps‑инструментов для резервного копирования, мониторинга и перераспределения - обменяем масштабируемость на живучесть.
Суть в том, что мы не сможем “разшардировать”. Однажды внедрив такое решение, с него нельзя спрыгнуть без стократного гемора.
А теперь настоящая проблема - не техническая, а организационная
Ни один бенчмарк не скажет, что самое узкое место в современном DevOps это не умственные ресурсы, память или скорость выполнения операций. Потому что это - задержка принятия решений из-за проблем с дорожной картой.
В некоторых компаниях отсутствует roadmap DevOps. А в некоторых не существует вообще. Потому что стратегия отдается демо-продажам коленочных решений.
К чему приводит культура реактивного исполнения?
- После того, как CTO подписывает заказ на разработку, инженеры вместо спецификаций получают пинок “Автоматизируйте это на 100 серверах” - без документации, без понятной архитектуры, без тестового покрытия
- А через три месяца: “Почему так медленно? И зачем мы это вообще строили?”
Это не лидерство. Это уклонение от ответственности.
Команды DevOps в реактивных организациях сжигают добрую волю, гоняясь за призраками в логах и графиках, исправляя то, что они никогда не проектировали, и защищая то, чем они никогда не владели.
А когда что‑то ломается? Вина ложится на людей, а не на процессы. Это не DevOps, а команда ясновидящих YasnoOps. Зрелая культура DevOps не спрашивает, кто ошибся. Она спрашивает, что дало сбой и исправляет систему, а не ищет виноватого. В вашем случае система — это отсутствие дорожной карты и отсутствие вовлечения DevOps на этапе принятия решения.
Российский контекст: скорость против стабильности
В 2023-2024 годах рынок SaaS в России вырос до нескольких трлн.руб, но это не стабильный предсказуемый рынок, а скороварка. Гонка за тем, чтобы выглядеть современно, разрушает основы, необходимые для того, чтобы быть современным.
Мы вроде должны двигаться в направлении, заданным ГосТех. К унифицированному логированию, сертифицированным API, мониторингу, соответствующим требованиям ФСТЭК и целостности цепочки поставок. Но как встроить стандарты в архитектуру, построенную на спешке и импульсивных решениях? Как обеспечить безопасность, если DevOps-команды не были вовлечены в проектирование?
Такая компания все еще относится к инфраструктуре как к второстепенному вопросу. Это не провал инженерии. Это провал управления ожиданиями.
Как изменить ситуацию?
Решение в смене позиции:
- От “Построим это сейчас для продажи” → “Готовы ли мы владеть этим в обозримом будущем?”
- От скорости внедрения функций → к устойчивости платформы
- От DevOps как пожарной команды → к DevOps как со‑архитектору
Крупные компании прошли этот путь. Они публикуют свои roadmap. Они откладывают запуски ради стабильности. Они измеряют операционную готовность, а не только даты релиза.
Они понимают простую истину - скорость без контроля это не гибкость. Это дрейф. И он особенно недопустим в корпоративном ПО, где на кону государственные секреты.
Для выхода из кризиса требуется переход
- От реактивного управления к проактивному планированию - разработка дорожной карты DevOps, вовлечение всех заинтересованных сторон на ранних этапах.
- От исполнителей к стратегическим партнёрам - признание DevOps как неотъемлемой части продуктового развития.
- От хаотичных внедрений к планомерной трансформации - поэтапное внедрение технологий с пилотированием и итеративным выявлением пробелов.
- И тогда кнопка “Купить” перестанет нажиматься автоматически
Потому что в современных реалиях, особенно в условиях ГосТеха, игнорирование операционной зрелости — это не просто риск, а стратегическая ошибка.