Перший тиждень у нового банківського клієнта. Я поставив запитання, яке вважав розминочним: «А де health check?» У кімнаті на мить стало тихо. Виявилося, що health check в Azure App Service не було налаштовано ніде — двадцять шість App Service крутяться в проді, проводять реальні транзакції, обслуговують живих клієнтів, і в жодного немає налаштованого health check endpoint. У банку. Платформа просто вважала, що все гаразд.
Надія — це не стратегія.
Різниця між «працює» і «відповідає»
Ось що пропускає більшість дашбордів. Між «сервер піднято» і «застосунок справді працює» — прірва. Інстанс App Service може бути запущений, процес живий, графік CPU ідеально спокійний — а застосунок усередині віддає 500 на кожен запит. Без health probe цього ніхто не помічає. Балансувальник так само бадьоро шле трафік на мертвий інстанс. Користувачі так само ловлять помилки. А в банку помилка — це не порожня сторінка, це платіж, що не пройшов, зависла транзакція, клієнт, який дивиться в екран і не розуміє, що взагалі сталося.
Це зомбі-інстанси: за всіма грубими метриками живі, за єдиною важливою — мертві. І найгірше — те, як ти про це дізнаєшся. Не з графіка, не з алерта, а з дзвінка клієнта. До моменту, коли жива людина руками лізе розбиратися, збитки вже рахуються в реальних грошах і реальній довірі.
Чому я не просто клацнув перемикачем
Звучить просто: налаштував health check endpoint — і готово. У банківському середовищі так не буває, і це правильно. Інфраструктуру платіжних систем не викочують «на авось». Тому я розкочував не одним махом, а в п'ять етапів.
- Етап 1 — спершу найтихіші, найменш критичні сервіси, суто щоб обкатати патерн.
- Етап 2 — внутрішні API, де помилка лишається всередині периметра.
- Етап 3 — сервіси середнього рівня.
- Етап 4 — те, що бачить клієнт.
- Етап 5 — і лише тепер критичні банківські навантаження.
Кожен етап проходив через Change Advisory Board з розписаним планом відкату ще до того, як я взагалі щось чіпав. Це не бюрократія заради бюрократії — саме вона дозволяє рухатися впевнено там, де радіус ураження включає чужі гроші. До критичних навантажень я підійшов тоді, коли патерн уже чотири рази довів, що працює.
Policy, а не сторінка у вікі
Розкочування probes закрило теперішнє. Майбутнє — ні. За півроку хтось підніме App Service номер двадцять сім, забуде про health check — і сліпа пляма повертається. Документація цього не лікує. Сторінка «best practices» у вікі — це цвинтар добрих намірів.
Тому найбільше я пишаюся не розкочуванням, а тим, що було після. Я налаштував Azure Policy, яка вимагає health check прямо на етапі деплою. Не порада, а реальний бар'єр. Деплоїш новий App Service без health check — деплой автоматично позначається як порушення. Плюс тепер автоматично підміняється нездоровий інстанс тієї самої миті, коли probe падає: платформа прибирає битий інстанс і піднімає свіжий. Команда дізнається про проблему від системи, а не зі скарги клієнта.
Результат, який лишається
Двадцять шість сервісів. П'ять етапів. Нуль даунтайму, нуль інцидентів. Але цифра, яка мені по-справжньому дорога, у слайд не вміщається: відтепер кожен новий App Service народжується здоровим. Не тому що інженер згадав про probe, а тому що система не дає забути. Знання перестало жити в одній голові й переїхало в саму платформу.
Ось у цьому й урок тих двадцяти шести сервісів. Health check — це не «зроблю, коли дійдуть руки». Це різниця між «дізнався з моніторингу» і «дізнався від клієнта». А єдиний health check, який реально існує, — той, без якого policy відмовляється деплоїти.
Тому лишу вас із тим самим запитанням, яке поставив у тій кімнаті на першому тижні: скільки ваших продових сервісів просто зараз мають справжній health check — і що вас страхує, коли наступна людина про нього забуде?