Наша почта:
В Москве:
РФ (звонок бесплатный):
7 причин аварий ИТ-системы и способы их избежать
{ Пресейл-инженер в wiSLA }
Дмитрий Дякив
Видео доклада
Презентация спикера
7 причин аварий ИТ-системы и способы их избежать
ИТ-аварии происходят внезапно, но почти никогда не являются случайным инцидентом. Это всегда накопленный эффект: напряжение копится днями, неделями, иногда месяцами. Где-то потихоньку отъедается место на диске — и в итоге падает база данных и перестаёт писать сырые метрики. Где-то постепенно растёт лаг репликации — реплика отстаёт от мастера, и при обращении к сервису пользователи видят разные картинки.
В современных реалиях инфраструктура становится всё более сложной и комплексной, завязанной на множество сервисов, в том числе облачных. По сути, это живой организм, за которым нужно постоянно следить. Ниже — четыре реальных кейса из практики, три узнаваемых образа, в которые они складываются, и семь основных причин аварий.
В современных реалиях инфраструктура становится всё более сложной и комплексной, завязанной на множество сервисов, в том числе облачных. По сути, это живой организм, за которым нужно постоянно следить. Ниже — четыре реальных кейса из практики, три узнаваемых образа, в которые они складываются, и семь основных причин аварий.
Кейс 1. Чёрная пятница у крупного ритейлера
Команда инженеров подготовилась к нагрузке: мониторинг настроен, серверы под наблюдением, CPU и база данных — всё зелёное. Пошёл наплыв клиентов, и на пике нагрузки отвалился мастер базы данных. Кластер отработал штатно: реплика стала мастером, бывший мастер начал догонять нового. Формально всё в порядке.
Но клиенты портала видели другую картину: товар добавлялся в корзину, а при оформлении покупки система сообщала, что товара нет. Люди злились и уходили к конкурентам. Расследование заняло три часа — столько же длилась авария.
Выяснилось следующее. В момент пиковых обращений канал провайдера не выдерживал нагрузки, лаг репликации относительно мастера постоянно рос. TCP-запросы продолжали отправляться, несмотря на то что не доходили до адресата, и в итоге забили буфер одного из коммутаторов.
Проблемы бы не было при сквозном мониторинге всего бизнес-процесса: канал для репликации базы данных должен всегда соответствовать требованиям и находиться под наблюдением. Здесь его просто не мониторили.
Но клиенты портала видели другую картину: товар добавлялся в корзину, а при оформлении покупки система сообщала, что товара нет. Люди злились и уходили к конкурентам. Расследование заняло три часа — столько же длилась авария.
Выяснилось следующее. В момент пиковых обращений канал провайдера не выдерживал нагрузки, лаг репликации относительно мастера постоянно рос. TCP-запросы продолжали отправляться, несмотря на то что не доходили до адресата, и в итоге забили буфер одного из коммутаторов.
Проблемы бы не было при сквозном мониторинге всего бизнес-процесса: канал для репликации базы данных должен всегда соответствовать требованиям и находиться под наблюдением. Здесь его просто не мониторили.
Вывод:
если объект или сервис в инфраструктуре не стоит на мониторинге, то для эксплуатации он мёртв.
если объект или сервис в инфраструктуре не стоит на мониторинге, то для эксплуатации он мёртв.
Кейс 2. Банк: система, которая приучила не реагировать
В банке работала старая система мониторинга, настроенная ещё энтузиастами, которые хотели мониторить всё и знать про всё. Система отлавливала любой чих в инфраструктуре и исправно уведомляла дежурного инженера — и в дневные, и в ночные смены.
Инженер, работавший в ночь, неделю за неделей получал шквал алертов, из которых внимания заслуживали в лучшем случае один-два за смену. В один из дней он принял решение поставить телефон на беззвучный режим и немного отдохнуть. По закону Мерфи именно в этот момент произошла реальная авария: отвалился диск, платёжная система встала на 40 минут. Начались звонки от регулирующих органов, следом — внутреннее разбирательство.
Это история не про ленивого инженера и не про безответственный подход. Инженер не саботировал инцидент — система, настроенная неправильно, сама приучила его не обращать внимания на важные события: шёл каскад алертов, внутри которого терялись два-три действительно значимых.
Инженер, работавший в ночь, неделю за неделей получал шквал алертов, из которых внимания заслуживали в лучшем случае один-два за смену. В один из дней он принял решение поставить телефон на беззвучный режим и немного отдохнуть. По закону Мерфи именно в этот момент произошла реальная авария: отвалился диск, платёжная система встала на 40 минут. Начались звонки от регулирующих органов, следом — внутреннее разбирательство.
Это история не про ленивого инженера и не про безответственный подход. Инженер не саботировал инцидент — система, настроенная неправильно, сама приучила его не обращать внимания на важные события: шёл каскад алертов, внутри которого терялись два-три действительно значимых.
Кейс 3. Человеческий фактор: опечатка в конфиге
Стриминговая платформа, вечер пятницы. Клиенты жалуются на задержки. Опытный дежурный инженер принимает решение быстро поправить конфигурацию балансировщика и увеличить тайм-ауты — по сути, правильное решение. Но при правке допускает опечатку в одном из IP-адресов, куда переправляются запросы. В результате 30% трафика уходит в никуда, у пользователей пропадает видео.
Кейс 4. Как автомасштабирование убило систему
В крупном e-commerce для важного приложения было настроено горизонтальное масштабирование. Случилась пиковая нагрузка, алгоритм рассчитал, что нужно добавить 500 подов, и добавил их — формально отработав правильно. Через три минуты легло всё: приложение, базы данных, сеть.
Одновременный каскад новых подов фактически устроил DDoS-атаку на собственную инфраструктуру. Инструмент, призванный защитить систему, убил три её основных элемента:
Одновременный каскад новых подов фактически устроил DDoS-атаку на собственную инфраструктуру. Инструмент, призванный защитить систему, убил три её основных элемента:
- 1.Кластер. Новые поды получали статусы, секреты, конфигурации, эндпоинты — всё это порождало лавину запросов к API кластера. Запросы не получали ответов и начинали зацикливаться.
- 2.Сетевой узел. Каждый под — это отдельное сетевое устройство и новый IP-адрес в таблице маршрутизации. Выросла утилизация CPU, начали отваливаться маршрутизаторы, следом посыпались каналы.
- 3.База данных. Каждый под держал по 10 активных сессий: при 50 подах это 500 подключений, при 500 — 5000. Отказ произошёл не по метрикам производительности, а по лимитам: база перестала принимать новые соединения и фактически прекратила функционировать.
Три образа, в которые складываются эти истории
Кейсы не разрознены — они выстраиваются в одну идеологическую линию. Где-то не хватило прозрачности инфраструктуры, где-то шум убил сигнал, где-то процессы были нарушены ради скорости, где-то не учли ёмкость системы при масштабировании. Эти сюжеты описываются тремя узнаваемыми образами:
- Кот Шрёдингера в эксплуатации.Канал не мониторился — значит, для эксплуатации он мёртв.
- Эффект арбуза.Снаружи все метрики зелёные, а внутри — красные, опасные инциденты. Это история про сквозной мониторинг и прозрачность инфраструктуры.
- Мониторинг, который кричит «Волки!».Доверие к сигналам теряется, глаз замыливается, и в момент реального инцидента реакция запаздывает.
Семь столпов аварии
Финал
Общий рецепт сводится к нескольким пунктам: выстроить правильный сквозной мониторинг, отладить пороги срабатывания, убрать информационный шум и поддерживать систему мониторинга в актуальном состоянии.
Если рассматривать ИТ-инфраструктуру как спортивную команду, то мониторинг — это её тренер: он показывает, где работа идёт правильно, а где нет, даёт рекомендации и позволяет достигать лучших результатов при тех же затратах.
Если рассматривать ИТ-инфраструктуру как спортивную команду, то мониторинг — это её тренер: он показывает, где работа идёт правильно, а где нет, даёт рекомендации и позволяет достигать лучших результатов при тех же затратах.
В Москве:
РФ (звонок бесплатный):
Наша почта:
GetNet
Остались вопросы?
Группа компаний VoxLink © 2011-2026