Как устроена техподдержка в идеальном мире, все знают: сработал алерт, и команда сразу понимает, почему он сработал и что с этим делать!
Как бывает в реальном мире — тоже все знают: то алерты не срабатывают тогда, когда должны бы, и всё летит к чертям… то алертов столько, что не успеваешь понять, какой из них критичный, а какой — «мусорный».
В общем, «всё сложно». Но может стать сильно проще — если внедрить грамотный менеджмент алертов. Как этого достичь — делимся своим опытом поиска ответа на вопрос в заголовке.
Организация потока алертов
Основа правильно организованного (эффективного и не чрезмерного) потока алертов — это их разноуровневое деление. Что это означает? То, что на один инцидент в разных частях системы нужно расставить несколько алертов.
Такой подход необходим по двум причинам. Первая — обязательно должны быть алерты, которые позволяют предотвратить инцидент. К примеру, чтобы на сервере внезапно не кончилась память, нужно настроить алерт на то, что скоро заполнится жесткий диск. Это могут быть оповещения, что на диске осталось только 80%, 85% и 90% памяти.
Вторая причина: часто для понимания, что за инцидент происходит или грядет, нужно несколько алертов, которые его характеризуют.
Например, та же нехватка памяти на сервере затрагивает несколько частей системы сразу. Не хватает памяти — падают приложения, срабатывают алерты по ним. Сбой в приложениях — пользователи не могут зайти на сайт, что вызывает алерты по ошибкам авторизации или доступа.
Но бывают и сложноуловимые инциденты, для определения которых удается сформировать только 1-2 алерта. А иногда происходят инциденты, вовсе не вызывающие алертов, — из-за недостаточной полноты покрытия инфраструктуры мониторингом.
Существует и обратная сторона медали — когда алерты хлещут потоком, но при этом проект прекрасно себя чувствует. Так бывает из-за сиюминутных колебаний нагрузки, которая не превышает критических значений.
Одна из основных задач организации потока алертов — как раз упорядочить текущий мониторинг так, чтобы по алертам можно было отследить всю картину развития инцидента и вовремя его предотвратить.
Как правильно организовать поток алертов?
-> Создайте набор корректно срабатывающих алертов. Помочь в этом может наша другая статья, в которой речь идёт о показателях системы, которые необходимо мониторить.
-> Проследите, чтобы алерт гарантированно дошел до адресата. В нашей практике это дежурные инженеры, которые круглосуточно следят за работой клиентских проектов.
-> Фиксируйте срабатывание и факт доставки алерта для последующего анализа. Обычно для этого все алерты, инциденты и действия сотрудников техподдержки логируются.
Как вообще алерт может потеряться? Вариантов несколько:
- он “утонул” в потоке других алертов;
- ему не придали значения из-за некорректной приоритезации;
- его не увидели из-за того, что отсутствует система эскалации.
Методы и инструменты, которые помогают настроить поток алертов
- Единая точка сбора и хранения алертов. Приложение или другой инструмент, который упрощает анализ инцидента во время и после аварии.
- Ранжирование алертов по уровню критичности. Отдавая приоритет действительно важным инцидентам, вы ускорите его разрешение. Инциденты, которые могут привести к остановке системы, — это высший уровень «угрозы». Инцидент, который ведет к деградации в работе, не так страшен и может пока подождать. На алерт, который говорит, что когда нибудь что-то пойдет не так, стоит обратить внимание уже после того, как вы устранили все главные опасности.
- Схема эскалации. У каждого алерта должен быть получатель — сотрудник ТП или даже команда, — который способен справиться с возникшей задачей. Иначе алерт может быть зафиксирован, но на этом всё: его не проэскалировали — инцидент остался без разрешения.
- Координация работы отделов. Есть ситуации, когда нужно планово сломать что-то в системе. Например, чтобы понять узкие места, перенастроить мониторинг или переделать часть инфраструктуры. Для таких осознанных поломок предусмотрена возможность так называемого мьюта — отключения потока алертов, чтобы они не мешали команде ТП. Соответственно, необходимо сообщать техподдержке, когда и как долго будут проводиться подобные работы.
Ещё критерием правильно настроенного потока алертов является нагрузка на сотрудников техподдержки. В целом все зависит от системы мониторинга, но наша эвристика — не более двухсот алертов в смену на одного сотрудника. Это и выполнимо чисто физически, и показывает, что поток сигналов от системы организован корректно.
Что может пойти не так, если его неправильно организовать?
Разные алерты могут попадать в разные каналы: Slack, который используют разработчики, Telegram для техподдержки или ещё куда-то. Переключаясь между ними, сотруднику ТП будет сложно понять, что происходит на самом деле. Поэтому важно, чтобы было единое место сборки и хранения алертов, например, дашборд, который помогает оценить ситуацию в целом.
Усложняется анализ алертов «на месте», из-за чего команда ТП может пропустить инцидент.
Если за алертами не закреплена схема эскалации, есть вероятность, что команда вовремя не сможет среагировать на аварию. Бывают ситуации, когда дежурный по каким-то причинам не справляется со всеми инцидентами. На этот случай всегда должен быть сотрудник (или целая команда), который поможет разобраться, в чем дело, и минимизировать ущерб.
Как часто должны срабатывать алерты?
Алерты должны срабатывать регулярно, только если это логически обосновано. К примеру, оповещение о том, что пора обновить SSL-сертификат, будет приходить периодически. И это нормально, ведь время от времени срок действия сертификата заканчивается, и его нужно продлевать.
Если алерт срабатывает постоянно, но он не завязан на подобную причину, — это сигнал о том, что мониторинг настроен неправильно.
Например, алерт о том, что заканчивается место под бэкапы, срабатывает раз в неделю или раз в месяц. Это может свидетельствовать о проблеме в настройке ротации или в неверной оценке скорости прироста данных.
Да, бывает так, что на подобные ситуации приходится закрывать глаза по разным причинам: сейчас нет ресурсов, есть более срочные задачи и т.д. Но это не выход. Если загрузка ЦП поднимается до критического уровня, но для системы раз в день это нормально, зачем тогда нужен этот алерт? Получается, надо перерабатывать его логику так, чтобы он срабатывал только тогда, когда это может вылиться в инцидент.
Анализ инцидентов и алертов — почему это важно?
Мониторинг и техподдержка должны подстраиваться под сам проект и развиваться вместе с ним. Это невозможно без обратной связи.
Хотя бы потому, что всегда есть инциденты, характерные только для конкретного проекта. Отчасти поэтому у бизнеса не всегда выходит самостоятельно сделать качественный мониторинг. Анализ инцидента и алертов, которые срабатывали во время происшествия, покажет, как донастроить текущий техсаппорт и скорректировать инструкции, чтобы избежать аналогичных аварий.
Даже алерты, которые вы настраиваете, основываясь на best practices опытных коллег, стоит проанализировать. В одном случае конкретное оповещение может быть чрезвычайно полезным, а в другом создаст ненужный шум и помешает отреагировать на важный сигнал системы.
Как правильно анализировать инциденты и поток алертов?
Прежде всего, смотрите на происхождении инцидента, особенно если случился даунтайм системы. В этом случае важно понять:
- сразу ли дежурные увидели инцидент;
- были ли алерты, по которым можно было предотвратить инцидент;
- соответствовали ли приоритеты алертов степени важности инцидента;
- если да, то можно ли написать какие-то инструкции именно к ним, чтобы в следующий раз просто не допустить даунтайма.
Далее проанализируйте действия команды ТП: знали ли они, что нужно делать, были ли инструкции, были ли какие-то проблемы с эскалацией. Если ответ на одни из этих вопросов — нет, это сигнал, что необходимо дорабатывать эти элементы.
Следующее, о чем стоит подумать — как сделать так, чтобы инцидент не случился в будущем. Какие инструкции следует обновить, какие новые алерты настроить, а метрики охватить, чтобы предотвратить аварию. Например, стоит создать горячий резерв для системы, чтобы быстрого на него переключиться, или доработать инфраструктуру. В общем, любой анализ должен закрепляться выводами, которые вынесены из полученного опыта.
Обработку алертов надо анализировать не так, как обработку инцидентов. Тут стоит обращать внимание непосредственно на сам процесс работы — например, если кого-то из коллег тревожит, что какой-то алерт всплывает регулярно, а раньше этого не было. Это может указать на неполноту покрытия системы или износ железа.
Например, мы раз в неделю по определенным критериям выделяем алерты, которые уж слишком часто срабатывали. И если на этой неделе не было инцидента, который мог бы их вызвать, анализируем, что означают эти сигналы.
При анализе конкретного алерта важно понять, валиден ли он в целом для логики системы. Если да, то не слишком ли чувствительные у него пороги. А если тут ответ нет, то вероятно, в системе есть проблема, которую необходимо устранить, но все её игнорируют.
Как делать не надо?
Пара напоминаний о том, как не превратить техподдержку в ад для сотрудников.
- Не взваливайте на одного пусть даже и высококвалифицированного специалиста все алерты в системе. Именно так образуются узкие места в системе мониторинга, а где тонко — там и порвется.
- Не пренебрегайте назначением ответственных. Обязательно доводите до команды дежурных, к кому обратиться в случае, если они не могут справиться с инцидентом или не готовы принимать какие-то решения из-за недостатка ответственности.
Так как же жить с потоком алертов и не сойти с ума?
Ответ — никак. Если у вас нет менеджмента алертов, то любые бестпрактисы не помогут. Да и настроенный по ним мониторинг может быть далек от идеала. Мало того что часть из них применима далеко не во всех проектах, так и ещё для грамотного управления инцидентами и алертами требуется немалый опыт. А он есть далеко не у каждой компании.
