Post-mortem для indie SaaS: страница статуса и коммуникации
Страница статуса уже «resolved», а клиенты спрашивают, что сломалось. Post-mortem превращает переписку в Slack в blameless-запись для публичной страницы и письма подписчикам. Разберём, когда хватит короткой заметки, а когда нужен полный отчёт, как собрать UTC-таймлайн из истории StillOnline и пройти чеклист из 30 пунктов без enterprise SRE.
Краткий ответ
Во время инцидента — короткие заметки; в течение 24–48 ч после стабилизации — blameless post-mortem. Временные метки — из алертов и постов StillOnline. Публично: impact, таймлайн, root cause простым языком, SMART-действия. StillOnline ставит DOWN после двух провалов (~10 мин на Free), но отчёт не пишет сам.
Живые апдейты: шаблон incident post · каденс обновлений.
1. Post-mortem или короткая заметка — когда что
| Ситуация | Сейчас | 24–48 ч |
|---|---|---|
| Логин у платящих не работает | Incident note | Полный post-mortem |
| Вендор тормозит, есть обход | Degraded note | Лёгкий retro |
| Ложный алерт | Тихий resolve | Только внутри |
Делайте: заметки < 150 слов — impact, статус, время следующего апдейта. Не спекулируйте про root cause до факта.
Первый пост на StillOnline — ~5 мин после признания impact. Обновления каждые 15–30 мин.
2. Таймлайн, impact, root cause, действия
UTC. Источники — алерты владельца и посты StillOnline.
Impact: «EU не могли экспортировать CSV 51 минуту» лучше, чем «degraded performance». Действия: «Добавить проверку StillOnline на /ready при исчерпании пула БД — Алекс — 2026-06-24 — P1».
Копируйте время из StillOnline, не из памяти через неделю.
3. Что выносить на публичную страницу статуса
| Публично | Только внутри |
|---|---|
| Impact и длительность | Имена on-call |
| Root cause простым языком | Секреты, конфиги |
| Действия, важные клиенту | HR |
Посты инцидентов StillOnline — для клиентов. Post-mortem — финальный пост; автогенерации нет. См. привычки после первого инцидента.
4. Письма подписчикам
Алерты владельца StillOnline ≠ email подписчиков страницы статуса.
- Во время сбоя — текст совпадает со страницей.
- После resolve — итоговое письмо или финальный пост с post-mortem.
- Без внутренних обвинений в публичной рассылке.
5. Чеклист из 30 пунктов (blameless)
Ключевое: resolve на странице → review за 48 ч → UTC-таймлайн → время алерта StillOnline DOWN → root cause без персоналий → SMART-действия с owner и датой → публичная версия без секретов → подписчики уведомлены → проверка StillOnline на customer-critical URL.
Полный список — в runbook команды; не закрывайте SEV-1 без одного структурного P1-fix.
Что дальше
После следующего инцидента — post-mortem за 48 ч с метками StillOnline. Финальный пост + подписчики.
Дашборд StillOnline — убедитесь, что health URL = то, от чего зависят клиенты.
Связанные материалы
- Шаблон incident post
- Каденс обновлений при инциденте
- Привычки после первого инцидента
- Письмо клиентам при сбое
FAQ
Через сколько публиковать post-mortem с данными StillOnline?
24–48 ч. Цель — в финальном incident update.
StillOnline сам пишет post-mortem?
Нет. Есть проверки, алерты и ваши посты — экспортируйте время в шаблон.
Incident post и post-mortem в StillOnline — в чём разница?
Короткие апдейты во время сбоя vs blameless-итог после resolve.
Имена инженеров на публичной странице?
«Команда разработки». Blameless — про систему.
Подписчики получат post-mortem?
Да, если опубликовать как новый incident post.
Root cause у вендора?
Прямо, со ссылкой на их status, плюс ваша скорость детекта.
Соло-фаундер — можно упростить?
Минимум: таймлайн, root cause, одно owned-действие.