Сайт
/
Блог
/
Мониторинг в DevOps

Мониторинг в DevOps: разработка процесса реагирования на инциденты

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

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

Что такое инцидент

Инциденты могут принимать разные формы. Хорошей отправной точкой для разработки процесса реагирования станет определение того, что представляет собой инцидент для вашей организации. Определение инцидента выглядит примерно так:

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

Этот список далеко не полный. Возможно, вы захотите исключить некоторые критерии или добавить дополнительные, в зависимости от вашей сферы бизнеса.

Как мы узнаем, что произошел инцидент

Первый шаг в устранении инцидента — понять, что что-то сломалось. О проблемах сообщают вручную (например, через службу поддержки, члену команды или напрямую клиенту) или автоматически с помощью решения для наблюдения, например Grafana или Prometheus. Вашим главным приоритетом должна быть установка системы мониторинга, которая будет как можно скорее оповещать, когда что-то происходит.

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

Например, простое правило оповещения может быть таким: Сообщите нам, если более 0,1% наших HTTP-ответов будут с кодом 500 в течение как минимум пяти минут.

Здесь мы указываем условие с конкретными значениями, отмечаем продолжительность, в течение которой это условие должно выполняться. Цифры необходимы, чтобы избежать нестабильных предупреждений из-за одиночных кратковременных сбоев.

Уровни серьезности

Кого уведомить, если инцидент произошел

Это один из самых сложных вопросов, поскольку он должен учитывать множество аспектов:

Кто бы мог это исправить?
Кто доступен?
Они точно проснулись?

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

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

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

Планирование графика

При составлении расписания учитывайте следующее:

Продолжительность смены: быть на дежурстве в течение нескольких недель очень утомительно, но и 10 часов в сутки также могут стать головной болью.
Предсказуемость: инженеры захотят заранее спланировать личные дела и должны знать, будут ли они на связи в это время.
Баланс: это само собой разумеется, но постарайтесь равномерно распределить смены между всеми членами команды.
Юридические ограничения: в разных странах действуют разные правила относительно того, как долго и как часто кто-то может быть на связи.

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

Хотите, чтобы мы взяли вас на техподдержку 24/7?

Оставьте заявку — мы подберем нужные решения и с радостью возьмемся за ваши задачи

Узнать больше

Есть две основные роли: условные командир и следователь. Дежурный инженер по умолчанию будет следователем, а второй дежурный инженер возьмет на себя роль командира. Конечно, если кто-то обладает более глубокими знаниями, он может добровольно занять любую из этих ролей — даже во время инцидента. Единственное требование состоит в том, чтобы смена ролей была согласована всеми сторонами, чтобы оба не делали одну и ту же работу.

Следователь

Раскрытием дела занимается следователь. То, как это будет выглядеть, зависит от используемых технологий, систем, опыта и степени воздействия, поэтому четких указаний о том, что делать, не существует. Если у вас есть Runbook, самое время его применить. Runbook — это документы, которые описывают реакции на известные и ожидаемые проблемы.

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

Работая над инцидентом, обязательно сообщайте о новых выводах как можно скорее.

Командир

Задача командира — поддерживать и давать следователям то, что им нужно. Это может быть доступ к системам, доступ к людям из других команд или общение с внешними поставщиками.

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

Другие люди

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

Мониторинг в DevOps: разработка процесса реагирования на инциденты

Что такое инцидент

Как мы узнаем, что произошел инцидент

Уровни серьезности

Кого уведомить, если инцидент произошел

Планирование графика

Хотите, чтобы мы взяли вас на техподдержку 24/7?

Как связаться с дежурным

Роли при реагировании на инциденты

Создание отчета после инцидента

Шпаргалка

Закажите аудит качества мониторинга