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