Недавно мне задали вопрос о том, какую систему оповещения я бы построил для загруженного отдела. После этого я пошел изучать тему более глубоко и нашел для себя совершенно новую Запись в блоге Google Cloud об использовании проверка доступности для мониторинга доступность. Идеи, которые он описывает, в основном хорошо известны (особенно из книги SRE) или интуитивны, но собранные вместе в сжатой форме могут служить своего рода контрольным списком. Ниже есть.

Сведите к минимуму шум/ложные срабатывания

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

Оповещения должны срабатывать, когда удовлетворенность пользователей падает.

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

Оповещения должны инициироваться сбоями в работе приложений, а не инфраструктурой.

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

ЧИТАТЬ   16 человек рассказали о том, какие национальные традиции, связанные с едой, приводят в трепет всех иногородних

Вы можете использовать тестирование времени безотказной работы в качестве основы для мониторинга времени безотказной работы.

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

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

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

Три вещи, которые следует оценить при оповещении с помощью тестирования времени безотказной работы

  • Проверьте частоту. Представим, что только что произошла предыдущая проверка, после которой сервис сразу остановился. Сколько времени нам потребуется, чтобы отреагировать на инцидент, и как долго мы можем терпеть неудачу?

  • Правильная регулировка. Мы можем реализовать проверка доступности, например, с помощью ICMP. Но что, если специалисты по безопасности изменят настройки брандмауэра и протокол будет заблокирован? Следует иметь в виду возможные изменения в системе, препятствующие проверкам.

  • Опять же шумоподавление. Большие системы в любом случае генерируют шум. Если у нас нет ответа на вопрос, что ожидается от инженера в ответ на присланный ему алерт, может быть, такой алерт нам и не нужен.

Google не просто опубликовал его статью. Так он же объявил ваша услуга для тестов доступности, поддерживающих мониторинг GCP, AWS, собственных хостов и приложений.

ЧИТАТЬ   Обновление правил Google Реклама в отношении рецептурных лекарств для животных

Source

От admin