Это история небольшой группы, которая добровольно объединилась, чтобы улучшить процесс обработки инцидентов в нашей компании. Это не история «мы отлично справились, вы должны сделать то же самое», а скорее «это то, что мы сделали, что бы вы сделали?» один.
Наш отдел разработки продуктов состоит из кросс-функциональных команд, которые обладают высокой степенью автономности и полностью владеют тем, что они предоставляют. Например, у нас есть команда, которая отвечает за функцию каталога продуктов, от внешнего интерфейса до серверной части, от проектирования до развертывания. Эта модель имеет много преимуществ, таких как полный контроль над всеми аспектами функции, но побочным эффектом является то, что каждая команда имеет свою собственную инженерную культуру и методы, и нет центрального органа, который предписывал бы, какие процессы должна выполнять каждая команда. следить.
Возникает вопрос: если у вас нет централизованного механизма управления, как вы вносите изменения, которые будут распространяться среди команд? В зависимости от вашего контекста точное решение, вероятно, будет отличаться для вашей компании, но есть некоторые основные принципы, которые могут способствовать изменению. Наш подход заключался в том, чтобы сосредоточиться на двух областях: выравнивание и прозрачность.
История
Мы начинаем в конце 2019 года. Я был Agile Coach, роль которого заключалась в том, чтобы помогать командам улучшать их рабочие процессы и культуру. Мне лично небезразличны инциденты, и я считаю, что уроки, полученные в результате вскрытия, очень ценны. Выражение моего интереса привело к тому, что меня пригласили на вскрытие инцидентов разные команды для фасилитации.
Однажды днем я сел за свой стол и подумал: «это уже слишком, каждый должен иметь возможность облегчить вскрытие». Я написал трехстраничный документ по этой теме и поделился им с нашим техническим директором.
Он сказал (перефразируя): «Здорово, что вы начали эту инициативу. Есть и другие люди, которые начали работать над этой темой. Может, будет лучше, если вы объединитесь с ними »
Такой подход оказался очень показательным. После объединения с разными людьми из разных частей компании (безопасность, ИТ, юриспруденция, риски и инженерия) я понял, что это не так просто, как научиться проводить вскрытие. Это было намного больше:
- Технические происшествия важны, но не только для инженерного отдела. Как только это затрагивает конечного пользователя, это становится важным для отделов рисков и юридических служб, а также для службы поддержки клиентов.
- Что составляет инцидент, следует определить и четко сообщить, иначе людям будет сложно решить, является ли аномалия инцидентом или нет.
- Точно так же должны быть четко определены уровни серьезности инцидентов.
- Ценность отчета об инциденте и вскрытия будет ограничена, если вы сосредоточитесь только на немедленных действиях. Многое можно получить от выявления закономерностей, поиска ссылок на другие инциденты и выявления основных проблем.
Работа началась с определения различных категорий инцидентов. Мы разделили команду на подгруппы, чтобы создать документы для каждой категории. Ниже приведены категории, которые мы придумали. Они могут отличаться в зависимости от вашего бизнеса.
Согласование через документацию
Нас было двое из категории «Оперативный инцидент». Когда мы начали работу над документацией, мы вскоре поняли, что это потенциально глубокая кроличья нора. В крайнем случае, мы могли бы полностью перечислить то, чем владеет каждая команда. Это не имело бы большого значения, поскольку оно, скорее всего, устареет и, что более важно, посягнет на области компетенции команд. Поэтому мы решили держать его на высоком уровне и позволить командам хранить более подробную техническую документацию внутри.
Это обзор того, что мы задокументировали для категории «Операционные происшествия»:
- Что такое инцидент?
- Быть на связи
- Инциденты, вызванные пользователями
- Принципы оповещения
- Runbooks
- Во время инцидента
- После инцидента
- Посмертный анализ
- Патологоанатомический отчет
- Советы по эффективному вскрытию - Дополнительные ресурсы
Подробную документацию хорошо иметь в качестве справки и источника истины, но ее слишком много, чтобы читать во время инцидента. Итак, мы создали схему процедуры на первой странице нашей документации, которой легко следовать под давлением.
Прозрачность благодаря общему списку инцидентов
Чтобы собирать информацию об инцидентах, нам нужно было единое место для сообщений о них. Поэтому мы создали портал, на котором можно сообщать о различных категориях инцидентов, как только непосредственный инцидент был устранен. На целевой странице репортер может выбрать одну из четырех категорий инцидентов, упомянутых выше. Затем им предоставляется форма, характерная для такого рода происшествий. Вот пример формы для оперативных происшествий:
Ожидается, что отчет должен быть представлен, как только пожар потушен, и репортер может приложить дополнительную информацию позже, например, результаты вскрытия.
Для большей прозрачности отчетов был создан публичный канал Slack с интеграцией с порталом. Каждый раз, когда создается отчет об инциденте, его сводка автоматически публикуется в канале. Это место, где люди могут быть проинформированы о текущих инцидентах, предложить помощь и поделиться, если они что-то знают о конкретном инциденте.
Экскурсия по новому процессу
Все необходимое для того, чтобы объявить о новом способе обработки инцидентов, было сделано. Мы решили сделать больше, чем просто электронную почту. Нам нужен был личный разговор, чтобы люди могли задавать вопросы и собирать отзывы. Итак, мы устроили тур для каждой команды, продемонстрировав весь процесс от начала до конца.
Повестка дня заседания:
- Вступление
- Портал инцидентов
a) Безопасность
b) Оперативный
c) Внутренний - Тестовый сценарий / Уведомления Slack
- Где найти документацию
Вскоре после туров люди начали присоединяться к каналу Slack, и начали появляться автоматические уведомления.
Обучение
Вот мои выводы как члена основной рабочей группы:
- Держите пользователей близко. В нашем случае нашими пользователями были инженеры и те, кто мог столкнуться с инцидентом. В категории «Операционные инциденты» мы неоднократно собирали отзывы от старших инженеров по вопросам удобства использования портала и документации.
- Работайте с другими. Работа в группе позволяет увидеть разные точки зрения, сделать решение более комплексным и увлекательным.
- Остерегайтесь слишком регламентированного нового процесса. Заставьте людей купиться на это и понять, какую ценность это приносит. Вы хотите, чтобы люди добровольно вносили свой вклад, а не чувствовали себя обязанными заполнять отчет как рутинную работу.
Еще осталось сделать
Теперь, когда новый процесс отправлен, начнется этап улучшения. Вот некоторые области, которые мы рассмотрим в ближайшем будущем:
- Как привлечь новых сотрудников к этому процессу? Должны ли мы полагаться на молву или сделать официальный процесс адаптации?
- Как сохранить темп при проведении вскрытий? Идеальный сценарий - иметь в каждой команде людей, которые могут облегчить вскрытие, а не полагаться на пару человек в компании.
- Как сделать его еще более прозрачным и ценным для компании? Одна из идей - ежеквартально рассылать электронное письмо со сводкой инцидентов, задокументированных на портале, и другими важными сведениями.
Оглядываясь назад на то, что мы сделали, я понимаю, что это было бы невозможно, если бы основная рабочая группа не чувствовала себя уполномоченной. Свобода и чувство силы были нашим основным топливом в этой команде. Наша цель состояла в том, чтобы внедрить практику, которая создает ценный ресурс для более широкой компании, сохраняя при этом автономию отдельных команд. Мы с нетерпением ждем его развития.
