Документирование простоя для посмертного обзора

14

На прошлой неделе у нас был довольно серьезный сбой, затронувший несколько сервисов, которые вывели нас из нашего SLA с клиентами. Теперь, когда все решено, я провожу посмертный обзор.

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

  • Сводка на уровне исполнительного руководства.
  • Затронутые Услуги
  • Влияние Как это повлияло на наших пользователей и SLA? Были ли затраты в долларовом выражении, пропущенные транзакции, потерянные клиенты и т. Д.?
  • Продолжительность простоя Для каждой затронутой услуги, если были отклонения
  • Причина Включая первичные и вторичные причины
  • разрешение
  • Хронология событий Уведомления, контакты с внешними поставщиками, уведомления клиентов, ответы и т. Д.
  • Проблемы с нашим ответом Не все ли пошло не так, как запланировано с нашим ответом на отключение? Правильные люди уведомлены? Выполнили ли продавцы свои договорные обязательства?
  • Профилактические меры Как мы можем предотвратить повторение этого сбоя или уменьшить его влияние?
  • Метод обнаружения Насколько хорошо мы обнаружили этот сбой и как мы можем улучшить обнаружение в будущем?
  • Изменения, которые необходимо внести в будущие ответы на сбой

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

Doug Luxem
источник

Ответы:

6

Хотя это может быть охвачено в превентивных , я бы порекомендовал иметь раздел « Метод обнаружения », который вы могли бы использовать, чтобы отметить истинные симптомы и как вы могли бы обнаружить проблему (быстрее), если она возникнет снова, в идеале с использованием автоматизации.

JayC
источник
Добавлено в вики
Дуг Люксем
2

Выглядит хорошо. Я бы только добавил следующее:

Эффекты / последствия : Каковы последствия сбоя - кто был затронут, какие SLA были нарушены (если таковые имеются), были ли какие-либо побочные эффекты?

отметка
источник
1

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

Влияние : Как это отразилось на пользователях и как это воспринималось? Сколько денег нам это стоило (из-за отсутствия SLA, потерянных заказов и т. Д.)?

user8996
источник
Мне нравится различие между затронутыми услугами и влиянием на бизнес, но я бы классифицировал его как «Воздействие на бизнес», а не просто влияние (чтобы провести различие между ним и информацией об услугах / продолжительности). Кроме того, это привлечет внимание руководства, которому необходимо знать о влиянии на бизнес, если не обо всех технических деталях того, какие услуги были затронуты ...
Милнер
1

Публичный релиз и внутренний релиз

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

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

SpaceManSpiff
источник
Я думаю, что этот внутренний документ может быть использован для создания внешнего выпуска для клиентов. Именно то, что будет сказано клиентам, будет зависеть от наших руководителей и отдела маркетинга / коммуникаций.
Даг Люксем