Книга: Руководство по DevOps
Совещания для послеаварийной ретроспективы
Разделы на этой странице:
Совещания для послеаварийной ретроспективы
Ниже приведен простой план совещания по разбору для послеаварийной ретроспективы.
• В самом начале руководитель встречи или координатор произносит небольшую вступительную речь, подчеркивая, что сегодня никто не будет искать виноватых, сосредоточиваться на прошедших событиях или рассуждать о том, что могло бы или должно было быть. Координатор может прочитать главную директиву разбора ошибок (Retrospective Prime Directive)[184] с сайта Retrospective.com.
Кроме того, координатор должен напомнить всем, что у контрмер должен быть конкретный исполнитель. Если по окончании совещания контрмера не оказывается приоритетной, то это не контрмера (так делается, чтобы не создавать длинный список хороших идей, которые никогда не воплотятся в жизнь).
• Участники встречи должны составить единую картину того, в каком порядке происходили события во время сбоя: кто и когда обнаружил неполадку, как она была обнаружена (например, с помощью автоматического мониторинга, контроля вручную, письма клиента), когда работоспособность сервиса была восстановлена и так далее. В последовательную цепочку событий также нужно внести все внешние коммуникации во время инцидента.
Используя выражение «цепочка событий», мы формируем в воображении образ линейной последовательности шагов: как формировалось понимание проблемы и как мы в итоге ее исправили. На самом деле, особенно в сложных системах, к сбою приводит много разных событий, и нужно вносить исправления по нескольким путям одновременно. На этом шаге следует отследить все события и все мнения участников и по возможности выдвинуть гипотезы о причинно-следственных связях.
• Далее команда создает список всех факторов, приведших к инциденту: и человеческих, и технических. Потом их можно распределить по категориям, например «проектировочное решение», «восстановление», «фиксация наличия проблемы» и так далее. Команда может использовать такие методики, как мозговой штурм и «бесконечные “как”», чтобы вскрыть более глубокие причины проблемы, если в этом есть необходимость. При этом все точки зрения должны восприниматься уважительно — никто не должен возражать или спорить с реальностью фактора, предложенного кем-то другим. Очень важно, чтобы координатор выделил достаточно времени на эту часть совещания и чтобы команда не пыталась свести все к одной-двум «главным причинам».
• На следующем этапе участники совещания должны определиться со списком корректирующих действий, которые нужно будет выполнить как можно быстрее. Чтобы составить список, полезно устроить мозговой штурм. По итогам необходимо выбрать наилучшие действия для предотвращения таких ошибок в будущем или хотя бы для их более быстрого обнаружения. Туда можно включить и другие способы улучшить рабочие системы.
Наша цель — определить наименьшее число небольших шагов для достижения желаемых результатов, в противоположность глобальным изменениям, отнимающим больше времени и замедляющим введение других необходимых изменений.
Также нужно составить другой список — менее приоритетных идей — и назначить ответственного за него. Если в будущем возникнут похожие проблемы, список может послужить отправной точкой возможных решений.
Участники совещания должны определиться с характеристиками инцидентов и их влиянием на организацию. Например, сбои можно характеризовать следующими показателями.
Тяжесть инцидента: насколько серьезной была проблема? Этот показатель непосредственно связан с влиянием на сервис и на клиентов.
Время простоя: как долго клиенты не могли пользоваться сервисом?
Время обнаружения: сколько времени потребовалось на то, чтобы заметить, что есть проблема?
Время устранения проблемы: сколько времени потребовалось на то, чтобы восстановить работу сервиса после того, как мы обнаружили сбой?
Бетани Макри из компании Etsy отмечает: «Отсутствие обвинений на совещаниях не означает, что никто не берет на себя ответственность. Но мы хотим понять, какие обстоятельства привели к тому, что человек совершил ошибку, каков был широкий контекст. Главная идея в том, что, исключив ответственность, вы устраняете страх; устранив страх, допускаете честность; тогда честность дает возможность предотвратить сбой».
Приложение 9
- Свод правил DevOps
- Бережливое производство
- Гибкая разработка
- Конференции Velocity
- Гибкая инфраструктура
- Непрерывная поставка
- Тойота Ката
- Бережливый стартап
- Lean UX
- Rugged computing
- Теория ограничений и ключевых хронических конфликтов
- Нисходящая спираль в виде таблицы
- Опасности передачи ответственности и очередей
- Время ожидания = (% Занят) / (% Свободен)
- Мифы об индустриальной безопасности
- Шнур-андон компании Toyota
- Коммерческое готовое программное обеспечение
- Совещания для послеаварийной ретроспективы
- Обезьянья армия
- Transperant Uptime
- Как мы проводим ретроспективы
- Глава 7 Планерки и совещания
- Глава 39 Как проводить совещания
- Глава 5 Как вести совещания
- Ежедневные совещания – настоятельная необходимость
- Статья Екатерины Сехиной «Секреты знаменитых переговоров. Как проводить полезные совещания»
- Эффективные совещания
- Как проводить эффективные совещания и летучки
- 3. Стандарт управления совещаниями
- Рис. 5.1. Вариант шаблона для записей на совещаниях
- Непроизводительные совещания
- Регулярные совещания участников проекта