פיתוח מדריך התאוששות מאסון למערכות קריטיות

אנו מפתחים Runbooks לשחזור מאסון (Disaster Recovery) עבור מערכות קריטיות — לא כתיאוריה, אלא ככלי שבאמת עובד ב-3 לפנות בוקר כשהעסק מושבת והמנהל מתקשר כל 10 דקות. בתנאים כאלה, רק פורמט אחד עוזר: שלב ספציפי → פקודה ספציפית → תוצאה צפויה → מה לעשות אם משהו משתבש. למידע נוסף על הרעיון, ראו Disaster Recovery.

משפטים כלליים כמו "שחזר את מסד הנתונים מהגיבוי האחרון" אינם runbook. זהו תסריט לאלתור, שבמצב לחץ כמעט מבטיח שגיאה. ה-runbooks שלנו, לעומת זאת, מכילים פקודות מוכנות: מ-pg_ctl promote ועד פקודות Ansible להעברת האפליקציה.

מדוע DR Runbook הוא קריטי?

ללא תיעוד שחזור מאסון, כל תקרית הופכת לכאוס: מהנדסים מנסים להיזכר מה נעשה בפעם הקודמת, מחפשים אישורי גישה בצ'אטים שונים, וזמן השחזור (MTTR) גדל. runbook טוב מקצר את ה-MTTR פי 3–5 — זה מאושר על ידי הפרויקטים שלנו. במקרה אחד, runbook עזר לשחזר מסד נתונים של 50 GB תוך 40 דקות במקום 4 שעות הרגילות. הלקוח ציין: "לאחר הטמעת ה-runbook, הפחתנו את ה-MTTR מ-6 שעות ל-40 דקות." במשך 5 שנות עבודה, ביצענו יותר מ-100 תרגילי DR, ו-95% מהם הצליחו עם RTO של פחות מ-15 דקות עבור שירותים קריטיים. זמן ההשבתה הממוצע מופחת ב-70%, מה שמאפשר חיסכון של עד $900–1.3k בשנה.

כיצד אנו מפתחים DR Runbooks

אנו לא כותבים הוראות תבניתיות. כל runbook נוצר עבור תשתית ספציפית: מחסנית, גרסאות, טופולוגיה, ספק ענן. המהנדסים שלנו עם שבע שנות ניסיון ב-DevOps עוברים על כל תרחישי הכשל — מכשל של צומת בודד ועד אובדן של אזור זמינות שלם. בדיקות הראו ש-runbooks שנכתבו לפי הסטנדרט שלנו מבטיחים שחזור מהיר פי שניים מהוראות טיפוסיות. הזמינו פיתוח runbook וקצרו את זמן השחזור שלכם.

תהליך העבודה:

1. ביקורת תשתית — אנו אוספים דיאגרמת תלויות, מזהים שירותים קריטיים, מבהירים RPO/RTO.
2. תכנון תרחישים — אנו מתארים כשלים טיפוסיים (קריסת master של מסד הנתונים, אי-זמינות אחסון, אובדן תצורה).
3. פיתוח runbook — עבור כל תרחיש, אנו כותבים שלבים אטומיים עם פקודות, בדיקות ותוצאות צפויות.
4. ולידציה בתרגיל DR — אנו מדמים כשל אמיתי, מתקנים שגיאות בתיעוד.
5. מסירה והדרכה — אנו מעלים את ה-runbook ל-Git (Markdown), מחברים CI/CD ליצירת PDF אוטומטית, ומכשירים מהנדסי תורנות.

מה כלול בתוצרים?

• DR Runbook עבור כל שירות קריטי (עד 5 מערכות בערכה הסטנדרטית).
• נוהל Failback — חזרה לארכיטקטורה המקורית לאחר השחזור.
• מטריצת תלויות ואנשי קשר להסלמה.
• אינטגרציה עם PagerDuty או Opsgenie.
• סקירת runbook לאחר 3 חודשים כלולה.

מבנה runbook עבור שירות אחד

כל שירות קריטי מקבל runbook משלו. מבנה:

סקירת שירות

• מטרה: מה השירות עושה, מי תלוי בו
• בעלים: שם + איש קשר של מהנדס תורנות
• RPO / RTO: מספרים ספציפיים
• תלויות: רשימת שירותים שבלעדיהם זה לא עובד

אינדיקטורים לתקרית

תסמינים ספציפיים שמציינים שצריך את ה-runbook הזה, לא אחר:

• alert: PostgreSQLDown{job="prod-db"} ב-Alertmanager
• HTTP 502 מ-nginx על /api/v1/health במשך יותר מ-5 דקות
• CPU על מסד הנתונים הראשי > 95% במשך יותר מ-10 דקות

אבחון (לפני הפעלת נוהלי DR)

בדיקות שיש לבצע לפני הפעלת DR — אולי אפשר לפתור את הבעיה בפשטות רבה יותר:

# Проверить состояние PostgreSQL
systemctl status postgresql-15
pg_isready -h localhost -p 5432

# Посмотреть активные соединения
psql -U postgres -c "SELECT count(*), state FROM pg_stat_activity GROUP BY state;"

# Проверить дисковое пространство
df -h /var/lib/postgresql

# Проверить журналы
journalctl -u postgresql-15 -n 100 --no-pager
tail -100 /var/log/postgresql/postgresql-15-main.log

שלבי נוהל DR

זהו החלק המרכזי. כל שלב הוא פעולה אטומית עם בדיקת תוצאה.

# ШАГ 1: Убедиться что primary недоступен (не ложная тревога)
# Выполнять с jump-хоста или из DR-сети
ping -c 3 10.0.1.10 # primary DB IP
ssh -o ConnectTimeout=5 [email protected] "echo ok"
# Ожидаемый результат при реальном отказе: connection timeout

# ШАГ 2: Проверить состояние DR-реплики
ssh [email protected] "pg_controldata /var/lib/postgresql/data | grep 'state'"
# Ожидаемый результат: "Database cluster state: in archive recovery"

# ШАГ 3: Promote DR-реплики (НЕОБРАТИМАЯ ОПЕРАЦИЯ — убедиться что primary мёртв)
ssh [email protected] pg_ctl promote -D /var/lib/postgresql/data
# Ожидаемый результат через 30 сек:
# pg_controldata /var/lib/postgresql/data | grep state
# "Database cluster state: in production"

# ШАГ 4: Проверить что promote прошёл успешно
psql -h 10.10.1.5 -U postgres -c "\dt"
psql -h 10.10.1.5 -U postgres -c "SELECT count(*) FROM users;"
# Ожидаемый результат: таблицы на месте, количество записей разумное

# ШАГ 5: Переключить приложение на DR-базу
# Обновить DATABASE_URL в конфигурации приложения
export DR_DB_HOST=10.10.1.5
ansible-playbook -i inventory/dr \
  playbooks/update-db-config.yml \
  -e "db_host=$DR_DB_HOST"

# ШАГ 6: Перезапустить приложение
ansible-playbook -i inventory/dr \
  playbooks/restart-app.yml

# ШАГ 7: Проверить работоспособность
curl -f https://app-dr.company.com/api/v1/health
# Ожидаемый результат: HTTP 200, {"status":"ok","db":"connected"}

נוהל Rollback / failback

לאחר שחזור הראשי, יש להעביר הכל בחזרה. זהו נוהל נפרד שלעתים קרובות שוכחים לתעד:

# После восстановления primary:
# 1. Настроить primary как реплику от DR (pg_basebackup)
# 2. Дождаться синхронизации
# 3. Переключить приложение обратно
# 4. Demote DR до реплики

אנשי קשר והסלמה

כיצד לאחסן ולעדכן runbook?

runbook צריך לחיות ליד הקוד — במאגר Git, לא ב-Confluence, שבו לא ניתן לגשת אליו אם Confluence נופל יחד עם הייצור. Markdown ב-Git, ייצוא ל-PDF במקרה של השבתה מלאה של המערכת. אנו מבטיחים שה-runbook יהיה מסונכרן עם התשתית: אנו משתמשים בגישת GitOps שבה כל שינוי תצורה מפעיל pipeline של CI לבדיקת עדכניות התיעוד.

כל 3 חודשים — סקירה: בדיקה שהפקודות עדיין תקפות, כתובות ה-IP לא השתנו, אנשי הקשר נכונים. הדרך הטובה ביותר לבדוק runbook היא לבצע תרגיל DR באמצעותו. אנו מארגנים תרגילים כאלה עם סימולציה של כשלים אמיתיים — צרו קשר.

הערכות לוחות זמנים

העלות מחושבת באופן אישי לאחר ביקורת תשתית. קבלו ייעוץ — אנו נעריך את ההיקף ונכין הצעה מסחרית. צרו קשר כדי לדון בפרטים ולבקש דוגמאות runbook עבור המערכות שלכם.