Круглосуточное сопровождение критичных систем: L1-L3 и runbook

Почему инциденты «зависают» в 24/7 поддержке

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

Чаще всего круглосуточная поддержка ломается не из-за «плохих специалистов», а из-за пробелов в организации. Дежурный видит алерт, но не уверен, его ли это зона. Контакты устарели, нужный человек не отвечает, а резервный не назначен. Или алертов так много, что важный тонет в шуме, и команда привыкает «проверять потом».

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

Почти все, что спасает ночью, готовится заранее, а не решается «по ситуации». Нужны: один ответственный за инцидент в каждый момент времени и правило назначения; разделение ролей L1/L2/L3 с границами ответственности; тайминги реакции и эскалации; актуальные контакты и резервные каналы связи; критерии закрытия и обязательные записи по итогам.

Простой пример: ночью падает часть виртуальной инфраструктуры на сервере. Если L1 не знает, где смотреть метрики и кому звонить, он тратит 30 минут на «поиск ответственного». С четкими ролями и инструкциями эти 30 минут превращаются в 3: подтвердил симптом, выполнил первые шаги, эскалировал по таймеру и держит связь с владельцем до восстановления.

Критичность, приоритеты и понятные цели по времени

Если у поддержки нет общего ответа на вопрос «насколько это срочно?», инциденты начинают «висеть» между сменами. Сначала договоритесь о списке критичных сервисов и их частей: приложение, сеть, серверы, хранилище, интеграции, доступ (AD/SSO), резервное копирование. Фиксируйте не только названия систем, но и что именно считается «работает/не работает».

Отдельно разведите понятия:

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

Запрос - «сделайте/добавьте/поменяйте» без аварии.

Задача - плановое изменение (обновление, миграция, настройка).

Когда это записано в одном месте, L1 не тратит ночь на «почините принтер», а L3 не отвлекается на доступ к папке.

Простые правила приоритета (P1-P4)

Приоритет лучше определять влиянием и срочностью, а не громкостью чата:

• P1: сервис недоступен для многих или есть угроза данных/безопасности.
• P2: сильная деградация, есть обходной путь, но бизнес страдает.
• P3: частичный сбой для небольшой группы, риск низкий.
• P4: единичная проблема, консультация, «не срочно».

Чтобы поддержка была управляемой, задайте цели по времени не только на «восстановить», но и на «держать в курсе».

Цели по времени: реакция, восстановление, статус

Набор, который реально выдерживать в дежурстве:

• время первой реакции (взяли в работу)
• время до эскалации, если нет прогресса
• целевое время восстановления
• периодичность обновления статуса для P1/P2
• время на закрытие и короткую заметку (что было сделано)

Кто утверждает и меняет правила: владелец сервиса (бизнес или ИТ) задает критичность и SLA, руководитель поддержки отвечает за процесс, изменения проходят через короткое согласование (например, раз в квартал или после крупных инцидентов). Так приоритеты не «плавают», и решения L1/L2/L3 выглядят одинаково в 02:00 и днем.

Как разделить роли L1, L2 и L3 без конфликтов

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

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

L2 подключается, когда нужна более глубокая диагностика и действия в конфигурациях: перезапуск компонентов, переключение на резерв, откат параметров, работа с инфраструктурой и смежными командами. Часто L2 решает проблему без разработки, но отвечает за технический план восстановления.

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

Чтобы не спорить, кто что должен, закрепите границы:

• L1 ведет инцидент до закрытия: таймлайн, статусы, протокол.
• L2 отвечает за восстановление, если нужны изменения в настройках и инфраструктуре.
• L3 отвечает за первопричину и долговременное исправление.
• Любое изменение в проде имеет явного исполнителя и того, кто согласовал.
• Эскалация запускается по таймеру: если шаг не дал результата, уровень повышается.

Полезно оформить мини-матрицу ответственности (RACI) для типовых работ: кто принимает решение (A), кто исполняет (R), кого консультируют (C), кого информируют (I). Например, статус для руководства: A у L1, C у L2, I у L3; изменение конфигурации: A и R у L2, C у L3, I у L1.

Дежурства: графики, передача смены и резервирование

Покрытие 24/7 можно организовать по-разному, и выбор влияет на скорость реакции и усталость команды. Для действительно критичных систем чаще всего работают смены (например, 2/2 или 12/12), когда человек всегда у консоли. On-call дешевле, но рискованнее там, где каждая минута простоя дорого стоит. Частый компромисс: L1 в смене, L2-L3 по on-call для редких, но сложных случаев.

Чтобы дежурный не начинал с «не знаю, что делать», у него с первой минуты должны быть доступы, инструменты и контакты. По минимуму: права, достаточные для диагностики и безопасных действий; мониторинг, логи, удаленный доступ и шаблоны сообщений; список дежурных L2/L3 и владельца сервиса; резервный канал связи, если корпоративный мессенджер недоступен; понятные рамки полномочий.

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

Резервирование должно быть формальным: дублер на каждую смену, понятное время на ответ (например, 5-10 минут) и порядок замены. Заранее решите, кто подтверждает замену и где это фиксируется, чтобы не возникло «я думал, что ты на связи».

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

Эскалации: правила, тайминги и каналы связи

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

Лестница и таймеры: когда повышать уровень

Лестница обычно такая: L1 фиксирует и стабилизирует, L2 разбирается глубже и делает изменения в пределах регламентов, L3 подключается, когда нужен доступ к коду, архитектуре или вендору. Заранее опишите признаки, которые переводят инцидент выше: нет прогресса, нужен доступ, растет риск для данных, затронуто несколько систем.

Чтобы не спорить «еще пять минут», задайте таймеры по приоритетам. Пример:

• P1 (остановка сервиса): эскалация L1 -> L2 через 10 минут без понятного плана, L2 -> L3 через 20 минут без восстановления.
• P2 (сильная деградация): L1 -> L2 через 20 минут, L2 -> L3 через 40 минут.
• Любой приоритет: эскалация сразу, если есть признаки инцидента безопасности.

Каналы связи и шаблон сообщения

Определите основной и запасной канал. Например: основной - чат и звонок дежурному, запасной - SMS или второй мессенджер. Отдельно пропишите, что делать при недоступности канала: кто звонит, сколько попыток, через сколько минут подключать руководителя смены.

Сообщение для эскалации должно экономить время. Достаточно пяти пунктов: что сломалось и с какого времени (симптомы, затронутые сервисы); приоритет и влияние на бизнес; что уже сделали и что получилось; что нужно от адресата; где вы на связи.

Разведите эскалации по направлениям: инфраструктура (сеть, серверы, виртуализация), безопасность (подозрительная активность, учетные записи), бизнес (останавливаем операции, включаем ручной режим). Если ночью в больнице или банке падает сервис, L1 параллельно поднимает L2 по инфраструктуре и уведомляет бизнес-ответственного о возможной остановке операций, не дожидаясь «идеального диагноза».

Runbook: как оформить инструкции, которые реально работают ночью

Инструкция (runbook) полезна только тогда, когда по ней можно действовать в 03:00 без догадок. Это страховка от зависших инцидентов и разного понимания «что делать дальше».

Хороший runbook начинается не с длинного описания сервиса, а с узнаваемых симптомов и быстрых проверок: «алерт по недоступности приложения», «диск на сервере почти заполнен», «ошибка авторизации у пользователей». Дальше - короткие безопасные шаги для L1 и четкие условия, когда нужно эскалировать.

Минимальный шаблон, который работает

Держите структуру постоянной, чтобы ночью не искать глазами нужное:

• симптомы и что считается инцидентом (1-2 строки)
• быстрые проверки (5-10 минут) и ожидаемый результат
• действия по устранению: шаги по одному, с критериями успеха
• откат: как вернуть состояние назад, если стало хуже
• эскалация: кого и с чем будить (логи, метрики, время начала)

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

Границы ответственности и безопасность

Runbook должен отвечать на вопрос «что можно без согласования». Четко разделите: что разрешено (например, перезапуск сервиса по кнопке или скрипту, сбор логов, переключение на резерв по инструкции) и что запрещено без L2/L3 (изменения конфигов, ручные правки в базе, отключение защит, удаление данных). Любое действие фиксируйте: время, что сделали, как изменились симптомы.

Храните runbook там, где он доступен дежурным: единое место, поиск, права на чтение. У документа должны быть владелец, версия, дата и план пересмотра (например, раз в квартал или после каждого крупного инцидента). Если вы поддерживаете парк рабочих станций и серверов, особенно важно обновлять инструкции после замены модели, прошивки или схемы резервирования, иначе ночные шаги быстро устаревают.

Оповещения: как настроить алерты, чтобы их читали

В 24/7 поддержке алерт должен помогать принять решение за минуту, а не создавать еще один поток тревоги. Правило простое: каждый сигнал либо ведет к действию, либо не должен существовать.

Сначала определите, что именно алертить. Обычно хватает пяти зон: влияние на пользователей (недоступность, рост ошибок, деградация ответа); ошибки приложения (повторы, всплески, критичные исключения); ресурсы (CPU, память, диск, но только когда это реально грозит остановкой); доступность зависимостей (БД, внешние API, балансировщики, сеть); очереди и фоновые задачи (рост очереди, лаг, застой).

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

Маршрутизация должна быть предсказуемой: по сервису (кто владелец), по приоритету (P1, P2) и по уровню (L1 проверяет базовые вещи, L2 углубляется, L3 подключается, когда нужны изменения в коде или архитектуре). Заранее решите, какой алерт будит ночью, а какой ждет утра.

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

Текст алерта должен отвечать на вопросы: что произошло и насколько срочно; где именно (сервис, окружение, узел); как быстро проверить гипотезу (1-2 шага); что делать прямо сейчас; где искать инструкцию (название runbook и шаг).

Пример формулировки: «P1: API billing 5xx > 10% за 5 мин, prod, pod-3. Проверка: статус БД, последние деплои. Действие: перевести трафик на резерв, открыть runbook Billing-API, шаг 2».

Пошаговый процесс от алерта до закрытия инцидента

Чтобы инциденты не «зависали», важнее всего один и тот же маршрут для каждого случая. У инцидента должен быть один вход и один владелец.

Сначала закрепите единый канал, куда падают алерты и обращения (например, сервис-деск или общий инцидент-чат), и назначьте дежурного владельца смены. Он принимает событие, заводит запись, дает номер, проверяет, что это не дубликат, и сразу определяет первичного исполнителя. Параллельно задайте правило времени первого ответа (например, 5-10 минут для P1), чтобы было ясно, когда поднимать следующего по цепочке.

Дальше исполнитель действует по runbook: собирает факты и делает первые безопасные шаги. Полезно заранее договориться, что считается обязательными данными: точное время начала и симптом; влияние на пользователей и сервисы; метрики и логи, которые подтверждают проблему; последние изменения (релиз, конфиг, обновления); что уже пробовали и какой результат.

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

Пока идет работа, обновляйте статус по расписанию (например, каждые 15-30 минут для P1). Закрывайте инцидент только с итогом: что было, что сделали, чем подтверждено восстановление, и какая причина (даже если пока «предварительная»).

После инцидента в течение 1-2 дней зафиксируйте изменения: что правим в алертах (порог, шум, маршрутизация), что дописываем в runbook, какие задачи ставим, чтобы случай не повторился. Если сбой случился на серверной стойке, часто выясняется, что мониторинг не показывал деградацию дисков заранее - это прямой кандидат на доработку.

Частые ошибки в 24/7 сопровождении и как их избежать

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

Одна из самых дорогих ошибок - у дежурного нет нужных доступов. В 02:15 он вместо действий начинает «просить в чате» доступ к логам, консоли, мониторингу или перезапуску сервиса. Время уходит, SLA горит, а виноватых потом ищут долго. Решение практичное: заранее оформить минимально достаточные права для L1, а для рискованных действий (например, перезагрузка узла) - быстрый и понятный путь эскалации с подтверждением.

Вторая частая проблема - нет владельца инцидента. Участников много, сообщений много, но никто не ведет таймлайн, не фиксирует решения и не закрывает хвосты. Назначайте Incident Owner сразу при подтверждении инцидента (часто это L1) и держите роль неизменной до закрытия.

Эскалации тоже часто настроены «по ощущениям». Слишком ранняя эскалация выматывает L2/L3 и рождает конфликты. Слишком поздняя приводит к простоям. Помогает правило: эскалировать по времени и условиям (нет прогресса, нет данных, растут риски), а не по уровню тревоги.

Типовые провалы и что делать:

• нет доступов у дежурного - заранее выдать роли и проверить их на учебном инциденте
• нет владельца инцидента - фиксировать Incident Owner и канал связи с первой минуты
• эскалации без таймингов - задать пороги (например, 10-15 минут без прогресса) и критерии передачи
• runbook «для галочки» - раз в месяц проходить по нему реальные шаги и обновлять после изменений
• алерт без контекста - добавлять «что это значит» и первые 2-3 действия прямо в уведомление

Без постинцидентных действий сбои повторяются. После закрытия достаточно ответить на три вопроса: что сломалось, почему не поймали раньше, что меняем (алерты, runbook, доступы).

Пример сценария: ночной сбой и работа L1-L3 по правилам

02:13 ночи. Падает критичный сервис обработки операций: пользователи видят ошибку и не могут завершить действие. Мониторинг поднимает алерт «ошибка 5xx выше порога 3 минуты» и звонит дежурному.

L1 отвечает за первые 10-15 минут. Он подтверждает, что алерт не ложный: проверяет дашборд, пробует выполнить типовую операцию, смотрит, затронут ли один регион или все. Дальше он открывает инцидент, фиксирует время начала, сохраняет ключевые факты и запускает первые шаги runbook: безопасный перезапуск компонента, проверка доступности зависимости (например, базы или очереди), сверка с последним известным «нормальным» состоянием.

Через 7 минут понятно, что быстрые шаги не помогли, и L1 эскалирует на L2 по правилу: «если нет улучшения за 10 минут, поднимать второй уровень». L2 проверяет недавние изменения: выкатки, конфиги, сертификаты, лимиты. Находит, что после планового изменения конфигурации выросло время ответа зависимости. L2 откатывает конфигурацию на последнюю стабильную версию и восстанавливает зависимость. Ошибки снижаются, сервис возвращается.

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

Таймлайн фиксируют коротко:

• 02:13 алерт, подтверждение проблемы
• 02:18 инцидент открыт, начаты шаги runbook
• 02:23 эскалация на L2
• 02:31 откат, восстановление сервиса
• 02:45 сервис стабилен, мониторинг в норме

После инцидента в разбор попадает: что сломалось, почему, как обнаружили, сколько длилось, что сработало, что нет. Обновляют алерты (например, добавить сигнал по деградации зависимости до 5xx) и runbook (явный шаг «проверить последние изменения и откатить по шаблону»), чтобы в следующий раз L1 не тратил время на догадки.

Короткий чеклист и следующие шаги для внедрения

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

Убедитесь, что при каждом алерте команда действует одинаково:

• назначен владелец инцидента (один человек ведет до закрытия, даже если задачи уходят на L2/L3)
• зафиксирован приоритет и цель по времени (когда должны начаться работы и когда обязана сработать эскалация)
• таймер эскалации запускается сразу при регистрации
• понятно, где общаться (один основной канал) и что делать, если он недоступен (запасной)
• дежурный и дублер определены заранее, передача смены фиксируется коротко и одинаково

Дальше проверьте runbook для критичных сервисов. Ночной дежурный должен открыть документ и за минуту понять: что сломалось, как подтвердить симптом, как безопасно откатить, и кому звонить. Минимум для каждого сервиса: первые 3-5 шагов диагностики, критерий «это уже L2/L3», контакт владельца и список типовых рисков (например, что нельзя перезапускать без согласования).

С алертами логика простая: каждый сигнал должен иметь смысл и маршрут. Если оповещения дублируются или приходят «на всякий случай», их перестают читать. Начните с 10-20 самых важных сигналов и доведите их до состояния «увидел - понял - сделал».

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

Если нужна помощь с организацией 24/7 поддержки и интеграцией инфраструктуры, в GSE.kz можно опереться не только на практику сопровождения, но и на опыт системной интеграции для организаций с высокими требованиями к доступности (включая серверы и рабочие станции).