העברה ללא השבתה מסביבה מקומית (On-Premise) לענן
אנחנו יודעים שרוב ההעברות לא מתנהלות כמתוכנן. לא בגלל שהתכנית גרועה — אלא בגלל שתשתית מקומית (On-Premise) מכילה עשרות תלותויות נסתרות שאיש לא תיעד בחמש השנים האחרונות. שירות A קורא במפתיע לשירות B דרך כתובת IP מקודדת 192.168.1.45. מסד הנתונים חי על שיתוף NFS המורכב על שרת קבצים שמשרת גם שש יישומים אחרים. אישורים עבור PKI פנימי מונפקים לשם מארח (hostname) שישתנה בענן. לפי ויקיפדיה, 80% מההפתעות כאלה מתגלות רק במהלך המעבר (cutover). לכן החודש הראשון של כל העברה הוא גילוי, לא העברה. זה בדרך כלל חוסך ללקוחות $50,000 בשנה, ואנחנו מגלים בממוצע 80 תלותויות נסתרות לכל פרויקט.
כיצד מתבצע ניתוח מלאי ותלותויות?
לפני העברת כל שירות, אנחנו צריכים תמונה מלאה. הכלים תלויים בטכנולוגיה: עבור סביבות VMware — VMware vRealize Network Insight או CloudPhysics; עבור bare metal — גילוי מבוסס netstat, סוכנים כמו AWS Application Discovery Service.
אנחנו אוספים את הנתונים הבאים:
- מפת קישוריות רשת בין שירותים (איזה תהליך מדבר עם איזה פורט)
- פרופילי צריכת משאבים במשך 2–4 שבועות (CPU, RAM, דיסק IO, רשת)
- רשימת תלותויות חיצוניות: AD/LDAP, NFS, SAN, שרתי רישוי
- יישומים הקשורים לחומרה (דונגלים USB, כרטיסי רשת ספציפיים, GPU)
AWS Migration Hub מאחד נתונים מסוכני גילוי שונים ובונה גרף תלותויות. זה לא תחליף לניתוח ידני אבל נקודת התחלה טובה.
בהתבסס על המלאי, כל שירות נכנס לקטגוריה אחת:
- Rehost (lift & shift) – ה-VM עובר כפי שהוא, עם שינויים מינימליים
- Replatform – מסד הנתונים מועבר ל-RDS מנוהל, היישום נשאר ללא שינוי קוד
- Refactor – כתיבה מחדש לענן טבעי (קונטיינרים, lambda, שירותים מנוהלים)
- Retire – השירות לא נחוץ, מכבים אותו
- Retain – נשאר מקומי מסיבות טכניות או רגולטוריות
בפועל, הגל הראשון של העברה הוא 70–80% Rehost, והשאר Replatform. Refactor הוא תכנית נפרדת לשישה חודשים עד שנה אחרי ההעברה הבסיסית.
העברה שלב-אחר-שלב: מקרה מסחר אלקטרוני
ניקח חברת מסחר אלקטרוני: 40 שרתים מקומיים, שלוש סביבות (dev/staging/prod), קלאסטר PostgreSQL על שני צמתים עם Patroni, Redis, מאזני עומסים Nginx, מספר שירותי Python/Node.js.
שלב 1: יסודות רשת ב-AWS. VPC עם CIDRs מתאימים, רשתות משנה בשתי אזורי זמינות (AZs), Transit Gateway, VPN Site-to-Site לסביבה המקומית. במהלך ההעברה, שני האתרים רצים במקביל ורואים זה את זה.
שלב 2: העברת מסד נתונים. זה החלק הקריטי ביותר. אנחנו מעבירים PostgreSQL באמצעות AWS DMS עם שכפול מתמשך: מקור – Patroni primary מקומי, יעד – RDS PostgreSQL. AWS DMS מהיר פי 3 משכפול ידני מסורתי. DMS מוגדר דרך Terraform:
resource "aws_dms_replication_instance" "migration" {
allocated_storage = 100
apply_immediately = true
auto_minor_version_upgrade = true
engine_version = "3.5.2"
multi_az = false
publicly_accessible = false
replication_instance_class = "dms.r5.large"
replication_subnet_group_id = aws_dms_replication_subnet_group.migration.id
vpc_security_group_ids = [aws_security_group.dms.id]
}
resource "aws_dms_replication_task" "postgres_migration" {
migration_type = "full-load-and-cdc"
replication_instance_arn = aws_dms_replication_instance.migration.replication_instance_arn
replication_task_id = "postgres-main-migration"
source_endpoint_arn = aws_dms_endpoint.source.endpoint_arn
target_endpoint_arn = aws_dms_endpoint.target.endpoint_arn
table_mappings = jsonencode({
rules = [
{
rule-type = "selection"
rule-id = "1"
rule-name = "all-tables"
object-locator = {
schema-name = "%"
table-name = "%"
}
rule-action = "include"
}
]
})
}DMS מריץ טעינה מלאה, ואז עובר למצב CDC ומשכפל שינויים בזמן אמת. השהיית השכפול מנוטרת דרך מדד CloudWatch resource "aws_dms_replication_instance" "migration" { allocated_storage = 100 apply_immediately = true auto_minor_version_upgrade = true engine_version = "3.5.2" multi_az = false publicly_accessible = false replication_instance_class = "dms.r5.large" replication_subnet_group_id = aws_dms_replication_subnet_group.migration.id vpc_security_group_ids = [aws_security_group.dms.id] } resource "aws_dms_replication_task" "postgres_migration" { migration_type = "full-load-and-cdc" replication_instance_arn = aws_dms_replication_instance.migration.replication_instance_arn replication_task_id = "postgres-main-migration" source_endpoint_arn = aws_dms_endpoint.source.endpoint_arn target_endpoint_arn = aws_dms_endpoint.target.endpoint_arn table_mappings = jsonencode({ rules = [{ rule-type = "selection" rule-id = "1" rule-name = "all-tables" object-locator = { schema-name = "%", table-name = "%" } rule-action = "include" }] }) } .
שלב 3: יישומים ב-ECS או EKS. אנחנו מעבירים תחילה dev, אחר כך staging. ייצור עובר אחרון. תמונות נבנות ב-ECR. Application Load Balancer מטפל בתעבורה.
שלב 4: מעבר (Cutover). מעבר DNS אורך כמה דקות. TTL מונמך ל-60 שניות יום לפני המעבר. ברגע המעבר, DMS מפסיק שכפול, יישומים מוגדרים מחדש לנקודת קצה RDS, והתעבורה זורמת רק ל-AWS. הסביבה המקומית נשארת במצב קריאה-בלבד לשבוע נוסף כגיבוי. המומחיות שלנו בהעברת DevOps כוללת העברת תשתית ותכנון מעבר, המבטיחה העברה ללא השבתה עם שירותי ענן כמו AWS DMS.
למה ניהול סודות (Secrets) חשוב במהלך העברה?
סודות מקומיים (סיסמאות מסד נתונים, מפתחות API) חיים בדרך כלל במשתני סביבה, קבצי CDCLatencySource, או בכספת מפתחות ארגונית. ב-AWS, אנחנו מעבירים אותם ל-AWS Secrets Manager. External Secrets Operator ב-Kubernetes מסנכרן סודות מ-Secrets Manager לתוך Kubernetes Secrets — היישום לא משנה כלום; הוא פשוט קורא ממשתני סביבה כמו קודם. המומחים המוסמכים שלנו ב-AWS מבטיחים אפס השבתה במהלך המעבר.
אילו טעויות עושים 90% מהצוותים?
- רישוי. Windows Server, Oracle, SQL Server — יש להם תוכניות Bring Your Own License (BYOL). אם לא מתחשבים בזה בגודל המשאבים, תקבלו חשבונית מ-Oracle. הקנס הממוצע להפרות רישוי הוא $50,000–$200,000.
- מדיניות גיבוי. גיבויים מקומיים לא עוברים אוטומטית לענן. צריך להקים AWS Backup או Velero מהיום הראשון.
- ניטור במהלך המעבר. במהלך ההעברה, תעבורה זורמת דרך שני האתרים. Prometheus עם remote_write בשתי הסביבות, מופע Grafana יחיד — כל השירותים נראים.
- Security Groups לעומת כללי Firewall. מדיניות Firewall מקומית עם 200 כללים לא מועברת אחד-לאחד. אנחנו כותבים מחדש Security Groups על עיקרון ההרשאה המינימלית, תוך שימוש ב-Tags לקיבוץ.
Rehost, Replatform, Refactor: מה לבחור?
| אסטרטגיה | שינויים | ציר זמן | מורכבות |
|---|---|---|---|
| Rehost | ללא | ימים–שבועות | נמוכה |
| Replatform | תשתית בלבד | שבועות–חודשים | בינונית |
| Refactor | קוד + תשתית | חודשים–שנים | גבוהה |
שירותי AWS מנוהלים (RDS, EKS) מפחיתים עומס תפעולי פי 3–5 בהשוואה לסביבה מקומית, לפי המדידות שלנו.
הערכות ציר זמן
| היקף | טווח | משך |
|---|---|---|
| קטן (10–20 שרתים) | Rehost + מסד נתונים מנוהל | 6–10 שבועות |
| בינוני (20–60 שרתים) | Rehost + Replatform חלקי | 3–5 חודשים |
| גדול (60+ שרתים) | העברה בשלבים, גלים מרובים | 6–18 חודשים |
תוצרים (Deliverables)
- דוח גילוי עם מפת תלותויות וסיכונים
- תכנית העברה עם הוראות שלב-אחר-שלב
- תצורות Terraform לכל תשתית הענן
- הקמת ניטור והתראות (Prometheus/Grafana)
- תיעוד מדיניות תפעול וגיבוי
- הדרכת צוות (2 מפגשים) ושבועיים של תמיכה לאחר העברה
- גישה לפורטל העברת הענן שלנו למעקב בזמן אמת
עלויות העברה נעות בדרך כלל בין $10k לפרויקטים קטנים ל-$100k לגדולים. לצוות שלנו יש מעל 10 שנות ניסיון ב-DevOps וביצע יותר מ-50 העברות מוצלחות. הפחיתו TCO ב-30–50% עם גישה מובטחת. צרו קשר לניתוח התשתית שלכם. הזמינו ביקורת (audit) היום והתחילו לחסוך.







