Обсуждение того, как управляются технические инциденты в индустрии разработки программного обеспечения.
Все время что-то идет не так. Это суровая правда жизни.
Чем больше становится система, тем больше шансов, что ее части время от времени будут ломаться. Если ваш бизнес процветает, а сломанная или частично сломанная система означает потерю денег или плохой пользовательский опыт, вы не можете не быть начеку, чтобы немедленно реагировать, когда что-то идет не так. Потому что деньги имеют значение, и вы не можете позволить себе терять клиентов из-за плохого пользовательского опыта.
Угадай, что? Даже если лучшие в мире инженеры построят вашу систему, следуя передовым методам разработки программного обеспечения, известным человечеству, она сломается сейчас или в ближайшем будущем. Это суровая правда жизни разработчиков.
Так что же с этим делать, зная, что ваша система или ее часть обязательно выйдет из строя? Короче говоря, управление инцидентами.
Как проводить управление инцидентами
Успешные крупные компании, обслуживающие пользователей круглосуточно и без выходных, должны серьезно относиться к управлению инцидентами. Здесь нет места расхлябанности.
По моему опыту, я видел следующую схему управления инцидентами в системах с большим количеством работающих служб:
- Выдача метрик — каждая служба выдает метрики во внешнюю систему, где эти метрики сохраняются. Обычно это база данных временных рядов с ключами и значениями.
- Визуализация — другая система используется для запроса сохраненных данных и их визуализации в некотором пользовательском интерфейсе. Эта система периодически запрашивает данные и соответствующим образом обновляет визуализации.
- Дашборд — дашборд создан для лучшей визуализации, где собраны многие метрики, связанные с сервисом.
- Правила оповещения — поскольку система периодически запрашивает системные метрики, можно настроить правила для публикации оповещений в системе оповещения.
- Оповещения и уведомления — при получении оповещения система оповещения может инициировать оповещение в системах связи, чтобы уведомить ответственных инженеров.
Архитектура управления инцидентами
Вышеизложенное может показаться немного расплывчатым. Позвольте мне быть более конкретным с помощью следующей диаграммы:
Предположим, вы разрабатываете архитектуру для создания хорошо автоматизированного управления инцидентами для критически важной службы вашей компании. Исходя из моего опыта, приведенная выше диаграмма показывает возможное решение.
- Сервис — сервис в вашей системе, который вы хотите отслеживать. Если что-то пойдет не так в этой службе, вы хотите исправить это как можно быстрее.
- Graphite — популярная система, поддерживающая хранение данных метрик в формате временных рядов. Обратите внимание, что важно, чтобы все метрики сохранялись с отметкой времени, потому что именно так вы можете отслеживать, как ваш сервис ведет себя с течением времени. Все различные системные метрики из службы сохраняются в Graphite.
- Datadog — хорошо зарекомендовавшая себя система мониторинга. Datadog будет запрашивать Graphite для получения метрик и предоставления визуализаций. Кроме того, в Datadog будут настроены правила для публикации предупреждений, чтобы владельцы службы могли быть уведомлены.
- PagerDuty — Datadog публикует оповещения в PagerDuty, широко используемой системе для предоставления услуг оповещения. PagerDuty получает оповещение от Datadog и выдает фактическое оповещение. PagerDuty поддерживает интеграцию со службами мгновенных сообщений и телекоммуникационными системами. Например, в нашем случае, как показано на изображении выше, PagerDuty отправляет сообщение на соответствующий канал в Slack и звонит по соответствующему номеру, чтобы уведомить о проблеме, обнаруженной в службе.
Как выполняются обязанности
Я уверен, что один очевидный вопрос приходит вам на ум — кто примет звонок?
В компаниях действуют правила дежурства, при которых по крайней мере один инженер доступен круглосуточно, чтобы ответить на уведомление, отправленное системой оповещения. В нашем примере идею можно кратко разбить следующим образом:
- Команда, обычно владеющая командой службы, настраивает политики дежурства на PagerDuty. Например, в команде из пяти человек каждый член может быть помечен как дежурный инженер на неделю в циклическом порядке.
- В PagerDuty также настраиваются графики дежурств, а также номера телефонов и имена пользователей Slack инженеров.
- Во время смены дежурный инженер является первой линией защиты от любых проблем в системе. Ожидается, что инженер ответит немедленно, как только получит уведомление.
- Когда дежурный инженер получает уведомление, он должен подтвердить его. Достаточно нажать кнопку, чтобы сообщить
PagerDuty, что инженер сейчас активно работает над проблемой. - Политики эскалации также настраиваются на PagerDuty. Это означает, что если дежурный инженер не отвечает на звонок, PagerDuty передаст предупреждение кому-то другому, обычно менеджеру команды-владельца.
- Также может быть несколько уровней политик эскалации, основанных на критичности проблемы. PagerDuty будет продолжать уведомлять всех в цепочке, пока не получит подтверждение от кого-либо.
Не думайте, что только дежурный инженер обязан найти решение проблемы в системе. В зависимости от критичности и сложности дежурные инженеры всегда могут обратиться за помощью, вручную активировав оповещения для других соответствующих инженеров на PagerDuty.
Самое главное ожидание от дежурного инженера (или группы инженеров) — решить проблему как можно быстрее, предприняв все необходимые шаги. Не обязательно сразу искать причину.
Например, предположим, что ваша служба начала сталкиваться с ошибками нехватки памяти после недавнего развертывания. Теперь дежурный инженер быстро определил развертывание, вызвавшее проблему, поэтому ожидается, что он отменит изменения. Не обязательно искать основную причину (конкретную часть кода), непосредственно ответственную за ошибки OOM.
Средства правовой защиты после инцидента
Теперь возникает большой вопрос — что происходит после разрешения инцидента?
После того, как дежурный инженер ответил и в конечном итоге устранил проблему, методы управления инцидентами на этом не заканчиваются. Крайне важно предпринять еще несколько шагов, чтобы уменьшить количество таких инцидентов в будущем. Как минимум, в компаниях с хорошей инженерной культурой вы можете ожидать следующее:
- В зависимости от критичности проблемы команда-владелец подготавливает документ о вскрытии или RFO (причина простоя).
- В доке ни на кого пальцем не указывают. Очень важно не обвинять кого-то конкретно в этой проблеме. Язык документа RFO не должен быть агрессивным.
- Другие заинтересованные стороны также проводят рецензирование документа. Также часто проводятся регулярные обзорные встречи RFO.
В RFO даны ответы на некоторые конкретные вопросы. Например,
- В чем причина проблемы или сбоя?
- Какие меры были предприняты для его смягчения?
- Что можно было сделать лучше?
- Каковы были сроки отключения?
- Каково было влияние на бизнес?
- Какие шаги предприняты (и будут предприняты) для предотвращения повторения подобного в будущем?
Как мы видим, идея состоит в том, чтобы поместить как можно больше подробной информации в документ и поделиться знаниями с соответствующими командами, чтобы уменьшить вероятность повторения одной и той же проблемы в будущем.
Проектировать хорошо спроектированную систему сложно. Защитить хорошо спроектированную систему от сбоев сложнее. Вот где хорошие методы управления инцидентами имеют значение. — Ваш скромный автор
На этом сегодняшняя дискуссия об управлении инцидентами в технологических компаниях завершена. Спасибо за прочтение! Надеюсь, вам понравилась статья и вы узнали что-то новое. :)
До следующего раза, адиос!
Всем привет! Я просто хочу воспользоваться этой возможностью, чтобы сообщить вам, что теперь у меня есть свой собственный бюллетень! Каждые две недели я делюсь со своими подписчиками тщательно отобранными статьями по разработке программного обеспечения из различных блогов компаний и инженеров. Если вы инженер-программист и хотите узнать больше о распределенных системах, микросервисах, масштабируемости и обо всем, что связано с лучшими отраслевыми практиками, ознакомьтесь с моим информационным бюллетенем здесь. Спасибо!
