AlertOps: Как вовремя поймать IT-катастрофу

Рассказываем про автоматизацию управления инцидентами. Как избежать потерь и сохранить репутацию компании

Инциденты в IT — это неизбежность. Если что-то может сломаться, оно обязательно сломается. Вопрос только в том, как быстро и эффективно мы на это отреагируем.

Например, в реаниматологии есть понятие золотого часа — критического промежутка времени, когда от скорости решения зависит жизнь пострадавших. В 2009 году экипаж воздушного судна Airbus A320 на высоте примерно 800 метров столкнулся со стаей птиц, что привело к отказу обоих двигателей. В его распоряжении было три с половиной минуты, чтобы осознать проблему, принять решение, связаться с диспетчерами и посадить самолёт на воду. 155 человек выжили, потому что у пилотов был чёткий алгоритм действий.

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

В IT этот принцип работает аналогично. Да, наши системы не падают с высоты 800 метров, но каждая минута промедления может стоить компании денег, репутации и доверия пользователей.

Поэтому я люблю алерты. Это наш спасательный круг, который позволяет быстро заметить проблему и среагировать до того, как она превратится в катастрофу. Но алерты сами по себе бесполезны, если не настроены правильные процессы:

В этой статье я расскажу вам о том, как мы настроили AlertOps. Это своего рода платформа для автоматизированного управления инцидентами и оповещениями. Она помогает командам быстро обнаруживать проблемы, эскалировать их нужным людям и минимизировать время реакции.

Кто-то вбрасывает вопрос в общий чат на 20–30 человек. Все молчат. Потом один человек отвечает. Он, конечно, молодец, но в следующий раз он просто может не захотеть это сделать. Через какое-то время чат превращается в бесполезный поток сообщений. Коллективная ответственность в IT не работает.

Когда падает система, нужен конкретный человек, который берёт алерт, понимает его и начинает работать. Не «кто-нибудь», не «кто успеет». Чёткое распределение задач — это основа эффективного реагирования.

Мы долго экспериментировали и пришли к правильной структуре эскалации.

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

Не все алерты одинаково важны. Мы выделили четыре уровня:

Что-то можно сказать в чате. Что-то нужно кричать прямо в ухо. Поэтому все каналы связи делятся на назойливые и неназойливые.

Назойливые — это то, что разрывает ваш work-life balance. Представьте: сидите вы вечером в баре или играете с детьми, и тут звонок. Вы всегда обратите на него внимание, даже если не хотите.

Неназойливые — мессенджеры, рабочие чаты. В них уведомление может просто зависнуть без ответа, если оно пришло в неподходящее время.

Disaster и critical должны прийти через звонок и SMS. High и warning можно отдать мессенджеру.

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

Назойливые каналы — для срочного реагирования. Неназойливые — для работы с менее критичными моментами.

Если слать ворнинги звонками, то люди перестанут на них реагировать. А когда придёт реальный критикал, то они просто не поднимут трубку.

Эскалация и критичность — фундамент управления инцидентами. Разберём следующий ключевой момент.

Если вы когда-нибудь просыпались среди ночи от звонка по инциденту, то знаете, что текст алерта должен быть максимально понятным.

Был у нас случай. Человека разбудили звонком. Он сам описывал алерты и сам их внедрял. Когда ему сообщили о проблеме, он ничего не понял. Разговор длился несколько минут, а он повторял: «Что?». Время уходило.

Алерт — это не просто уведомление. Это руководство к действию.

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

Мы вывели формулу идеального описания:

Здесь всё чётко:

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

Однажды мы провели эксперимент — перевели все голосовые оповещения на голосового ассистента.

Первая попытка провалилась. Ассистент пытался озвучить HTML-теги, и это выглядело катастрофически.

Но потом мы настроили систему иначе:

Результаты были разительно лучше.

Мы сделали вывод о том, что алерт должен быть написан так, как говорит живой человек, а не как машина, читающая код.

Теперь - следующий шаг после получения алерта.

Инцидент произошёл. Алерт получен. Теперь важно не растеряться, а собрать команду быстро и без суеты.

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

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

Бывает так, что человек не отвечает. Тогда начинается эскалация. Если реакции нет в течение заданного времени, то подключаются лидер команды, СТО и другие ключевые специалисты. Важные события передаются через назойливые каналы — звонки и SMS, а не мессенджеры, которые легко проигнорировать.

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

Когда всё настроено правильно, команда реагирует без потери времени.

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

Главный принцип: алерт должен вести к действию, а не просто сообщать о проблеме.

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