Метод CASE: гуманный мониторинг

Дзииииииинь! На часах 3 утра, вы смотрите чудесный сон, и вдруг — звонок. На этой неделе вы дежурите, и, видимо, что-то случилось. Автоматизированная система зовет разобраться, в чем дело. Это важный момент управления современными компьютерными системами, но давайте посмотрим, как сделать уведомления удобнее для людей.

Знакомьтесь с философией мониторинга, родившейся за несколько десятилетий моих дежурств в разных командах по мониторингу. На нее во многом повлияла настоящая библия от Роба Еващука My Philosophy on Alerting (Моя философия уведомлений), включенная в книгу по Google SRE, и книга Джона Олспо Considerations for Alert Design (Замечания по настройке оповещений).

Келли Данн, Ариджит Мукхерьи и Максим Петаццони — спасибо за помощь в редактировании поста.

Что такое CASE?

Я решил придумать красивую аббревиатуру, как у метода USE Брендана Грегга или метода RED Тома Уилки. Я зову это метод CASE. Он описывает четыре момента, на которые нужно обратить внимание при работе с автоматическим мониторингом:

• Context-heavy (привязка к контексту)
• Actionable (практическая ценность)
• Symptom-based (акцент на симптомы)
• Evaluated (оценка)

Если вы используете CASE, вы относитесь к уведомлениям со здоровым пофигизмом и не будите людей по ночам. Нужно регулярно оценивать мониторинг на предмет полезности и эффективности. Когда человек получит уведомление, у него будут лучшие ментальные модели и больше уверенности.

Чтобы легче запомнилось, представьте, что вам нужен CASE [то есть кейс, причина — прим.переводчика], чтобы оправдать каждое оповещение. :sunglasses:

И зачем это все?

Дежурство может быть мучением. По многим причинам. И CASE не устранит их все. Но с ним по ночам вы будете просыпаться от более качественных уведомлений. Этот метод охватывает разные организационные процессы, которые тоже помогут в этом деле.

Прелесть методов RED и USE в том, что с их помощью мы не только знаем, как работать, но и говорим друг с другом на одном языке. Я надеюсь, что с методом CASE будет проще обсуждать уведомления, которые защищают наши системы, но не дают покоя коллегам.

Суть в том, что надо создать в организации такую культуру, где к уведомлениям относятся со здоровым пофигизмом. Уведомления могут создаваться по делу, но не факт, что позже они не потеряют ценность. Почему мы настроили это уведомление? Давно ли пересматривались его критерии? С CASE на эти вопросы можно найти ответы.

Context-Heavy — привязка к контексту

3 утра — не лучшее время, чтобы читать сообщения, в которых много умных слов. Чтобы эффективно отреагировать, нужна информация. В идеале это должна быть информация о конкретной проблеме, по которой сразу понятен контекст, и нужно настраивать уведомления так, чтобы это было возможно. Это «наблюдение» и «ориентация» из цикла НОРД. На эту настройку не жалко потратить время, потому что постоянно отвлекать человека — еще дороже. Давайте уважать друг друга.

У проблем много источников. Особенно призраки.

Как помочь дежурному? Первым делом дежурный видит уведомление, поэтому все гипотезы он строит на его основе. Потом он смотрит инструкции и дашборды, но всегда ли там есть данные по конкретному уведомлению, а не просто общая информация? Олспо советует «думать, как можно интерпретировать уведомление или отреагировать на него» (слайд 29)1. Хорошее уведомление ориентировано на дежурного, а не просто настроен по пороговому значению.

Поэтому вот идеи, как улучшить контекст уведомлений:

• Покажите пользователю что-то полезное и созданное специально, а не просто обычные инструкции или дашборд. Раньше мы с ребятами использовали дашборды для расследования, настроенные на конкретные уведомления. Это поможет, если проблема известная, и только запутает в других случаях. Тут надо найти баланс.
• Расскажите об истории уведомления: он новый? Он часто срабатывает? Он сезонный?
• Покажите недавние изменения в состоянии системы. Недавно что-нибудь изменилось? (Например, деплой или включение/отключение функционала.)
• Покажите отношения и дайте информацию для ментальной модели: зависимости системы должны быть четко видны, желательно с указанием работоспособности.
• Оперативно свяжите пользователя с командой: он видит текущие инциденты или может узнать, кто еще в компании получил уведомление? Программа управления инцидентами активирована?

В идеале программа управления инцидентами дает советы, как улучшить контекст уведомления при расследовании инцидентов. Тут всегда есть над чем работать!

Actionable — практическая ценность

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

View post on imgur.com

Что делать-то? Чего надо?

Раньше, когда системы были простыми, а команды маленькими, мы настраивали мониторинг, чтобы просто быть в курсе дел. Уведомление о том, что нагрузка на кучу выросла, даст нам контекст, если потом сервис будет работать со сбоями. В большом масштабе такие уведомления только запутают, потому что наши системы всегда работают в состоянии деградации разной степени тяжести. Это быстро приводит к усталости от уведомлений и, конечно, к потере чувствительности. Поэтому дежурный игнорирует или даже фильтрует такие уведомления и не всегда реагирует на них, как нужно. Не попадайтесь в эту ловушку! Не настраивайте все уведомления подряд, чтобы потом отправлять их на почту в какую-нибудь богом забытую папку.

Вот как выглядит уведомление с практической ценностью:

• Уведомление требует действия, а не просто сообщает новости.
• Это действие сложно или рискованно автоматизировать. Если действие можно автоматизировать, так возьмите и автоматизируйте, хватит приставать к людям!
• Уведомление содержит срочные рекомендации в виде соглашения об уровне обслуживания (SLA) или целевого времени восстановления (RTO). Тогда дежурный может задействовать программу управления инцидентами в организации.

Хочу уточнить: я не говорю, что уведомления должны приходить только по самым важным SLO (service-level objectives, цели уровня обслуживания) для API. Мониторинг SLO постоянно дробится и делится и требует одинакового подхода ко всем сервисам. Понятно, что вы будете отслеживать самые важные SLO для клиентов, которые вам платят. Но SLO инфраструктуры, например баз данных, тоже нужно отслеживать. Скоро вам придется заниматься внутренними клиентами и поддерживать их. И так до бесконечности.

Symptom-based — акцент на симптомы

Нравится вам это или нет, но вы работаете в распределенной системе (Кавадж)2. В результате вы используете разные тактики, чтобы изолировать сервисы и защитить их от сбоев (Трейнор и др.)3. И хотя затянувшийся garbage collection или задумавшийся запрос к базе данных указывают на неполадки, не нужно бросаться устранять их, если у пользователей не будет проблем в ближайшее время.

Это важные сигналы, и они могут иметь практическую ценность, но если они не мешают пользователям, то это не настолько срочно, чтобы отвлекать дежурного. Уведомления на основе причины — это снимки наших ментальных моделей о системном сбое. Лучше отслеживать важные симптомы, чем пытаться перечислить все возможные причины сбоя.

Чтобы уведомления имели практическую ценность, сосредоточьтесь на индикаторах производительности, важных для пользователей. Еващук называет это «мониторингом для пользователей». Помните, что эту философию нужно применять по всей организации. Если у сервиса где-то в глубине инфраструктуры возникнут срочные проблемы, ими займется соответствующая команда. Защита систем от таких сбоев — это совершенно отдельный вопрос (Трейнер и др., раздел о стратегиях для минимизации критических зависимостей)3.

Симптомы не такие изменчивые

Ричард Кук напоминает, что в сложных системах куча изъянов, недостатков и проблем4. Пытаться перечислить все возможные причины — Сизифов труд. Вы пытаетесь описывать проблемы, а они все время меняются. Синди Шридхаран считает, что «системы не обязательно должны каждую секунду пребывать в идеальном состоянии» и лучше использовать более человечный подход («Distributed Systems Observability» («Наблюдение за распределенными системами»), 7)5.

Избегайте уведомлений по факту инцидента

Обычно для исправления инцидентов настраиваются уведомления для причин. И эти ограниченные уведомления о факте случившегося создают ложное чувство уверенности, ведь система каждый раз придумывает новые способы сломаться.

Не обманывайте себя уведомлениями о причинах. Лучше подумайте:

• Почему уведомление на базе симптомов не заметило проблему?
• Будет ли полезно улучшить контекст для пользователя?
• Как улучшить инструменты мониторинга, чтобы быстрее ставить диагноз, а не накапливать уведомления о случившемся?

Инструменты мониторинга для диагностики помогут, только если вы будете воспринимать их как способ перейти от симптома к решению. Без этой обратной связи вас просто завалят запоздалые уведомления и диаграммы о прошлых сбоях — и ни слова о будущих. Для организации это отличная возможность перейти из обороны в атаку. А у разработчиков и продуктовых менеджеров будут одинаковые ожидания и понятные цели. Кейс — CASE (:wink:) — для каждого уведомления ясен.

Уведомления на основе причины терпимы в умеренном количестве

Иногда наша система почти не оставляет нам выбора в плане уведомлений на основе причины. А иногда дежурные прекрасно понимают, что симптом обязательно приведет к сбою, а значит содержит практическую ценность. Может быть, вы просто не уверены, что происходит, и настраиваете уведомления для перестраховки. Будем надеяться, что это действие требуется временно, пока мы не изменим систему, чтобы решить вопрос снижения производительности.
Помните о других компонентах CASE, когда разбираетесь с такими ситуациями. Если это временно, не значит, что можно не думать головой.

Evaluated — оценка

Любые изменения в системе (новый код, новая инфраструктура, да что угодно новое) расширяют ассортимент сбоев (Кук, 3).4 Это уведомление точно все еще работает, как ожидалось? Четкие и актуальные ментальные модели систем и опыт реагирования на некоторые уведомления в поддержку профилактического подхода — это ключевые черты организации, ориентированной на обучение. Дефекты в системах постоянно развиваются, и мы должны поспевать за ними.

Нужно постоянно оценивать качество каждого уведомления, чтобы они работали, как ожидалось. Уважаемые руководители! Вашим командам будет гораздо проще, если вы поможете им наладить этот процесс! Вот несколько идей по оценке:

• Используйте хаос-инжиниринг, игровые дни или другие методы тестирования уведомлений. Команда может сделать это сама, не задействуя тяжеловесную систему управления инцидентами!
• Включите сбор данных обо всех уведомлениях, связанных с инцидентами, в программу управления инцидентами. Отмечайте полезные, вредные, неуместные, непонятные и т. д. Используйте их как фидбэк.
• Правильные уведомления срабатывают нечасто и тщательно проверены. Убедитесь, что все ссылки работают, указывают на нужный контекст и т. д.
• Если уведомление не срабатывает никогда или срабатывает слишком часто, с ним что-то не так. Почините его или удалите. Остерегайтесь чрезмерной пассивности или активности!
• Настройте для уведомлений метки времени со сроком годности. Если срок годности истек, оцените уведомление по методу CASE и обновите метку времени. Регулярно проверяйте срок годности, как у еды.
• Упростите процесс улучшения уведомлений. Используйте мониторинг в виде кода и храните уведомления в репозитории Git. Пул-реквесты помогают привлекать команду, а у вас будет история прошлых уведомлений. И вы перестанете бояться менять уведомления или спрашивать разрешение у тех, кто за них отвечает.
• Налаживайте фидбэк для уведомлений, даже если это просто Google форма, чтобы дежурные помечали уведомления как бесполезные или навязчивые. Встройте в само уведомление ссылку или призыв к действию и регулярно просматривайте фидбэк.
• Установите в команде правило — пусть дежурные работают над упрощением дежурства, когда мало работы. Пусть после вас все станет чуть лучше, чем было до.

Заключение

Я считаю, что метод CASE помогает разработчикам и организациям обсуждать настройку и отправку автоматических уведомлений. Один разработчик может начать оценку уведомлений по методу CASE, а потом к нему присоединится вся организация с другими разработчиками, руководством и программами управления инцидентами, чтобы поддерживать уведомления в хорошем состоянии. Для этого не нужны никакие особенные инструменты или сложные процессы.

Вся отрасль должна задуматься о человеческом факторе во время дежурства без ущерба для первоклассного обслуживания клиентов. Все эти инструменты и практики можно и нужно совершенствовать. Надеюсь, метод CASE поможет в этом.

Наслаждайтесь усовершенствованными уведомлениями!

Источник: habr.com