Дюжина (или около того) уроков за 15 лет управления инцидентами с программным обеспечением

Для инженера-программиста иметь дело с инцидентами — отстой. Получить этот вызов в 3 часа ночи в субботу утром? Это может вызывать страх, высасывать душу и вообще быть отвратительным эпизодом. Если это происходит часто на вашем рабочем месте, это может буквально вызвать посттравматическое стрессовое расстройство.

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

В этой статье рассматриваются два аспекта реагирования на инциденты с программным обеспечением:

• 🛠️ Практики, которые необходимо внедрить в свою программную платформу и команды, чтобы предотвращать подобный опыт и учиться на нем.

• 🧘 Отношение, которое нужно иметь, — быть стойким и уйти от этих переживаний не только невредимыми, но и с большим, чем они вложили.

Темы, которые мы затронем:

1. Автоматизируйте свои системы настолько, насколько это возможно.
2. Отслеживание опережающих и запаздывающих индикаторов
3. «Практические» оповещения должны быть очевидными
4. Установите четкие цепочки вызовов и пути эскалации
5. Расширьте возможности передовой для принятия важных решений
6. Не все инциденты одинаковы
7. Сначала решите, потом задавайте вопросы
8. Убедитесь, что один человек отвечает
9. Общайтесь четко и часто
10. Безукоризненное вскрытие имеет решающее значение
11. Последующие результаты вскрытий имеют решающее значение
12. Инциденты не являются плохими, пока MTTD низкий
13. Юмор – великий уравнитель

Давайте углубимся в некоторые детали!

Автоматизируйте свои системы настолько, насколько это возможно

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

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

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

Отслеживание опережающих и запаздывающих индикаторов

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

«Практические» оповещения должны быть очевидными

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

Вы можете добавить эти сведения в содержимое самого оповещения или, если оно достаточно подробное, вы можете дать ссылку на runbook(ы), которые команда поддерживает для решения подобных проблем.

Установите четкие цепочки вызовов и пути эскалации

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

Часто, если проблема сложна или намного превышает масштабы, с которыми может справиться один человек, может возникнуть необходимость привлечь более старших сотрудников (или несколько человек в команде), а также межфункциональных заинтересованных сторон. Обеспечение легкого доступа ко всему этому с помощью инструментов (таких как PagerDuty, OpsGenie) или кристально понятной документации (книги запуска, вики-страницы, репозитории README) может стать разницей между катастрофическим инцидентом или пустым бургером.

Расширьте возможности передовых сотрудников для принятия важных решений

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

Не все инциденты одинаковы

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

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

Сначала решите, потом задавайте вопросы

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

Убедитесь, что за вас отвечает один человек

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

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

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

Командиры инцидентами обычно запускают синхронную линию голосовой связи, например, собрание в Slack или собрание Google Meet. Это гарантирует, что люди, имеющие решающее значение для разрешения инцидента, находятся в постоянном контакте. Удивительно, насколько эффективна эта маленькая вещь по сравнению с возможностью просто решать проблемы асинхронно с помощью чата.

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

Как говорится, если попросить двух человек покормить лошадь, лошадь умрет. Руководитель инцидента предотвращает это и в конечном итоге несет ответственность за быстрое разрешение инцидента.

Общайтесь четко и часто

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

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

Безупречное вскрытие имеет решающее значение

Вскрытие или ретроспективы после инцидентов важны для формирования культуры обучения, и они абсолютно не должны быть безупречными. Критично относитесь к процессу, а не к человеку. Никто не относится к себе строже, чем человек(и), которые могли стать причиной этого, и вы ничего не выиграете от бичевания их публично. Во всяком случае, все исследования показывают, что вы на самом деле проигрываете, делая это. Ребята из Etsy гораздо лучше об этом говорят, так что прочитайте https://www.etsy.com/codeascraft/blameless-postmortems, если хотите узнать больше.

Продолжение результатов вскрытия имеет решающее значение

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

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

Инциденты не являются плохими, пока MTTD низкий

Все это понимают. Даже деловые люди это понимают. Создание программного обеспечения СЛОЖНО, и в мире, где все наше программное обеспечение имеет сотни из тысяч зависимостей, невозможно предсказать, где линии разлома могут треснуть. Дерьмо попадет в вентилятор, и это нормально. Мы не можем предотвратить возникновение инцидентов. Однако что действительно помогает, так это убедиться, что MTTD для ваших инцидентов действительно низкий.

Среднее время обнаружения (MTTD) — это ключевой показатель производительности (KPI), который измеряет среднее время, необходимое организации для выявления инцидента или угрозы безопасности. Трудно обобщать, учитывая сферу бизнеса, серьезность воздействия и т. д., но если вы сможете сократить время MTTD с секунд до минут, вы, вероятно, сможете значительно уменьшить влияние инцидента, а не говорить об этом. длились часы или дни (не говоря уже о неделях или месяцах, что, к сожалению, вполне возможно).

Юмор избавляет вас от боли в данный момент

Все это очень СЕРЬЕЗНО! Деньги теряются! У клиентов ужасные впечатления! Однако посреди всего этого я обнаружил, что крайне важно иметь чувство юмора. Не следует забывать, что в этом процессе каждый человек – человек и переживает разную степень стресса. Добавление порции юмора в соответствующие моменты помогает частично снять это давление.

Это создает чувство товарищества, которое заставляет команду чувствовать себя так, будто они вместе, а не на острове в аду.

Это завершение. Спасибо за прочтение!

⭐ Если вам нравится контент такого типа, обязательно подпишитесь на меня или подпишитесь на https://a1engineering.substack.com/subscribe ! ⭐

Художественное фото Жюльена Л. на Unsplash