Мне совсем недавно пришлось отвечать на вопрос о том, как выстроить систему алертов при мониторинге высоко нагруженного сервиса. После этого я пошел изучать тему глубже и нашел совсем свежую статью в блоге Google Cloud об использовании uptime checks для мониторинга availability. Идеи, которые в ней изложены, в основном хорошо известны (в частности, из SRE book) либо интуитивно понятны, но собранные вместе в краткой форме могут служить своего рода чек-листом. Ниже он и есть.
Надо минимизировать шум/ложные срабатывания
Необходимость постоянно реагировать то на одно, то на другое, может приводить к стрессу и выгоранию. Алерт нужен лишь тогда, когда без ручного вмешательства не обойтись. О прочих инцидентах можно автоматически создавать тикеты и рассматривать их в обычной рабочей обстановке. Таким образом, ключевые вопросы: 1) какие события мы будем алертить и 2) почему.
Алерты должны срабатывать при снижении удовлетворенности пользователей
В идеале срочное вмешательство должно требоваться только тогда, когда отказ тех или иных компонентов сказывается на бизнесе. Если клиенты не могут совершить покупку или даже просто зайти на сайт магазина, это важно. Если отказала какая-то нода, но все продолжает работать без ухудшения пользовательского опыта, это может подождать.
Алерты должны возникать при сбоях в работе приложений, а не инфраструктуры
Чем больше инфраструктура автоматизирована, тем на более высокой степени абстракции мы находимся с точки зрения алертов. В идеале нас должны перестать интересовать сами по себе сбои в инфраструктуре. Вместо этого мы будем обращать внимание только на сбои приложений. Иными словами, алертить только в ситуациях, когда пользователь не получает от приложения то, для чего оно служит.
В качестве базы для мониторинга availability можно использовать uptime checks
Это очень простой и быстрый способ мониторинга, не требующий ни сложных инструментов, ни особых усилий. При этом с его помощью мы тоже можем посмотреть на работу нашего сервиса под разными углами: например, мы можем мониторить, открывается ли сайт, доступен ли он из различных регионов и отвечает ли наш балансировщик нагрузки.
Uptime checks отлично подходят для мониторинга критических сервисов, которые нечасто используются
Представим себе, что у нас есть сервис, который получает всего несколько запросов в день, но нам очень важно, чтобы они были обработаны. Мониторинг запросов может рассказать о проблеме слишком поздно. Простые, но регулярные проверки uptime покажут, что сервис мертв еще до того, как к нему придет важный запрос.
Три вещи, которые нужно оценивать при алертинге с помощью uptime checks
Частота проверок. Представим себе, что предыдущая проверка только что произошла, после чего сервис сразу сломался. Как много времени нам понадобится, чтобы отреагировать на инцидент, и отказ какой продолжительности является для нас терпимым?
Правильная настройка. Мы можем проводить uptime checks, например, с помощью ICMP. Но что если специалисты по безопасности изменили настройки файрвола, и протокол оказался заблокирован? Приходится иметь в виду возможные изменения в системе, препятствующие проверкам.
И снова минимизация шума. Большие системы в любом случае рождают шум. Если у нас нет ответа на вопрос, что ожидается от инженера в ответ на направленный ему алерт, возможно нам не нужен такой алерт.
DikSoft
Рекомендации - маркетинг чистой воды. Пускай ваши розовые пони не парятся по поводу того, где они живут, и долго ли они живут (умрут - ещё создадим). Лишь бы эго творцов высокого полёта было всегда в иллюзии, что всё прекрасно.
Так и рождается снобизм разработчиков - "сетевые инженеры не нужны", "инфраструктура - не барское дело", "DBA - чернорабочий, нам абстракции подавай".
В результате применения такого подхода на выходе получаются дорогущие приложения-мутанты из миллиона микросервисов, отображающие одну кнопку, которая через раз нажимается. И пафосные презентации по DDD, SRE и т.п.
ИТ сервис делить так , как предлагается - путь в никуда. Всё важно. И бизнес логика и компоновка (архитектура) и то, на чем оно работает.
lyova Автор
Обычный мониторинг инфраструктуры никто не отменял, просто статья об алертах, то есть о тех случаях, когда SRE надо прямо сейчас что-то чинить. Неслучайно Kubernetes стал стандартом де-факто при эксплуатации высоко нагруженных приложений. Мы хотим, чтобы приложение реплицировалось и скейлилось автоматически. Сейчас это делает оркестратор, а раньше для этого кому-то алерты прилетали. Так что я думаю, что предпосылка для взглядов, описанных google, не в привлекательности идеи смотреть на все с точки зрения бизнеса, а во все нарастающей автоматизации инфраструктуры.
DikSoft
А за самим оркестратором и тем, в чём он живёт, получается, следить не нужно, просто купите у гугла, так? )
Когда "надо чинить прямо сейчас" неплохо было бы знать для начала на каком слое проблема ..
lyova Автор
Следить будем за всем, а алертить только в том случае, когда отказ сказывается на пользователях. Если не сказывается, будем чинить в спокойной обстановке.
Как я и сказал, от мониторинга системы на всех уровнях не отказываемся. Это как раз и позволит понять, на каком слое проблема. Я не увидел в том, что пишет Google, ничего противоречащего этому.
DikSoft
Т.е. подход "оно как-то ещё работает и это хорошо" Вас устраивает?
lyova Автор
Когда нам надо принять решение, будить ли человека, чтобы он немедленно шел и разбирался, меня этот подход полностью устраивает. Такие ситуации должны быть редкостью. Зачем нам будить человека, ставить его в стрессовую ситуацию, если пользователи несмотря на поломку могут нормально пользоваться сервисом? Лучше он встанет утром выспавшимся, придет на работу и во всем разберется.
DikSoft
Будить ночью это конечно крайний случай, если сервис не 24/7. Плохо другое. С таким подходом он у Вас и днём будет беззаботно распивать смузи с такими же наивно восторженными разработчиками, у которых "всё работает".
Если только вы заботу о платформе и инфраструкткре не купили у гугла/амазона. Хотя и там я бы алерты не выключал. Качество сервиса в последнее время большая проблема у всех гигантов.
lyova Автор
Я думаю, что большинство сервисов сегодня 24/7, особенно если они рассчитаны на пользователей из разных концов мира или даже одной большой России. Но хорошо, давайте посмотрим на это с другой стороны.
Исследования показывают, что постоянный context switching плохо влияет на продуктивность работы инженеров. Если SRE постоянно приходится прерывать запланированные работы из-за того, что прилетел алерт, он сделает меньше работы. При этом запланированные инфраструктурные улучшения и автоматизация в конце концов даже важнее для компании, чем устранение проблем, если эти проблемы не оказывают критического влияния на пользовательский опыт.