במאמר הזה מוסבר איך לתכנן את גלי ההעברה.
אפשר לקבץ את המועמדים להעברה לגל העברות. אפשר לבצע את הקיבוץ ברמה גבוהה (לפי קטגוריה) או ברמה מפורטת (אפליקציות, מיקומים, רכיבים), בהתאם למידע שאוספים במהלך שלב הגילוי וההערכה.
יצירת קטלוג אפליקציות
כדי להתחיל בתכנון, צריך ליצור קטלוג אפליקציות. כדאי לארגן את האפליקציות בקטגוריות על סמך ארכיטקטורת האפליקציה, שיקולים עסקיים ופעולות IT. כך אפשר לתעדף אותם לפי חשיבות עסקית, מורכבות וסיכונים שקשורים למעבר לענן. השילוב והסדר העדיפויות של הגורמים האלה משתנים בין ארגונים, בהתאם לצרכים העסקיים שלהם ולמיפוי של הצרכים האלה לעומסי עבודה, גם בארכיטקטורה הנוכחית וגם בארכיטקטורה העתידית שלGoogle Cloud .
ברשימה הבאה מפורטות שלוש הקטגוריות העיקריות והגורמים שצריך לקחת בחשבון בכל קטגוריה.
ארכיטקטורה של אפליקציות
- מגבלות טכניות
- מספר התלויות
- מספר הרמות
- עם שמירת מצב לעומת בלי שמירת מצב
- דרישות הביצועים
- תלות גיאוגרפית
שיקולים עסקיים
- דרישות התאימות
- חשיבות עסקית
- יכולת שינוי העסק
- מספר המשתמשים
- סוג המשתמשים (פנימיים, חיצוניים)
- TCO
תפעול IT
- סביבת הפעלה
- הסכם רמת שירות (SLA)
- זמינות
- גיבוי
מיפוי ותעדוף
מקטלוג האפליקציות, ממפים את האפליקציות על סמך המורכבות וגישת ההעברה הממוקדת. הגישה למיגרציה צריכה להתבסס על התוצאות העסקיות שאתם מצפים להן, על המאמץ שנדרש למיגרציה ועל גורמי הסיכון הנלווים, גם במהלך המיגרציה וגם אחריה.
לאחר מכן, מדרגים את המועמדים להעברה לפי סדר עדיפות, על סמך הערך העסקי והמאמץ הנדרש להעברה. כדי להתכונן להעברה, צריך לזהות אפליקציות עם תכונות שסביר להניח שיועברו קודם. אתם יכולים לבחור רק אחת, או לכלול הרבה אפליקציות בגל הראשון. האפליקציות בגל הראשון מאפשרות לצוותים שלכם לבדוק את הפריסה בסביבת הענן, תוך התמקדות בהעברה במקום במורכבות של האפליקציות.
התחלה עם אפליקציה עצמאית מפחיתה את הסיכון הראשוני, כי בהמשך תוכלו להשתמש בידע החדש של הצוות באפליקציות מורכבות יותר עם הרבה תלויות.
אפליקציות בגל הראשון בדרך כלל לא קריטיות לעסק, ויש להן פחות תלות במערכת וברשת. בנוסף, הם דורשים פחות ארגון הקוד מחדש (Refactoring), בדרך כלל יש להם פחות נתונים, אין להם אתגרים ספציפיים בתחום התאימות והם יכולים להרשות לעצמם חלון זמן למעבר חד למערכת אחרת (cutover). מידע נוסף זמין במאמר בנושא בחירת האפליקציות להעברה ראשונה.
העברת אפליקציות לקבוצות בגלים
לקבץ את האפליקציות לכמה גלים עם ציר זמן שמשויך לכל גל, וגם להגדיר את הזמן לשינוי התוכניות על סמך המשוב מכל גל.
- גל 1: ערך עסקי גבוה, מאמץ הטמעה נמוך.
- האפליקציות האלה מתאימות במיוחד להעברות מוקדמות או להוכחת היתכנות.
- גל 2: ערך עסקי גבוה, מאמץ הטמעה גבוה.
- יכול להיות שהבקשות האלה יקבלו עדיפות בשלב הבא.
- גל 3: ערך עסקי נמוך, מאמץ הטמעה נמוך.
- יכול להיות שהבקשות האלה יקבלו עדיפות בשלב הבא.
- גל 4: ערך עסקי נמוך, מאמץ רב להטמעה.
- האפליקציות האלה צריכות להיות בעדיפות האחרונה.
אחרי שמגדירים את גלי ההעברה, אפשר לארגן אותם בתוכנית פרויקט.
שימוש בשיטות המומלצות
כדי לשפר את תוכנית ההעברה, מומלץ לפעול לפי השיטות המומלצות לאימות תוכנית העברה. יישום הרעיונות שמופיעים במסמך הזה לא מבטיח הצלחה. עם זאת, במסמך מודגשות כמה נקודות שלרוב מתעלמים מהן כשמתכננים העברות, כמו:
- חשוב לוודא שיש לכם אסטרטגיית חזרה לכל שלב בתוכנית ההעברה.
- תכנון פריסה והשקה הדרגתית, כפי שצוין קודם במסמך הזה.
- שליחת התראות לכל צוותי הפיתוח והתפעול שאחראים על עומסי העבודה להעברה.
- הסרת משאבים וניסויים להוכחת היתכנות מסביבת הייצור של היעד.
- הגדרת קריטריונים להוצאה בטוחה משימוש של סביבת המקור.
- חשוב לוודא שאתם מבצעים הערכת סיכונים להעברה בכל גל העברה, ומיישמים אמצעים לצמצום הסיכונים שזוהו.