העיקרון הזה, שמופיע בעמודה 'מהימנות' בGoogle Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לתכנן ולהריץ בדיקות לשחזור במקרה של כשלים.
העיקרון הזה רלוונטי לתחום ההתמקדות למידה בנושא אמינות.
סקירה כללית של העקרונות
כדי לוודא שהמערכת יכולה להתאושש מכשלים, צריך להריץ מעת לעת בדיקות שכוללות מעבר לגיבוי באזור אחר, חזרה לגרסה קודמת של התוכנה ושחזור נתונים מגיבויים.
הבדיקות האלה עוזרות לכם להתכונן למקרים של אירועים שעלולים לפגוע באופן משמעותי באמינות, כמו הפסקה זמנית בשירות באזור שלם. הבדיקה הזו גם עוזרת לוודא שהמערכת מתנהגת כמצופה במהלך שיבוש.
במקרה הנדיר של השבתה של אזור שלם, צריך לבצע מעבר אוטומטי של כל התעבורה לאזור אחר. במהלך פעולה רגילה של עומס העבודה, כשנתונים משתנים, צריך לסנכרן אותם מהאזור הראשי לאזור היתירות כשל. צריך לוודא שהנתונים המשוכפלים תמיד עדכניים מאוד, כדי שהמשתמשים לא יחוו אובדן נתונים או ניתוק של הסשן. בנוסף, מערכת איזון העומסים צריכה להיות מסוגלת להעביר את התנועה לאזור יתירות הכשל בכל שלב, בלי הפרעות בשירות. כדי למזער את זמן ההשבתה אחרי הפסקה זמנית בשירות אזורית, מהנדסי תפעול צריכים גם להיות מסוגלים להסיט את תנועת המשתמשים מאזור מסוים באופן ידני ויעיל, תוך כמה שפחות זמן. הפעולה הזו נקראת לפעמים ריקון אזור, כלומר עצירה של התנועה הנכנסת לאזור והעברת כל התנועה למקום אחר.
המלצות
כשמתכננים ומריצים בדיקות לשחזור אחרי כשל, כדאי להביא בחשבון את ההמלצות שבקטעי המשנה הבאים.
הגדרת היעדים וההיקף של הבדיקה
הגדירו בבירור מה אתם רוצים להשיג מהבדיקה. לדוגמה, המטרות שלכם יכולות לכלול את הדברים הבאים:
- מאמתים את משך ההתאוששות (RTO) ואת היעד להתאוששות מאסון (RPO). פרטים נוספים מופיעים במאמר בנושא היסודות של תכנון התאוששות מאסון.
- הערכת חוסן המערכת ועמידותה בפני כשלים בתרחישי כשל שונים.
- בודקים את היעילות של מנגנוני מעבר אוטומטי לגיבוי.
מחליטים אילו רכיבים, שירותים או אזורים ייכללו בהיקף הבדיקה. ההיקף יכול לכלול רמות ספציפיות של אפליקציות כמו חזית האפליקציה, העורף ומסד הנתונים, או שהוא יכול לכלול משאבים ספציפיים כמו מופעי Cloud SQL או אשכולות GKE. Google Cloud בנוסף, בהיקף צריך לציין תלות חיצונית, כמו ממשקי API של צד שלישי או קישורי ענן.
הכנת הסביבה לבדיקה
בוחרים סביבה מתאימה, רצוי סביבת Staging או סביבת Sandbox, שמשכפלת את הגדרת הייצור. אם אתם מבצעים את הבדיקה בסביבת הייצור, הקפידו להכין אמצעי בטיחות כמו ניטור אוטומטי ונהלים לביטול שינויים באופן ידני.
יוצרים תוכנית גיבוי. כדאי לצלם תמונות מצב או לגבות מסדי נתונים ושירותים קריטיים כדי למנוע אובדן נתונים במהלך הבדיקה. מוודאים שהצוות מוכן לבצע התערבויות ידניות אם מנגנוני יתירות הכשל האוטומטיים נכשלים.
כדי למנוע שיבושים בבדיקה, חשוב לוודא שהגדרתם בצורה נכונה את תפקידי ה-IAM, את כללי המדיניות ואת הגדרות היתירות כשל. מוודאים שההרשאות הנדרשות מוגדרות עבור כלי הבדיקה והסקריפטים.
לעדכן את בעלי העניין, כולל צוות התפעול, צוות DevOps ובעלי האפליקציה, לגבי לוח הזמנים של הבדיקה, ההיקף וההשפעה הפוטנציאלית. מספקים לבעלי העניין ציר זמן משוער והתנהגויות צפויות במהלך הבדיקה.
סימולציה של תרחישי כשל
תכנון והרצה של כשלים באמצעות כלים כמו Chaos Monkey. אפשר להשתמש בסקריפטים בהתאמה אישית כדי לדמות כשלים בשירותים קריטיים, כמו השבתה של צומת ראשי באשכול GKE מרובה אזורים או השבתה של מופע Cloud SQL. אפשר גם להשתמש בסקריפטים כדי לדמות הפסקה זמנית בשירות ברשת באזור מסוים באמצעות כללי חומת אש או הגבלות של API, בהתאם להיקף הבדיקה. להגדיל בהדרגה את תרחישי הכשל כדי לבחון את התנהגות המערכת בתנאים שונים.
כדאי להציג בדיקות עומס לצד תרחישי כשל כדי לשכפל את השימוש בעולם האמיתי במהלך הפסקות שירות. בודקים את ההשפעות של כשלים מצטברים, למשל איך מערכות קצה קדמי פועלות כששירותי קצה עורפי לא זמינים.
כדי לאמת שינויים בהגדרות ולבדוק את חוסן המערכת בפני טעויות אנוש, כדאי לבדוק תרחישים שכוללים הגדרות שגויות. לדוגמה, הפעלת בדיקות עם הגדרות שגויות של מעבר לגיבוי בעקבות כשל ב-DNS או הרשאות שגויות של IAM.
מעקב אחר התנהגות המערכת
מעקב אחר האופן שבו מאזני עומסים, בדיקות תקינות ומנגנונים אחרים מנתבים מחדש את התעבורה. משתמשים בכלים כמו Cloud Monitoring ו-Cloud Logging כדי לתעד מדדים ואירועים במהלך הבדיקה. Google Cloud
כדאי לעקוב אחרי השינויים בחביון, בשיעורי השגיאות ובקצב העברת הנתונים במהלך הסימולציה של הכשל ואחריה, ולבדוק את ההשפעה הכוללת על הביצועים. לזהות שינויים לרעה או חוסר עקביות בחוויית המשתמש.
מוודאים שיומנים נוצרים והתראות מופעלות לגבי אירועים מרכזיים, כמו הפסקות שירות או מעבר לגיבוי. אפשר להשתמש בנתונים האלה כדי לוודא שהמערכות שלכם להתראות ולתגובה לאירועים פועלות בצורה יעילה.
אימות השחזור בהשוואה ל-RTO ול-RPO
בודקים כמה זמן לוקח למערכת לחזור לפעילות רגילה אחרי כשל, משווים את הנתונים האלה ל-RTO שהוגדר ומתעדים את הפערים.
חשוב לוודא ששלמות הנתונים והזמינות שלהם תואמות ל-RPO. כדי לבדוק את העקביות של מסד הנתונים, משווים בין תמונות מצב או גיבויים של מסד הנתונים לפני ואחרי כשל.
הערכת שחזור השירות ואישור שכל השירותים שוחזרו למצב תקין עם הפרעה מינימלית למשתמשים.
תיעוד וניתוח של התוצאות
מתעדים כל שלב בבדיקה, כל תרחיש של כשל והתנהגות המערכת שמתאימה לו. כדאי לכלול חותמות זמן, יומנים ומדדים לניתוחים מפורטים.
הדגשת צווארי בקבוק, נקודות כשל בודדות או התנהגויות לא צפויות שנצפו במהלך הבדיקה. כדי לתעדף את התיקונים, כדאי לחלק את הבעיות לקטגוריות לפי מידת החומרה וההשפעה שלהן.
הצעת שיפורים לארכיטקטורת המערכת, למנגנוני יתירות כשל או להגדרות המעקב. בהתאם לממצאים של הבדיקה, מעדכנים את מדיניות המעבר לגיבוי (failover) ואת תוכניות הפעולה הרלוונטיות. הצגת דוח לאחר המוות לבעלי עניין. הדוח צריך לכלול סיכום של התוצאות, המסקנות והשלבים הבאים. מידע נוסף זמין במאמר בנושא עריכת ניתוח מפורט לאחר האירוע.
איטרציה ושיפור
כדי לאמת את המהימנות והחוסן המתמשכים, מומלץ לתכנן בדיקות תקופתיות (לדוגמה, רבעוניות).
מומלץ להריץ בדיקות בתרחישים שונים, כולל שינויים בתשתית, עדכוני תוכנה ועומסי תנועה מוגברים.
אפשר להשתמש בפייפליינים של CI/CD כדי לשלב בדיקות אמינות במחזור החיים של הפיתוח, וכך לבצע אוטומציה של בדיקות יתירות כשל.
במהלך ניתוח התוצאות, כדאי להשתמש במשוב מבעלי עניין ומשתמשי קצה כדי לשפר את תהליך הבדיקה ואת חוסן המערכת.