Dev // Ops

Гайд проведення post-mortem мітингу після інциденту 🤓

Як то кажуть, інцидент вирішили, але осад залишився. Навіть якщо ви вчасно розв’язали проблему і користувач не постраждав, бажано провести post-mortem мітинг та проговорити деталі. Звісно, не для того, щоб знайти винного, а для того, щоб попередити подібне в майбутньому. Підготували для вас коротенький гайд для цього.

💥 Основні правила:
- Не шукаємо винного і встановлюємо нейтральний тон спілкування.
- Фіксуємо всі факти й думки.
- Вчимося на помилках та виносимо з них досвід.

👌Чек-ліст:
- Зберіть всіх, хто залучений до інциденту, та ключових стейкхолдерів, що приймають рішення в цьому напрямі.
- Встановіть чітку адженду: тема та цілі зустрічі.
- Зробіть повноцінне рев’ю: таймлайн, вплив на проєкт/компанію, зроблені кроки для розв’язання інциденту тощо.
- Заохочуйте дискусію, аналізуйте різні думки та робіть висновки на майбутнє.
- Проаналізуйте суміжні фактори, які могли вплинути на інцидент: прогалини в бізнес-процесах, людський фактор, технічні недосконалості системи тощо.
- Зафіксуйте результати та best-practices, що винесли з інциденту.
- Пропишіть follow-up зустрічі та домовтеся з командою-оунером про подальші дії.

У кожній організації структура та наповнення таких мітингів може відрізнятися. Наприклад, хтось готує документ для аналізу до зустрічі, а інші можуть наповнювати його під час мітингу згідно з наявним шаблоном. Деякі команди-оунери залучають стейкхолдерів вже на початковому етапі, а інші звітують по зробленому аналізу з висновками.

Ви можете створити свій власний шлях post-mortem мітингів, бо жорстких правил тут немає. Головне – аналізувати та робити висновки після кожного інциденту, адже в майбутньому це зекономить ваші нерви і гроші бізнесу 👌

👍5

www.tgoop.com/devops_zone3000/394

392 viewsDec 11, 2023 at 15:33

Гайд проведення post-mortem мітингу після інциденту 🤓

Як то кажуть, інцидент вирішили, але осад залишився. Навіть якщо ви вчасно розв’язали проблему і користувач не постраждав, бажано провести post-mortem мітинг та проговорити деталі. Звісно, не для того, щоб знайти винного, а для того, щоб попередити подібне в майбутньому. Підготували для вас коротенький гайд для цього.

💥 Основні правила:
- Не шукаємо винного і встановлюємо нейтральний тон спілкування.
- Фіксуємо всі факти й думки.
- Вчимося на помилках та виносимо з них досвід.

👌Чек-ліст:
- Зберіть всіх, хто залучений до інциденту, та ключових стейкхолдерів, що приймають рішення в цьому напрямі.
- Встановіть чітку адженду: тема та цілі зустрічі.
- Зробіть повноцінне рев’ю: таймлайн, вплив на проєкт/компанію, зроблені кроки для розв’язання інциденту тощо.
- Заохочуйте дискусію, аналізуйте різні думки та робіть висновки на майбутнє.
- Проаналізуйте суміжні фактори, які могли вплинути на інцидент: прогалини в бізнес-процесах, людський фактор, технічні недосконалості системи тощо.
- Зафіксуйте результати та best-practices, що винесли з інциденту.
- Пропишіть follow-up зустрічі та домовтеся з командою-оунером про подальші дії.

У кожній організації структура та наповнення таких мітингів може відрізнятися. Наприклад, хтось готує документ для аналізу до зустрічі, а інші можуть наповнювати його під час мітингу згідно з наявним шаблоном. Деякі команди-оунери залучають стейкхолдерів вже на початковому етапі, а інші звітують по зробленому аналізу з висновками.

Ви можете створити свій власний шлях post-mortem мітингів, бо жорстких правил тут немає. Головне – аналізувати та робити висновки після кожного інциденту, адже в майбутньому це зекономить ваші нерви і гроші бізнесу 👌

BY Dev // Ops