Дзиіііііінь! На годиннику 3 ранку, ви дивитеся чудовий сон, і раптом – дзвінок. Цього тижня ви чергуєте, і, мабуть, щось трапилося. Автоматизована система кличе розібратися, у чому річ. Це важливий момент управління сучасними комп'ютерними системами, але давайте подивимося, як зробити повідомлення зручнішим для людей.
Знайомтесь з філософією моніторингу, яка народилася за кілька десятиліть моїх чергувань у різних командах моніторингу. На неї багато в чому вплинула справжня Біблія від Роба Єващука (Моя філософія повідомлень), включена до книги , і книга Джона Олспо (Примітки щодо налаштування оповіщень).
, и - Дякую за допомогу в редагуванні посту.
Що таке CASE?
Я вирішив придумати гарну абревіатуру, як у або . Я кличу це метод CASE. Він описує чотири моменти, на які потрібно звернути увагу під час роботи з автоматичним моніторингом:
- (Прив'язка до контексту)
- (практична цінність)
- (Акцент на симптоми)
- (Оцінка)
Якщо ви використовуєте CASE, ви ставитеся до повідомлень зі здоровим пофігізмом і не будіть людей ночами. Потрібно регулярно оцінювати моніторинг щодо корисності та ефективності. Коли людина отримає повідомлення, у нього будуть кращі ментальні моделі та більше впевненості.
Щоб легше запам'яталося, уявіть, що вам потрібний CASE. прим.перекладача], щоб виправдати кожне сповіщення. :sunglasses:
І навіщо це все?
. З багатьох причин. І CASE не усуне їх усі. Але з ним ночами ви прокидатиметеся від якісніших повідомлень. Цей метод охоплює різні організаційні процеси, які також допоможуть у цій справі.
Принадність методів RED і USE у цьому, що з допомогою ми не тільки знаємо, як працювати, а й говоримо друг з одним однією мовою. Я сподіваюся, що з методом CASE буде простіше обговорювати повідомлення, які захищають наші системи, але не дають спокою колегам.
Суть у тому, що треба створити в організації таку культуру, де до повідомлень ставляться зі здоровим пофігізмом. Повідомлення можуть створюватись у справі, але не факт, що пізніше вони не втратять цінність. Чому ми налаштували це повідомлення? Чи давно переглядалися його критерії? З CASE на ці запитання можна знайти відповіді.
Context-Heavy - прив'язка до контексту
3 ранку - не найкращий час, щоб читати повідомлення, в яких багато розумних слів. Щоб ефективно відреагувати, потрібна інформація. В ідеалі це має бути інформація про конкретну проблему, з якої одразу зрозумілий контекст, і потрібно налаштовувати повідомлення так, щоб це було можливо. Це «спостереження» та «орієнтація» з . На це налаштування не шкода витратити час, тому що постійно відволікати людину ще дорожче. Давайте шанувати один одного.
У проблем багато джерел. Особливо примари.
Як допомогти черговому? Насамперед черговий бачить повідомлення, тому всі гіпотези він будує на його основі. Потім він дивиться інструкції та дашборди, але чи завжди там є дані щодо конкретного повідомлення, а не просто загальна інформація? Олспо радить «думати, як можна інтерпретувати повідомлення або відреагувати на нього» (слайд 29). Хороше повідомлення орієнтоване на чергового, а не просто налаштоване за пороговим значенням.
Тому ось ідеї, як покращити контекст повідомлень:
- Покажіть користувачеві щось корисне та створене спеціально, а не просто звичайні інструкції чи дашборд. Раніше ми з хлопцями використовували дашборди для розслідування, налаштовані на конкретні повідомлення. Це допоможе, якщо проблема відома і лише заплутає в інших випадках. Тут треба знайти баланс.
- Розкажіть про історію повідомлення: він новий? Він часто спрацьовує? Він сезонний?
- Покажіть останні зміни у стані системи. Нещодавно щось змінилося? (Наприклад, деплой або увімкнення/вимкнення функціоналу.)
- Покажіть стосунки та дайте інформацію для ментальної моделі: залежності системи мають бути чітко видно, бажано із зазначенням працездатності.
- Оперативно зв'яжіть користувача з командою: чи він бачить поточні інциденти, чи може дізнатися, хто ще в компанії отримав повідомлення? Програма активовано?
В ідеалі програма управління інцидентами дає поради, як покращити контекст сповіщення під час розслідування інцидентів. Тут завжди є над чим працювати!
Actionable - практична цінність
Черговий має щось зробити у відповідь на повідомлення? Якщо нічого не потрібно робити чи незрозуміло, що робити, навіщо розбудили? Потрібно уникати повідомлень, які дістають чергових та не вимагають дій.
Що робити? Чого треба?
Раніше коли системи були простими, а команди маленькими, ми налаштовували моніторинг, щоб просто бути в курсі справ. Повідомлення про те, що навантаження на купу зросло, дасть нам контекст, якщо потім сервіс працюватиме зі збоями. У великому масштабі такі повідомлення лише заплутають, тому що наші системи завжди працюють у стані деградації різного ступеня важкості. Це швидко призводить до і, звісно, до втрати чутливості. Тому черговий ігнорує або навіть фільтрує такі повідомлення і не завжди реагує на них як треба. Не трапляйтесь у цю пастку! Не налаштовуйте всі повідомлення поспіль, щоб потім відправляти їх на пошту в якусь богом забуту папку.
Ось як виглядає повідомлення із практичною цінністю:
- Повідомлення потребує дії, а не просто повідомляє новини.
- Цю дію складно чи ризиковано автоматизувати. Якщо дію можна автоматизувати, то візьміть та автоматизуйте, вистачить чіплятися до людей!
- Повідомлення містить термінові рекомендації у вигляді (SLA) або (RTO). Тоді черговий може задіяти програму управління інцидентами в організації.
Хочу уточнити: я не кажу, що повідомлення повинні надходити тільки по найважливіших SLO (service-level objectives, цілі рівня обслуговування) для API. Моніторинг SLO постійно дробиться та ділиться та вимагає однакового підходу до всіх сервісів. Зрозуміло, що ви відстежуватимете найважливіші SLO для клієнтів, які вам платять. Але SLO інфраструктури, наприклад, баз даних, теж потрібно відстежувати. Скоро вам доведеться займатися внутрішніми клієнтами та підтримувати їх. І так до безкінечності.
Symptom-based - акцент на симптоми
Подобається вам це чи ні, але ви працюєте у розподіленій системі (Кавадж). В результаті ви використовуєте різні тактики, щоб ізолювати сервіси та захистити їх від збоїв (Трейнор та ін.)3. І хоча garbage collection, що затягнувся, або задуманий запит до бази даних вказують на неполадки, не потрібно кидатися усувати їх, якщо у користувачів не буде проблем найближчим часом.
Це важливі сигнали, і вони можуть мати практичну цінність, але якщо вони не заважають користувачам, це не настільки терміново, щоб відволікати чергового. Повідомлення на основі причини – це знімки наших ментальних моделей про системний збій. Краще відстежувати важливі симптоми, аніж намагатися перерахувати всі можливі причини збою.
Щоб сповіщення мали практичну цінність, зосередьтеся на , важливі для користувачів. Єващук називає це «моніторингом для користувачів». Пам'ятайте, що цю філософію слід застосовувати по всій організації. Якщо у сервісу десь у глибині інфраструктури виникнуть термінові проблеми, ними займеться відповідна команда. Захист систем від таких збоїв — це окреме питання (Трейнер та ін., розділ про стратегії для мінімізації критичних залежностей).
Симптоми не такі мінливі
Річард Кук нагадує, що у складних системах купа вад, недоліків та проблем. Намагатися перерахувати всі можливі причини — праця Сизіфа. Ви намагаєтесь описувати проблеми, а вони постійно змінюються. Сінді Шрідхаран вважає, що «системи не обов'язково повинні кожну секунду перебувати в ідеальному стані» і краще використовувати людяніший підхід ( («Спостереження за розподіленими системами»), 7).
Уникайте повідомлень за фактом інциденту
Зазвичай для виправлення інцидентів налаштовуються повідомлення причин. І ці обмежені повідомлення про факт того, що трапилося, створюють хибне почуття впевненості, адже система щоразу вигадує нові способи зламатися.
Не обманюйте себе сповіщення про причини. Краще подумайте:
- Чому повідомлення на основі симптомів не помітило проблему?
- Чи корисно покращити контекст для користувача?
- Як покращити інструменти моніторингу, щоб швидше ставити діагноз, а не накопичувати повідомлення про те, що сталося?
Інструменти моніторингу для діагностики допоможуть, тільки якщо ви сприйматимете їх як спосіб перейти від симптому до рішення. Без цього зворотного зв'язку вас просто завалять запізнілі повідомлення та діаграми про минулі збої — і ні слова про майбутніх. Для організації це чудова можливість перейти із оборони в атаку. А у розробників та продуктових менеджерів будуть однакові очікування та зрозумілі цілі. Кейс – CASE (:wink:) – для кожного повідомлення зрозумілий.
Повідомлення на основі причини терпимі в помірній кількості
Іноді наша система майже не залишає нам вибору в плані сповіщень на основі причини. А іноді чергові чудово розуміють, що симптом обов'язково призведе до збою, а отже, містить практичну цінність. Можливо, ви просто не впевнені, що відбувається, і налаштовуєте повідомлення для перестрахування. Сподіватимемося, що ця дія потрібна тимчасово, поки ми не змінимо систему, щоб вирішити питання зниження продуктивності.
Пам'ятайте про інші компоненти CASE, коли знаєте про такі ситуації. Якщо це тимчасово, значить, що не думати головою.
Evaluated — оцінка
Будь-які зміни в системі (новий код, нова інфраструктура, та будь-що нове) розширюють асортимент збоїв (Кук, 3). Це повідомлення точно все ще працює, як очікувалося? Чіткі та актуальні ментальні моделі систем та досвід реагування на деякі повідомлення на підтримку - це ключові риси . Дефекти в системах постійно розвиваються, і ми маємо встигати за ними.
Потрібно постійно оцінювати якість кожного повідомлення, щоб вони працювали, як очікувалося. Шановні керівники! Вашим командам буде набагато простіше, якщо ви допоможете налагодити цей процес! Ось кілька ідей щодо оцінки:
- Використовуйте , або інші методи тестування повідомлень. Команда може зробити це сама, не задіявши важку систему управління інцидентами!
- Увімкніть збір даних про всі повідомлення, пов'язані з інцидентами, до програми керування інцидентами. Визначайте корисні, шкідливі, недоречні, незрозумілі і т. д. Використовуйте їх як фідбек.
- Правильні повідомлення спрацьовують нечасто та ретельно перевірені. Переконайтеся, що всі посилання працюють, вказують на потрібний контекст і т.д.
- Якщо повідомлення не спрацьовує ніколи або спрацьовує занадто часто, щось не так. Починіть його або видаліть. Остерігайтеся надмірної пасивності чи активності!
- Налаштуйте для повідомлень мітки часу із терміном придатності. Якщо термін придатності минув, оцініть повідомлення за методом CASE та оновіть позначку часу. Регулярно перевіряйте термін придатності, як у їжі.
- Спростіть процес покращення повідомлень. Використовуйте моніторинг у вигляді коду та зберігайте повідомлення у репозиторії Git. Пул-реквести допомагають залучати команду, а у вас буде історія минулих повідомлень. І ви перестанете боятися міняти повідомлення або запитувати дозвіл у тих, хто відповідає за них.
- Налагоджуйте фідбек для повідомлень, навіть якщо це просто щоб чергові позначали повідомлення як марні або нав'язливі. Встановіть посилання або заклик до дії і сповіщайте про фідбек.
- Встановіть у команді правило – нехай чергові працюють над спрощенням чергування, коли мало роботи. Нехай після вас все стане трохи кращим, ніж було до.
Висновок
Я вважаю, що метод CASE допомагає розробникам та організаціям обговорювати налаштування та надсилання автоматичних повідомлень. Один розробник може почати оцінку повідомлень за методом CASE, а потім до нього приєднається вся організація з іншими розробниками, керівництвом та програмами управління інцидентами, щоб підтримувати повідомлення у хорошому стані. Для цього не потрібні особливі інструменти або складні процеси.
Вся галузь має задуматися про людський чинник під час чергування без шкоди першокласного обслуговування клієнтів. Всі ці інструменти та практики можна і потрібно вдосконалювати. Сподіваюся, метод CASE допоможе цьому.
Насолоджуйтесь удосконаленими повідомленнями!
Джерело: habr.com