SRE (Site Reliability Engineering) – підхід до забезпечення доступності веб-проектів. Вважається фреймворком для DevOps і говорить як досягти успіху в застосуванні DevOps-практик. У цій статті переклад книги від Google. Цей переклад я готував самостійно та покладався на власний досвід розуміння процесів моніторингу. У телеграм-каналі и я публікував також посилання на переклад 4 розділу цієї книги про цілі рівня обслуговування.
Переклад катом. Приємного читання!
У командах SRE компанії Google є базові принципи та найкращі практики для створення успішних систем моніторингу та повідомлень. У цьому розділі наведено рекомендації про те, які проблеми можуть зустрітися відвідувачу веб-сторінки і як вирішувати проблеми, які ускладнюють відображення веб-сторінок.
визначення
Єдиного словникового запасу, який використовується для обговорення тем, пов'язаних з моніторингом, не існує. Навіть у Google, наведені нижче терміни не є загальновживаними, але ми перерахуємо найпоширеніші інтерпретації.
моніторинг
Збір, обробка, агрегування та відображення кількісних даних у реальному часі про систему: кількість запитів та типи запитів, кількість помилок та типи помилок, час обробки запиту та час роботи сервера.
Моніторинг White-box
Моніторинг, що ґрунтується на показниках, що відображаються внутрішніми компонентами системи, включаючи журнали, метрики профілювання віртуальної машини Java або обробника HTTP, які генерують внутрішню статистику.
Моніторинг Black-box
Тестування поведінки програми з погляду користувача.
Dashboard (панелі моніторингу)
Інтерфейс (зазвичай Інтернет), що надає огляд основних показників здоров'я сервісів. На панелі моніторингу можуть бути фільтри, можливість вибору показників, що демонструються, і т. д. Інтерфейс створений, щоб виявити найбільш важливі для користувачів показники. На панелі моніторингу також можуть відображатися інформація для співробітників технічної підтримки: черга запитів, список високопріоритетних помилок, закріплений інженер для заданої зони відповідальності.
Alert (повідомлення)
Повідомлення, призначені для отримання людиною електронною поштою або іншим шляхом, які можуть бути ініційовані внаслідок помилок або збільшення черги запитів. Повідомлення класифікуються як: тикети, оповіщення електронною поштою та повідомлення в месенджери.
Root cause (коренева причина)
Дефект програмного забезпечення чи людський чинник, які під час усунення не повинні виникати знову. Проблема може мати кілька основних причин: недостатня автоматизація процесів, дефект програмного забезпечення, недостатнє опрацювання логіки роботи програми. Кожен із цих факторів може бути першопричиною, і кожен із них має бути усунений.
Node and machine (нода та машина)
Взаємозамінні поняття, щоб позначити один екземпляр працюючого додатка на фізичному сервері, віртуальній машині або контейнері. На одній машині може бути кілька сервісів. Сервіси можуть бути:
- пов'язані один з одним: наприклад, сервер кешування та веб-сервер;
- не пов'язані сервіси на єдиному апаратному забезпеченні: наприклад, репозиторій коду та майстер для системи конфігурації, такі як або .
Штовхати
Будь-яка зміна конфігурації програмного забезпечення.
Навіщо потрібний моніторинг
Є кілька причин, чому програми потрібно ставити на моніторинг:
Аналіз тривалих трендів
Наскільки велика база даних та як швидко вона зростає? Як змінюється кількість користувачів?
Порівняння швидкодії
Чи швидше виконуються запити на Acme Bucket of Bytes 2.72 у порівнянні з Ajax DB 3.14? Наскільки кешуються запити після появи додаткової ноди? Чи став повільніше працювати сайт порівняно з минулим тижнем?
Alerting (повідомлення)
Щось зламалося і хтось має це полагодити. Або щось скоро зламається і хтось має це скоро перевірити.
Створення дашбордів
Дашборди повинні відповідати на основні питання та включати щось із - затримки (latency), трафік (traffic), помилки (errors) та величину навантаження (saturation).
Проведення ретроспективного аналізу (debugging)
Затримка обробки запиту збільшилася, а що ще трапилося приблизно в цей час?
Системи моніторингу корисні як джерело даних для систем бізнес-аналітики та спрощення аналізу інцидентів з безпеки. Оскільки ця книга присвячена інженерним областям, в яких SRE мають експертизу, ми не обговорюватимемо тут методики моніторингу.
Моніторинг та оповіщення дозволяють системі розповісти, коли вона зламалася, або ось-ось зламається. Коли система неспроможна автоматично відновлювати себе, хочемо, щоб оповіщення аналізував людина, визначив, чи актуальна проблема, усунув і визначив її основну причину. Якщо ви не здійснюєте аудит компонентів системи, ви ніколи не отримаєте оповіщення просто тому, що щось здається трохи дивним.
Навантаження сповіщення людини — досить дороге використання часу співробітника. Якщо працівник працює, сповіщення перериває робочий процес. Якщо співробітник перебуває вдома, оповіщення перериває особистий час і, можливо, сон. Коли сповіщення відбуваються надто часто, співробітники швидко їх переглядають, відкладають або ігнорують вхідні попередження. Іноді вони ігнорують справжнє оповіщення, замасковане шумовими подіями. Перерви в сервісі можуть тривати тривалий час, оскільки шумові події заважають швидкій діагностиці та усунення проблеми. Ефективні системи оповіщення мають хороше співвідношення сигнал/шум.
Визначення розумних очікувань системи моніторингу
Налаштування моніторингу комплексної програми — саме по собі складне інженерне завдання. Навіть маючи значну інфраструктуру інструментів збору, відображення та оповіщення, команда Google SRE з 10–12 членами зазвичай включає одну або дві особи, основне призначення яких у створенні та обслуговуванні систем моніторингу. Ця кількість згодом скоротилася, у міру того, як ми узагальнюємо та централізуємо інфраструктуру моніторингу, але кожна команда SRE зазвичай має принаймні одного співробітника, який займається лише моніторингом. Слід сказати, що хоча досить цікаво спостерігати за дашбордами системи моніторингу, команди SRE ретельно уникають ситуацій, які вимагають від когось дивитися на екран, щоб стежити за проблемами.
Загалом Google перейшов на прості та швидкі системи моніторингу з оптимальними інструментами постфактум-аналізу. Ми уникаємо «чарівних» систем, які намагаються прогнозувати граничні значення або автоматично виявляють першопричину. Сенсори, які виявляють непередбачений вміст у запитах кінцевих користувачів, є єдиним контрприкладом; до тих пір, поки ці сенсори залишаються простими, вони дозволяють швидко виявити причини серйозних аномалій. Інші формати використання даних моніторингу, такі як планування потужностей або прогнозування трафіку являють собою складніше завдання. Спостереження, проведене протягом дуже тривалого часу (місяці чи роки) з низькою частотою дискретизації (годинник або дні), дозволить розкрити довготривалу тенденцію.
Команда Google SRE працювала зі змінним успіхом зі складними ієрархіями залежностей. Ми рідко використовуємо такі правила, як «якщо я дізнався, що база даних почала повільно працювати, отримую оповіщення про уповільнення бази даних, інакше отримую оповіщення про сайт, що повільно працює». Правила, засновані на залежностях, зазвичай відносяться до незмінних частин нашої системи, таких як система для фільтрації трафіку користувача до центру обробки даних. Наприклад, «якщо налаштована фільтрація трафіку до центру обробки даних, не попереджайте мене про затримки обробки користувацьких запитів» - це одне загальне правило для оповіщень від центру обробки даних. Деякі команди Google підтримують складні ієрархії залежностей, тому що наша інфраструктура має постійну швидкість безперервного рефакторингу.
Деякі з ідей, описаних у цьому розділі, як і раніше актуальні: завжди є можливість швидше рухатися від симптому до першопричини, особливо в системах, що постійно змінюються. Тому, хоча в цьому розділі викладено деякі цілі для систем моніторингу та способи досягнення цих цілей, важливо, щоб системи моніторингу були прості та зрозумілі всім у команді.
Аналогічно, щоб підтримувати низький рівень шуму та високий рівень сигналу, підходи до моніторингу об'єктів, за якими здійснюється оповіщення, мають бути дуже простими та надійними. Правила, які генерують попередження для людей, повинні бути простими для розуміння і бути явною проблемою.
Симптоми проти причин
Ваша система моніторингу має відповідати на два питання: «що зламалося» та «чому зламалося».
"Що зламалося" говорить про симптом, а "чому зламалося" про причину. У таблиці нижче наведено приклади таких зв'язок.
РЎРёРјРїС,РѕРј
Причина
Отримання HTTP-помилки 500 або 404
Сервери бази даних відхиляють підключення
Повільні відповіді сервера
Висока утилізація CPU або пошкодження кабелю Ethernet
Користувачі в Антарктиці не отримують гіфки з кітами
Ваша CDN ненавидить вчених і котячих, таким чином деякі IP-адреси опинилися в чорному списку
Приватний контент став доступним звідусіль
Накочування нового релізу ПО змусило файрвол забути всі ACL і пускає всіх поспіль
«Що» і «чому» — одна з найважливіших цеглинок для створення гарної системи моніторингу з максимумом сигналу та мінімумом шуму.
Black-box проти White-box
Ми поєднуємо великий White-box моніторинг зі скромним Black-box моніторингом для критичних метрик. Найпростіший спосіб порівняти Black-box з White-box - це те, що Black-box орієнтований на симптоми і є реактивним, а не проактивним моніторингом: «система прямо зараз працює некоректно». White-box залежить від можливостей внутрішньої перевірки систем: журналів подій чи веб-серверів. Таким чином, White-box дозволяє виявляти майбутні проблеми, несправності, що виглядають як повторна передача запиту і т.д.
Зверніть увагу, що у багатошаровій системі симптом у зоні відповідальності одного інженера є симптомом у зоні відповідальності іншого інженера. Наприклад, знизилася продуктивність бази даних. Повільні читання з бази даних є симптомом для SRE за базами даних, який їх виявляє. Тим не менш, для SRE по фронтенду, що спостерігає повільний веб-сайт, причиною того ж повільного читання бази даних є повільна робота бази даних. Тому White-box моніторинг іноді орієнтований на симптоми, інколи ж на причини, залежно від того, наскільки він великий.
Під час збирання телеметрії для налагодження необхідний White-box моніторинг. Якщо веб-сервери повільно реагують на запити, пов'язані з базою даних, потрібно знати, наскільки швидко веб-сервер взаємодіє з базою даних і наскільки швидко вона видає відповідь. В іншому випадку, ви не зможете відрізнити повільний сервер бази даних від проблеми мережі між веб-сервером і базою даних.
Black-box моніторинг має ключову перевагу при надсиланні оповіщень: ви ініціюєте відправлення повідомлення одержувачу, коли проблема вже призвела до виникнення реальних симптомів. З іншого боку, для проблеми, що ще не виникла, але майбутньої Black-box моніторинг марний.
Чотири золоті сигнали
Чотири золоті сигнали моніторингу — це затримка, трафік, помилки та насиченість. Якщо ви можете виміряти лише чотири показники користувача системи, зосередьтеся на цих чотирьох.
затримка
Час, необхідний обробки запиту. Важливо розрізняти затримку успішних та невдалих запитів. Наприклад, помилка HTTP 500, викликана втратою з'єднання з базою даних або іншим бекендом, може бути діагностована дуже швидко, однак, помилка HTTP 500 може вказувати на невдалий запит. Виявлення впливу помилки 500 на загальну затримку може спричинити помилкові висновки. З іншого боку, повільна помилка навіть швидкої помилки! Тому важливо відстежувати затримку з помилкою, а не просто фільтрувати помилки.
трафік
Кількість запитів до вашої системи вимірюється у високорівневими метриками системи. Для веб-служби цей вимір зазвичай представляє кількість HTTP-запитів за секунду, розділені за характером запитів (наприклад, статичний чи динамічний контент). Для системи потокової передачі звуку цей вимір може бути сконцентрований на швидкості введення-виведення мережі або кількості одночасних сеансів. Для системи зберігання ключ-значення такий вимір може бути транзакціями або результатами пошуку за секунду.
Помилки
Це частота невдалих запитів, які явно (наприклад, HTTP 500), неявно (наприклад, HTTP 200, але у поєднанні з неправильним контентом) або політикою (наприклад, «Якщо ви зафіксували відповідь за одну секунду, будь-яка односекундна помилка »). Якщо кодів відповіді протоколу HTTP недостатньо для всіх умов збою, для виявлення часткової відмови можуть знадобитися вторинні (внутрішні) протоколи. Моніторинг всіх таких помилкових запитів може виявитися неінформативним, у той час як наскрізні тести допоможуть виявити, що ви обробляєте неправильний контент.
насичення
Метрика показує, наскільки інтенсивно використовується ваш сервіс. Це міра системного моніторингу, що виявляє ресурси, які найбільш обмежені (наприклад, у системі з обмеженою пам'яттю, показує пам'ять, у системі з обмеженнями вводу/виводу показується кількість вводів-виводів). Зверніть увагу, що багато систем погіршують продуктивність, перш ніж вони досягають 100% використання, тому наявність мети використання має важливе значення.
У складних системах насичення може бути доповнено вимірюванням навантаження вищого рівня: чи може ваша служба належним чином обробляти подвійний трафік, обробляти лише на 10% більше трафіку або обробляти ще менше трафіку, ніж в даний час? Для простих сервісів, які не мають параметрів, які змінюють складність запиту (наприклад, «Дайте мені нічого» або «Мені потрібно унікальне одне ціле монотонне ціле число»), які рідко змінюють конфігурацію, статичне значення тесту навантаження може бути адекватним, Однак, як обговорювалося в попередньому абзаці, більшість служб повинні використовувати непрямі сигнали, такі як утилізація CPU або пропускну спроможність мережі, які мають відому верхню межу. Підвищення затримки часто є основним показником насичення. Вимірювання часу відгуку 99-го відсотка у невеликому вікні (наприклад, одна хвилина) може дати дуже ранній сигнал насичення.
Нарешті, насичення також пов'язане з передбаченнями про насичення, що насувається, наприклад: «Схоже, ваша база даних заповнить жорсткий диск за 4 години».
Якщо ви вимірюєте всі чотири золоті сигнали і, коли виникає проблема з однією з метрик (або, у разі насичення, майже проблема), сповіщаєте людину, ваш сервіс буде більш-менш охоплений моніторингом.
Занепокоєння про «хвіст» (або інструментація та продуктивність)
При створенні системи моніторингу з нуля виникає спокуса розробити систему, засновану на середніх значеннях: середня затримка, середня утилізація CPU вузлів або середня заповненість баз даних. Небезпека двох останніх прикладів очевидна: процесори та бази даних утилізуються дуже непередбачуваним чином. Те саме стосується затримки. Якщо ви запускаєте веб-сервіс із середньою затримкою в 100 мс при 1000 запитах на секунду, 1% запитів може тривати 5 секунд. Якщо користувачі залежать від кількох таких веб-сервісів, 99% одного бекенда може легко стати медіанним часом відповіді інтерфейсу.
Найпростіший спосіб розмежування між повільним середнім і дуже повільним «хвостом» запитів полягає в тому, щоб збирати вимірювання запитів, виражені в статистиці (підходящий інструмент для відображення гістограми), а не фактичні затримки: скільки запитів обслужив сервіс, які займали між 0 мс і 10 мс, між 10 мс і 30 мс, між 30 мс і 100 мс, між 100 і 300 мс і т. д. Розширення меж гістограми приблизно експоненційно (з приблизним коефіцієнтом 3) часто є простим способом візуалізації розподілу запитів.
Вибір відповідного ступеня деталізації для вимірювань
Різні елементи системи повинні вимірюватися з різним ступенем деталізації. Наприклад:
- Спостереження за утилізацією завантаження CPU у певний проміжок часу не покаже тривалих викидів, які призводять до високих затримок.
- З іншого боку, для веб-сервісу, орієнтованого на не більше ніж 9 годин простоїв на рік (99,9% річного часу безвідмовної роботи), перевірка на HTTP відповідь 200 більше одного або двох разів на хвилину буде, ймовірно, занадто частою.
- Так само перевірка наявності вільного місця на жорсткому диску для 99,9% доступності більше одного разу кожні 1-2 хвилини, ймовірно, не потрібна.
Подбайте про те, як ви структуруєте гранулярність вимірів. Періодичність збору завантаження CPU 1 раз на секунду може дати цікаві дані, але такі часті виміри можуть бути дуже дорогими для збору, зберігання та аналізу. Якщо ціль моніторингу потребує високої гранулярності і не вимагає високої швидкості реакції, ви можете зменшити ці витрати, налаштувавши збір метрик на сервері, а потім налаштувавши зовнішню систему для збору та агрегування цих метрик. Ви могли б:
- Вимірювати завантаження CPU кожну секунду.
- Урізати деталізацію до 5%.
- Агрегувати метрики щохвилини.
Ця стратегія дозволить збирати дані з високо гранулярністю, не зазнаючи високих накладних витрат на аналіз та зберігання.
Як можна простіше, але не простіше
Накладення різних вимог одна на одну може призвести до дуже складної системи моніторингу. Наприклад, ваша система може придбати наступні ускладнюючі елементи:
- Оповіщення відповідно до різних порогових значень для затримки обробки запитів у різних відсотках за всіма видами різних показників.
- Написання додаткового коду для виявлення та виявлення можливих причин.
- Створення пов'язаних дашбордів кожної з можливих причин проблем.
Джерела потенційного ускладнення ніколи не закінчуються. Як і всі програмні системи, моніторинг може ускладнитися настільки, що стане крихким, складним для змін та обслуговування.
Тому проектуйте свою систему моніторингу з метою якнайбільше її спростити. Вибираючи, що потрібно відстежувати, пам'ятайте:
- Правила, які найчастіше ловлять реальні інциденти, мають бути максимально простими, передбачуваними та надійними.
- Конфігурація для збору даних, агрегації та оповіщення, які рідко виконуються (наприклад, менш ніж раз на квартал для деяких команд SRE), має бути видалена.
- Метрики, які збираються, але не відображаються на будь-якій попередній панелі та не використовуються будь-яким попередженням, є кандидатами на видалення.
У Google базовий збір та агрегація показників, у поєднанні з оповіщеннями та дашбордами, добре працюють як відносно автономна система (Фактично система моніторингу Google розбита на кілька підсистем, але зазвичай люди знають про всі аспекти цих підсистем). Може виникнути спокуса поєднувати моніторинг з іншими методами перевірки складних систем: детальне профільування системи, налагодження процесу, відстеження деталей про винятки або збої, тестування навантаження, збирання та аналіз журналів або перевірка трафіку. В той час як більшість з цих речей мають спільні риси з основним моніторингом, їх змішання призведе до занадто великої кількості результатів у створенні складної та крихкої системи. Як і в багатьох інших аспектах розробки програмного забезпечення, підтримка різних систем з чіткими, простими, слабко пов'язаними точками інтеграції є найкращою стратегією (наприклад, використання веб-API для отримання зведених даних у форматі, який може залишатися постійним протягом тривалого часу).
Зв'язування принципів воєдино
Принципи, які обговорюються в цьому розділі, можуть бути об'єднані у філософію моніторингу та оповіщення, яка схвалена та дотримується в командах Google SRE. Дотримання цієї філософії моніторингу бажано, вона є гарною відправною точкою для створення або перегляду методики оповіщень і може допомогти ставити правильні питання служби експлуатації незалежно від розміру вашої організації або складності сервісу або системи.
При створенні правил моніторингу та оповіщення, задаючи наступні питання, ви можете уникнути помилкових спрацьовувань та зайвих оповіщень:
- Чи виявляє це правило, інакше стан системи, що не виявляється, який є терміновим, що закликає до дії і неминуче впливає на користувача?
- Чи можу я ігнорувати це попередження, знаючи, що воно доброякісне? Коли і чому я можу ігнорувати це попередження, і як я можу уникнути цього сценарію?
- Чи означає це сповіщення, що користувачі зазнають негативного впливу? Чи існують ситуації, коли користувачі не зазнають негативного впливу, наприклад, через фільтрацію трафіку або при використанні тестових систем, оповіщення за якими слід відфільтрувати?
- Чи можу я вжити заходів у відповідь на це сповіщення? Чи є ці заходи терміновими чи можуть чекати до ранку? Чи можна безпечно автоматизувати дію? Чи буде ця дія довгостроковим рішенням або короткостроковим обхідним рішенням?
- Деякі люди отримують кілька оповіщень щодо цієї проблеми, тому чи можна скоротити їх кількість?
Ці питання відображають фундаментальну філософію щодо сповіщень та систем оповіщення:
- Щоразу, коли надходить оповіщення, я маю негайно реагувати. Я можу негайно реагувати кілька разів на день, перш ніж втомлюся.
- Кожне сповіщення має бути актуальним.
- Кожна реакція на оповіщення має вимагати втручання людини. Якщо оповіщення може оброблятися автоматично, вона не повинна надходити.
- Оповіщення мають бути про нову проблему чи подію, якої не було раніше.
Такий підхід стирає певні відмінності: якщо оповіщення задовольняє попереднім чотирма умовами, не має значення, чи надсилається оповіщення із системи White-box моніторингу чи Black-Box. Цей підхід також посилює певні відмінності: краще витрачати набагато більше зусиль виявлення симптомів, ніж причини; коли справа доходить до причин, турбуватися потрібно лише про неминучі причини.
Моніторинг у довгостроковій перспективі
У сучасних продуктивних оточеннях системи моніторингу відстежують продуктивну систему, що постійно розвивається, із змінними архітектурою програмного забезпечення, характеристиками навантаження і цільовою продуктивністю. Оповіщення, які в даний час складно автоматизувати, можуть стати частим явищем, можливо, навіть заслуговує на те, щоб його вирішити. У цей момент хтось має знайти та усунути кореневі причини проблеми; якщо такий дозвіл неможливий, реакція на оповіщення потребує повної автоматизації.
Важливо, щоб рішення про постановку на моніторинг ухвалювалися з урахуванням довгострокових цілей. Кожне сповіщення, яке сьогодні виконується, відволікає людину від удосконалення системи завтра, тому часто трапляється зниження доступності чи продуктивності продуктивної системи на час, необхідний для покращення системи моніторингу у довгостроковій перспективі. Давайте розглянемо два приклади, що ілюструють це явище.
Bigtable SRE: історія про надмірне сповіщення
Внутрішня інфраструктура Google зазвичай надається та вимірюється з прив'язкою до рівня обслуговування (SLO). Багато років тому SLO служби Bigtable ґрунтувалася на середній продуктивності синтетичної транзакції, що імітує працюючого клієнта. Через проблеми в Bigtable і на нижчих рівнях стека зберігання даних середня продуктивність була обумовлена «великим» хвостом: гірші 5% запитів часто були значно повільнішими за інші.
Повідомлення електронною поштою надсилалися з наближенням до порога SLO, а сповіщення в месенджер відправлялися при перевищенні SLO. Обидва типи попереджень вирушали досить часто, споживаючи неприйнятні обсяги інженерного часу: команда витратила значну кількість часу на розбір сповіщень, щоб знайти кілька справді актуальних. Ми часто пропускали проблему, яка насправді торкалася користувачів, тому що тільки деякі з оповіщень були з цієї проблеми. Багато з оповіщень були нетерміновими через зрозумілі проблеми в інфраструктурі і відпрацьовувалися стандартним чином, або взагалі ніяк не оброблялися.
Щоб виправити ситуацію, команда використала тристоронній підхід: докладаючи великих зусиль для підвищення продуктивності Bigtable, ми тимчасово визначили як нашу мету SLO 75-ю процентиль для затримки відповіді на запит. Ми також відключили оповіщення електронною поштою, оскільки їх було так багато, що витрачати час на діагностику за ними було неможливо.
Ця стратегія дозволила нам перепочити, щоб почати виправляти довгострокові проблеми в Bigtable та нижніх рівнях стеку зберігання даних, а не постійно фіксувати тактичні проблеми. Інженери могли фактично виконати роботу, коли їх постійно не атакували оповіщення. Зрештою, тимчасове відстрочення обробки оповіщень дозволило нам підвищити якість обслуговування.
Gmail: передбачувані, алгоритмізовані відповіді людей
На початку служба Gmail була побудована на модифікованій системі управління процесом Workqueue, яка була створена для пакетної обробки фрагментів пошукового індексу. Workqueue був адаптований до довготривалих процесів і згодом застосований до Gmail, але деякі помилки в непрозорому коді планувальника виявилися дуже важковиліковними.
На той час моніторинг Gmail був структурований таким чином, що попередження спрацьовували, коли індивідуальні завдання скасовувалися за допомогою Workqueue. Цей підхід був не ідеальним, тому що навіть у той час Gmail виконував багато тисяч завдань, кожна з яких надавалася часткам відсотка наших користувачів. Ми дуже дбали про те, щоб користувачі Gmail користувалися хорошим інтерфейсом користувача, але відпрацювання такої кількості оповіщень була недосяжна.
Щоб вирішити цю проблему, Gmail SRE створив інструмент, який допоміг налагодити планувальник якнайкраще, щоб мінімізувати вплив на користувачів. У команди було кілька дискусій про те, чи потрібно просто автоматизувати весь цикл від виявлення проблеми до усунення, доки не буде знайдено довгострокове рішення, але деякі з них були стурбовані тим, що таке рішення затримає реальне виправлення проблеми.
Така напруга була спільною в команді і часто відображала недовіру до самодисципліни: в той час, як деякі члени команди хочуть дати час для правильного виправлення, інші турбуються про те, що остаточне виправлення забудуть і тимчасове усунення проблеми триватиме нескінченно. Ця проблема заслуговує на увагу, оскільки занадто легко тимчасово виправляти проблеми, замість того, щоб робити виправити ситуацію на постійній основі. Керівники та технічний персонал відіграють ключову роль у реалізації довгострокових виправлень, підтримуючи та пріоритизуючи потенційно тривалі довгострокові виправлення, навіть коли початковий «біль» вщухає.
Регулярні оповіщення, що повторюються, і алгоритмізовані реакції повинні бути червоним прапором. Небажання вашої команди автоматизувати такі оповіщення означає, що команді не вистачає впевненості, що вони можуть довіритися алгоритмам. Це серйозна проблема, яку слід вирішувати.
У довгостроковій перспективі
Загальна тема пов'язує приклади Bigtable та Gmail: конкуренція між короткостроковою та довгостроковою доступністю. Часто сильне зусилля може допомогти тендітній системі досягти високої доступності, але цей шлях зазвичай недовговічний, загрожує вигорянням команди і залежністю від невеликої кількості членів цієї героїчної команди.
Контрольоване, короткострокове зниження доступності часто є болючим, але стратегічно важливим завданням для довгострокової стабільності системи. Важливо не розглядати кожне сповіщення ізольовано, а враховувати, чи веде загальний рівень кількості оповіщень до здорової, належним чином доступної системи із життєздатною командою та сприятливим прогнозом. Ми аналізуємо статистику частоти сповіщень (які зазвичай виражаються у вигляді інцидентів за зміну, коли інцидент може складатися з декількох пов'язаних інцидентів) у щоквартальних звітах з керівництвом, що дозволяє особам, які приймають рішення, постійно представляти навантаження на систему оповіщень та загальний стан команди.
Висновок
Шлях до здорового моніторингу та сповіщень простий і зрозумілий. Основна увага приділяється симптомам проблеми, якими виконуються оповіщення, моніторинг причини служить допоміжним засобом налагодження проблем. Моніторинг симптомів тим простіше, чим вище ви знаходитесь в стеку, який ви контролюєте, хоча моніторинг навантаження та продуктивності бази даних повинен виконуватися безпосередньо на ній самій. Повідомлення електронною поштою мають дуже обмежену користь і, як правило, легко переростають у шум; замість цього ви повинні використовувати панель моніторингу, яка контролює всі поточні проблеми, через які виконуються сповіщення електронною поштою. Панель моніторингу може бути пов'язана з журналом подій, щоб аналізувати історичні кореляції.
У довгостроковій перспективі необхідно досягнення успішного чергування оповіщень про симптоми і неминучі реальні проблеми, адаптувати цілі до забезпечення того, щоб моніторинг підтримував швидку діагностику.
Дякую, що прочитали переклад до кінця. Підписуйтесь на мій телеграм-канал про моніторинг и .
Джерело: habr.com