Contabo Вимкнув Мій Сервер Без Попередження, і я Дізнався Про це п'ять Годин Пізніше Випадково

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

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

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

Чому Пасивний Моніторинг Не Вдається, Коли Вам це Найбільше Потрібно

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

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

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

Що П'ять Годин Тишини Насправді Коштує

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

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

Деградація часу відповіді - це ще один вимір, який пасивний моніторинг повністю пропускає. Сервер не завжди переходить від роботи до смерті в один момент. Частіше за все, продуктивність поступово деградує. Часи реагування, які були 200 мілісекунд, починають повзти до 800, потім 1500, потім 3000. На той час, коли сервер насправді вилітає, користувацька навички деградував протягом годин або днів. Без активного моніторингу, який відслідковує часи реагування та попереджає, коли перевищуються порогові значення, ця поступова деградація залишається абсолютно непоміченою, поки не відбудеться остаточний катастрофічний збій. А до того часу вже завдана шкода користувацькому досвіду та рейтингам пошуку.

Побудова Монітора, Яка Повинна Була Існувати

Рішення про створення uptime.yeb.to не був спонтанною реакцією на поганий день. Це був логічний висновок проблеми, яка будувалася довгий час та остаточно стала неможливою ігнорувати. Вимоги були чіткі з самого початку, тому що вони походили безпосередньо з досвіду. Монітор повинен був постійно перевіряти доступність сервера, не один раз на годину або один раз на день, а достатньо часто, щоб перерив було виявлено протягом кількох секунд. Потрібно було переконатися не лише в тому, що сервер реагує на запити ping, але що з'єднання HTTPS успішно завершуються, що сертифікати SSL є дійсними та не наближаються до терміну дії, а часи реагування знаходяться в прийнятих діапазонах. І потрібно було негайно надати сповіщення, не через приладну дошку, яка вимагала ручної перевірки, а через поштові сповіщення, які прибудуть до поштової скриньки протягом кількох секунд виявлення проблеми.

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

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

Від Особистого Інструменту До Платформи

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

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

Вся платформа в uptime.yeb.to тепер існує через один необголошене вимкнення сервера та п'ять годин тишини. Кожна функція відслідковується до конкретного збою, який був би виявлен, або повністю запобігнут, правильним моніторингом. Інцидент Contabo не був останнім проблемою сервера, який сталася, але він був останнім, який залишився невиявленим протягом п'яти годин. Цей розподіл робить всю різницю.