Blameless postmortem что значит

How to run a blameless postmortem

Incident postmortems focused on growth – without the blame game

Most companies experience major incidents at least several times per year.

We can work to prevent incidents, reduce their impact, and shorten their timelines. But they’re probably not going to disappear altogether anytime soon.

The good news is that incidents are a learning opportunity. They’re a chance to uncover vulnerabilities in our systems, prevent future recurrences, hone our processes to reduce incident impact, and build better software in the future.

The best way to learn from incidents is to institute incident postmortems. And here at Atlassian, our postmortems are blameless.

What is a blameless postmortem?

An incident postmortem brings teams together to take a deeper look at an incident and figure out what happened, why it happened, how the team responded, and what can be done to prevent repeat incidents and improve future responses.

Blameless postmortems do all this without any blame games.

In a blameless postmortem, it’s assumed that every team and employee acted with the best intentions based on the information they had at the time. Instead of identifying—and punishing—whoever screwed up, blameless postmortems focus on improving performance moving forward.

When things go wrong, looking for someone to blame is a natural human tendency. It’s in Atlassian’s best interests to avoid this, though, so when you’re running a postmortem you need to consciously overcome it. We assume good intentions on the part of our staff and never blame people for faults. The postmortem needs to honestly and objectively examine the circumstances that led to the fault so we can find the true root cause(s) and mitigate them.

Advocates—like Google and Etsy—say this approach helps foster a culture of learning and improves performance over time. They point out that removing the witch hunt portion of the program creates a psychological shift. Instead of worrying about being fired or demoted and trying to pass around blame like a hot potato, teams can focus on fixing the underlying issues.

Detractors wonder if blameless postmortems are really possible (aren’t humans wired for blame?) and worry the approach doesn’t foster accountability.

Are blameless postmortems even possible?

One of the primary critiques of blameless postmortems is that they simply aren’t possible. After all, blame and judgment are natural. Accountability is an essential part of running a successful team. And detractors imagine that blameless postmortems are like an awkward family dinner – everyone trying semi-successfully to smile and not say what they’re really thinking.

These critiques assume that the point of blameless postmortems is to make those responsible for an incident feel better—a goal that would probably stifle real conversation and accountability.

But the actual point of blameless postmortems is to remove the fear of looking stupid, being reprimanded, or even losing your job with the ultimate goal of encouraging honest, objective and fact-centric communication that leads to better future outcomes.

For example, let’s say an incident happened because Employee A assumed, incorrectly, that Employee B had deployed a fix. Instead of spending the postmortem trying to figure out whether Employee A or Employee B was ultimately to blame, a blameless postmortem would have each employee walk through their work processes and thought processes to try to get to the heart of the issue.

By walking through the process, we can identify where we can improve. Perhaps our training processes aren’t working. Perhaps the documentation was confusing. Maybe there’s a way to create checks and balances within our technical systems so that employees don’t have to remember who to check in with.

The point isn’t that blameless postmortems never identify who made a mistake. It’s that blamelessness opens up communication and acknowledges that IT incidents are complex and there may be multiple ways to improve in the future—without shaming or firing Employee A.

The value of effective blameless postmortems

For many, blameless postmortems may require a culture shift. But in our experience, the benefits outweigh the work it takes to get there. Blameless postmortems:

· Create a healthy culture between teams

If we’re not looking for another team to blame, we’ll be more effective at working together, communicating clearly and without fear, and having empathy for the teams around us.

· Decrease the chances of ignoring incidents for fear of blame

If an incident isn’t going to result in public shaming or firing, employees are more likely to communicate about that incident, bring it to the team’s attention, and share ideas for future fixes. If there’s a chance of losing a job, the incentive is to clam up and keep slip-ups to ourselves.

· Create an open, always-improving culture of learning

Blameless postmortems encourage teams to talk through what went wrong step-by-step and brainstorm ideas for improving. They also acknowledge that incidents are complicated and we’re all human—giving employees permission to embrace learning and change instead of defending their choices out of fear of consequences.

· Increase support and communication

If Employee A and B don’t have to blame each other for an outage, chances are their relationship will be stronger. Removing the fear takes the pressure off and gives people the chance to support each other.

· Free teams up to do their best work

Watching a teammate be blamed, shamed, or even fired for a misstep makes other employees less confident and more fearful about doing their own jobs. It can slow down operations and create obstacles to future progress.

Best practices for a blameless culture

Implementing successful blameless postmortems starts with laying a foundation for a blameless culture. Here’s where to start:

Communicate an open, mistake-friendly approach up front

Make sure teams know before the meeting even begins that this isn’t a witch hunt. It’s an opportunity for the company to learn and improve. People can be honest about assumptions, incorrect expectations, and missteps without fear of reprisal.

Encourage honesty and acceptance of failure

The detractors who say blameless postmortems don’t have enough accountability? Here’s where they’re wrong. Your postmortems should encourage honesty and accountability. Removing the fear of consequences frees people up to be honest about their missteps and misunderstandings. And that’s the only way to fix them.

Share information and build a timeline

Before you start digging into an incident, make sure everyone’s on the same page about what actually happened. A misunderstanding of the core issue can make an incident postmortem go quickly off the rails. This is why building a timeline of the incident is important.

Be consistently blameless

If one postmortem is blameless and others aren’t, the removal of fear and introduction of more openness won’t work.

Get C-suite buy-in

Blameless postmortems will be a culture change for most organizations. Make sure you sit down with company leaders to help them understand the benefits of blameless postmortems and blameless company culture before you begin. Culture shifts are only possible with top-level buy-in.

Collaborate

Even teams who weren’t directly involved in the incident may learn or contribute something in a postmortem.

Inviting different teams to a postmortem encourages cross-team collaboration and brings more perspectives to the table, ultimately improving incident management. Inviting someone from the security and privacy team, legal, or risk and compliance can help identify previously unknown contributing factors, other potential pitfalls in existing processes, and ways other teams can improve their support of technical systems and processes.

Make decisions, but get approval

A good blameless postmortem should result in some suggestions that help prevent future incidents. Make sure you identify who is responsible for approving recommended actions and reviewing the write-ups themselves.

At Atlassian, that person is a division-level head of engineering. They’re responsible for reviewing the conclusions and prioritizing agreed actions and mitigations after the postmortem.

A blameless postmortem success story

So, do blameless postmortems really improve results? Internally at Atlassian, all signs point to yes.

A couple years ago, an engineer made a big mistake with the syntax of a config file for a piece of critical equipment—and it took down the entire company for 45 minutes. If you quantify it, we’re talking hundreds of thousands of dollars.

But instead of shaming the engineer, we did a blameless postmortem. Because our goal wasn’t to punish someone for a mistake, it was to find out if there was a way to prevent that same mistake in the future. Humans make errors. There’s no getting around that. The question is how do we make it less possible for human error to happen? And to answer that, we needed to know what happened and why.

In the end, the simple, permanent fix was putting an automated “will it start” check on the config file before loading, and eventually removing all human interaction with the system’s configuration. The issue that caused the outage is now prevented by a quick technical fix. The engineer involved still works at Atlassian and adds a lot of value to our team.

At Atlassian, we’re fans of simple, repeatable processes—and our blameless postmortems are no exception. We’ve come up with a process that works well for us and you can find a breakdown here or read about it in-depth in our incident handbook.

Get the PDF handbook

We’ve got a limited supply of print versions of our Incident Management Handbook that we’re shipping out for free. Or download a PDF version.

Источник

Как коммуникации помогают в решении инцидентов

Все понимают, что 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 ноября. Питерское расписание уже готово, а количество билетов уменьшается.

Источник