Классификация инцидентов по степени серьёзности – ключевой момент в управлении инцидентами. Она нужна, чтобы SRE команда могла быстро и эффективно устранять неполадки в сложных системах и минимизировать их влияние на клиентов. В этой статье описана система SEV (Security Evaluation Version), которая помогает стандартизировать процесс устранения проблем, быстрее восстановить работу системы и уведомить о происшествии всех, кого это касается, в зависимости от серьёзности инцидента.
Итак: насколько серьёзна проблема?
Самый быстрый способ ответить на этот вопрос — использовать простое число от 1 до 4. Каждый уровень серьёзности представляет собой различные стратегии реагирования и коммуникации в зависимости от масштаба инцидента. Если мы говорим, что это инцидент уровня SEV-2, нужно сообщить внутри компании о важности данного вопроса и мгновенно понять, что с этим делать.
Уровни серьёзности инцидентов похожи на медицинские протоколы сортировки Triage tag. Это такие бирки или карты, которые используются для категоризации и приоритизации помощи в условиях чрезвычайных ситуаций, массовых катастроф или при большом наплыве пациентов. Разные цветовые коды помогают медикам сортировать пациентов по категориям и приоритетам. Есть угроза жизни? Это красный код и требует немедленного вмешательства. Пациент без сознания, но дышит? Это жёлтый код и может подождать. Есть травмы, которые не угрожают жизни? Это зелёный код и классифицируется как незначительное происшествие.
Цветные бирки помогают медикам на расстоянии нескольких футов быстро понять, что это за пациент перед ними. Цифры лучше подходят для программных инцидентов, которые требуют вмешательства инженеров и быстрой категоризации и сортировки с помощью систем мониторинга.
Четырехуровневая матрица серьёзности инцидента
В этой 4-уровневой системе каждый уровень серьёзности имеет соответствующий уровень срочности реагирования.
SEV-1 (критическое воздействие)
Инциденты уровня SEV-1 имеют наиболее критический уровень. Обычно это случаи, когда вся платформа не работает или значительно ухудшается пользовательский опыт. По сути, этот уровень используется для любых инцидентов, которые ставят под угрозу бизнес или приводят к потере значительных сумм дохода.
Для инцидентов уровня SEV-1 обычно существует свой собственный специфический процесс SEV-1, в котором команда по управлению инцидентами разделяется на группу разрешения и группу коммуникации. В инцидентах участвует от нескольких десятков до иногда сотен человек.
Время реагирования — минимальное, наблюдение 24/7, информацию необходимо передать высшему руководству (например, техническому директору или руководителю разработки). Часто об инцидентах такого уровня стоит сообщить публично вашим клиентам.
Постмортемы обязательны. На них стоит пригласить руководство.
SEV-2 (высокое воздействие)
Инциденты уровня SEV-2 имеют высокий уровень воздействия, но не достигают такого масштаба, когда требуется вовлекать широкий круг специалистов. Этот уровень может влиять на доход и требует быстрого разрешения, но локализован для конкретной соответствующей инженерной команды. Эта команда хорошо знает затронутый компонент системы, который вышел из строя.
Реагировать нужно 24/7 и быстро, например, в течение 15 минут по SLA. Информация будет передана лидеру соответствующей инженерной команды (например, вице-президенту или директору). Иногда стоит сообщить об инциденте клиентам, которых он затрагивает.
Необходимо провести постмортемы с соответствующей инженерной командой.
SEV-3 (среднее воздействие)
Инциденты уровня SEV-3 имеют среднее воздействие, вызывая некоторые неудобства у клиентов, но имеют незначительное или нулевое влияние на доход. Этот уровень приоритетнее, чем любые другие повседневные задачи, но не требует непрерывного реагирования 24/7. Эти проблемы могут быть решены в рабочее время и должны быть решены до полного разрешения.
Уровень SEV-3 по сути является «дневным SEV-2», так как в рабочее время инцидент должен получать такое же внимание и приоритет, как и SEV-2, с той лишь разницей, что для инцидента уровня SEV-3 усилия должны быть завершены в конце рабочего дня, чтобы избежать выгорания инженеров, находящихся в режиме ожидания.
Соответственно, время реагирования должно быть таким же, как у SEV-2 в рабочее время (в течение 15 минут), но в нерабочее время реакция является опциональной по усмотрению соответствующей инженерной команды.
Постмортемы необязательны. Многие инциденты уровня SEV-3 не требуют такого уровня инвестиций, но инженерная команда может принять решение составить документ с последующим анализом, чтобы зафиксировать действия. Обычно это делают для сложных инцидентов уровня SEV-3, которые трудно решить, или для повторяющихся инцидентов уровня SEV-3, имеющих общую причину.
SEV-4 (низкое или нулевое воздействие)
Инциденты уровня SEV-4 имеют низкое или нулевое воздействие, и типичные пользователи не могут заметить ухудшения пользовательского опыта. Этот уровень не имеет приоритета перед другими задачами и может получить отсроченное внимание в зависимости от пропускной способности команды.
Хотя сигнал тревоги указывает на то, что какой-то компонент находится в деградированном состоянии. Это может быть незаметно для пользователей или может быть настолько незначительным, что просто не привлекает внимания.
Отреагировать на инцидент нужно в течение 1 рабочего дня по SLA. Действия по смягчению могут быть отложены или запланированы по усмотрению команды. Постмортемы не требуются.
Распространённая ошибка: слишком мало уровней
Часто возникает вопрос, почему не использовать три уровня. На первый взгляд кажется, что уровень SEV-4 не имеет большой ценности, зачем его включать в систему уровней?
Польза уровня SEV-4 заключается в его способности служить системой раннего оповещения. Сигналы тревоги обычно настраиваются с разными порогами важности.
Например, использование хранилища базы данных часто предсказуемо, и для него установлен максимальный размер. Это означает, что можно настроить сигнализацию следующим образом:
Установить уровень SEV-1, если критически важная база данных полностью исчерпает место для хранения.
Установить уровень SEV-2, если критически важная база данных с высокой вероятностью исчерпает место для хранения в ближайшие 24 часа.
Установить уровень SEV-3, если критически важная база данных с высокой вероятностью исчерпает место для хранения в ближайшую неделю.
Установить уровень SEV-4, если критически важная база данных с высокой вероятностью исчерпает место для хранения в ближайшие два месяца.
Уровень SEV-4 полезен тем, что сигнализация заранее предупреждает инженерную команду о скором переходе системы в аварийное состояние. Когда срабатывает сигнализация уровня SEV-4, у команды ещё достаточно времени, чтобы запланировать свою деятельность и отреагировать на проблему, не откладывая всё остальное. Это как срабатывающая за некоторое время до пожара пожарная сигнализация — очень важное раннее предупреждение. Оно позволяет спокойно и упорядоченно отреагировать на проблему, которая, будет расти и усугубляться, если на неё не обращать внимание.
Распространённая ошибка: слишком много уровней
Также часто встречается неправильное понимание степени серьёзности инцидентов, когда компании разрабатывают 5-уровневую систему серьёзности. Затем уровню SEV-5 присваиваются ошибки или проблемы с технической поддержкой. Однако это неправильное понимание разницы между ошибками и инцидентами. То, что ошибки можно создавать и отслеживать в той же системе, что и инциденты, не означает, что так и должно быть. На самом деле для ошибок должен быть отдельный процесс управления ошибками, который отслеживает приоритет каждой ошибки, а не перегружает серьезность инцидента, чтобы охватить оба варианта использования.
На первый взгляд может показаться, что ошибки похожи на инциденты, поскольку и те, и другие являются незапланированной работой, однако на этом сходство заканчивается. Ошибки обычно являются результатом пропущенного QA-тестирования и являются ошибкой в процессе разработки. Многие ошибки — это мелкие раздражители, которые не оказывают влияния на прибыль и иногда не исправляются неделями, месяцами и даже годами, а другие ошибки представляют собой критические сбои в работе пользователей и требуют приоритетного исправления.
С другой стороны, инциденты — это чрезвычайные события, требующие внимания из-за серьёзности их воздействия на пользователей. Если эти два процесса смешать вместе, то пострадают оба.
Если вы планируете внедрять SRE-практики в вашей компании, приходите в Слёрм на курс SRE: data-driven подход к управлению надежностью систем. На время обучения вы станете SRE для сервиса покупки билетов в кинотеатр. Решая предложенные кейсы, вы получите представление, чем занимается SRE в реальности.
