Все понимают, что shit happens — и чаще всего не если, а когда. У нас может быть много девяток в SLA, но 100% ни у кого нигде никогда не бывает. Поэтому, когда этот SHIT все-таки HAPPENS, есть два пути. 

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

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

Если у вас сейчас лежит прод, то вряд ли вы читаете эту статью. А если у вас всё хорошо, то самое время подумать, как вы его будете поднимать. Понятно, что есть disaster recovery plan и прочие технические важные штуки, но сегодня речь не об этом.

Чтобы всё прошло спокойно и без нервов, важно определить роли и границы ответственности. Они должны быть известны, понятны и установлены заранее. Степень формальности – на ваш вкус.

Казалось бы, всё просто. Но сложность в том, чтобы это внедрить в команду.

Про доверие

Ваши пользователи узнают о проблеме. И лучше если узнают о ней от вас. То, какие выводы они сделают, определит, в том числе, что именно и откуда они узнали. «Криворукие админы опять всё сломали» или «У наших ребят проблемы, чем мы можем им помочь?»

Еще к доверию ведёт прозрачность. Отличный пример — это GitLab. У них все дашборды публичные, включая вот такие:

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

Казалось бы, ну думают про вас пользователи что-то, кому какое дело? Но их доверие важно — как минимум лояльные пользователи не будут мешать вам тушить пожар или охотнее будут выполнять действия, необходимые с их стороны. А может быть, даже предложат какие-то неожиданные решения.

Готовим тушение пожара

Определяем роли

Мы как основу используем некоторые роли из SRE Book от Google — немного их  подправили и скомпилировали с другими источниками. Опишу основные.

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

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

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

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

Особенно важно защищать пожарных от больших боссов.

Как это делать? Соглашаться, кивать и говорить то, что от вас хотят услышать, потому что если мы перешли в эту плоскость, то конструктива уже нет: «Да, вы нас всех уволите, но завтра. Потому что если вы нас уволите сегодня, всё так и будет лежать». Этот аргумент довольно сложно перекрыть. Гнев, эмоции, негатив остаются на лидере коммуникации, ему с этим жить. Но я верю, что токсичных боссов в целом у нас в индустрии мало.

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

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

Прописываем роли

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

Например, у GitLab прямо в ролях прописано, что человек должен делать:

Готовим коммуникации внутри команды

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

Если у вас удаленка и мессенджеры, координатору будет даже легче: он может пересылать сообщения, делать пины в мессенджерах, подсвечивать важное, автоматически куда-то их собирать. Если у вас очный war room, где вы все в одной комнате с ноутбуками и перекрикиваетесь идеями, то нужен летописец. Он будет это все записывать и фиксировать, чтобы не потерять данные.

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

Действуем внутри пожара

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

Героизм, кстати — это плохо, часто он появляется там, где не хватает профессионализма. Поэтому если вы устали — отдыхайте. Давайте отдохнуть пожарным. В 4 утра после 20 часового рабочего дня очень редко приходят хорошие идеи, обычно становится только хуже.

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

Но без крайностей. Не стоит транслировать все свои действия. Информируйте только тех, кому это нужно.

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

Ура, мы всё починили!

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

В этот момент часто со стороны пользователей нужны какие-то действия — например, перезапустить пайплайны, передеплоить что-то или восстановить данные. И если они вам доверяют, то охотнее это сделают. Если вы еще объясните, почему им надо это сделать, то помимо плюса в карму, есть шанс, что всё у них (а значит, и у вас) пройдет более гладко.

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

Теперь настало время разбираться в причинах инцидента.

Postmortem 

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

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

5 почему для хорошего постмортема

Хорошие постмортемы — это про Root Cause Analysis. Количество Почему варьируется, но в среднем по больнице хватает пяти, иногда надо больше. Вот пример инцидента в  GitLab:

Это постмортем 2017 года. GitLab тогда лежал 18 часов и потерял пользовательские данные. 

• Почему GitLab лежал? Потому, что директория основной базы данных была случайно удалена вместо вторичной.

• Почему она была удалена? Очистка директории требуется перед возобновлением репликации. Это ручная работа, которая плохо задокументирована и не автоматизирована.

• Почему была остановлена репликация? Потому что выросла пиковая нагрузка.

• Почему она выросла? Одновременно произошли два события: повышенное количество спама и процесс удаления аккаунтов сотрудников GitLab с их данными.

• Почему был запущен процесс удаления сотрудников? На аккаунты сотрудников поступали жалобы от троллей. В текущая реализации рассмотрения жалоб слишком легко пропустить суть жалобы и принять решение об удалении учётной записи. Из-за этого было запланировано удаление аккаунтов ряда сотрудников.

Так мы дошли до корневой причины. Этот постмортем от GitLab — отличный пример, как это надо делать. 

Постмортем без реальных задач – плохой постмортем

Постмортем без реальных задач — это плохой постмортем. При этом важно, чтобы задачи были реализуемыми и понятными, а не «сделать, чтобы было хорошо и не было плохо». То есть у задач должны быть формальные критерии выполнения и проверки, сроки и исполнители. Да, некогда и надо пилить фичи, но надо и правда сделать.

Почему это важно?

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

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

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

Blameless postmortem

Про концепцию blameless в постмортемах классно рассказывают ребята из Atlassian в Incident Management book. 

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

Один из моих самых любимых вопросов на собеседованиях: «Расскажите про какой-нибудь ваш факап». Я настороженно отношусь к людям, которые отвечают: «Ну, у меня не было никаких факапов!» или «Ничего такого, что тут рассказывать!»

Опыт мелких инцидентов предотвращает крупные.

Итоги инцидента

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

• Почему инцидент произошел;

• Как починили, что именно сделали;

• Почему он больше не повторится.

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

Продолжение следует

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

1 августа повысились цены билетов на петербургский и московский HighLoad++. Через 26 дней будет очередное повышение.

Обе конференции пройдут этой осенью. В Питере — 20-21 сентября, а в Москве — 25-26 ноября. Питерское расписание уже готово, а количество билетов уменьшается.