Runbook: Olay yönetimi ve status page

Kaynaklar: Alertmanager (#pushizo-alerts, #pushizo-oncall, e-posta), Grafana panoları (infra/monitoring/grafana/dashboards), Loki logları (request_id ile izleme), Sentry. Status page: https://status.<alan adı> → dashboard /status, veri GET /status.json (API; platform_incidents tablosu + bileşen sağlığı: DB/Redis ping, worker heartbeat'leri). Yönetim: platform admin → /admin/incidents.

ŞiddetBağlantıyı kopyala

AkışBağlantıyı kopyala

1. Tespit — alarm ya da müşteri bildirimi. Nöbetçi olayı üstlenir, Slack #pushizo-oncall içinde iş parçacığı açar ([SEV1] <başlık> — <saat UTC>).
2. Status page olayı (SEV1/SEV2, 10 dk içinde) — /admin/incidents → Yeni olay: başlık, şiddet (minor|major|critical), etkilenen bileşenler (api, dashboard, worker, delivery, sdk), ilk güncelleme (investigating). GET /status.json anında degraded/major_outage döner; ApiTransactionalLatencyHigh gibi alarmlar inhibit edilir (Alertmanager inhibit kuralları).
3. Teşhis — ilgili runbook: provider-outage.md, queue-backlog.md, restore.md, key-rotation.md. Standart sorular:
   • Son dağıtım ne zaman? (docker compose ps imaj etiketleri / GitHub release) → şüpheliyse geri al: IMAGE_TAG=<önceki> ./infra/scripts/deploy.sh prod (migration'lar geriye dönük uyumlu olduğundan önceki imaj yeni şema ile çalışır).
   • Hangi bileşen? GET /readyz (DB/Redis), worker /readyz (heartbeat), Grafana API ve Veritabanı panoları.
   • Tek kiracı mı? Loki | json | org_id="org_…".
4. Güncelleme ritmi — SEV1 30 dk, SEV2 60 dk: status page güncellemesi (identified → monitoring) + Slack. Müşteri e-postası (status page aboneliği) yalnızca 1 saati aşan SEV1'de.
5. Çözüm — kök neden giderildi, metrikler 15 dk normal → status page resolved (bileşenler operational). Alarmlar resolved bildirir.
6. Post-mortem (SEV1, 5 iş günü içinde) — docs/postmortems/YYYY-MM-DD-<slug>.md: zaman çizelgesi (UTC), etki (kiracı sayısı, kaybolan/geciken teslimat), kök neden, iyi giden/gitmeyen, aksiyonlar (sahip + tarih). Suçlamasız.

Hazır komutlarBağlantıyı kopyala

# genel durum
curl -s https://api.<alan>/readyz | jq . ; curl -s https://api.<alan>/status.json | jq .components
docker compose --env-file .env.prod -f infra/compose/docker-compose.prod.yml ps
# loglar (son 10 dk, hata)
docker compose … logs --since 10m api-1 api-2 worker-dispatch worker-system | grep '"level":50'
# tek istek izleme
# Loki: {project="pushizo"} | json | request_id="req_…"
# acil kapasite
docker compose … up -d --scale worker-dispatch=2
# geri alma
IMAGE_TAG=<önceki sürüm> ./infra/scripts/deploy.sh prod
```text

## İletişim şablonları
- *investigating*: "Bildirim gönderimlerinde gecikme/hatalar araştırılıyor. Etkilenen bileşen: \<kanal>. Sonraki güncelleme 30 dk içinde."
- *identified*: "Neden tespit edildi: \<sağlayıcı/altyapı>. Düzeltme uygulanıyor; bekleyen gönderimler kuyrukta, veri kaybı yok."
- *monitoring*: "Düzeltme uygulandı, gönderimler normale döndü; 30 dk izleniyor."
- *resolved*: "Olay çözüldü. \<süre> boyunca \<etki>. Post-mortem paylaşılacak."

## Sorumluluklar
| Rol | Görev |
|-----|-------|
| Nöbetçi (on-call) | ilk yanıt, status page, teknik müdahale |
| Olay yöneticisi (SEV1) | iletişim ritmi, karar (geri alma / DR), post-mortem sahibi |
| Platform admin | `/admin` ekranları: olay, kiracı askıya alma, support session (salt okunur), özellik bayrakları (riskli özelliği kapatma) |