Цупко Игорь

Когда инциденты обходятся компании в миллионы, хаотичное реагирование — недопустимая роскошь. Я взял под контроль ситуацию: создал команду SRE, обучил её работать не только на тушение пожаров, но и на их предотвращение.
Мы внедрили чёткие регламенты, разграничили зоны ответственности, научились мыслить системно и не теряться в потоке событий. Там, где раньше люди метались в поисках "где светло", мы начали действовать методично. Я лично подключался к критическим кейсам — не просто как эксперт, но и как катализатор осознанных решений. Учитывал всё: от логики диагностики до эмоционального состояния команды, потому что паника дорого стоит.
Ключевой точкой стало управление изменениями. Я разложил хаотичный поток апдейтов на категории рисков, ввёл бескомпромиссные чек-листы и систему оценки последствий. Теперь каждое изменение проходит через фильтр здравого смысла. Итог? Инцидентов стало меньше, время реакции сократилось, а компания сэкономила 60 миллионов, которые раньше просто сгорали.

Компания столкнулась с проблемой: релизы задерживались, команды буксовали, а тимлиды были перегружены. Я провёл аудит, изучил процессы, поговорил с командами — картина стала очевидной. Тимлиды тратили львиную долю времени на мердж веток, ручную проверку и спасение релизов в последний момент. Разработчики не чувствовали ответственности за стабильность кода, а менеджмент привык к пожарам.
Я помог им сместить фокус: тимлиды должны не тушить пожары, а развивать команды. Вместе мы ввели практики экстремального программирования, убрали долгоживущие ветки, изменив git flow, и вернули ответственность за качество производимого кода разработчикам. В команде изменился майндсет, выросла дисциплина, улучшились коммуникации.
Когда тимлиды освободились от рутинного микроменеджмента, они наконец смогли заняться стратегией. Мы автоматизировали процесс релизов, улучшили тестирование — вместо хаоса с флешками и звонками системному администратору клиента, который пытается установить релиз в закрытом контуре без какого-либо понимания, появился предсказуемый процесс с высокой надёжностью.
Итог? Стабильные релизы, уменьшение Time To Market и рост показателей команды без перегрузки ключевых людей.

Мы привыкли думать, что SLA — это цифры. Проценты доступности, латентность, среднее время отклика. Но реальность сложнее. Особенно когда твоя платформа — это фундамент для чужих продуктов, а не конечная услуга.
В начале мы пытались делали, как все: измерять доступность и отклик. Клиенты требовали цифр, и мы давали, но в силу того. как устроена реальность — цифры эти показывали погоду на Марсе, и на самом деле не давали клиентам ничего. Приложения падали из-за внешних факторов — сети, виртуализации, архитектурных решений клиентов. Но страдали мы: "Ваш SLA нарушен!"
Мы пытались исправить это: выдумывали новые метрики, отделяли свою зону ответственности от чужой, искали показатели, которые точно отражали бы нашу работу. Но всё равно оставалось ощущение, что мы просто играем в математику, не решая корневую проблему.
Прорыв случился, когда мы задали себе ключевой вопрос: а что мы на самом деле даём клиенту?
Мы не продукт. Мы — платформа. И наша задача — не просто "держать доступность", а обеспечивать предсказуемость, стабильность, управляемость среды. Мы перестроили подход: вместо того, чтобы оправдываться за чужие сбои, мы внедрили метрики, которые реально влияли на надёжность.
Так появился манифест уровня обслуживания — не просто документ, а система принципов, описывающая:

• Как мы взаимодействуем с зависимостями (инфраструктура, сеть, виртуализация).
• Как строятся процессы расследования инцидентов.
• Как SLI превращаются в инструмент выявления проблем, а не повод для штрафов.

SLA — это не просто цифры. Это способность влиять, разбираться в причинах, предлагать решения. Я отказался от формального соответствия и сделал SLA инструментом, который помогает бизнесу работать лучше.

Когда процессы непрозрачны, бизнес топчется на месте. В компании, где я работал, хаотичный поток задач привел к завалам, потере управляемости и падению доверия клиентов. Задачи ставились в чатах, исчезали в недрах бэклогов, а термин «дрищпак» означал, что клиенту никто даже не скажет, что его запрос ушёл в никуда.
Мы начали с диагностики. Глубокий анализ показал: проблема не просто в хаосе, а в отсутствии четкой системы. Вместе с командами и CTO мы создали новую модель управления задачами на основе Scrumban. Ключевое отличие – максимальная прозрачность: клиенты всегда знали, где их задачи, без лишней бюрократии.
Что изменилось? Теперь при списании времени сотрудник фиксировал, что сделано, а клиент получал обновления прямо в том же чате, где ставил задачу. Мы ввели еженедельные синхронизации, чтобы заказчики могли управлять приоритетами, исходя из реальной загруженности команды. Вся система была не просто внедрена в работу – я обучил менеджеров работать с ней и развивать её самостоятельно.
Результат? Компания вышла из операционного хаоса, снизила нагрузку на команды, повысила прогнозируемость и лояльность клиентов. А главное – процесс продолжил работать и эволюционировать даже после моего ухода.

Компания росла. DevOps-команды брали всё больше проектов, но в какой-то момент рост замедлился: не хватало тех, кто мог бы возглавить новые команды. Людей назначали на роли тимлидов, но они не справлялись — их не учили, не поддерживали, просто бросали в пекло.
Я понял, что так дальше не пойдёт. Сначала я заменил неподходящих тимлидов на тех, кто реально мог вести за собой. Но этого было мало — компании нужна была система, а не разовые исправления.
Я ввёл институт заместителей тимлидов — сильных специалистов, которые со временем должны были вырасти в полноценных лидеров. Разработал фреймворк развития, где каждый зам получал поэтапную передачу ответственности, поддержку и обратную связь. Вся система отслеживала их прогресс и обеспечивала плавный переход к лидерству.
Результат? Компания снова начала расти. Уже в процессе внедрения появились две новые команды, а после моего ухода процесс масштабирования не остановился. Сегодня компания продолжает развиваться, потому что у неё есть надёжный механизм выращивания лидеров, а не хаотичное назначение «первых попавшихся».