הקמת אתר DR (Standby חם/חם-למחצה/קר)

השבתה של מערכת מידע עלולה לעלות לעסק בהפסדים כבדים—כל שעה של חוסר זמינות פוגעת במוניטין וברווחים. אנחנו מתכננים ומקימים אתר DR (Hot, Warm, או Cold Standby) במתכונת turnkey, ועוזרים לכם לבחור את מודל הגיבוי האופטימלי. צוות המומחים שלנו מטפל בכל התהליך, מהביקורת ועד היישום והתמיכה השוטפת, כדי להבטיח שחזור אמין ללא פספוס של זמנים.

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

הקמת אתר DR (Standby חם/חמים/קר)

חברה מפסידה עשרות אלפי דולרים לכל שעת השבתה — זהו הטריגר להטמעת DR. אנו מתכננים אתרי Standby מאפס: מבחירת מודל ועד תרגולים. למהנדסים שלנו יש הסמכות AWS וניסיון בשחזור מהשבתות עבור לקוחות בפינטק ובמסחר אלקטרוני. הבחירה בין Hot, Warm ו-Cold Standby אינה החלטה טכנית אלא החלטה פיננסית עם אילוצים טכניים. ככל שצריך לשחזר מהר יותר, כך אתר ה-Standby יקר יותר. תפקיד המהנדס הוא להציג לעסק אפשרויות ריאליות עם נתוני RTO ועלויות קונקרטיים, ולא רק לתכנן פתרון "נכון" מספר לימוד.

איך לבחור את מודל השכפול?

הגורמים המכריעים הם זמן השבתה מקובל (RTO) ואובדן נתונים (RPO). לפי ויקיפדיה, RTO ו-RPO הם מדדי DR מרכזיים. ככל שה-RTO קטן יותר, כך התשתית יקרה יותר. אנו עוזרים למצוא איזון: להעריך קריטיות שירות, עלות השבתה ותקציב.

Hot Standby: מראה בזמן אמת

Hot Standby הוא עותק מלא של תשתית הייצור הפועל בזמן אמת. המעבר אורך שניות או מספר דקות. RPO מתקרב לאפס עם שכפול סינכרוני.

ארכיטקטורת ענן: קלאסטר active/passive בשני אזורים עם שכפול מסד נתונים סינכרוני ו-AWS Global Accelerator או Cloudflare עבור DNS failover.

# hot-standby/rds.tf
resource "aws_db_instance" "primary" {
  identifier = "prod-primary"
  engine = "postgres"
  engine_version = "15.4"
  multi_az = true # внутри одного региона
  deletion_protection = true
  backup_retention_period = 7
  tags = {
    Role = "primary"
  }
}

resource "aws_db_instance" "dr_replica" {
  identifier = "prod-dr-replica"
  # Read replica в DR-регионе — при failover promote до master
  replicate_source_db = aws_db_instance.primary.arn
  availability_zone = "eu-west-1a"
  # При promote эта реплика станет новым мастером
  auto_minor_version_upgrade = false
  tags = {
    Role = "dr-hot-standby"
  }
}

עלות Hot Standby מכפילה בערך את הוצאות התשתית. עבור רוב הסטארטאפים זה מוגזם. זה מוצדק עבור פינטק, בריאות ומסחר אלקטרוני עם הפסדים העולים על $10K לשעת השבתה.

Warm Standby: איזון בין עלות ל-RTO

Warm Standby פירושו שתשתית DR קיימת אך פועלת בקיבולת מופחתת. מסד הנתונים משתכפל עם פיגור קטן. שרתי היישומים כבויים או פועלים בהספק מינימלי. בעת הפעלת DR, יש להפעיל את המופעים, להחיל שינויי תצורה ממתינים ולהחליף DNS.

RTO: בין 15 דקות לשעתיים בהתאם למורכבות. RPO: בין מספר דקות לשעה.

---
# ansible/dr-warmup.yml — процедура прогрева DR-сайта
---
- name: Warm up DR site
  hosts: dr_site
  become: yes
  tasks:
    - name: Start application servers
      systemd:
        name: "{{ item }}"
        state: started
      loop:
        - app-server
        - worker
        - nginx
    - name: Promote PostgreSQL replica
      command: |
        su - postgres -c "pg_ctl promote -D /var/lib/postgresql/data"
      when: promote_db | bool
    - name: Update DNS to DR endpoint
      community.aws.route53:
        state: present
        zone: company.com
        record: app.company.com
        type: A
        ttl: 60
        value: "{{ dr_lb_ip }}"
        overwrite: yes
    - name: Run health checks
      uri:
        url: "https://app-dr.company.com/health"
        status_code: 200
        retries: 10
        delay: 30

Warm Standby בדרך כלל עולה 20–40% מתשתית הייצור. זו הבחירה הנפוצה ביותר עבור חברות עם SLA של 99.9%.

Cold Standby: עלות מינימלית, RTO מקסימלי

Cold Standby פירושו שתשתית DR לא באמת קיימת. יש גיבויים, תיעוד לבניית סביבה חדשה ותצורת Terraform. בעת הפעלת DR, התשתית נוצרת מאפס, והנתונים משוחזרים מגיבויים.

RTO: 4 עד 24 שעות. RPO: תואם לתדירות הגיבוי, בדרך כלל 1–24 שעות.

#!/bin/bash
# dr-coldstart.sh — скрипт холодного старта DR
set -euo pipefail

echo "=== DR Cold Start initiated at $(date) ==="

# Шаг 1: Поднять инфраструктуру через Terraform
cd /opt/terraform/dr-site
terraform init -backend-config="bucket=company-tf-state-dr"
terraform apply -auto-approve -var="environment=dr"

# Шаг 2: Восстановить данные из последнего бэкапа
LATEST_BACKUP=$(aws s3 ls s3://company-backups/db/ \
  --recursive | sort | tail -1 | awk '{print $4}')
aws s3 cp "s3://company-backups/$LATEST_BACKUP" /tmp/db-restore.dump

# Шаг 3: Восстановить БД
pg_restore \
  --host="${DR_DB_HOST}" \
  --username=postgres \
  --dbname=production \
  --jobs=8 \
  /tmp/db-restore.dump

# Шаг 4: Переключить DNS
./scripts/switch-dns-to-dr.sh

echo "=== DR Cold Start completed at $(date) ==="

Cold Standby מתאים לשירותים לא קריטיים או לחברות עם תקציב DR מוגבל מאוד. חשוב לוודא שתצורות ה-Terraform מעודכנות ו-# hot-standby/rds.tf resource "aws_db_instance" "primary" { identifier = "prod-primary" engine = "postgres" engine_version = "15.4" multi_az = true # внутри одного региона deletion_protection = true backup_retention_period = 7 tags = { Role = "primary" } } resource "aws_db_instance" "dr_replica" { identifier = "prod-dr-replica" # Read replica в DR-регионе — при failover promote до master replicate_source_db = aws_db_instance.primary.arn availability_zone = "eu-west-1a" # При promote эта реплика станет новым мастером auto_minor_version_upgrade = false tags = { Role = "dr-hot-standby" } } אכן עובד — אחרת, באסון, עלול לגלות שהמצב סטה מהמציאות לפני חודשים.

מה כלול בתכנון אתר DR?

אנו מספקים:

  • ביקורת תשתית קיימת וזיהוי שירותים קריטיים.
  • חישוב RTO/RPO ובחירת מודל Standby.
  • ארכיטקטורת אתר DR עם דיאגרמות בלוקים.
  • הטמעה באמצעות Terraform ו-Ansible (קוד במאגר שלך).
  • הגדרת שכפול נתונים (מסד נתונים, קבצים, תצורה).
  • תיעוד נהלי הפעלה ותפקידי צוות.
  • ביצוע תרגול ראשון עם דוח.
  • תמיכה לאחר ההטמעה: ייעוץ ושיפורים.

כל זה — מפתח ביד: מרעיון ועד DR עובד מוכן לבדיקה.

רשימת בדיקה לבחירת מודל

קריטריון קר חמים חם
RTO 4–24 שעות 15 דקות–שעתיים < 5 דקות
RPO 1–24 שעות 5 דקות–שעה < דקה
עלות ~5% מהייצור ~30% מהייצור ~100% מהייצור
מורכבות הקמה נמוכה בינונית גבוהה
דורש תרגולים חובה חובה מומלץ

למה בדיקות הן קריטיות?

ללא תרגולים, אתר DR הוא קונספט תיאורטי. אנו מבצעים את הבדיקה הראשונה תוך חודש מהפריסה. במהלך התרגול, אנו בודקים: הפעלת תשתית, שחזור נתונים, מעבר DNS, זמן תגובה. אנו מתעדים ומתקנים שגיאות. הניסיון שלנו מראה שגם עם תיעוד מושלם, הריצה הראשונה חושפת 5–10 בעיות בלתי צפויות.

תהליך תכנון והטמעה

אנו מתחילים בלכידת דרישות RPO/RTO יחד עם העסק. לאחר מכן — ביקורת תשתית קיימת: מלאי של שירותים קריטיים, ניתוח תלות, נפח נתונים לשכפול. בהתבסס על דרישות ותקציב, אנו בוחרים את מודל ה-Standby. אנו מתכננים את ארכיטקטורת אתר ה-DR, מתארים אותה ב-Terraform. אנו מיישמים שכפול נתונים. אנו מתעדים נהלי הפעלה. אנו מבצעים את הבדיקה הראשונה.

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

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

סוג Standby היקף לוח זמנים
קר עד 20 שירותים 2–4 שבועות
חמים עד 30 שירותים 4–8 שבועות
חם כל היקף 2–3 חודשים

העלות מחושבת באופן אישי לאחר ביקורת תשתית.

אנו נעריך את הפרויקט שלך — צור קשר. אנו מבטיחים תפעול DR בכפוף לתרגולים שנתיים. במשך 5 שנים, הטמענו יותר מ-50 פרויקטים של שחזור מאסון.