Все компоненты зелёные, а продакшн недоступен: как авария обнаружилась в истории изменений
Иногда самая сложная авария начинается не с красных графиков и массовых ошибок, а с почти идеальной картины наблюдаемости. Метрики базы данных в норме, сервисы отвечают, облачная платформа не фиксирует проблем, а пользователи всё равно не могут работать. Именно такой случай произошёл во время миграции крупного проекта с аудиторией более миллиона пользователей в день.
Инфраструктура была описана кодом почти полностью, а мониторинг охватывал все основные компоненты. Но продакшн оказался недоступен примерно на двадцать минут. Первые пятнадцать минут команда пыталась найти неисправный компонент, хотя проблема находилась не внутри отдельных систем, а на стыке между ними. Подробный разбор аварии и выводы из неё собраны в материале о сбое, который обнаружился в истории изменений: разбор аварии в продакшене.
События произошли больше шести лет назад. Рабочие записи, дашборды и точный протокол инцидента не сохранились, поэтому приведённые значения следует воспринимать как порядок величин. При этом механизм сбоя, последовательность действий и корневая причина восстановлены достаточно точно: именно этот инцидент привёл к пересмотру подходов к миграции и эксплуатации.
Симптом, который легко принять за случайный сбой
Авария случилась в обычный рабочий день. Не было релиза, рекламной кампании, резкого роста нагрузки или других очевидных факторов риска. Сначала сработал алерт по доле ошибок одного из сервисов. Пользователи увидели сообщения об ошибках, но проблема проявлялась не во всех запросах.
Примерно треть обращений завершалась неудачей, затем доля отказов постепенно выросла примерно до двух третей. Причина такой динамики заключалась в пятиминутном кеше. Данные, уже находившиеся в кеше, сервис отдавал без обращения к базе. Запросы, для которых требовалось получить свежую информацию, завершались ошибкой. По мере истечения TTL кеш переставал сглаживать проблему, и процент неудачных операций увеличивался.
Кеш одновременно отсрочил полный отказ и усложнил диагностику. При абсолютной недоступности сервиса ситуация очевидна: все запросы падают. Частичная деградация выглядит гораздо менее определённо - система то работает, то нет, а первые минуты команда тратит на выяснение, действительно ли началась авария.
Почему обычные дашборды не помогли
Проверка компонентов по отдельности давала исключительно положительные результаты:
- задержка базы данных на уровне p99 составляла единицы миллисекунд;
- число соединений оставалось ниже половины установленного лимита;
- загрузка процессора была около 10%;
- отставание репликации отсутствовало;
- медленные запросы не обнаруживались;
- соседние базы на том же сервере работали без ошибок;
- процессы проблемного сервиса были запущены, память не заканчивалась, рестартов не происходило;
- облачный провайдер показывал штатный статус.
Это типичная ситуация для сложных систем: каждый узел исправен, но цепочка взаимодействия между ними разрушена. Дашборды не были плохими - они просто отвечали на другой вопрос. Они показывали состояние отдельных компонентов, но не подтверждали, что сервис действительно может обратиться к нужной базе по нужному маршруту.
Первые минуты ушли на последовательную проверку базы, приложения, ресурсов и облачной платформы. Каждый "зелёный" результат создавал ложное ощущение, что подозреваемый компонент исключён. На практике это лишь уводило расследование дальше от причины, потому что команда анализировала узлы, а не зависимости между ними.
Миграция, о которой не было единой картины
Главной организационной проблемой оказалось отсутствие точной схемы размещения. В это время шёл переезд инфраструктуры в новое облако, и сведения о том, какие сервисы в каких локациях обслуживают пользователей, находились преимущественно в головах инженеров.
В первые дни миграции такая ситуация кажется временной и терпимой. Но во время аварии она превращается в отдельный фактор риска. Никто не держал перед глазами актуальную карту: сервис находился в одной локации, а его база данных - в другой. Между площадками возникла проблема связности, однако обе стороны продолжали выглядеть исправными.
Именно поэтому гипотеза о межлокационном взаимодействии появилась не сразу. Команда сначала проверила соседние базы, затем ресурсы сервиса, параметры подключения и состояние провайдера. Лишь после сопоставления размещения компонентов стало ясно: база работала, приложение работало, но они не могли нормально взаимодействовать.
Это важный класс проблем для любой инфраструктуры как кода. Описание ресурсов в репозиториях ещё не гарантирует, что инженеры видят актуальную топологию и понимают реальные зависимости. Код может быть корректным, а эксплуатационная модель - неполной.
Корневая причина и последствия
Во время миграции сервис и его база оказались в разных локациях без гарантированной связности между ними. Никакой компонент не вышел из строя в привычном смысле. База принимала запросы от доступных ей клиентов, приложение продолжало работать, облачная платформа не фиксировала общей аварии. Нарушилась именно связь между частями системы.
После обнаружения проблемы маршрут восстановили, и сервис постепенно вернулся в штатное состояние. Кеш объясняет, почему сбой развивался не мгновенно, а нарастал по мере истечения времени жизни данных. За это время пользователи столкнулись с ошибками, а команда потеряла значительную часть периода простоя на проверки, которые не могли показать межкомпонентную зависимость.
Подобные инциденты хорошо демонстрируют ограничения традиционного подхода к наблюдаемости. Мониторинг production должен измерять не только CPU, память, задержки и ошибки отдельных приложений, но и реальные пользовательские сценарии: может ли сервис выполнить критический запрос, получить данные из нужного хранилища и завершить операцию через фактический сетевой маршрут.
Что изменили после инцидента
Первым решением стала фиксация топологии в явном виде. Для каждого сервиса должны быть понятны его размещение, зависимости, точки отказа и допустимые маршруты между компонентами. Такая информация не должна оставаться только в документации, которая быстро устаревает, или в памяти отдельных специалистов.
Второе направление - автоматические проверки связности. Если приложение расположено в одной зоне, а база в другой, система должна регулярно проверять доступность именно с точки зрения реального клиента. Проверка "порт открыт" недостаточна: полезнее выполнять синтетический запрос, который проходит весь критический путь.
Третье - развитие практик эксплуатации. DevOps практики эффективны не тогда, когда команда просто хранит Terraform или Ansible в Git, а когда изменения инфраструктуры связаны с тестами, политиками, картой зависимостей и понятным процессом отката. История изменений способна объяснить аварию, но только если команда регулярно анализирует её до возникновения проблем.
Не менее важен разбор аварий в продакшене без поиска виноватых. Нужно выяснять, какой сигнал оказался недоступен, какая гипотеза появилась слишком поздно и почему система позволила разместить связанные компоненты несовместимым образом. Такой подход повышает надежность IT-инфраструктуры системно, а не за счёт разовых исправлений.
Что проверить в первые пять минут
Если все графики зелёные, но пользователи получают ошибки, стоит быстро пройти несколько пунктов:
1. Проверить реальный пользовательский сценарий, а не только доступность отдельных сервисов.
2. Сопоставить долю ошибок с TTL кешей и временем обновления данных.
3. Уточнить фактическое размещение приложения, базы, очередей и внешних зависимостей.
4. Проверить сетевые маршруты между локациями, зонами и сегментами.
5. Сравнить состояние компонентов с их связями: кто именно к кому обращается и по какому адресу.
6. Посмотреть последние изменения инфраструктуры, маршрутизации, DNS, правил доступа и балансировки.
7. Проверить, не маскирует ли проблему один из резервных путей или локальных кешей.
Главный вывод этой истории прост: зелёные метрики компонентов не означают работоспособность системы. Надёжность определяется не только исправностью узлов, но и тем, могут ли они взаимодействовать в нужной последовательности. Иногда самый полезный диагностический инструмент - не очередной дашборд, а история изменений и актуальная карта зависимостей. Именно там может находиться ответ на вопрос, почему вся инфраструктура выглядит здоровой, а продакшн уже лежит.
