צ'קליסט מעבר לענן: איך להעביר שרתים בלי השבתה מיותרת

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

מה השלבים של מעבר לענן?

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

מה צריך למפות לפני מעבר לענן?

צריך למפות כל מה שרץ על השרתים הקיימים, כולל דברים "קטנים" שאף אחד לא זוכר שהם שם. מערכת שנשכחה - משימה מתוזמנת, תיבת דואר, חיבור VPN לספק - היא הגורם הנפוץ ביותר לתקלות אחרי מעבר.

• שרתים ומערכות הפעלה: גרסה, תפקיד, מי האחראי.
• אפליקציות ושירותים: שרת ווב, מסדי נתונים, תוכנות הנהלת חשבונות, CRM, שיתוף קבצים.
• משימות מתוזמנות: cron ב-Linux, Task Scheduler ב-Windows, גיבויים, סקריפטים לייצוא נתונים.
• תלויות רשת: מי מתחבר למה ובאיזה פורט, כתובות IP שמורשות אצל ספקים או בנקים (Whitelisting), חיבורי VPN.
• DNS ודואר: כל הרשומות באזור הדומיין - A, CNAME, MX, TXT (SPF, DKIM, DMARC).
• תעודות ורישיונות: תעודות TLS, רישיונות תוכנה שקשורים לחומרה או לכתובת MAC, רישיונות Windows ו-RDS.
• נתונים: נפח כולל, קצב שינוי יומי ומה רגיש (מידע אישי, רפואי, פיננסי).

טיפ מעשי: הריצו ss -tulpn בשרתי לינוקס או netstat -ano ב-Windows, וגם בדקו את לוגי חומת האש - הם מראים חיבורים שלא מופיעים באף תיעוד.

איך יודעים איזה שרת ענן צריך אחרי המעבר?

קובעים את גודל שרת היעד לפי צריכה בפועל ולא לפי החומרה הישנה. שרת משרדי עם 32GB זיכרון שמנוצל ב-20% לא צריך 32GB בענן. אספו נתוני שימוש לאורך שבוע-שבועיים, כולל שעות עומס וסוף חודש:

• מעבד: ממוצע ושיא. שיא קבוע מעל 70% מצדיק עוד vCPU.
• זיכרון: שימוש בפועל בלי מטמון מערכת ההפעלה, עם מרווח של 20%-30%.
• דיסק: נפח נוכחי, קצב גדילה שנתי ו-IOPS בשעות שיא. דיסקי NVMe בענן מהירים לרוב מדיסקים מכניים ישנים, כך שצוואר בקבוק בדיסק עשוי להיעלם.
• רשת: תעבורה יוצאת חודשית ומספר משתמשים מרוחקים במקביל.

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

למה להוריד את ה-TTL ב-DNS לפני המעבר?

מורידים את ה-TTL כדי שכשתחליפו את כתובת ה-IP של הדומיין, העולם יתעדכן תוך דקות ולא תוך שעות. ה-TTL הוא הזמן (בשניות) שבו שרתי DNS אחרים שומרים את התשובה במטמון.

1. בדקו את ה-TTL הנוכחי: dig +noall +answer example.co.il A - המספר בעמודה השנייה.
2. הורידו את ה-TTL של הרשומות שישתנו ל-300 שניות. עשו זאת לפחות פרק זמן השווה ל-TTL הישן לפני המעבר (אם היה 86400, כלומר יממה - לפחות יממה מראש).
3. ביום המעבר עדכנו את רשומות ה-A (ו-AAAA אם יש IPv6) לכתובת החדשה.
4. אחרי שהכול יציב (כמה ימים), החזירו את ה-TTL לערך גבוה, למשל 3600.

אם הדואר נשאר אצל ספק אחר, אל תגעו ברשומות MX. אם השרת החדש שולח דואר, עדכנו את רשומת SPF והגדירו rDNS לכתובת החדשה.

איך מסנכרנים נתונים לשרת החדש בלי השבתה ארוכה?

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

# סנכרון ראשוני של קבצים (אפשר להריץ כמה פעמים - כל ריצה מעבירה רק שינויים)
rsync -aHAX --info=progress2 /var/www/ dana@new-server:/var/www/

# מסד נתונים MySQL - ייצוא עקבי בלי לנעול טבלאות InnoDB
mysqldump --single-transaction --routines --triggers appdb | gzip > appdb.sql.gz

בשרתי Windows אפשר להשתמש ב-robocopy /MIR לקבצים ובגיבוי ושחזור של SQL Server. למסדי נתונים גדולים או פעילים מאוד, שכפול (Replication) מהישן לחדש מקצר את חלון ההשבתה לדקות. ודאו שהנתונים עוברים מוצפנים - דרך SSH, VPN או TLS - במיוחד כשמדובר במידע אישי; רקע על הדרישות נמצא במדריך על תיקון 13 לחוק הגנת הפרטיות.

מה עושים ביום המעבר עצמו?

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

1. הודעה מוקדמת למשתמשים וללקוחות על חלון התחזוקה.
2. גיבוי מלא אחרון של השרת הישן ו-Snapshot של השרת החדש לפני הסנכרון הסופי.
3. הקפאת שינויים: מצב תחזוקה באתר, עצירת משימות מתוזמנות, ניתוק משתמשים מהתוכנה.
4. סנכרון אחרון של קבצים ומסד נתונים.
5. בדיקות לפני החלפת DNS: גישה לשרת החדש דרך קובץ hosts מקומי - התחברות, טפסים, תשלומים, שליחת דואר, הדפסות ודוחות.
6. החלפת DNS או כתובות בתוכנות הלקוח (למשל קיצורי RDP).
7. ניטור צמוד של לוגים ושגיאות בשעות הראשונות.

מה זו תוכנית חזרה (Rollback) ולמה היא חובה?

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

• הגדירו נקודת החלטה: למשל "אם תוך שעתיים מתחילת החלון הבדיקות הקריטיות לא עוברות - חוזרים".
• אל תכבו ואל תמחקו את השרת הישן. השאירו אותו במצב קריאה בלבד או כבוי-אך-שלם.
• תכננו את כיוון הנתונים: אם השרת החדש כבר קיבל הזמנות או רשומות חדשות, איך הן חוזרות לישן? זו הנקודה שרוב התוכניות שוכחות.
• TTL נמוך מאפשר גם לחזור במהירות - עוד סיבה להשאיר אותו נמוך כמה ימים.

מה הסיכונים הנפוצים במעבר לענן ואיך מצמצמים אותם?

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

לגבי השהיה: כשהמשתמשים בישראל, שרת בחוות שרתים בישראל נותן זמני תגובה נמוכים יותר מאזור ענן באירופה - זה מורגש במיוחד בתוכנות שעובדות ב-RDP. ההשוואה המלאה נמצאת במדריך ענן ישראלי מול AWS ו-Azure.

מה בודקים אחרי המעבר לענן?

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

• גיבוי אוטומטי רץ, ושחזור ניסיון אחד לפחות הצליח - לפי שיטת 3-2-1.
• ניטור זמינות ומשאבים שולח התראות לאדם הנכון.
• הקשחת אבטחה בסיסית: עדכונים, חומת אש, גישת ניהול מוגבלת.
• תעודות TLS מתחדשות אוטומטית בשרת החדש.
• משימות מתוזמנות רצות בזמן ובהצלחה.
• ה-TTL הוחזר לערך רגיל, והתיעוד עודכן עם הכתובות והסיסמאות החדשות (בכספת סיסמאות).
• רק אחרי כל אלה - גיבוי אחרון של השרת הישן וכיבוי מסודר.