Runbook حادثه — از alert تا postmortem

ساعت ۰۳:۱۴ alert می‌آید: HTTP 5xx rate > 2% for 5m. این runbook همان مسیری است که در production طی می‌کنیم — و همزمان نمونهٔ محتوای Markdown برای صفحهٔ مقاله.

#وضعیت اولیه

یادآوری: قبل از restart دسته‌جمعی، حتماً snapshot از log و metric بگیر. حدس زدن بدون داده، زمان recovery را دو برابر می‌کند.

#چک‌لیست triage

• incident channel در Slack/Teams باز شد
• on-call secondary صدا زده شد
• آخرین deploy شناسایی شد
• rollback آماده است
• اطلاع‌رسانی به stakeholders

#تشخیص سریع

#۱. لاگ اپلیکیشن

journalctl -u myapp -S "15 min ago" --no-pager | tail -n 80

#۲. اتصال دیتابیس

psql "$DATABASE_URL" -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

#۳. health endpoint

curl -fsS -o /dev/null -w "%{http_code} %{time_total}s\n" https://api.example.com/health

خروجی نمونه:

#فرضیه‌ها

1. Connection pool exhaustion — محتمل‌ترین علت با توجه به spike همزمان latency
2. Migration ناقص — deploy ۴۵ دقیقه قبل
3. Upstream timeout — کمتر محتمل؛ gateway سالم است

#کد مرتبط (pool config)

const pool = new Pool({
  max: Number(process.env.PG_POOL_MAX ?? 20),
  idleTimeoutMillis: 30_000,
  connectionTimeoutMillis: 5_000,
})

#اقدام اصلاحی

# graceful reload — نه restart سخت
systemctl reload myapp

# اگر جواب نداد:
systemctl restart myapp
sleep 3
curl -fsS https://api.example.com/health

اگر error rate بعد از ۱۰ دقیقه زیر ۱% نرفت → rollback به tag قبلی:

git checkout v2.4.1
./scripts/deploy.sh production

#ارتباطات

#timeline نمونه

1. T+0 — alert
2. T+7m — علت احتمالی: pool
3. T+18m — reload + restart
4. T+31m — error rate < 0.5%
5. T+24h — postmortem draft

#postmortem (خلاصه)

Root cause: افزایش traffic بعد از campaign بدون scale افقی؛ pool ثابت ماند.

Action items:

• autoscaling rule برای app tier
• alert روی pg_stat_activity
• load test قبل از campaign بعدی

#منابع

• Monitoring best practices
• runbook داخلی: /solutions/markdown-showcase
• on-call schedule: https://example.com/oncall