ביצוע ההעברה

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

לפני שמתחילים

צריך לוודא שהשלמתם את המשימות הבאות:

הכנות ראשוניות להעברה

פרויקט ההעברה ל-Cloud הוא מאמץ ארגוני משמעותי שמניע את ההעברה של עומסי העבודה אל Google Cloud.

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

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

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

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

תהליך ומתודולוגיה של מיגרציה

תכנון ספרינט ומדריך

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

# פריט תיאור
0 ארכיטקטורה של כלי העברה ארכיטקטורה של כלים שמרכיבים מפעל העברה (כלים להערכה שוטפת, לשיפור תוכנית הגלים, להעברה, לבנייה, לבדיקה, לפריסה ולמעקב ספציפיים לעומס עבודה)
1 רשימת משימות להעברה רשימת משימות לשימוש לפני ספרינט ההעברה ובמהלכו
2 מלאי רשימת עומסי העבודה שיועברו אל Google Cloud
3 Sprint runbook הנחיות לביצוע העברה של כל עומס עבודה
4 תוכנית העברה תוכנית העברה מפורטת (תהליך) שצריך לפעול לפיה במהלך ספרינט ההעברה
5 כללי רשת ואבטחה רשימה של כל כללי חומת האש לתעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) ב- Google Cloud
שינויים ב-DNS במהלך המיגרציה ל- Google Cloud
6 סיכונים וצמצום סיכונים סיכונים אפשריים במהלך ספרינט המיגרציה ושלבים לצמצום הסיכונים
7 בדיקות ואימות תוכנית בדיקה לאימות דרישות פונקציונליות ודרישות לא פונקציונליות
8 חזרה לתוכנית קודמת שלבי חזרה לעומס עבודה
9 הרכב הקבוצה הרכב הקבוצה ורשימת השחקנים עם פרטים ליצירת קשר
10 ניהול מטריצת RACI של צוות הביצוע של ההעברה, קצב ודיווח, מנגנונים לפתרון בעיות שדורשות העברה לטיפול ברמה גבוהה יותר

ביצוע ההעברה

אחרי שמשלימים את שלב התכנון וההכנה של המיגרציה, בחלק הזה מוסבר איך לבצע מיגרציות ואימותים חוזרים Google Cloud.

מחזור ביצוע ההעברה

הערכה

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

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

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

תוכנית

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

  • העברת קבוצות במסגרת הספרינט הנוכחי
  • רשימת משימות ל-Sprint של מיגרציה
  • פתרונות לבעיות שחוסמות את ההשקה
  • תוכנית להעברה, לפיתוח, לבדיקה ולפריסה
  • תוכנית רולבק
  • תזמון של ביצוע

תכנון מפורט ברמה נמוכה הוא קריטי לפריסה מוצלחת.

כלים לפריסה

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

הפלט של שלב הפריסה הוא:

  • עדכונים בתוכנית ההעברה (סטטוס לכל שלב, הערות)
  • עדכונים בכלי למעקב אחרי בעיות בהעברה
  • תוצאות הבדיקה אחרי ההעברה
  • עדכונים ב-CMDB (אם רלוונטי)
  • העברת תוצאות ההעברה לבעלי עניין

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

אופטימיזציה

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

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

הפלט של השלב הזה הוא:

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

כלים להעברה

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

במסמכים הבאים מוצגים כמה כלי אוטומציה שמתייחסים ליכולות הבאות:

המאמרים הבאים