Настройка StatusPage (Atlassian/Cachet/Instatus) для публичного статуса

Когда сервис недоступен, пользователи засыпают поддержку вопросами, а время уходит на объяснения вместо исправления. Мы настраиваем публичную страницу статуса, чтобы клиенты видели актуальное состояние сервисов и получали уведомления об инцидентах. Наша команда реализует проект под ключ — от выбора инструмента до настройки уведомлений, обеспечивая прозрачность и снижая нагрузку на поддержку.
Часто задаваемые вопросы

Представьте: в пятницу вечером падает база данных, пользователи пишут в поддержку, а вы тратите время на ответы вместо фикса. Публичная страница статуса решает эту проблему: клиенты видят текущее состояние сервисов и подписываются на уведомления. Мы развернули такие страницы для десятка проектов — и каждый раз инциденты перестают быть сюрпризом. Вместо шквала обращений в поддержку клиент видит: «Известная проблема. Работаем над исправлением. ETA 14:30». Это снижает нагрузку на первую линию и сохраняет доверие. По данным нашей практики, внедрение статус-страницы уменьшает количество обращений в поддержку на 40%, а MTTR — в среднем на 30%. Кроме того, 60% пользователей проверяют статус-страницу перед обращением, что дополнительно разгружает поддержку.

Сравнение инструментов: 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 — зрелый продукт с готовыми интеграциями. Instatus — дешевле и проще. Cachet — выбор тех, кто не может передавать данные внешним вендорам. По скорости настройки hosted-решения выигрывают в 1,5 раза.

Как развернуть 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 внутри контейнера. Подробнее — в официальной документации Cachet.

Как автоматизировать обновление статуса?

Ручное обновление статус-страницы во время инцидента — узкое место. Мы интегрируем API статус-сервиса с Alertmanager. Вот пошаговая инструкция:

  1. Настройте webhook в Alertmanager для отправки POST-запросов при изменении алерта.
  2. Создайте эндпоинт (например, на Node.js или через готовый коннектор), который принимает алерт и обновляет компонент через REST API.
  3. Протестируйте сценарии: 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, etc.)
  • Выбор подходящего статус-сервиса по критериям безопасности и стоимости
  • Развёртывание (hosted или self-hosted) с кастомным доменом и SSL
  • Настройка компонентов сервиса (API, БД, CDN, Payment)
  • Интеграция с системами алертинга через webhook/API
  • Подготовка шаблонов инцидентов и правил обновления
  • Тестирование end-to-end и обучение команды

Типичные ошибки при внедрении

Ошибка Последствия Решение
Компоненты слишком агрегированы (один «Бэкенд» вместо API, Workers, DB) Долгая локализация, путаница у клиентов Детализируйте компоненты до уровня сервисов
Отсутствие подписки на обновления Клиенты не получают уведомления, поддержка завалена вопросами Обязательно включите email/webhook подписку
Забывают настроить CNAME на кастомный домен до запуска Страница недоступна по нужному URL Настройте CNAME заранее и проверьте DNS

Сроки и стоимость

Hosted-решение (Atlassian/Instatus) — от 4 часов до полного дня. Self-hosted Cachet с настройкой всей инфраструктуры и автоматизацией — 1–2 рабочих дня. Точные сроки зависят от сложности интеграций. Свяжитесь с нами — мы оценим ваш проект и подберём оптимальное решение. Закажите консультацию по интеграции статус-страницы — получите готовую страницу без скрытых ошибок. Опыт наших инженеров — более 10 лет в DevOps, десятки реализованных статус-страниц. Мы гарантируем, что пользователи увидят актуальную информацию об инцидентах без задержек.

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1369
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1142