Мій сервер впав, і я дізнався про це п'ять годин потому випадково

Сповіщення не прийшло від служби моніторингу. Воно не прийшло від автоматичного оповіщення або вебхука, який запустився в Slack. Воно прийшло з найпримітивнішої системи моніторингу, яку можна уявити: відкрив браузер, ввів URL-адресу та глянув на порожню сторінку. То був вівторок після обіду. Сайт був недоступний з якихось дев'яти ранку, а зараз було добре за дві дня. П'ять годин абсолютної тиші від веб-програми, яка зазвичай обробляла тисячі запитів на день. П'ять годин, протягом яких кожен відвідувач бачив сторінку помилки, кожен виклик API повертав нічого, а кожне запланован завдання мовчки не виконувалося в фоні. Сервер не впав драматично. Не було паніки ядра, відмови диска, вектора атаки, який залишив судово-медичні докази. VPS Contabo просто перестав відповідати на HTTP-запити, сидячи там із дійсною IP-адресою та пульсом на рівні мережі, але відмовляючись обслуговувати будь-який веб-трафік.

Виявлення сталося через зовсім не пов'язане завдання. Потрібно було перевірити певний макет сторінки для зміни дизайну, тому браузер перейшов на URL-адресу та повернув нічого. Перша інстинкція була винити локальну мережу. Оновив сторінку. Все ще нічого. Спробував інший браузер. Все ще нічого. Відкрив термінал та пінгував сервер. Пакети поверталися нормально. З'єднання SSH? Працює чудово. Статус Apache? Неживий. Процес веб-сервера зламався якось на ранніх ранкових годинах і ніколи не перезавантажився, тому що не було налаштованого супервізора процесів для обробки цього точного режиму відмови. Виправлення заняло тридцять секунд. Усвідомлення того, що це могло статися знову й, ймовірно, сталося раніше без чиєїсь уваги, зайняло значно більше часу.

Кожен розробник, який запускав виробничі послуги на VPS, має версію цієї історії. Можливо, це була не п'ять годин. Можливо, це були дві, вісім або цілий вихідний день. Специфіка варіюється, але схема однакова. Сервер впав, ніхто не помітив, і виявлення було випадковим. Корінь проблеми не в надійності сервера. Сервери відмовляють, процеси падають, диски заповнюються, витоки пам'яті накопичуються. Це природа запуску програмного забезпечення на фізичному обладнанні. Корінь проблеми — це відсутність моніторингу, а точніше розрив між знанням того, що сервер працює, і знанням того, що програма насправді працює.

Різниця між моніторингом часу роботи та знанням того, що ваш сайт насправді працює

Традиційні монітори часу роботи роблять одну справу добре. Вони надсилають HTTP-запит на URL-адресу з регулярними інтервалами та перевіряють, чи коди відповіді дорівнюють 200. Якщо код що-небудь інше або якщо запит закінчився за часом, сповіщення спрацьовує. Це перевіває найбільш катастрофальні відмови: сервер абсолютно недосяжний, домен закінчився, сертифікат SSL недійсний. Але це пропускає величезну категорію проблем, які, можливо, більш поширені й більш шкідливі.

Розглянемо сценарій, у якому сервер повертає статус-код 200, але сторінка порушена. З'єднання з базою даних не вдалося, тому область вмісту показує повідомлення про помилку замість очікуваного переліку продуктів. Файл CSS не завантажився, тому сторінка відображається як неформатоване HTML. Помилка JavaScript запобігає ініціалізації основної програми, залишаючи користувача біля спінера завантаження, який ніколи не розв'язується. Віджет третьої сторони вводить оверлей, який закриває весь вміст сторінки. У всіх цих випадках монітор часу роботи повідомляє все як здорово, тому що отримав відповідь 200. Сервер працює. Сайт порушений. Ніхто не знає.

Цей розрив між «сервер відповідає» та «сайт працює» це місце, де моніторинг скріншотів стає необхідним. Запланований скріншот фіксує те, як сторінка насправді виглядає з регулярними інтервалами. Якщо сторінка раптом показує повідомлення про помилку, розламану макет або порожній білий екран, скріншот робить це негайно видимим. Поєднайте заплановані скріншоти із порівнянням піксельних різниць, і система може автоматично виявляти, коли сторінка змінилася несподіванимми способами. Кілька піксельних зрушень через оновлення вмісту це нормально. Вся сторінка повертається білою або показує слід стеку помилок ні, а алгоритм різниці може розрізнити між двома за допомогою налаштовуваних порогів чутливості.

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

Будування трубопровіду оповіщення, який повинен був існувати з першого дня

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

Трубопровід моніторингу скріншотів працює поетапно. Планувальник розпочинає завдання захоплення з налаштованим інтервалом, зазвичай кожні п'ять, десять або п'ятнадцять хвилин залежно від критичності сторінки. Завдання захоплення запускає безголовий екземпляр Chromium, який завантажує сторінку, чекає завершення відображення та зберігає отриманий скріншот. Новий скріншот потім порівнюється проти попереднього захоплення за допомогою алгоритму піксельної різниці, який визначає змінені регіони та обчислює загальний відсоток зміни. Якщо зміна перевищує налаштований поріг, сповіщення розпочинається через налаштовані канали: електронна пошта, вебхук, Slack або будь-яка користувацька кінцева точка.

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

П'ятигодинна перерва була б виявлена протягом хвилин за цієї системи. Перший запланований скріншот після того, як сервер впав, би повернув або порожній зображення, або сторінку помилки, обидва з яких суттєво відрізнялися б від базової лінії. Відсоток різниці буде близький до 100%, далеко вище будь-якого розумного порога, і сповіщення б спрацювало негайно. П'ять годин простою було б п'ять хвилин, і ці п'ять хвилин були б самим інтервалом моніторингу, а не час, який потрібен людині, щоб випадково натрапити на проблему.

Що п'ять годин невидимого простою насправді коштує

Негайна вартість п'ятигодинного простою легко обчислити, коли числа доступні. Для сайту, який обробляє тисячі щоденних запитів, п'ять годин становить значний відсоток денного трафіку. Кожен запит, який повернув помилку, це користувач, який не отримав те, що прийшов. Деякі з цих користувачів були новими відвідувачами, які ніколи не повернеться. Деякі були існуючими користувачами, які втратили б невелику кількість довіри. Деякі були споживачами API, чиї власні програми не вдалися через залежність. Прямий вплив доходу залежить від природи сайту, але навіть для невеликої SaaS-програми п'ять годин простою під час робочих годин легко може представляти сотні доларів у втрачених перетвореннях.

Приховання вартість важче кількісно, але можливо більше. Пошукові двигуни, які повзли сайт протягом тих п'яти годин, отримали відповіді про помилки, і хоча коротка перерва, як правило, виконується інфраструктурою повзання Google, розширена перерва може привести до тимчасового видалення з індексу постраждалих сторінок. Кампанії електронної пошти, які були запущені під час перерви, спрямовували трафік на мертву кінцеву точку, витрачаючи всю суму витрат кампанії. Заплановані завдання, які залежать від веб-програми, як-от доставка вебхуків, генерація звітів та пакетна обробка, все не вдалося мовчки й потребувало вручну визначення й повторного запуску після відновлення сервера.

Найпідступніша вартість це репутаційна. Користувачі, які зустрічаються з дауном сайту, зазвичай не надсилають електронний лист, який каже «ваш сайт не працює». Вони просто йдуть й можливо не вернуться. Немає механізму зворотного зв'язку для простоїв, оскільки сам механізм зворотного зв'язку не працює. П'ятигодинне вікно було достатнім, щоб деякі користувачі майже напевно спробували сайт, знайшли його розламаним і перейшли до конкурента без генерування жодної точки даних, яка б указала, що сталося. Вони просто пішли, і немає способу знати, скільки або кого вони були.

Від реактивного до проактивного й ніколи не дізнаватися випадково знову

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

Комбінація моніторингу часу роботи та візуального моніторингу скріншотів охоплює обидва шари проблеми. Монітор часу роботи перевіває повне переходу сервера в режим офлайн. Монітор скріншотів перевіває програму, яка потерпає, поки сервер залишається. Разом вони скорочують вікно виявлення від «коли хтось випадково помітить» до самого інтервалу моніторингу, який може бути таким коротким, як одна хвилина для критичних послуг. Сповіщення спрацьовує, сповіщення надходить, й виправлення розпочинається протягом хвилин замість годин.

Сервер впав ще два рази з того первісного інциденту. Обидва рази сповіщення надійшло протягом трьох хвилин. Обидва рази виправлення було застосовано до того, як буд-який значущий трафік був втрачений. Інфраструктура моніторингу окупила себе самим першим інцидентом, який вона перевіла, а все після цього було чистим плюсом. Эра дізнавання про простої випадково закінчилася, і в зворотному напрямку єдине справжнє питання полягає в тому, чому це зайняло п'ятигодинний простій, щоб зробити інвестицію очевидною.