תוכנית התאוששות מאסון: RPO, RTO ואוטומציה

תוכנית התאוששות מאסון: RPO, RTO ואוטומציה

תארו לעצמכם: מרכז הנתונים הראשי נופל בלילה, לקוחות לא יכולים לבצע הזמנות. ללא תוכנית DR מוכחת, כל אירוע הוא הגרלה. ראינו מקרים שבהם תוכנית DR כביכול התבררה כמיושנת בשנה ו-runbooks לא עבדו. לכן אנחנו בונים נהלים שבאמת מתבצעים, עם שלבים אוטומטיים ותרגולים סדירים. המהנדסים שלנו עם ניסיון של 10+ שנים ב-DevOps ו-SRE מבטיחים שתוכנית ה-DR שלכם תופעל בזמן כשזה הכי חשוב. אוטומציה של DR יכולה לחסוך עד 80% מזמן ההתאוששות בהשוואה לתהליכים ידניים.

למה RPO ו-RTO חייבים להיות מיושרים עם העסק?

לפני תכנון DR, יש להסכים על שני מדדים עם העסק, לא לנחש אותם מהנדסים. RPO (Recovery Point Objective) הוא אובדן הנתונים המקסימלי המקובל בזמן. אם RPO = שעה אחת, אפשר לאבד לכל היותר שעה אחת של עסקאות. זה קובע את תדירות הגיבוי ואת הצורך בשכפול סינכרוני. RTO (Recovery Time Objective) הוא זמן ההשבתה המקסימלי המקובל. RTO = 4 שעות אומר ששירותים חייבים לחזור לפעילות תוך 4 שעות. זה קובע את מודל אתר ה-DR (חם/חמים/קר) ואת מידת האוטומציה ב-failover.

טעות נפוצה: מהנדסים קובעים RPO = 0 ו-RTO = 15 דקות בלי להבין שזה דורש שכפול סינכרוני בזמן אמת ו-hot standby — מה שמכפיל למעשה את עלות התשתית. העסק עשוי להסתפק ב-RPO = 24 שעות ו-RTO = 8 שעות בעלות נמוכה משמעותית. יישור המספרים האלה הוא הצעד הראשון לתוכנית ריאלית.

איך לבחור מודל אתר DR?

בחירת הארכיטקטורה תלויה ב-RPO/RTO ובתקציב. עבור RTO מינימלי (< דקה אחת), צריך hot standby פעיל עם שכפול סינכרוני. עבור RTO עד 4 שעות, warm standby עם שכפול אסינכרוני מספיק. אם העסק יכול לסבול יום של השבתה, cold standby עם שחזור מגיבויים עובד. השוו אפשרויות בטבלה:

מלאי מערכות קריטיות

תוכנית DR מתחילה בסיווג מערכות לפי רמת קריטיות:

עבור כל מערכת ברמה 1, רשמו תלותיות (מה נופל איתה), בעלים, נוהל שחזור ואנשי קשר אחראיים.

פתרונות ארכיטקטוניים ל-RPO/RTO

PostgreSQL עם שכפול ו-Patroni. עבור RPO < 5 דקות ו-RTO < 10 דקות, השתמשו בשכפול סטרימינג עם failover אוטומטי דרך Patroni:

---
# patroni.yml — конфиг для DR-кластера
scope: pg-production
namespace: /service/
restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.1.10:8008
etcd3:
  hosts:
    - 10.0.0.1:2379
    - 10.0.0.2:2379
    - 10.0.0.3:2379
bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576  # 1 MB — лаг репликации
    postgresql:
      use_pg_rewind: true
      use_slots: true
      parameters:
        wal_level: replica
        hot_standby: "on"
        max_wal_senders: 10
        max_replication_slots: 10
        synchronous_commit: "on"
        synchronous_standby_names: "ANY 1 (replica-dr)"
postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.1.10:5432
  data_dir: /var/lib/postgresql/data
  pg_hba:
    - host replication replicator 10.0.0.0/24 md5
    - host all all 0.0.0.0/0 md5

Terraform לתשתית כקוד. תשתית DR צריכה להיות מתוארת ב-Terraform ומאוחסנת ב-Git. Terraform מהיר פי 10 מפריסה ידנית לריצות חוזרות — הדרך היחידה להבטיח התאוששות צפויה שנה אחר כך:

# dr-site/main.tf
module "dr_vpc" {
  source = "../modules/vpc"
  cidr_block = "10.10.0.0/16"
  availability_zones = ["eu-central-1a", "eu-central-1b"]
  tags = {
    Environment = "dr"
    Tier = "1"
  }
}

module "dr_rds" {
  source = "../modules/rds"
  identifier = "prod-dr-replica"
  source_db_identifier = "prod-primary"
  # Read replica в DR-регионе — основа для failover
  replicate_source_db = "arn:aws:rds:us-east-1:123456789:db:prod-primary"
}

Nginx ומאזני עומסים. DNS failover דרך Route53 או Cloudflare: כשהנקודת קצה הראשית לא בריאה, התעבורה עוברת ל-DR. עבור RTO < 15 דקות, נדרשות בדיקות בריאות אקטיביות עם TTL ≤ 60 שניות.

מבנה תוכנית ה-DR: מה המסמך צריך להכיל

תוכנית DR טובה היא לא תיאור ארכיטקטורה. היא הוראות שלב-אחר-שלב לאדם שמקבל שיחה ב-3 לפנות בוקר אחרי התראה. מבנה:

1. טריגרים להפעלת DR — תנאים ספציפיים שמתחילים את נוהל ה-DR. לא "בעיות משמעותיות" אלא "אתר ראשי לא זמין יותר מ-15 דקות לפי התראת Prometheus Alertmanager # patroni.yml — конфиг для DR-кластера scope: pg-production namespace: /service/ restapi: listen: 0.0.0.0:8008 connect_address: 10.0.1.10:8008 etcd3: hosts: - 10.0.0.1:2379 - 10.0.0.2:2379 - 10.0.0.3:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 retry_timeout: 10 maximum_lag_on_failover: 1048576 # 1 MB — лаг репликации postgresql: use_pg_rewind: true use_slots: true parameters: wal_level: replica hot_standby: "on" max_wal_senders: 10 max_replication_slots: 10 synchronous_commit: "on" synchronous_standby_names: "ANY 1 (replica-dr)" postgresql: listen: 0.0.0.0:5432 connect_address: 10.0.1.10:5432 data_dir: /var/lib/postgresql/data pg_hba: - host replication replicator 10.0.0.0/24 md5 - host all all 0.0.0.0/0 md5 ."
2. מטריצת אחריות — מי מחליט להפעיל DR, מי מבצע, מי מודיע לעסק.
3. Runbooks שלב-אחר-שלב — runbook נפרד לכל שירות ברמה 1 עם פקודות, תוצאות צפויות ונקודות אימות.
4. נוהל failback — חזרה לראשי אחרי התאוששות. לעתים קרובות נשכח, ואז אתר ה-DR הופך ל"ראשי" החדש ללא תיעוד.
5. תוכנית תקשורת — תבניות הודעה ללקוחות, התחייבויות SLA, אנשי קשר של ספקים (ענן, אירוח, CDN).

למה תרגולים סדירים הם קריטיים?

ללא תרגולים סדירים, תוכנית ה-DR מתיישנת במהירות. אפילו מסמך כתוב היטב לא מבטיח שהצוות יכול לבצע אותו תחת לחץ. אנחנו ממליצים על תרגולים לפחות אחת לרבעון עבור רמה 1, וחודשי עבור השירותים הקריטיים ביותר. תרגולים חושפים runbooks מיושנים, שינויי תשתית ופערי ידע. אחרי כל תרגול, התוכנית מתעדכנת.

מה כלול בעבודה

כשאנחנו מפתחים תוכנית DR סוהר, אנחנו מספקים:

• ביקורת תשתית נוכחית וסיווג רמות
• יישור RPO/RTO עם העסק ותיעוד
• עיצוב ארכיטקטורת אתר DR (בחירת חם/חמים/קר)
• הגדרת שכפול, אוטומציית failover וניטור
• Runbooks לכל השירותים הקריטיים
• תיעוד נהלים (טריגרים, מטריצת אחריות, failback)
• תרגולים ראשוניים והתאמות לתוכנית לפי התוצאות
• הדרכת צוות והעברת גישה
• תמיכה בתקופת האחריות לאחר הפריסה

תהליך פיתוח התוכנית

העבודה מתחילה בסדנת עבודה עם בעלי עניין מרכזיים: ביקורת מערכות קריטיות, איסוף דרישות RPO/RTO, מלאי תלותיות. משך זמן טיפוסי הוא 1-2 ימים לתשתית פשוטה, שבוע לתשתית מורכבת.

השלב הבא הוא ניתוח פערים: מה כבר קיים ל-DR ומה חסר. לעתים קרובות יש גיבויים אבל אין נוהל שחזור, או ששכפול מוגדר אבל אף פעם לא נבדק.

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

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

העלות מוערכת באופן אישי אחרי ביקורת תשתית. כדי להעריך את הפרויקט שלכם, צרו קשר — ננתח את התשתית שלכם ונציע את הפתרון האופטימלי. קבלו ייעוץ ממהנדס עם ניסיון של 10+ שנים ב-DevOps ו-SRE.

תיעוד רשמי של Patroni