Перевод статьи директора по инфраструктуре @Synthesio — крик души про усталось от алертов и боль от не cloud-ready мониторинга.В прошлом году я и мой коллега Гийом провели два авральных месяца, когда только мы вдвоем остались на поддержке. Мы отработали более 300 часов сверхурочно, что в 4 раза больше обычного и вдвое больше по сравнению с самым загруженным месяцем с тех пор как мы работаем в компании.
У нас было очень много инцидентов и у каждого из них были причины, но на самом деле примерно половина не требовала немедленного вмешательства. Тем не менее мы получали алерты, и нам приходилось просыпаться среди ночи или отвлекаться в выходные дни, чтобы все поправить. Потому что с такой кучей алертов мы не знали, что может подождать, а что критично и требует немедленной починки.
Перед этим моя команда потратила 2 года на улучшение инфраструктуры. Мы заменили устаревшее программное и аппаратное обеспечение, переключились на модель работы в двух дата-центрах и сделали, чтобы все системы были задублированны. Мы также улучшили мониторинг, добавив более 150 000 метрик и 30 000 триггеров, более 5000 из которых алертили в Pagerduty.
У нас была отличная инфраструктура и отличный мониторинг, но вместе с тем и проблема постоянно поступающих оповещений.
Старая система мониторинга и оповещения была создана для нашей старой инфраструктуры, над которой мы взяли контроль двумя годами ранее и которая не могла пережить потерю ни одного сервера. Существовавший мониторинг не подходил для нашей новой инфраструктуры и его нужно было полностью переделывать.
За эти два года, мы добавили огромное количество сервер-ориентированных, а также функциональных чеков. И, поверьте, это были отличные чеки.
В одно прекрасное утро понедельника я сказал Гийому, что мы переключаемся с мониторинга, ориентированного на инфраструктуру, на бизнес-ориентированный мониторинг.
> «Мы можем позволить себе потерять половину любого кластера: поиска, баз данных, обработки, или даже целого дата-центра, если поток данных останется прежним.»
Идея была многообещающей, но мы не знали, возможно ли ее осуществить, учитывая специфику нашей текущей системы мониторинга.
Оказалось, что это легко. Мы начали переделывать каждое оповещение, которое приходило за последние месяцы, под одно требование:
> «Не надо оповещать о том, что не требует немедленных действий и не критично для бизнеса.»
Мы начали с малого и “ослабили” пороги алертов для наших кластеров Elasticsearch. Каждый кластер состоял из более чем 40 серверов, что позволяло легко переживать потерю железа без влияния на production. Кроме того эти серверы были сильно нагружены в течение последних двух месяцев, и именно от них приходило большая часть оповещений. Мы оставили только те оповещения, которые относились ко всему кластеру целиком, и оставили так на неделю, чтобы посмотреть, что будет.
Все прошло чудесно.
Через неделю мы проделали тоже самое на всей платформе. Для каждого компонента мы задавали себе простой вопрос:
> «Если мы потеряем это, сможет ли оно подождать до следующего утра или следующего понедельника?»
Если ответ был «да», уровень оповещения снижался. Ответ «нет» часто означал отсутствие функциональных чеков, и тогда мы их добавляли.
Это методика сработала прекрасно. Мы уменьшили количество триггеров, поднимающих тревогу в Pagerduty с 5000 до 250. В первый месяц после этого количество сверхурочной работы упало в 4 раза. 3 месяца спустя, оно уменьшилось в 7,5 раз по сравнению с нашими самыми загруженными месяцами. Работать стало прекрасно.
Тем не менее, один вопрос остался открытым: «Могли ли мы сделать это раньше?»
Это сложный вопрос и на него нет конкретного ответа. Часть инфраструктуры была готова для переключения с сервер-ориентированного на бизнес-ориентированный мониторинг. Но у нас тогда было слишком много вещей, которые по приоритету стояли выше проблемы уменьшения количества оповещений. Или, честно говоря, у нас было так много задач, требующих решения, что у оповещений был второстепенный приоритет.
>«Проблема снижения количества оповещений стала приоритетной, только когда все вышло из-под контроля.»
Спустя несколько месяцев я могу сказать, что проблема снижения количества оповещений должна была стать главной, прежде чем ситуация вышла из-под контроля, по нескольким причинам:
- Постоянные предупреждения не позволяли команде сосредоточиться на том, что было важно.
Отвлечение внимания даже на то, что может подождать несколько часов, снижает нашу производительность, когда мы работаем над вещами, которые не могут ждать.
- Пробуждение среди ночи каждые сутки, несколько раз за ночь выматывает команду и делает людей менее продуктивными днем и более склонными к ошибкам.
- Слишком много вмешательств в нерабочее время стоило компании огромных денег, которые вместо этого можно было бы потратить на улучшение инфраструктуры или найма кого-то другого.
Что делать дальше — тоже очевидно, и у нас уже есть первые наработки: анализ трендов, для того чтобы наша система мониторинга могла сигнализировать заранее, до возникновения проблем. Об этом мы напишем в следующей статье.
