Мониторинг в DevOps: разработка процесса реагирования на инциденты
Чтобы противодействовать этому, вам понадобится четко определенный процесс реагирования на инциденты.
Что такое инцидент
Инциденты могут принимать разные формы. Хорошей отправной точкой для разработки процесса реагирования станет определение того, что представляет собой инцидент для вашей организации. Определение инцидента выглядит примерно так:
- Он оказывает заметное влияние на клиентов.
- Для решения проблемы вам необходимо привлечь вторую команду.
- Проблема не решена после часа.
Этот список далеко не полный. Возможно, вы захотите исключить некоторые критерии или добавить дополнительные, в зависимости от вашей сферы бизнеса.
Как мы узнаем, что произошел инцидент
Первый шаг в устранении инцидента — понять, что что-то сломалось. О проблемах сообщают вручную (например, через службу поддержки, члену команды или напрямую клиенту) или автоматически с помощью решения для наблюдения, например Grafana или Prometheus. Вашим главным приоритетом должна быть установка системы мониторинга, которая будет как можно скорее оповещать, когда что-то происходит.
После аудита систему мониторинга нужно настроить для наблюдения за конкретными метриками, журналами или другими индикаторами. Она должна отправлять оповещения, когда определенный индикатор нарушает правило.
Например, простое правило оповещения может быть таким: Сообщите нам, если более 0,1% наших HTTP-ответов будут с кодом 500 в течение как минимум пяти минут.
Здесь мы указываем условие с конкретными значениями, отмечаем продолжительность, в течение которой это условие должно выполняться. Цифры необходимы, чтобы избежать нестабильных предупреждений из-за одиночных кратковременных сбоев.
Уровни серьезности
Кого уведомить, если инцидент произошел
Это один из самых сложных вопросов, поскольку он должен учитывать множество аспектов:
- Кто бы мог это исправить?
- Кто доступен?
- Они точно проснулись?
Чтобы вы не думали об этом, когда авария случилась, нужно заранее сгруппировать людей в команды и спланировать расписание для этих команд.
Решение, какая команда сможет справиться с инцидентом, должно быть простым, условно: если вы создавали это, вы его и поддерживаете. В зависимости от вашей организационной структуры это также может быть оперативная группа.
Совет: создайте документ для новых членов команды с указанием критичности и классификации проблем, обязанностей на вызове и окружений, к которым им необходим доступ. Это может существенно помочь в адаптации и избежать казусов при авариях.
Планирование графика
При составлении расписания учитывайте следующее:
- Продолжительность смены: быть на дежурстве в течение нескольких недель очень утомительно, но и 10 часов в сутки также могут стать головной болью.
- Предсказуемость: инженеры захотят заранее спланировать личные дела и должны знать, будут ли они на связи в это время.
- Баланс: это само собой разумеется, но постарайтесь равномерно распределить смены между всеми членами команды.
- Юридические ограничения: в разных странах действуют разные правила относительно того, как долго и как часто кто-то может быть на связи.
Если у вас распределенная команда, возможно, вам стоит рассмотреть возможность ротации по графику, при которой дежурные будут на связи только в обычные рабочие часы. Для небольших, географически централизованных команд, хорошей практикой станет еженедельная ротация.
Хотите, чтобы мы взяли вас на техподдержку 24/7?
Оставьте заявку — мы подберем нужные решения и с радостью возьмемся за ваши задачи
Узнать большеКак связаться с дежурным
Окей, мы получили оповещение, направили его нужной команде (автоматически или вручную) и выяснили, кого стоит потревожить в данный момент. Следующий вопрос: как мы можем с ними связаться?
За это отвечают цепочки эскалации и политики уведомлений. Они продолжают маршрутизировать оповещения через интеграции с другими сервисами.
Пример цепочки эскалации может выглядеть так:
- Уведомить дежурного инженера
- Опубликовать оповещение в Slack
- Подождать 20 минут
- Сообщить второму дежурному инженеру
При уведомлении инженера его политика уведомлений будет определять, какие сигналы должны сработать. Это может выглядеть так:
- Отправить push-уведомление
- Отправить письмо
- Подождать пять минут
- Позвонить
Если в какой-то момент предупреждение будет подтверждено, оставшиеся шаги пропускаются.
Роли при реагировании на инциденты
Есть две основные роли: условные командир и следователь. Дежурный инженер по умолчанию будет следователем, а второй дежурный инженер возьмет на себя роль командира. Конечно, если кто-то обладает более глубокими знаниями, он может добровольно занять любую из этих ролей — даже во время инцидента. Единственное требование состоит в том, чтобы смена ролей была согласована всеми сторонами, чтобы оба не делали одну и ту же работу.
Следователь
Раскрытием дела занимается следователь. То, как это будет выглядеть, зависит от используемых технологий, систем, опыта и степени воздействия, поэтому четких указаний о том, что делать, не существует. Если у вас есть Runbook, самое время его применить. Runbook — это документы, которые описывают реакции на известные и ожидаемые проблемы.
Совет: в первую очередь, займитесь снятием симптомов инцидента, а не полным устранением проблемы в рамках обработки инцидента. Цель в том, чтобы в кратчайшие сроки смягчить последствия инцидента, сохранив при этом доказательства, которые помогут расследованию.
Работая над инцидентом, обязательно сообщайте о новых выводах как можно скорее.
Командир
Задача командира — поддерживать и давать следователям то, что им нужно. Это может быть доступ к системам, доступ к людям из других команд или общение с внешними поставщиками.
Командир сообщает о статусе инцидента другим командам (и службе поддержки клиентов) и помогает следователю расставить приоритеты. Он также может предлагать идеи и гипотезы. Другая обязанность — извлечение важной информации, найденной следователем, для документирования инцидента.
Другие люди
Иногда инциденты требуют сотрудничества множества разных людей. Даже если член команды не работает над инцидентом, предполагается, что он окажет поддержку, если попросит командир. Оповещение об инциденте дает руководителю инцидента полномочия реквизировать любого человека в компании на любом уровне, чтобы помочь внести свой вклад в разрешение ситуации.
Создание отчета после инцидента
Руководителю инцидента нужно создать аналитический документ после инцидента (PIR). Работа над ним начинается уже во время инцидента. PIR документирует то, что произошло во время инцидента и как решали ситуацию. В дальнейшем это поможет сделать работу над ошибками и понять, что пошло хорошо, что пошло не так и где нам повезло.
Совет: если инцидент был объявлен ложной тревогой, PIR может быть полезен только для того, чтобы поразмышлять над тем, как не тратить на это ресурсы в будущем.
PIR предназначены для внутреннего обучения и могут служить справкой для будущих инцидентов. Если вам необходимо сообщить об инциденте клиентам или широкой общественности, создайте отдельный документ на основе PIR.
Чтобы улучшить этот рабочий процесс, создайте шаблон документа.
Шпаргалка
Закажите аудит качества мониторинга
Мы проверим все системы и поможем составить план дежурств
Узнать больше