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

Last reviewed 2025-05-05 UTC

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

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

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

בדיקה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התוצאות של ההערכה הזו הן לרוב מודלים של הביקוש שעומס העבודה מספק והנתונים שעומס העבודה מייצר בחלון זמן נתון. כשאתם אוספים נקודות נתונים כדי ליצור מודלים כאלה, חשוב לזכור שנקודות הנתונים האלה עשויות להשתנות באופן משמעותי בין חלונות זמן של שיא לבין חלונות זמן שלא חלים בהם שיאים. למידע נוסף על מה ואיך כדאי לעקוב, אפשר לעיין ביעדים לרמת השירות בספר 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) ודרישות התאימות להעברה תואמים לצרכים של הארגון.
  • חיזוק תחושת הביטחון והסכמה של בעלי העניין: עוזרים להבטיח את שביעות הרצון של בעלי העניין. הוכחת היתכנות מוצלחת מחזקת את הביטחון של בעלי העניין בתוכנית ההעברה, כי היא מציגה יתרונות מוחשיים לצוותי ההנהלה והצוותים הטכניים.
  • הערכת העלויות ואפשרויות האופטימיזציה: מעריכים את העלויות שקשורות להעברה. בודקים אפשרויות אופטימיזציה, כמו בדיקת גדלים שונים של סביבת היעד וכלי העברה שונים.

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

תכנון ההעברה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • תרשימי ארכיטקטורה: צריך לעדכן את תרשימי הארכיטקטורה כך שישקפו את הארכיטקטורה של Google Cloud , במיוחד אם מבצעים מודרניזציה וארגון מחדש של עומסי העבודה.
  • חיבור ואימות: צריך לעדכן את התיעוד של שיטות האימות, כמו IAM, ואת הגדרות הרשת, כך שישקפו את הארכיטקטורה. Google Cloud
  • אבטחה: צריך לעדכן את המסמכים שבהם מוסבר עלGoogle Cloud תכונות האבטחה, כולל הצפנה במנוחה ובמעבר, ואמצעי בקרה לגישה שמבוססים על IAM.
  • תחזוקה והרחבה: עדכון של חוברות הפעלה של ייצור בחלונות תחזוקה של שירותים מנוהלים, הליכי הרחבה אנכית ואופקית ושיטות מומלצות לאופטימיזציה של הביצועים.
  • זמינות גבוהה ומעבר לגיבוי: צריך לעדכן את התיעוד בנוגע להגדרות של זמינות גבוהה, שיקולים לגבי סינכרון אזורי ואזורי, ומנגנונים למעבר לגיבוי.
  • גיבוי ושחזור: צריך לעדכן את תהליכי הגיבוי והשחזור כך שיתאימו לתהליכים ש 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