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