Як створити сторінку статусу: компоненти, інциденти та перевірки доступності

Сторінка статусу в одному місці показує користувачам, чи працює ваш сервіс. Щоб її створити, потрібен список компонентів (сайт, API, платежі, доставка електронної пошти), поточний статус кожного, інциденти з позначками часу в оновленнях, історія минулих інцидентів і, за бажання, підписки, щоб люди дізнавалися про проблеми, не перевіряючи сторінку самі. Сама сторінка проста. Головне рішення полягає в тому, де вона працює: сторінка статусу має залишатися доступною, коли недоступний ваш застосунок, тож вона не повинна ділити хостинг, базу даних чи конвеєр розгортання з тим, про що повідомляє.

Для чого потрібна сторінка статусу

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

Це не журнал змін. Нові функції описують у журналі змін, а збої та технічні роботи розміщують тут.

Що потрібно сторінці

Дані

Статуси компонентів зазвичай становлять короткий фіксований список: працює, знижена продуктивність, часткова недоступність, повна недоступність, технічні роботи.

Сторінки

• Публічна сторінка статусу: загальний банер («Усі системи працюють» або найгірший поточний статус), кожен компонент зі статусом, активний інцидент з оновленнями, майбутні технічні роботи та смугу історії за 90 днів, якщо є дані перевірок.
• Сторінка інциденту: повна хронологія оновлень для одного інциденту з власною URL-адресою, щоб служба підтримки могла на неї посилатися.
• Історія: минулі інциденти за місяцями.
• Підписка: реєстрація електронною поштою з підтвердженням і налаштуваннями для кожного компонента.
• Адмін-панель: створення інциденту, публікація оновлень, зміна статусів компонентів, планування технічних робіт.

Права доступу

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

Головне рішення: зробити її незалежною

Тут найчастіше ламаються самописні сторінки статусу. Якщо ваша сторінка статусу:

• працює на тому самому сервері або в тому самому обліковому записі хостингу, що й застосунок,
• читає ту саму базу даних,
• розташована за тим самим налаштуванням домену чи CDN,
• або розгортається тим самим конвеєром,

то багато збоїв уразять і її, саме тоді, коли люди найбільше її потребують. Практичні кроки:

• Окремий хостинг. Інший проєкт або провайдер, ніж у основного застосунку.
• Власний піддомен, наприклад status.example.com, прив’язаний окремо в DNS. Див. як працюють домени та DNS.
• Власні дані. Інциденти зберігаються у власному сховищі сторінки статусу, а не в базі даних застосунку.
• Статичний запасний варіант. Деякі команди роблять публічну сторінку статичною та перебудовують її після кожного оновлення, тож майже нічому ламатися.

Ручні оновлення чи автоматичні перевірки

Вручну (з цього варто почати)

Ваша команда публікує інциденти й змінює статуси компонентів вручну з адмін-панелі. Так працює багато сторінок статусу на практиці, бо рішення людини («оплата з деякими типами карток повільна») корисніше, ніж автоматична червона крапка.

Щоб швидко дізнаватися про проблеми, використовуйте зовнішній монітор доступності, який перевіряє ваш застосунок приблизно щохвилини та сповіщає електронною поштою, SMS або в чаті. Багато сервісів моніторингу мають безкоштовні тарифи.

Автоматично

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

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

Автоматичні зміни можуть «миготіти» (працює, не працює, працює) на повільній мережі. Вимагайте два-три невдалі перевірки перед зміною статусу та дозволяйте людині підтвердити перед оголошенням серйозного збою.

Як писати оновлення про інцидент

• Публікуйте рано. «Розслідуємо скарги на невдалі входи» за кілька хвилин краще за ідеальне повідомлення через годину.
• Пишіть, що помічають користувачі, а не те, що зламалося всередині.
• Обіцяйте час наступного оновлення і дотримуйтеся його.
• Завершуйте коротким підсумком після вирішення: що сталося, скільки тривало і що ви змінюєте.

Перший промпт, який працює

Створи окрему сторінку статусу для нашого застосунку Parcelio, яка хоститься окремо за адресою status.parcelio.com. Компоненти: Website, Tracking API, Notifications, Payments; кожен має статус Operational, Degraded performance, Partial outage, Major outage або Under maintenance. Публічна сторінка показує загальний банер за найгіршим поточним статусом, кожен компонент зі статусом, активні інциденти з оновленнями з позначками часу (найновіші зверху), майбутні технічні роботи та список минулих інцидентів за місяцями. Кожен інцидент має власну сторінку. Додай адмін-сторінку із захистом паролем для створення інцидентів (заголовок, вплив, уражені компоненти), публікації оновлень (повідомлення та статус: Investigating, Identified, Monitoring, Resolved), зміни статусів компонентів і планування технічних робіт. Додай endpoint POST /api/check-result, який приймає назву компонента та up/down від зовнішнього монітора, захищений секретним токеном, і позначає компонент як Degraded лише після трьох поспіль невдалих перевірок. Зберігай усе у власній базі даних застосунку. Простий, спокійний дизайн, який швидко завантажується на телефонах.

Кроки побудови

1. Публічна сторінка й адмін-панель з ручними інцидентами. Цього вже достатньо для робочої сторінки статусу.
2. Окремий хостинг і прив’язка піддомену.
3. Сторінки інцидентів та історія.
4. Вікна технічних робіт.
5. Підписки. Реєстрація електронною поштою з подвійним підтвердженням і сповіщення про нові інциденти та оновлення. Для електронної пошти потрібен провайдер; див. як надсилати електронні листи з застосунку.
6. Вебхук монітора, якщо потрібні автоматичні зміни статусу.
7. Проведіть тренування. Створіть умовний інцидент, опублікуйте оновлення, вирішіть його, перевірте листи й видаліть.

Типові помилки

• Хостинг разом із застосунком. Найпоширеніша і найсерйозніша помилка.
• Сторінка, яка завжди каже «Усі системи працюють». Якщо вона ніколи не показує проблем, користувачі перестають їй довіряти.
• Немає позначок часу чи часового поясу. Завжди показуйте час із зазначенням поясу.
• Вхід в адмін-панель через логін основного застосунку.
• Тиша між оновленнями. «Змін немає, ще працюємо» є цілком нормальним оновленням.
• Статуси, що миготять. Вимагайте повторних збоїв перед зміною.

Коли краще готовий сервіс сторінок статусу

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

Створюйте власну сторінку, коли хочете повний контроль над дизайном і формулюваннями, коли потреби прості (кілька компонентів, ручні оновлення) або коли сторінка статусу є частиною продукту, який ви створюєте для інших.

Створення з Mythex

У Mythex можна створити сторінку статусу як окремий проєкт, відокремлений від основного застосунку. Так вона отримує окремий хостинг і власну базу даних. Опишіть її в чаті, перевірте в живому попередньому перегляді, потім опублікуйте та під’єднайте піддомен на кшталт status.yourdomain.com (власні домени доступні на тарифі Pro). Майте на увазі, що опубліковані застосунки Mythex і їхні бази даних засинають у простої й прокидаються при наступному відвідуванні, тож перше завантаження після тиші може бути повільнішим. Проста, легка сторінка тут допомагає.

Mythex поки не документує запланованих завдань, тому для автоматичних перевірок використовуйте зовнішній монітор доступності, який викликає вебхук-endpoint вашої сторінки статусу (див. рецепт з вебхуками). Сповіщення підписникам надсилаються через вашого власного провайдера, а ключ зберігається як секрет проєкту (рецепт надсилання електронної пошти).

Запитання