מעבר ל-Google Cloud: שיטות מומלצות לאימות של תוכנית העברה

Last reviewed 2025-05-05 UTC

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

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

המסמך הזה הוא חלק מסדרה של כמה מאמרים בנושא מעבר אלGoogle Cloud:

בדיקה

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

ביצוע הערכה מלאה

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

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

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

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

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

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

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

הערכת מצבי הכשל שעומסי העבודה תומכים בהם

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

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

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

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

הערכת צינורות עיבוד הנתונים

ההערכה של עומס העבודה צריכה לספק תשובות לשאלות הבאות:

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

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

מוודאים שאפשר לעדכן ולפרוס כל עומס עבודה להעברה

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

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

הערכת תשתית הרשת

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

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

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

אחרי ששוקלים שאלות לגבי תשתית איזון העומסים, כדאי לשקול שאלות לגבי תשתית ה-DNS, כמו השאלות הבאות:

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

כדאי ליצור הוכחת קונספט

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

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

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

כדאי ליצור הוכחת היתכנות כשרוצים לבדוק את התחומים הבאים:

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

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

תכנון ההעברה

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

פיתוח אסטרטגיית חזרה לכל שלב בתוכנית המיגרציה

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

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

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

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

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

תכנון מודרניזציה והתאמה של עומסי העבודה

כשמתכננים את המעבר אל Google Cloud, חשוב לזכור שהעברה ושילוב של עומסי עבודה (workloads) לוקחים זמן, ויכול להיות שתיתקלו באתגרים. מומלץ ליצור מסמך סקירה כללית שמתאר את הארכיטקטורה הכללית של עומסי העבודה, כולל מידע על הנושאים הבאים:

  • תלויות במערכות חיצוניות ובתוכנות ביניים של צד שלישי, כמו אחסון, העברת הודעות ואירוח.
  • מנגנונים לאימות ולהרשאה של עומסי עבודה.
  • תהליכים לשילוב עם IAM.
  • הדרישות לגבי סביבת זמן הריצה.
  • אינטראקציות עם אפשרויות של שכבת האחסון, כמו Cloud Storage ומסדי נתונים שלGoogle Cloud .
  • הדרישות לגבי נפח העברת הנתונים ורוחב הפס.
  • שינויים בקוד האפליקציה שאולי תבצעו במהלך המיגרציה.
  • אפשרויות לשילוב עם Google Cloud Observability.

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

תכנון השקות ופריסות הדרגתיות

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

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

התראה לצוותי פיתוח ותפעול

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

אם הצוותים שלכם עובדים באזורי זמן שונים ואתם משתמשים במודל התפעול follow-the-sun, חשוב לוודא את הדברים הבאים:

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

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

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

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

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

הגדרת קריטריונים להוצאה בטוחה משימוש של סביבת המקור

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

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

תכנון עדכון של כל המסמכים ולוחות הבקרה

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

  • תרשימי ארכיטקטורה: כדאי לעדכן את תרשימי הארכיטקטורה כדי לשקף את הארכיטקטורה Google Cloud שלכם, במיוחד אם אתם מבצעים מודרניזציה וארגון מחדש של עומסי העבודה.
  • חיבור ואימות: צריך לעדכן את התיעוד של שיטות האימות, כמו IAM, ואת הגדרות הרשת, כך שישקפו את ה Google Cloud ארכיטקטורה.
  • אבטחה: צריך לעדכן את המסמכים שבהם מוסבר עלGoogle Cloud תכונות האבטחה, כולל הצפנה במנוחה ובמעבר, ואמצעי בקרה לגישה שמבוססים על IAM.
  • תחזוקה והרחבה: עדכון של חוברות הפעלה של ייצור בחלונות תחזוקה של שירותים מנוהלים, הליכי הרחבה אנכית ואופקית ושיטות מומלצות לאופטימיזציה של הביצועים.
  • זמינות גבוהה ומעבר לגיבוי (failover): צריך לעדכן את התיעוד שלכם בנוגע להגדרות של זמינות גבוהה, שיקולים לגבי סנכרון אזורי וסנכרון בין אזורים ומנגנוני מעבר לגיבוי (failover).
  • גיבוי ושחזור: צריך לעדכן את תהליכי הגיבוי והשחזור כך שיתאימו לתהליכים ש Google Cloud ולשירות הגיבוי וההתאוששות מאסון (DR) תומכים בהם. התהליכים האלה כוללים גיבויים אוטומטיים, אפשרויות לשחזור מערכת מנקודה מסוימת בזמן (PITR) ונהלים לייצוא ולייבוא.
  • התאוששות מאסון: צריך לעדכן את תוכנית ההתאוששות מאסון ואת הנהלים בהתאם ליכולות ההתאוששות מאסון של Google Cloud , ואז לבדוק את הנהלים המעודכנים.
  • מעקב ורישום ביומן: שילוב של Google Cloud Observability בלוחות הבקרה של המעקב ובמערכות ההתראות. צריך לעדכן את התיעוד ב-Cloud Quotas ולציין איך לפרש יומנים, מדדים והתראות.

תפעול

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

מעקב אחרי הסביבות

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

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

‫Google Cloud Observability תומך במעקב, ברישום ביומן ובשליחת התראות משולבים עבור סביבתGoogle Cloud .

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

ניהול המיגרציה

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

לדוגמה, כדי להתחיל לתכנן את ניהול ההעברה, כדאי לענות על השאלות הבאות:

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

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

שותפים ביצירת התוכן

מחבר: Marco Ferrari | Cloud Solutions Architect

תורם נוסף: Alex Cârciu | Solutions Architect