Алертинг

Алерт — це прохання перервати людину

Алертинг зазвичай подають як технічне питання: яка метрика, який поріг, яке вікно. Куди краще розуміти його як питання етичне й організаційне, бо алерт насправді забирає людину з її вечора, сну чи зосередженості й наводить на проблему. Ця рамка дає перевірку, якої не дасть жодна суперечка про пороги: якщо це спрацює о третій ночі, чи є щось, що людина мусить зробити негайно, і чи знає вона що саме? Якщо хоч одна половина — «ні», це не виклик.

Нижній лівий квадрант вартий довгого погляду, бо саме там більшість систем алертингу справді ламається. Умова виглядає терміновою, когось будять — і зробити немає чого: диск заповнюється на вузлі, який платформа однаково замінить; залежність деградувала, і її власники вже цим займаються; алерт спрацював на сплеску, що розсмоктався сам, поки ніхто не встиг відкрити ноутбук. Інстинкт — сказати інженерові бути терплячішим. Правильна реакція — змінити алерт, бо кожен виклик, на який не можна було зреагувати, є маленьким внеском у переконання, що виклики можна ігнорувати, — і це переконання знімають з рахунку під час справжнього.

Алертуйте на симптоми, а не на причини

Природний спосіб побудувати алертинг — перелічити те, що може зламатися, і повісити алерт на кожне: CPU понад 90%, памʼять понад 85%, диск понад 80%, реплік менше трьох, черга довша за тисячу. Кожне окремо виправдане, а набір є пасткою — з двох причин, що тягнуть у різні боки. Він постійно спрацьовує на умовах, які нікому не шкодять (пакетна задача законно тримає CPU десять хвилин), — і зовсім пропускає той збій, якого ніхто не перелічив, а саме він вас і кладе.

Алертинг на симптомах перевертає це. Замість питання, що може зламатися, спитайте, що відчуває користувач, коли вже зламалося, — і алертуйте на це: запити падають, запити повільні, черга не розбирається, замовлення не оформлюються. Таких умов на сервіс — жменя, вони покривають причини, яких ніхто не передбачив, і кожна з них за побудовою є тим, на що користувач поскаржився б, — і питання «чи варто когось будити» відповідає само собі.

SLO і швидкість спалювання: алерт на число, що має сенс

Алертингу на симптомах потрібна ціль, а обрана на дотик вона дає або алерт, який не спрацьовує ніколи, або такий, що спрацьовує щовівторка. Три терміни роблять ціль явною, і їх варто означити точно — бо вживають їх усюди приблизно.

• SLI — це вимір: частка запитів, що завершилися успішно за 300 мс, числом від 0 до 1. Це відношення добрих подій до дійсних, а не середнє.
• SLO — це ціль для цього виміру у вікні: 99,9% запитів за останні 28 днів. Це обіцянка, яку ви обираєте, а не та, яку дає система.
• Бюджет помилок — це те, що SLO дозволяє: 0,1% від 28 днів — це близько 40 хвилин збоїв, які ви маєте право витратити, і витрачати їх нормально, а не є проявом браку дисципліни.

Саме бюджет робить алертинг притомним, бо перетворює питання без відповіді («чи 0,3% помилок — це погано?») на арифметичне («з такою швидкістю скільки лишилося до кінця місячного бюджету?»). Це відношення і є швидкістю спалювання: горіння на 1× витрачає бюджет рівно за вікно, а на 14,4× місячний бюджет зникає за два дні. Алертуйте на швидкість спалювання, а не на сиру частку помилок, — і той самий алерт покриє і раптову аварію, і повільну кровотечу, яку фіксований поріг завжди пропускає.

Втома від алертів — це збій проєктування

Коли черговий інженер перестає реагувати швидко, звичний діагноз — що людина ставиться несерйозно. Чесний діагноз — що система її цього навчила. Людина, яку двадцять разів на тиждень переривають умови, що виявилися нічим, засвоює — правильно й неминуче, — що наступне переривання теж, мабуть, ніщо. Це не витренувати; можна лише прибрати ті переривання, що це спричинили.

Механіки, що тримають обсяг стерпним, невидовищні — і вони працюють:

• Групуйте повʼязані алерти в одне сповіщення. Залежність, що впала, має дати один виклик, а не по одному на кожен сервіс, що від неї залежить.
• Придушуйте нижні, поки горить верхній, — щоб до людини дійшла причина, а не сорок наслідків.
• Вимагайте тривалості, а не миті. Умова, що має протриматися пʼять хвилин, відсіює сплески, які минають самі.
• Давайте кожному викликові посилання на ранбук із першими трьома речами для перевірки. Алерт без нього — це загадка для людини, що напівспить.
• Щотижня переглядайте алерти, що спрацювали, і видаляйте або знижуйте ті, на які ніхто не зреагував. Ця зустріч і є всією дисципліною.
• Стежте за кількістю викликів на зміну як за числом, яке має власника. Якщо його не міряти, воно лише зростає.

Що має існувати ще до того, як виклик надіслано

Алерт — це лише перша секунда процесу, і те, що йде після нього, вирішує, чи вартувало переривання хоч чогось. Чотири складові мають існувати до того, як алерт увімкнуть, — а не після першого інциденту, що доведе їхню відсутність.

• Названий власник

  Чергування, а не список розсилки. Алерт, скерований у групу, де кожен припускає, що взяв хтось інший, — це алерт, якого не взяв ніхто.

• Ранбук

  Із посиланням із самого алерту: що це означає, перші три перевірки, як помʼякшити і до кого ескалювати. Пишеться до алерту, завидна.

• Ескалація з таймером

  Якщо ніхто не квітує за кілька хвилин, воно автоматично йде до наступного. Телефони бувають без звуку, і люди пропускають; система має це припускати.

• Розбір після

  Безобвинувальний, зосереджений на тому, що уможливило збій і що зробило його важковидимим. Його результат — зміни, зокрема й до алерту, що його знайшов.

Один організаційний пункт варто сказати прямо, бо саме він вирішує, чи переживе все це зіткнення з завантаженим кварталом. Чергування має бути оплаченим і обмеженим: ротація достатньо велика, щоб ніхто не ніс її постійно; години, визнані роботою; і дозвіл лагодити причини викликів у звичайний час. Де цього немає, система алертингу деградує в передбачуваному напрямку: пороги послаблюють, алерти замовчують, і моніторинг тихо перестає описувати систему. Цей результат — не провал інженерів у ротації, і його не полагодити ще одним алертом.

Антипатерни, які варто назвати

• Алерт на кожну метрику ресурсу на кожному хості: стіна викликів під час будь-якого звичайного сплеску навантаження.
• Пороги, обрані один раз і ніколи не переглянуті: вони описують систему, у якої відтоді втричі зріс трафік.
• Алерти в чат-канал, який усі замовчали, — це видалення з додатковими кроками.
• Виклик без ранбука, вручений найновішому в ротації о другій ночі.
• Моніторинг, що працює всередині того, що моніторить: аварія забирає з собою й алертинг.
• Дашборд, який вважають моніторингом: він працює, лише поки хтось випадково на нього дивиться.

Коли це застосовувати

Пов’язані сторінки

• ІнфраструктураЛогуванняЛогування — це слід, який залишає працююча система, щоб пізніше можна було відповісти на питання про неї, — і саме та частина експлуатації, яку найчастіше роблять так, що нею неможливо скористатися. Перевірка не в тому, скільки ви записуєте, а в тому, чи має відповідь питання, поставлене за три тижні, — і це вирішується тоді, коли пишеться код, а не коли починається інцидент. На цій сторінці — чому рядок логу має бути подією, а не реченням, для чого потрібні логи порівняно з метриками й трасуванням, які поля роблять інцидент відповідним на питання і яка арифметика перетворює звичку логувати на рахунок, якого ніхто не передбачав.
• ІнфраструктураModel ServingModel serving — це коли натреновану модель ставлять за інтерфейс, що відповідає на запити. Щойно модель натреновано, її подача — це задача затримки й вартості, а вже потім машинного навчання. Сам інференс зазвичай є найменшою частиною часу відповіді, залізо тут — це залізо для пропускної здатності, від якого просять роботу на затримку, а те, що більшість команд моніторить — точність, — саме те, чого наживо не видно. На цій сторінці — шлях запиту, три форми подачі й чому зазвичай виграє найдешевша, батчинг і правильний сигнал масштабування, як викотити нову версію, не ставлячи на неї все, і за чим стежити, коли правда приходить із запізненням на тижні.
• ІнфраструктураKubernetesKubernetes — це цикл керування з API перед ним. Ви не наказуєте йому запустити контейнер: ви записуєте бажаний стан, а контролери постійно звіряють цей запис із тим, що працює насправді, і діють на різницю — завжди, а не один раз. Кожен обʼєкт, який він пропонує, і кожна його несподівана поведінка походять звідси. На цій сторінці — сам цикл, кілька обʼєктів, що справді важать, чому ліміти ресурсів і перевірки здоровʼя спричиняють більшість інцидентів у проді й коли все це вам справді потрібне.