К концу 2025 года у нас в Provet почти не проходило ни недели без очередного ухудшения работы инфраструктуры. Сбои шли один за другим, диагностировать их было трудно, а терпение клиентов подходило к концу.

Когда в октябре произошёл крупный сбой AWS, клиенты не стали разбираться, где проблема Amazon, а где наша: месяцы нестабильной работы уже подорвали их доверие.

Поэтому мы впервые объявили режим «жёлтого кода» (Code Yellow). Мы разослали всей компании письмо, в котором объяснили суть этого режима, структуру работы, критерии завершения и причины такого решения. Цель была простой: подтянуть показатели SLA и добиться нулевого времени недоступности на протяжении восьми недель подряд.

Хорошая новость в том, что мы справились. За весь этот период произошёл лишь один кратковременный эпизод ухудшения работы, и разница с ситуацией всего несколькими неделями ранее была поразительной.

Эта статья — о нашем опыте и о практике применения «жёлтого» и «красного кода» (Code Red) в целом: что это за режимы, как правильно организовать работу, когда их объявлять и когда завершать.

Вот что мы разберём:

• Что на самом деле означают Code Yellow и Code Red и откуда взялись эти термины.

• Как мы организовали «жёлтый код» в Provet: структура, работа и полученные уроки.

• Универсальный шаблон, который можно адаптировать под свою организацию.

• Когда объявлять такой режим, когда повышать уровень эскалации и каких типовых сценариев провала стоит опасаться.

Начнём.

Прежде чем рассказывать о нашем опыте, стоит разобраться с терминами.

Понятия Code Yellow и Code Red появились в Google. Как пишет Стивен Леви в книге In the Plex, название произошло от жёлтой майки руководителя инженерного подразделения Уэйна Розинга. Тот, кто надевал её, становился ответственным руководителем и получал право напрямую привлекать к работе любого сотрудника Google, временно снимая его с текущего проекта.

Со временем эта практика распространилась по всей индустрии. Собственные варианты используют LinkedIn, Meta, Shopify, Instacart и OpenAI. 

Основная идея проста. «Жёлтый код» — это официальное признание того, что возникла серьёзная проблема, которая уже сейчас требует сосредоточенной работы специалистов из разных подразделений, пока ситуация не стала катастрофической. «Красный код» — следующий уровень: угроза существованию бизнеса, из-за которой все остальные работы останавливаются до устранения проблемы.

Вот чем эти режимы отличаются друг от друга по основным параметрам. 

Настоящая сила этих режимов в том, что они создают общий язык внутри компании. Когда все понимают, что означает «жёлтый код», не приходится отдельно объяснять серьёзность ситуации, договариваться о приоритетах или убеждать людей переключиться на проблему: термин уже говорит сам за себя.

Сравните это с фразами вроде «нас серьёзно беспокоит доступность» или «это должно стать главным приоритетом». Они настолько расплывчаты, что их легко проигнорировать. Кроме того, другие подразделения, например продуктовая команда, могут начать доказывать, что их задачи важнее.

Как сформулировала SRE-команда LinkedIn, цель состоит в том, чтобы вывести команду «из реактивного режима, в котором она постоянно перебегает от одного кризиса к другому, и перевести её в проактивный режим работы». Именно так всё ощущалось и для нас. Об этом и пойдёт речь в следующем разделе.

Теперь подробнее разберём, как проходил Code Yellow у нас.

Поводом стал не один конкретный инцидент, а повторяющийся паттерн. Как я уже писал в начале статьи, во второй половине 2025 года у нас произошло несколько сбоев, причины которых было мучительно трудно диагностировать. Сама эта сложность уже была тревожным сигналом: она указывала не на отдельные баги, а на более глубокие проблемы в инфраструктуре.

Когда в октябре произошёл сбой AWS, клиенты восприняли его как нашу проблему, потому что месяцы нестабильной работы уже приучили их считать, что и на этот раз во всём виноваты мы.

Руководство компании пришло к выводу, что нужны более решительные меры, и CEO одобрил инициативу. Я письменно объявил о ней всей компании. Поскольку это был наш первый «жёлтый код», в сообщении мы объяснили не только детали, но и саму концепцию: чего хотим добиться, сколько времени это займёт, каковы критерии завершения и почему действовать нужно именно сейчас.

Формулировка была намеренно прямой: показатели доступности ухудшаются, мы теряем доверие клиентов, и нужно вмешаться сейчас, пока ситуация не переросла в «красный код».

Первая неделя выдалась напряжённой и хаотичной: ежедневные стендапы, ежедневные встречи оперативного штаба и полный аудит мониторинга, замеров производительности, логов и оповещений.

Объём необходимых исправлений оказался больше, чем мы ожидали. Даже расстановка приоритетов внутри самого Code Yellow вызвала серьёзные споры. При этом мы обнаружили на удивление много простых и быстро реализуемых улучшений, например добавили дополнительные тайм-ауты и паттерны Circuit Breaker. Эти быстрые результаты помогли с самого начала набрать темп.

Когда срочные исправления уступили место более долгосрочной работе с инфраструктурой — переносу сервисов на более подходящие технологии и переработке архитектуры ради устойчивости, — ритм постепенно замедлился: сначала мы встречались ежедневно, затем дважды в неделю, а потом раз в неделю.

Мы решили пройти по стеку системы снизу вверх. Начали с баз данных и всего, что с ними связано: анализировали паттерны доступа к данным и вызовы API, а затем поднимались выше по стеку и разбирались с ограничением частоты запросов. Кто вызывает наш API? Какие медленные запросы у нас есть? Какими должны быть тайм-ауты на разных уровнях системы с учётом полученных данных?

Одновременно мы двигались и снаружи внутрь: изучали мониторинг и оповещения, находили пробелы и устраняли их.

Всё это время мы публиковали асинхронные обновления статуса в открытом Slack-канале. Мы намеренно делились информацией с избытком, чтобы любой сотрудник компании мог в точности видеть, что происходит. Письменные отчёты выходили примерно с той же периодичностью, что и встречи.

Эта прозрачность, а также близость к реальной работе и её видимость для всей компании стали одной из самых ценных частей всего процесса.

Одно из сильных организационных решений в Code Yellow — так называемое право напрямую привлекать специалистов. Если какой-то endpoint особенно медленно работал для наших крупнейших клиентов, любой участник Code Yellow мог обратиться к команде, отвечавшей за эту область, и потребовать немедленно изменить приоритеты, чтобы ускорить его.

Такие полномочия работают только тогда, когда вся компания понимает и поддерживает режим эскалации. Именно поэтому так важно было заранее объяснить саму концепцию и правильно выстроить коммуникацию.

В нашем случае убедить людей отложить работу по продуктовой дорожной карте оказалось на удивление легко, хотя я понимаю, что во многом это объяснялось обстоятельствами. В компании нашего размера нестабильность ощущали все, а после сбоя AWS никто не сомневался, что её устранение должно стать приоритетом номер один. В конце концов, между стабильностью продукта и удовлетворённостью клиентов есть прямая связь.

Полагаю, в крупных организациях менять приоритеты сложнее, потому что последствия проблемы распределяются неравномерно. Если это ваш случай, коммуникация становится ещё важнее: формулировка проблемы должна наглядно показывать её влияние на всю компанию, а поддержка и официальное одобрение руководства критически необходимы.

Если вы руководитель, но не можете самостоятельно менять приоритеты, принесите данные вышестоящему руководству и попросите его публично принять решение. Худший вариант — тихий, неофициальный «жёлтый код», расходы на который несёт ваша команда без поддержки всей организации. 

Чтобы вы представляли масштаб работы: мы доработали и ужесточили ограничение частоты запросов, исправили тайм-ауты базы данных, добавили Circuit Breaker, отказались от Redis там, где он становился узким местом, а также нашли и устранили утечки памяти в фоновых задачах. Мы начали измерять производительность всех вызовов API с разбивкой по командам и установили предельное время ответа, которое команды должны были выдерживать. С каждой неделей этот предел становился строже.

Мы перенесли инструменты управления инцидентами и заново обучили всех более строгому процессу работы с инцидентами. И это лишь малая часть проделанной работы.

Когда мы достигли цели — восемь недель с фактически стопроцентной доступностью по данным нашего мониторинга, — ощущения были невероятными. О результате сообщали поэтапно: сначала инженерной команде, затем всей компании, а после выпустили намеренно нетехническое объявление для клиентов.

Если бы мне пришлось повторить этот опыт, я бы действовал ещё интенсивнее в первые две-три недели. Именно на этот первоначальный рывок пришлась основная часть работы, и дополнительное ускорение на старте, пока все были заряжены, позволило бы быстрее нарастить результат.

Как превратить наш опыт в универсальный подход? Неважно, с чем вы столкнулись: проблемами надёжности, сложностями масштабирования или техническим долгом, который достиг критического уровня. Базовая схема остаётся той же.

Прежде чем объявлять собственный «жёлтый код», нужно подготовить четыре элемента:

Формулирование проблемы. Формулировка должна быть настолько простой, чтобы её мог повторить любой сотрудник компании. «Наша инфраструктура ненадёжна, и клиенты теряют доверие» — понятно. «Нам нужно улучшить показатели соблюдения SLA для сервисов уровня P0» — нет.

Критерии завершения. Они должны быть конкретными, измеримыми и ограниченными по срокам. Определить их нужно до объявления «жёлтого кода». В нашем случае критерием были восемь недель без простоев. Без чётких критериев вы никогда не поймёте, когда работа закончена, и Code Yellow либо растянется навсегда, либо постепенно сойдёт на нет.

Сроки. Установите точную дату начала и предполагаемую дату завершения. Не планируйте Code Yellow дольше чем на квартал: если вам требуется больше трёх месяцев, значит, вы либо задали слишком широкие рамки, либо имеете дело уже с Code Red.

Распределение полномочий. Нужно заранее определить, кто может привлекать людей к работе, кто, кому и как отчитывается о ходе работ, а также кто решает, нужно ли менять границы инициативы. В небольшой компании это может быть прямое право привлекать специалистов. В крупной — эскалация по управленческой цепочке до VP или назначенный руководитель реагирования на инцидент, наделённый полномочиями координировать несколько команд. Конкретный механизм не так важен, как то, чтобы он был явно определён и понятен всем.

Следующий важный элемент — коммуникация. На неё стоит потратить достаточно времени и сделать всё как следует: объявите Code Yellow всей компании, изложите формулировку проблемы, критерии завершения и сроки. Тогда соседние команды будут понимать, что происходит, заранее учтут задержки по другим задачам и смогут подключиться, если потребуется помощь.

Сила Code Yellow — в прозрачности. Это не опциональная часть процесса. Такое сообщение должно появиться как минимум в канале уровня #announcements. Code Yellow, о котором никто за пределами команды не знает, — это просто и без того перегруженная команда, которая начинает работать ещё больше. Хотя смысл подобных инициатив как раз в обратном: облегчить ей задачу за счёт поддержки всей компании.

Есть и культурные предпосылки, которые важнее любого процесса. Не воспринимайте объявление Code Yellow как признание провала. Напротив, это признак того, что организация достаточно зрелая, чтобы вовремя заметить проблему и решительно на неё отреагировать. Если за раннюю эскалацию наказывают, а не поощряют, люди будут её избегать. И к тому моменту, когда кто-то наконец поднимет тревогу, вы уже окажетесь в режиме «красного кода».

Итак, у вас есть терминология и шаблон. Но самое сложное — не провести Code Yellow, а понять, когда его объявлять и, что ещё труднее, когда заканчивать.

Среди распространённых ранних сигналов — усталость от оповещений (alert fatigue), из-за которой команды перестают справляться с потоком алертов, технический долг, достигший критического уровня, устойчивое ухудшение ключевых метрик и инциденты, которые накапливаются быстрее, чем вы успеваете их устранять. Ищите не единичный громкий сбой, а постепенно нарастающую проблему. Как отмечала SRE-команда LinkedIn, Code Yellow обычно становится следствием «растущего технического долга, множества мелких проблем или сбоев в процессах», а не одного драматического отказа.

Если вы ждёте такого отказа, значит, вы уже прождали слишком долго.

Переходить к Code Red нужно, когда под угрозой оказывается основной бизнес: влияние на клиентов становится серьёзным и продолжает расширяться, появляется угроза существованию компании со стороны конкурентов или происходит фундаментальный отказ системы. Известный пример — Google, объявивший Code Red после запуска ChatGPT в декабре 2022 года. Тогда компания перераспределила команды по всей организации, чтобы ускорить развитие собственных ИИ-технологий, которые впоследствии легли в основу Gemini. Именно о таком уровне серьёзности идёт речь: это угроза существованию бизнеса, а не просто неудобство.

Завершение Code Yellow требует дисциплины: режим заканчивается только после выполнения критериев завершения. «Мы вымотались» — не причина снижать уровень реагирования. Как и «кажется, стало лучше». Именно поэтому измеримые критерии определяют заранее.

Когда критерии выполнены, проведите ретроспективу без поиска виноватых, сообщите о завершении всей компании, осознанно возобновите приостановленную работу и проверьте состояние команды. Такой рывок неизбежно отнимает силы, и важно это признать.

Особенно важно, чтобы ретроспектива Code Yellow привела к системным изменениям, а не просто зафиксировала произошедшее. Если после Code Yellow ничего не изменилось в расстановке приоритетов, поддержке мониторинга или порядке эскалации ранних сигналов, значит, вы устранили симптом, но не причину.

Цель — не просто пережить текущий Code Yellow, а снизить вероятность следующего.

Наконец, следите за такими типовыми сценариями провала:

Чрезмерное использование. Если объявлять Code Yellow слишком часто, сигнал потеряет силу: любая эскалация превратится в информационный шум, и люди перестанут воспринимать её всерьёз.

Показная эскалация. Это происходит, когда оперативные штабы превращаются в театр: много заметной активности, впечатляющие дашборды, но никаких реальных изменений в приоритетах или подходе. Если во время Code Yellow вы работаете так же, как и раньше, никакой эскалации на самом деле не произошло.

Неспособность завершить эскалацию. Code Yellow, который никак не заканчивается, превращается в постоянный режим срочности, а тот уже ничем не отличается от обычной работы. Если выйти из этого режима не получается, значит, критерии завершения были выбраны неправильно.

Соблазн пойти по пути быстрых обходных решений. Наращивать технический долг ради завершения Code Yellow — значит полностью обесценить всю инициативу. Через несколько месяцев вы снова окажетесь в таком же режиме, только теперь придётся выбираться из ещё более глубокой долговой ямы.

Что можно сделать на практике, опираясь на эту статью:

Подготовьте собственный протокол эскалации. Даже если Code Yellow сейчас не нужен, готовая схема избавит вас от необходимости придумывать её уже во время кризиса. Определите, что в вашей организации служит основанием для «жёлтого», а что — для «красного кода», кто имеет право их объявлять и как будет устроена коммуникация.

Проанализируйте последний кризис. Вспомните недавнюю ситуацию, когда ваша команда отложила все дела ради устранения проблемы. Была ли у неё чёткая формулировка, критерии завершения и определённые сроки? Что изменилось бы, если бы вы официально оформили эту работу как Code Yellow?

Обсудите общую терминологию. Познакомьте команду или руководство с этой концепцией. Ценность терминов Code Yellow и Code Red в том, что они упаковывают большой объём смысла всего в два слова. Даже если вы никогда не станете использовать их официально, общее понимание уровней эскалации поможет легче пройти следующий кризис.

Code Yellow работает, когда у него есть понятная структура и чёткие критерии завершения, а команды получают и самостоятельность, и право сосредоточиться на проблеме. Это грубый, но действенный инструмент. Как выразился один из инженерных руководителей Instacart: «Code Yellow — это тяжело. Он подрывает моральный дух команды и оставляет неприятный осадок у всех участников. Но при этом именно он оказался самым эффективным и стабильно работающим инструментом, который помогал нам добиваться реального прогресса в решении самых сложных и неприятных проблем».

Это полностью совпадает с моим опытом. Проведение Code Yellow в Provet вымотало нас, но результат — настоящая уверенность в инфраструктуре после нескольких месяцев тревоги — стоил каждой потраченной минуты.

Главное — относиться к такому режиму как к исключению, подтверждающему правило: это структурированное и временное отступление от обычной работы, а не постоянное состояние кризиса.

Инженерные кризисы часто упираются не только в технологии, но и в то, как внутри команды распределены ответственность, решения и коммуникация. Разобрать подробнее эти управленческие задачи можно будет в сентябре на бесплатных уроках от преподавателей курсов — посмотреть на подходы к делегированию и сложным разговорам, задать вопросы и заодно познакомиться с форматом обучения. Присоединяйтесь:

• 9 сентября в 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться

• 16 сентября в 20:00. «Сложные разговоры в команде: как давать обратную связь без эскалации». Записаться

Полный список бесплатных уроков августа смотрите в дайджесте.