Посмертное Происшествие Для Новичков



Посмертное происшествие для новичков

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

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



Зачем нужно вскрытие?

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

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

Поскольку инциденты будут происходить в любом случае, они должны приносить пользу, а не вред.

«В некотором смысле неопределенность, беспорядок, ошибки и время приносят пользу антихрупким системам…» Антихрупкость, Нассим Николас Талеб (2012)
Когда это не удается, мы узнаем что-то новое о системе, особенно о скрытых связях между компонентами.

Допустим, у нас есть простая система из трех компонентов (A, B и C) со следующими свойствами:

  • А соединен с Б;
  • А соединен с С;
  • Между B и C нет никаких связей;
  • любой процесс, порожденный A, открывает соединение с B и C.
Вот как выглядит диаграмма:

Посмертное происшествие для новичков

Внезапно Б начинает тормозить.

В результате A сохраняет множество открытых соединений с C до тех пор, пока не начнет отклонять новые входящие соединения.

А не может открыть новые соединения с С и тоже начинает глючить.

Мы обнаружили скрытую связь между B и C. Вот как выглядит новая схема:

Посмертное происшествие для новичков

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

А если это повторится, нужно описать, как смягчить последствия и ускорить разрешение.



Когда проводить вскрытие

Когда в системе происходит достаточно серьезный инцидент. Теоретически любое происшествие.

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

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



Что мы должны делать

Опишите, что произошло.

Четко изложите последствия происшествия:

  • ВОЗ?
  • Что?
  • Сколько?
Сочинить хроника события и коммуникации между участниками относительно инцидента.

Попытаться найти первопричина , если можно что-то с этим сделать:

  • пять почему ;
  • практичность важнее «истины»;
  • Процесс поиска основной причины должен быть документирован.

«Между истиной и практической пользой существует важная разница».

Данные и реальность, Уильям Кент (1978)

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

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

«Решайте проблемы коллективно, чтобы быстро учиться новому».

Справочник DevOps, Джин Ким, Джез Хамбл, Патрик Дебуа, Джон Уиллис (2006)

Предложить улучшение системы Если это произойдет снова:
  • Запишите корректирующие действия, чтобы в следующий раз сделать это быстрее.

  • Что можно сделать, чтобы минимизировать последствия?
Обратите внимание на поток информации, обратную связь и задержки в общении:
  • Удалось ли нам вовремя узнать о происшествии?
  • Все ли нужные люди были уведомлены?
  • Получили ли необходимые подсистемы (например, автомасштабирование) необходимую обратную связь?
«Измените длительность задержки, и поведение всей системы может кардинально измениться».

Мышление в системах, Донелла Х.

Медоуз (2008)



Чего не делать

Не вини никого Если мы будем показывать друг на друга пальцем, люди будут скрывать информацию, и весь процесс развалится.

Не копайте слишком глубоко Четкой границы между вашей системой и остальным миром нет — они плавно перетекают друг в друга.

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

Вы потратите ресурсы.



Что делать с документом?

Основная цель — извлечь урок для себя и своей организации.

Посмертные документы должны быть:

  • доступный для поиска ;
  • открыть максимально широкой аудитории (без разглашения конфиденциальной информации);
  • понятный аудитория (инженеры, заинтересованные стороны, пользователи и т. д.).



Для вдохновения

Вот список общедоступных (и подробных) вскрытий: Теги: #программирование #Управление проектами #Администрирование серверов #DevOps #sre #postmortem
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.