Статус и инциденты
Как читать статусную страницу AACsearch и чего ждать в ходе инцидента.
Статус и инциденты
Единая точка истины о текущем состоянии AACsearch — status.aacsearch.com. Хостится отдельно от основной инфраструктуры — чтобы оставаться доступной, когда мы — нет.
Компоненты статусной страницы
| Компонент | Что покрывает |
|---|---|
| Search API — EU | Публичные search/ingest-эндпоинты в регионе Frankfurt. |
| Search API — US | Публичные search/ingest-эндпоинты в регионе Virginia. |
| Search API — RU | Публичные search/ingest-эндпоинты в Москве. |
| Dashboard | Web UI на app.aacsearch.com. |
| Connector API | CMS-ориентированные эндпоинты коннекторов (PrestaShop, Bitrix и др.). |
| Widget delivery | Хостинг виджета: скрипт + CSS на app.aacsearch.com/api/widget/*. |
| Webhooks | Исходящая доставка событий на ваши endpoint-ы. |
| Auth | Вход, magic link, OAuth, passkeys. |
У каждого — одно из четырёх состояний:
- Operational — зелёный. Probes проходят; error-rate в пределах SLO.
- Degraded performance — жёлтый. Probes проходят, но latency или error-rate выше нормы.
- Partial outage — оранжевый. Часть запросов падает.
- Major outage — красный. Компонент массово недоступен.
Смена состояния пишется на страницу в течение 60 секунд после детекции.
Жизненный цикл инцидента
Investigating → Identified → Monitoring → Resolved
↓
Post-mortem (в течение 14 дней)| Фаза | Что означает |
|---|---|
| Investigating | Заметили проблему, причины ещё не знаем. |
| Identified | Знаем, что сломано, и чиним. |
| Monitoring | Фикс выкачен; наблюдаем перед объявлением resolved. |
| Resolved | Компонент здоров минимум 15 минут. |
| Post-mortem | Для любого инцидента с воздействием на клиента ≥ 15 мин выпускаем публичный PIR в течение 14 дней. |
Мы не пометим инцидент Resolved до 15 минут зелёных probes — даже если уверены в фиксе. Это сознательно. Если ошиблись — лучше переэскалировать, чем делать вид, что всё.
Подписка на обновления
В подвале статусной страницы Subscribe:
- Email — один адрес. Апдейты в течение ~30 секунд.
- SMS — только для major outage (без спама на жёлтые события).
- Webhook — JSON POST на изменение состояния. Удобно подключить к PagerDuty, Opsgenie или своим инструментам.
- RSS / Atom — для дашбордов и агрегаторов.
Enterprise-клиенты дополнительно получают оповещения о P1 в своём регионе через TAM.
Уровни severity
Классификация в момент детекции; апгрейд/даунгрейд по мере прояснения.
| Уровень | Воздействие на клиента | Время реакции |
|---|---|---|
| P1 — Critical | Поиск недоступен по региону или компонент массово в дауне. | 24/7, немедленно. |
| P2 — High | Значительная деградация, большинство запросов проходит. | 24/7, ≤ 15 минут. |
| P3 — Medium | Локальная проблема (одна фича, один tenant, один кластер). | Рабочие часы, ≤ 4 ч. |
| P4 — Low | Косметика, dashboard-only, не-прод поведение. | Рабочие часы, ≤ 1 день. |
Это наши внутренние цели. Enterprise-клиенты согласовывают более жёсткие контрактные времена — см. Dedicated cluster.
Что мы сообщаем в инцидент
Типичный апдейт содержит:
- Что затронуто (компонент, регион).
- Когда началось (UTC, ISO 8601).
- Что мы считаем причиной — с поправкой на текущую неопределённость.
- Что делаем (rollback, scale-up, failover и т. п.).
- Следующий апдейт к (конкретное время, даже если новой информации нет).
Догадки о причине, в которые мы не уверены, не публикуем. Если не знаем — пишем «Investigating — следующий апдейт в HH:MM UTC». Это сознательно.
Что нужно сообщить вам нам в инцидент
При открытии P1/P2 во время публичного инцидента полезная информация:
- Organization ID.
- Index slug, если проблема привязана к индексу.
- Request ID из логов приложения по упавшему запросу (заголовок
x-request-id). - Первое наблюдение проблемы (UTC).
- Постоянная или интермиттентная, и какой процент запросов задет.
Уже присланное мы не переспросим. Спросим, можете ли воспроизвести с открытым DevTools — иногда один HAR закрывает то, что не закрыло бы 200-строчное описание.
После инцидента: post-mortems
Для каждого инцидента ≥ 15 мин воздействия:
- Публикуем public PIR на
status.aacsearch.com/incidents/<id>в течение 14 дней. - PIR содержит: таймлайн, contributing factors, влияние на клиентов (цифры, не прилагательные) и конкретные corrective actions с дедлайнами.
- PIR переслинкован из исходного инцидента.
Имён инженеров не публикуем. Имена систем, сервисов и решений — да.
Частые ошибки
- «Зелёный статус = моя проблема». Зелёный статус — кластер здоров. Ваша проблема может быть в неправильно настроенном ключе или 429. Сначала troubleshooting.
- Смотрите на дашборд во время P1. Дашборд зависит от тех же auth/БД, что и API; во время регионального инцидента он сам может тормозить. Статусная страница независима.
- Спрашиваете ETA каждые 5 минут. Апдейты — в обещанном ритме. Сказали «следующий к 14:30 UTC» — будет к 14:30 UTC.
См. также
- Мониторинг — ваш observability, дополняет наш
- Эскалация саппорту — что класть в тикет
- DR runbook — бэкстоп на катастрофические инциденты