Який вигляд має хороша публічна сторінка статусу

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

Що має бути на хорошій сторінці статусу

Поточний стан кожного ключового сервісу. Не просто "усе OK", а з розбивкою за компонентами (API, web, dashboard, emailing, payment processing).
Історія інцидентів за останні 90 днів. Без спроб щось приховати - прозора історія зміцнює довіру.
Метрика uptime (зазвичай за 30 днів) для кожного компонента, виражена прозорим відсотком.
Планове обслуговування. Банер із датою та описом того, що буде недоступним.
Активний інцидент із часовою шкалою оновлень. Investigating → Identified → Monitoring → Resolved.
Форма підписки. Клієнти отримують лист при зміні статусу, і їм не потрібно повторно перевіряти сторінку.

Чітка ієрархія компонентів

Замість єдиного запису "monitor" розбийте сервіс на компоненти, які мають сенс із погляду клієнта:

Web App - frontend (ним користуються відвідувачі)
API - backend для програмних інтеграцій
Auth / Login - вхід у систему
Email delivery - транзакційні листи
Background jobs - sync, білінг, експорти
Status page - мета-компонент: сама сторінка статусу теж може впасти (тому вона має працювати на іншій інфраструктурі, ніж продукт)

Incident communication: анатомія хорошого оновлення

Під час реального збою дотримуйтеся цих фаз:

Investigating - "Ми виявили проблему з [компонент]. Команда з'ясовує причину." (упродовж 5 хв із моменту виявлення)
Identified - "Причина - [стисло]. Працюємо над виправленням. ETA [час]." (коли ви знаєте, що спричиняє проблему)
Monitoring - "Ми розгорнули виправлення. Спостерігаємо, чи не повториться проблема." (після розгортання рішення)
Resolved - "Інцидент усунено. Тривалість X хвилин. Далі буде postmortem." (після підтвердженого відновлення)

Кожна фаза отримує timestamp і власне оновлення. Після інциденту опублікуйте post-mortem (root cause, timeline та заходи, що запобігають повторенню).

Правило: Ніколи не використовуйте розпливчасті фрази на кшталт "experiencing some issues". Клієнти хочуть конкретики: "Вхід не вдається у ~30 % спроб. API працює нормально. Веб доступний лише в режимі read-only."

Hosting: принцип незалежної інфраструктури

Сторінка статусу має працювати на іншій інфраструктурі, ніж сервіс, який моніториться. Якщо у вас падає регіон AWS, сторінка статусу, розміщена в тому самому регіоні, падає разом із ним - саме в той момент, коли вона клієнтам потрібна найбільше.

Практичні рішення:

Хостинг через зовнішній SaaS (ePulz.io, Better Stack, Atlassian Statuspage)
Власна статична сторінка на CDN (Cloudflare Pages, Netlify) з API-ендпоінтом в іншому місці
У крайньому разі - мінімальна статична сторінка на Cloudflare з вручну оновлюваним текстом

Subscribers: email і webhook

Клієнти не хочуть постійно оновлювати сторінку статусу. Тому хороша сторінка підтримує:

Email subscribers - в ePulz.io доступно для авторизованих користувачів із платним планом (підписки ми збираємо лише з підтверджених акаунтів, а не з анонімних відвідувачів)
Webhook - для команд, які хочуть інтегрувати статус у власний Slack або PagerDuty

Anti-pattern: приховування проблем

Спокуса позначити збій як "degraded" замість "down" (або не показувати його взагалі) велика, але недалекоглядна:

Клієнти все одно помітять збій (через власний моніторинг, тікети в підтримку чи соцмережі)
Ви втрачаєте довіру, коли вони виявляють, що статус показує "OK" під час очевидного збою
Ви втрачаєте реальну картину тренду uptime, яка потрібна вам для внутрішніх рішень

Найкраща стратегія - радикальна прозорість. GitLab, Cloudflare і Stripe публікують детальні post-mortem навіть за незручних помилок, і спільнота це цінує.

SEO і бренд

Сторінка статусу має:

Бути на стабільному та легко запам'ятовуваному URL для статусу сервісу
Мати власний брендинг (логотип, кольори) - клієнт повинен бачити, що він усе ще на вашій сторінці
Бути проіндексованою в Google (краща видимість під час пошуку "[бренд] down")
Бути прилінкованою з головної сторінки (футер "Статус сервісу")

Висновок

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

Створіть сторінку статусу за 5 хвилин

Сторінки статусу ePulz.io із власним брендингом, email subscribers та incident timeline. 7 днів безкоштовно.

Спробувати ePulz.io →