Хабрахабр

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

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

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

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

Что такое CASE?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Evaluated — оценка

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

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

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

Заключение

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»