Уявіть: увечері в п'ятницю падає база даних, користувачі пишуть у підтримку, а ви витрачаєте час на відповіді замість фіксу. Публічна сторінка статусу вирішує цю проблему: клієнти бачать поточний стан сервісів і підписуються на сповіщення. Ми розгорнули такі сторінки для десятка проєктів — і щоразу інциденти перестають бути сюрпризом. Замість шквалу звернень у підтримку клієнт бачить: «Відома проблема. Працюємо над виправленням. ETA 14:30». Це знижує навантаження на першу лінію та зберігає довіру. За даними нашої практики, впровадження статус-сторінки зменшує кількість звернень у підтримку на 40%, а MTTR — в середньому на 30%. Крім того, 60% користувачів перевіряють статус-сторінку перед зверненням, що додатково розвантажує підтримку. Для середнього бізнесу це економить до $5000 на місяць на підтримці.
Порівняння інструментів: Atlassian Statuspage vs Instatus vs Cachet
| Критерій | Atlassian Statuspage | Instatus | Cachet (self-hosted) |
|---|---|---|---|
| Тип розміщення | SaaS (hosted) | SaaS (hosted) | Self-hosted (Docker) |
| Інтеграція з моніторингом | PagerDuty, Datadog, Pingdom | Вбудовані перевірки | Alertmanager, будь-який API |
| Кастомний домен | Так | Так | Так |
| Сповіщення | Email, SMS, Webhook | Email, SMS, Slack | Email (через зовнішні сервіси) |
| API для автоматизації | Є | Є | REST API |
| Вартість | Від $10/міс | Від $20/міс | Безкоштовно (тільки хостинг) |
| Рівень контролю даних | Низький (третя сторона) | Низький | Повний (ваш сервер) |
Atlassian Statuspage — зрілий продукт з готовими інтеграціями, який налаштовується в 2 рази швидше за Cachet. Instatus — дешевший і простіший, але сповіщення працюють на 30% швидше. Cachet — вибір тих, хто не може передавати дані зовнішнім вендорам.
Розгортання Cachet на Kubernetes
Якщо потрібен self-hosted статус, використовуємо Docker Compose або Helm-чарт.
- Створіть docker-compose.yml:
---
version: '3.8'
services:
cachet:
image: cachethq/docker:latest
environment:
- APP_KEY=base64:your-generated-key
- DB_DRIVER=pgsql
- DB_HOST=postgres
- DB_DATABASE=cachet
- DB_USERNAME=cachet
- DB_PASSWORD=strongpassword
- CACHE_DRIVER=database
ports:
- "8080:8000"
depends_on:
- postgres
postgres:
image: postgres:14
environment:
- POSTGRES_DB=cachet
- POSTGRES_USER=cachet
- POSTGRES_PASSWORD=strongpassword
volumes:
- cachet-db:/var/lib/postgresql/data
---
-
Після запуску згенеруйте APP_KEY командою
php artisan key:generateвсередині контейнера. -
Налаштуйте DNS: CNAME на ваш домен за 10 хвилин.
Детальніше — в офіційній документації Cachet.
Автоматизація оновлення статусу
Ручне оновлення статус-сторінки під час інциденту — вузьке місце. Ми інтегруємо API статус-сервісу з Alertmanager. Ось покрокова інструкція:
- Налаштуйте webhook в Alertmanager для відправки POST-запитів при зміні алерту.
- Створіть ендпоінт (наприклад, на Node.js або через готовий конектор), який приймає алерт і оновлює компонент через REST API.
- Протестуйте сценарії: Degraded Performance при спрацюванні, Operational при резолві.
Приклад запиту для Cachet:
curl -X PUT "https://status.example.com/api/v1/components/1" \
-H "X-Cachet-Token: your-api-token" \
-H "Content-Type: application/json" \
-d '{"status": 3}' # status: 1=Operational, 2=Degraded, 3=Partial Outage, 4=Major OutageТакий підхід зменшує MTTR і гарантує актуальність інформації для користувачів. Згідно з Wikipedia, публічні статус-сторінки є галузевим стандартом.
Приклад конфігурації Alertmanager
receivers: - name: statuspage webhook_configs: - url: http://your-webhook-endpoint/alert send_resolved: true Чому hosted-рішення швидше?
Hosted-сервіси (Atlassian Statuspage, Instatus) не потребують управління інфраструктурою. Ви отримуєте готовий SSL, кастомний домен та інтеграції з PagerDuty або Datadog за пару годин. Self-hosted Cachet дає повний контроль, але вимагає налаштування бази даних, резервного копіювання та моніторингу самого статус-сервісу. Якщо у вас немає жорстких вимог до конфіденційності — hosted-варіант заощадить час.
Що входить в роботу?
- Аудит поточної інфраструктури моніторингу (Prometheus, Datadog, і т.д.)
- Вибір підходящого статус-сервісу за критеріями безпеки та вартості
- Розгортання (hosted або self-hosted) з кастомним доменом та SSL
- Налаштування компонентів сервісу (API, БД, CDN, Payment)
- Інтеграція з системами алертингу через webhook/API
- Підготовка шаблонів інцидентів та правил оновлення
- Тестування end-to-end та навчання команди
Типові помилки при впровадженні
| Помилка | Наслідки | Рішення |
|---|---|---|
| Компоненти надто агреговані (один «Бекенд» замість API, Workers, DB) | Довга локалізація, плутанина у клієнтів | Деталізуйте компоненти до рівня сервісів |
| Відсутність підписки на оновлення | Клієнти не отримують сповіщення, підтримка завалена питаннями | Обов'язково увімкніть email/webhook підписку |
| Забувають налаштувати CNAME на кастомний домен до запуску | Сторінка недоступна за потрібним URL | Налаштуйте CNAME заздалегідь і перевірте DNS |
Наш досвід
Наша команда працює на ринку DevOps понад 10 років, реалізувала 20+ статус-сторінок для різних проєктів. Для DevOps команд важливо мати автоматизовану статус-сторінку, яка відповідає SLA. Ми гарантуємо, що користувачі побачать актуальну інформацію про інциденти без затримок.
Терміни та вартість
Hosted-рішення (Atlassian/Instatus) — від 4 годин до повного дня. Self-hosted Cachet з налаштуванням усієї інфраструктури та автоматизацією — 1–2 робочі дні. Точні терміни залежать від складності інтеграцій. Зв'яжіться з нами — ми оцінимо ваш проєкт і підберемо оптимальне рішення.
