העמודה 'מהימנות' ב-Google Cloud Well-Architected Framework כוללת עקרונות והמלצות שיעזרו לכם לתכנן, לפרוס ולנהל עומסי עבודה מהימנים ב- Google Cloud.
המסמך הזה מיועד למומחי Cloud Architect, למפתחים, למהנדסי פלטפורמות, לאדמינים ולמהנדסי Site Reliability.
אמינות היא היכולת של מערכת לבצע באופן עקבי את הפונקציות המיועדות שלה בתנאים מוגדרים ולשמור על שירות ללא הפרעות. שיטות מומלצות לאמינות כוללות יתירות, עיצוב סובלני לתקלות, מעקב ותהליכי שחזור אוטומטיים.
כחלק מהאמינות, חוסן הוא היכולת של המערכת לעמוד בכשלים או בשיבושים בלתי צפויים ולהתאושש מהם, תוך שמירה על הביצועים. תכונות שלGoogle Cloud , כמו פריסות מרובות אזורים, גיבויים אוטומטיים ופתרונות להתאוששות מאסון, יכולות לעזור לכם לשפר את החוסן של המערכת.
המהימנות חשובה לאסטרטגיית הענן שלכם ממגוון סיבות, כולל:
- זמן השבתה מינימלי: זמן השבתה עלול לגרום לאובדן הכנסות, לירידה בפריון ולפגיעה במוניטין. ארכיטקטורות עמידות יכולות לעזור להבטיח שהמערכות ימשיכו לפעול במהלך כשלים או להתאושש ביעילות מכשלים.
- חוויית משתמש משופרת: המשתמשים מצפים לאינטראקציות חלקות עם הטכנולוגיה. מערכות עמידות יכולות לעזור לשמור על ביצועים וזמינות עקביים, והן מספקות שירות אמין גם בזמן ביקוש גבוה או בעיות בלתי צפויות.
- תקינות הנתונים: כשלים עלולים לגרום לאובדן נתונים או לפגמים בנתונים. מערכות עמידות מיישמות מנגנונים כמו גיבויים, יתירות ושכפול כדי להגן על הנתונים ולוודא שהם יישארו מדויקים ונגישים.
- המשכיות עסקית: העסק שלכם מסתמך על טכנולוגיה לפעולות קריטיות. ארכיטקטורות גמישות יכולות לעזור להבטיח המשכיות אחרי כשל קטסטרופלי, כך שהפעולות העסקיות יכולות להימשך ללא הפרעות משמעותיות, וההתאוששות מהירה.
- תאימות: בתעשיות רבות יש דרישות רגולטוריות לגבי זמינות המערכת והגנה על הנתונים. ארכיטקטורות גמישות יכולות לעזור לכם לעמוד בתקנים האלה על ידי הבטחה שהמערכות יישארו פעילות ומאובטחות.
- הפחתת עלויות לטווח ארוך: ארכיטקטורות עמידות דורשות השקעה מראש, אבל העמידות יכולה לעזור להפחית את העלויות לאורך זמן. היא מונעת השבתה יקרה, מאפשרת להימנע מתיקונים תגובתיים ומאפשרת שימוש יעיל יותר במשאבים.
מנטליות ארגונית
כדי שהמערכות שלכם יהיו אמינות, אתם צריכים תוכנית ואסטרטגיה מבוססת. האסטרטגיה הזו צריכה לכלול הדרכה וסמכות לתת עדיפות לאמינות לצד יוזמות אחרות.
חשוב להבהיר שכל הארגון אחראי על מהימנות, כולל פיתוח, ניהול מוצרים, תפעול, הנדסת פלטפורמות ו-Site Reliability Engineering (SRE). אפילו קבוצות שמתמקדות בעסקים, כמו שיווק ומכירות, יכולות להשפיע על מהימנות.
כל צוות צריך להבין את יעדי המהימנות והסיכונים של האפליקציות שלו, ולעמוד בדרישות האלה. אם יש סתירה בין מהימנות לבין פיתוח תכונות רגילות של מוצרים, צריך לתת עדיפות למהימנות ולהעביר את הבעיה לטיפול ברמה גבוהה יותר.
תכננו ונהלו את המהימנות באופן הוליסטי, בכל הפונקציות והצוותים. כדאי לשקול להגדיר מרכז מצוינות בענן (CCoE) שכולל עמודה של מהימנות. למידע נוסף, ראו אופטימיזציה של המעבר של הארגון לענן באמצעות מרכז מצוינות בענן.
תחומי המיקוד בנושא מהימנות
הפעילויות שאתם מבצעים כדי לתכנן, לפרוס ולנהל מערכת אמינה אפשר לחלק לקטגוריות הבאות. כל אחד מהעקרונות וההמלצות בנושא אמינות שמופיעים בקטגוריה הזו רלוונטי לאחת מהקטגוריות האלה.
- הגדרת היקף: כדי להבין את המערכת, צריך לבצע ניתוח מפורט של הארכיטקטורה שלה. צריך להבין את הרכיבים, איך הם פועלים ואיך הם מתקשרים ביניהם, איך הנתונים והפעולות זורמים במערכת ומה יכול להשתבש. זיהוי כשלים פוטנציאליים, צווארי בקבוק וסיכונים, כדי שתוכלו לפעול לצמצום הבעיות האלה.
- המלצה: כדי למנוע כשלים במערכת, מומלץ להטמיע תהליך מקיף ורציף של תצפית ומעקב. באמצעות התצפית הזו, תוכלו להבין מגמות ולזהות בעיות פוטנציאליות באופן יזום.
- תגובה: כדי לצמצם את ההשפעה של כשלים, צריך להגיב בצורה מתאימה ולבצע שחזור יעיל. תשובות אוטומטיות יכולות גם לעזור לצמצם את ההשפעה של כשלים. גם עם תכנון ואמצעי בקרה, עדיין יכולות להיות תקלות.
- למידה: כדי למנוע הישנות של כשלים, חשוב ללמוד מכל חוויה ולבצע את הפעולות המתאימות.
עקרונות ליבה
ההמלצות בעמודה 'מהימנות' של Well-Architected Framework ממופות לעקרונות הליבה הבאים:
- הגדרת מהימנות על סמך יעדים של חוויית משתמש
- הגדרת יעדים ריאליים לאמינות
- פיתוח מערכות עם זמינות גבוהה באמצעות יתירות משאבים
- ניצול היתרונות של יכולת הרחבה אופקית
- זיהוי כשלים פוטנציאליים באמצעות יכולת התבוננות (Observability)
- תכנון של שדרוג הדרגתי
- ביצוע בדיקות להתאוששות מכשלים
- ביצוע בדיקות לשחזור מאובדן נתונים
- עורכים ניתוח מפורט של האירוע
שותפים ביצירת התוכן
מחברים:
- Laura Hyatt | Customer Engineer, FSI
- Jose Andrade | Customer Engineer, SRE Specialist
- Gino Pelliccia | Principal Architect
תורמי תוכן אחרים:
- אנדרס-לאונרדו מרטינז-אורטיז | מנהל תוכנית טכנית
- Brian Kudzia | Enterprise Infrastructure Customer Engineer
- Daniel Lees | Cloud Security Architect
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
- גארי הרמסון (Gary Harmson) | אדריכל ראשי
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Marwan Al Shawi | Partner Customer Engineer
- ניקולא פינטו (Nicolas Pintaux) | Customer Engineer, Application Modernization Specialist
- רדיקה קנאקאם | מובילת התוכנית, Google Cloud Well-Architected Framework
- ריאן קוקס (Ryan Cox) | אדריכל ראשי
- Samantha He | Technical Writer
- Wade Holmes | Global Solutions Director
- Zach Seils | מומחה לרשתות
הגדרת מהימנות על סמך יעדים של חוויית משתמש
העיקרון הזה, שנכלל בעמודה 'מהימנות' של Google Cloud Well-Architected Framework, עוזר לכם להעריך את חוויית המשתמשים, ואז למפות את הממצאים למדדים וליעדים של מהימנות.
העיקרון הזה רלוונטי להגדרת ההיקף של תחום המיקוד בנושא אמינות.
סקירה כללית של העקרונות
כלי ניראות (observability) מספקים כמויות גדולות של נתונים, אבל לא כל הנתונים קשורים ישירות להשפעות על המשתמשים. לדוגמה, יכול להיות שתראו שימוש גבוה במעבד (CPU), פעולות איטיות בשרת או אפילו קריסות של משימות. עם זאת, אם הבעיות האלה לא משפיעות על חוויית המשתמש, הן לא נחשבות להפסקה זמנית בשירות.
כדי למדוד את חוויית המשתמש, צריך להבחין בין התנהגות של מערכת פנימית לבין בעיות שמשפיעות על המשתמשים. מתמקדים במדדים כמו יחס ההצלחה של בקשות משתמשים. אל תסתמכו רק על מדדים שמתמקדים בשרת, כמו שימוש ב-CPU, כי הם עלולים להוביל למסקנות מטעות לגבי המהימנות של השירות. מהימנות אמיתית פירושה שהמשתמשים יכולים להשתמש באפליקציה או בשירות שלכם באופן עקבי ויעיל.
המלצות
כדי למדוד את חוויית המשתמש בצורה יעילה, כדאי לעיין בהמלצות שבקטעים הבאים.
מדידת חוויית המשתמש
כדי להבין באמת את רמת המהימנות של השירות, חשוב לתת עדיפות למדדים שמשקפים את החוויה בפועל של המשתמשים. לדוגמה, אפשר למדוד את יחס ההצלחה של שאילתות המשתמשים, את זמן האחזור של האפליקציה ואת שיעורי השגיאות.
מומלץ לאסוף את הנתונים האלה ישירות מהמכשיר או מהדפדפן של המשתמש. אם אי אפשר לאסוף נתונים ישירות, צריך להרחיק בהדרגה את נקודת המדידה מהמשתמש במערכת. לדוגמה, אפשר להשתמש במאזן העומסים או בשירות הקצה הקדמי כנקודת המדידה. הגישה הזו עוזרת לכם לזהות ולפתור בעיות לפני שהן משפיעות באופן משמעותי על המשתמשים.
ניתוח התהליכים שעוברים המשתמשים
כדי להבין איך משתמשים מקיימים אינטראקציה עם המערכת שלכם, אתם יכולים להשתמש בכלי מעקב כמו Cloud Trace. מעקב אחרי מסלול המשתמש באפליקציה מאפשר לזהות צווארי בקבוק ובעיות של זמן אחזור שעלולים לפגוע בחוויית המשתמש. Cloud Trace מתעד נתוני ביצועים מפורטים לכל hop בארכיטקטורת השירות. הנתונים האלה עוזרים לכם לזהות בעיות בביצועים ולטפל בהן בצורה יעילה יותר, וכך לשפר את חוויית המשתמש.
הגדרת יעדים ריאליים למהימנות
העיקרון הזה, שנכלל בעמודת האמינות של Google Cloud Well-Architected Framework, עוזר לכם להגדיר יעדי אמינות שניתנים להשגה מבחינה טכנית עבור עומסי העבודה שלכם ב- Google Cloud.
העיקרון הזה רלוונטי להגדרת ההיקף של תחום המיקוד בנושא אמינות.
סקירה כללית של העקרונות
כדאי לתכנן את המערכות כך שיהיו אמינות מספיק כדי שהמשתמשים יהיו מרוצים. זה אולי נראה לא הגיוני, אבל יעד של 100% מהימנות הוא לרוב לא האסטרטגיה היעילה ביותר. מהימנות גבוהה יותר עשויה להוביל לעלויות גבוהות משמעותית, גם מבחינת השקעה כספית וגם מבחינת מגבלות פוטנציאליות על חדשנות. אם המשתמשים כבר מרוצים מרמת השירות הנוכחית, יכול להיות שהמאמצים להגברת שביעות הרצון לא יניבו החזר השקעה גבוה. במקום זאת, כדאי להשקיע את המשאבים במקומות אחרים.
אתם צריכים לקבוע את רמת המהימנות שמשתמשים מרוצים ממנה, ולקבוע את הנקודה שבה העלות של שיפורים מצטברים מתחילה להיות גבוהה מהיתרונות. כשאתם קובעים את הרמה הזו של מהימנות מספקת, אתם יכולים להקצות משאבים באופן אסטרטגי ולהתמקד בתכונות ובשיפורים שמספקים ערך רב יותר למשתמשים.
המלצות
כדי להגדיר יעדי מהימנות ריאליים, כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
קבלת כישלון מסוים ותעדוף רכיבים
מומלץ לשאוף לזמינות גבוהה, כמו 99.99% זמן פעולה תקינה, אבל לא להגדיר יעד של 100% זמן פעולה תקינה. חשוב להבין שחלק מהכשלים הם בלתי נמנעים.
הפער בין זמינות של 100% לבין יעד של 99.99% הוא המרווח לטעויות. הפער הזה נקרא לעיתים קרובות תקציב השגיאות. תקציב השגיאות יכול לעזור לכם לקחת סיכונים ולחדש, וזה חיוני לכל עסק שרוצה לשמור על יתרון תחרותי.
קובעים סדר עדיפויות לאמינות של הרכיבים הקריטיים ביותר במערכת. מבינים שרכיבים פחות קריטיים יכולים להיות סובלניים יותר לכשלים.
איזון בין אמינות לעלות
כדי לקבוע את רמת המהימנות האופטימלית למערכת שלכם, מומלץ לבצע ניתוח מקיף של עלות-תועלת.
צריך לקחת בחשבון גורמים כמו דרישות המערכת, ההשלכות של כשלים ומידת הסיכון שהארגון מוכן לקחת על עצמו לגבי האפליקציה הספציפית. חשוב לזכור לקחת בחשבון את מדדי תוכנית ההתאוששות מאסון (DR), כמו היעד למשך ההתאוששות (RTO) ויעד להתאוששות מאסון (RPO). צריך להחליט איזו רמת מהימנות מקובלת במסגרת התקציב והמגבלות האחרות.
כדאי לחפש דרכים לשפר את היעילות ולהפחית את העלויות בלי לפגוע בתכונות האמינות החיוניות.
פיתוח מערכות עם זמינות גבוהה באמצעות יתירות משאבים
העיקרון הזה, שנכלל בעמודה 'מהימנות' בGoogle Cloud מסגרת Well-Architected Framework, מספק המלצות לתכנון, לבנייה ולניהול של יתירות משאבים, שיכולות לעזור לכם להימנע מכשלים.
העיקרון הזה רלוונטי להגדרת ההיקף של תחום המיקוד בנושא אמינות.
סקירה כללית של העקרונות
אחרי שקובעים את רמת המהימנות שדרושה, צריך לתכנן את המערכות כך שיימנעו מנקודות כשל יחידות. כל רכיב קריטי במערכת חייב להיות משוכפל במספר מכונות, אזורים ואזורים גיאוגרפיים. לדוגמה, אי אפשר למקם מסד נתונים קריטי רק באזור אחד, ואי אפשר לפרוס שרת מטא-נתונים רק באזור אחד או באזור זמין אחד. בדוגמאות האלה, אם יש הפסקת חשמל באזור או בתחום היחיד, המערכת מושבתת בכל העולם.
המלצות
כדי לבנות מערכות מיותרות, כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
זיהוי של דומיינים של כשלים ושכפול של שירותים
כדאי למפות את אזורי הכשל של המערכת, החל ממכונות וירטואליות בודדות ועד לאזורים, ולתכנן יתירות בכל אזורי הכשל.
כדי להבטיח זמינות גבוהה, כדאי לפרוס את השירותים והאפליקציות שלכם בכמה אזורים ותחומים. כדאי להגדיר את המערכת ליתירות כשל אוטומטית כדי לוודא שהשירותים והאפליקציות ימשיכו להיות זמינים במקרה של הפסקות זמניות באזור או בתחום.
דוגמאות לארכיטקטורות מרובות אזורים ומרובות אזורי זמינות מופיעות במאמר תכנון תשתית מהימנה לעומסי העבודה ב-Google Cloud Google Cloud.
זיהוי בעיות וטיפול בהן באופן מיידי
עוקבים באופן רציף אחרי הסטטוס של דומייני הכשל כדי לזהות בעיות ולטפל בהן במהירות.
אתם יכולים לעקוב אחרי הסטטוס הנוכחי של שירותים בכל האזורים באמצעות Google Cloud לוח הבקרה Service Health. אתם יכולים גם לראות אירועים שרלוונטיים לפרויקט שלכם באמצעות Service Health בהתאמה אישית. אתם יכולים להשתמש במאזני עומסים כדי לזהות את תקינות המשאבים ולהפנות באופן אוטומטי את התעבורה לעורפי קצה תקינים. מידע נוסף זמין במאמר סקירה כללית על בדיקות תקינות. Google Cloud
בדיקת תרחישי מעבר לגיבוי בעת כשל
בדומה לתרגול כיבוי שריפות, מומלץ לבצע סימולציות של כשלים באופן קבוע כדי לאמת את היעילות של אסטרטגיות השכפול והמעבר לגיבוי.
מידע נוסף זמין במאמרים בנושא הדמיה של הפסקת חשמל באזור עבור MIG אזורי והדמיה של כשל באזור באשכולות אזוריים של GKE.
ליהנות מהיתרונות של מדרגיות אופקית
העיקרון הזה, שנכלל בעמודה 'מהימנות' בGoogle Cloud מסגרת Well-Architected Framework, כולל המלצות שיעזרו לכם להשתמש בהרחבה אופקית. שימוש בהרחבת קנה מידה אופקית יכול לעזור לכם לוודא שעומסי העבודה ב-Google Cloud יכולים להתרחב ביעילות ולשמור על הביצועים.
העיקרון הזה רלוונטי לתחום ההתמקדות בהיקף של האמינות.
סקירה כללית של העקרונות
תכננו מחדש את המערכת כך שתהיה לה ארכיטקטורה אופקית. כדי להתמודד עם גידול בתנועה או בנתונים, אפשר להוסיף עוד משאבים. אפשר גם להסיר משאבים כשלא משתמשים בהם.
כדי להבין את היתרונות של הרחבה אופקית, כדאי להכיר את המגבלות של הרחבה אנכית.
תרחיש נפוץ לשינוי קנה מידה אנכי הוא שימוש במסד נתונים של MySQL כמסד הנתונים הראשי עם נתונים קריטיים. ככל שהשימוש במסד הנתונים גדל, נדרשים יותר זיכרון RAM ויחידת CPU. בסופו של דבר, מסד הנתונים מגיע למגבלת הזיכרון במכונת המארח וצריך לשדרג אותו. יכול להיות שיהיה צורך לחזור על התהליך הזה כמה פעמים. הבעיה היא שיש מגבלות קשיחות על הגודל של מסד נתונים. גודלי המכונות הווירטואליות אינם בלתי מוגבלים. יכול להיות שמסד הנתונים יגיע למצב שבו אי אפשר להוסיף עוד משאבים.
גם אם המשאבים לא מוגבלים, מכונה וירטואלית גדולה יכולה להפוך לנקודת כשל יחידה. כל בעיה במכונה הווירטואלית של מסד הנתונים הראשי עלולה לגרום לתגובות שגיאה או להפסקת פעולה בכל המערכת, שתשפיע על כל המשתמשים. מומלץ להימנע מנקודות כשל יחידות, כמו שמתואר במאמר יצירת מערכות עם זמינות גבוהה באמצעות יתירות משאבים.
בנוסף למגבלות ההרחבה האלה, הרחבה אנכית נוטה להיות יקרה יותר. העלות יכולה לגדול באופן אקספוננציאלי ככל שרוכשים מכונות עם יותר כוח מחשוב וזיכרון.
לעומת זאת, הרחבה אופקית יכולה להיות זולה יותר. הפוטנציאל להרחבה אופקית הוא כמעט בלתי מוגבל במערכת שמיועדת להרחבה.
המלצות
כדי לעבור מארכיטקטורה של מכונה וירטואלית יחידה לארכיטקטורה אופקית של כמה מכונות, צריך לתכנן בקפידה ולהשתמש בכלים הנכונים. כדי לעזור לכם להשיג קנה מידה אופקי, כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
שימוש בשירותים מנוהלים
שירותים מנוהלים מייתרים את הצורך בניהול ידני של התאמה לעומס אופקי. לדוגמה, באמצעות קבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine, אתם יכולים להוסיף או להסיר מכונות וירטואליות כדי להרחיב את האפליקציה באופן אופקי. במקרה של אפליקציות בקונטיינרים, Cloud Run היא פלטפורמה ללא שרתים שיכולה לשנות את גודל הקונטיינרים ללא שמירת מצב באופן אוטומטי, בהתאם לתעבורת הנתונים הנכנסת.
קידום עיצוב מודולרי
רכיבים מודולריים וממשקים ברורים עוזרים לכם להרחיב רכיבים ספציפיים לפי הצורך, במקום להרחיב את כל האפליקציה. מידע נוסף זמין במאמר קידום עיצוב מודולרי בנושא אופטימיזציה של הביצועים.
הטמעה של עיצוב ללא מצב
תכננו את האפליקציות כך שלא יהיה בהן מצב, כלומר שלא יהיו נתונים שמאוחסנים באופן מקומי. כך תוכלו להוסיף או להסיר מופעים בלי לדאוג לגבי עקביות הנתונים.
זיהוי כשלים פוטנציאליים באמצעות יכולת התבוננות
העיקרון הזה, שמופיע בעמודה 'מהימנות' של Google Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לזהות באופן יזום אזורים שבהם עלולות להתרחש שגיאות וכשלים.
העיקרון הזה רלוונטי לתחום ההתמקדות בתצפית בנושא מהימנות.
סקירה כללית של העקרונות
כדי לשמור על האמינות של עומסי העבודה ב-Google Cloudולשפר אותה, צריך להטמיע יכולות אבחון יעילות באמצעות מדדים, יומנים ויומני מעקב.
- מדדים הם מדידות מספריות של פעילויות שאתם רוצים לעקוב אחריהן באפליקציה שלכם במרווחי זמן ספציפיים. לדוגמה, יכול להיות שתרצו לעקוב אחרי מדדים טכניים כמו קצב הבקשות ושיעור השגיאות, שאפשר להשתמש בהם כאינדיקטורים ברמת השירות (SLI). יכול להיות שתצטרכו גם לעקוב אחרי מדדים עסקיים שספציפיים לאפליקציה, כמו הזמנות שבוצעו ותשלומים שהתקבלו.
- יומנים הם רשומות עם חותמת זמן של אירועים נפרדים שמתרחשים באפליקציה או במערכת. האירוע יכול להיות כשל, שגיאה או שינוי במצב. היומנים עשויים לכלול מדדים, ואפשר גם להשתמש ביומנים כדי להגדיר SLI.
- trace מייצג את התהליך שעובר משתמש יחיד או טרנזקציה דרך מספר אפליקציות נפרדות או רכיבים של אפליקציה. לדוגמה, הרכיבים האלה יכולים להיות מיקרו-שירותים. בעזרת traces אפשר לעקוב אחרי הרכיבים שבהם נעשה שימוש בתהליכים, לזהות צווארי בקבוק ולראות כמה זמן נמשכו התהליכים.
מדדים, יומנים ועקבות עוזרים לכם לעקוב אחרי המערכת באופן רציף. מעקב מקיף עוזר לכם להבין איפה ומדוע התרחשו שגיאות. אפשר גם לזהות כשלים פוטנציאליים לפני שמתרחשות שגיאות.
המלצות
כדי לזהות ביעילות כשלים פוטנציאליים, כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
קבלת תובנות מקיפות
כדי לעקוב אחרי מדדים מרכזיים כמו זמני תגובה ושיעורי שגיאות, משתמשים ב-Cloud Monitoring וב-Cloud Logging. הכלים האלה גם עוזרים לוודא שהמדדים עומדים באופן עקבי בדרישות של עומס העבודה.
כדי לקבל החלטות שמבוססות על נתונים, צריך לנתח את מדדי שירות ברירת המחדל כדי להבין את התלות בין הרכיבים ואת ההשפעה שלהם על הביצועים הכוללים של עומס העבודה.
כדי להתאים אישית את אסטרטגיית המעקב, אפשר ליצור ולפרסם מדדים משלכם באמצעות Google Cloud SDK.
ביצוע פתרון בעיות יזום
צריך להטמיע טיפול חזק בשגיאות ולהפעיל רישום ביומן בכל הרכיבים של עומסי העבודה ב- Google Cloud. מפעילים יומנים כמו יומני גישה ל-Cloud Storage וVPC Flow Logs.
כשמגדירים רישום ביומן, צריך לקחת בחשבון את העלויות הנלוות. כדי לשלוט בעלויות של רישום ביומן, אפשר להגדיר מסנני החרגה באובייקטים sink ביומן כדי להחריג שמירה של יומנים מסוימים.
אופטימיזציה של ניצול המשאבים
כדי לזהות משאבים שהוקצו להם יותר מדי או פחות מדי משאבים בשירותים כמו GKE, Compute Engine והשירות המנוהל ל-Apache Spark, כדאי לעקוב אחרי מדדי צריכת CPU, מדדי קלט/פלט ברשת ומדדי קלט/פלט בדיסק. לרשימה מלאה של השירותים הנתמכים, אפשר לעיין בסקירה הכללית של Cloud Monitoring.
קביעת סדרי עדיפויות להתראות
כדאי שההתראות יהיו ממוקדות למדדים קריטיים, מוגדרות לפי ערכי סף מתאימים כדי למזער את התשישות מהתראות ולוודא שבעיות משמעותיות יקבלו מענה בזמן מתאים. הגישה הממוקדת מאפשרת לשמור על האמינות של עומסי העבודה באופן יזום. מידע נוסף מופיע בסקירה הכללית על התראות.
תכנון לשדרוג הדרגתי
העיקרון הזה, שנכלל בעמודה 'אמינות' ב-Google Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לתכנן את Google Cloud עומסי העבודה כך שהם יפסיקו לפעול בצורה מסודרת.
העיקרון הזה רלוונטי לתגובה ולאזור ההתמקדות של מהימנות.
סקירה כללית של העקרונות
הפחתה חיננית (graceful degradation) היא גישה עיצובית שבה מערכת שחווה עומס גבוה ממשיכה לפעול, אולי עם ביצועים או דיוק מופחתים. הפחתה חיננית (graceful degradation) מבטיחה את המשך הזמינות של המערכת ומונעת כשל מוחלט, גם אם העבודה של המערכת לא אופטימלית. כשהעומס חוזר לרמה נסבלת, המערכת חוזרת לפעול באופן מלא.
לדוגמה, בתקופות של עומס גבוה, תוצאות החיפוש ב-Google מקבלות עדיפות מדפי אינטרנט עם דירוג גבוה יותר, ולכן יכול להיות שרמת הדיוק תהיה נמוכה יותר. כשהעומס יורד, תוצאות החיפוש ב-Google מחושבות מחדש.
המלצות
כדי לתכנן את המערכות כך שיפעלו בהפחתה חיננית (graceful degradation), כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
הטמעה של ויסות נתונים
מוודאים שהרפליקות יכולות לטפל בעומסים באופן עצמאי, ויכולות להגביל את מספר הבקשות הנכנסות בתרחישים של תנועה גבוהה. הגישה הזו עוזרת למנוע כשלים מדורגים שנגרמים כתוצאה משינויים בתנועה עודפת בין אזורים.
מומלץ להשתמש בכלים כמו Apigee כדי לשלוט בקצב של בקשות ה-API בזמנים של תנועה גבוהה. אפשר להגדיר כללי מדיניות שישקפו את האופן שבו רוצים לצמצם את הבקשות.
הפחתת בקשות עודפות בשלב מוקדם
כדי להגן על רכיבי ה-בק-אנד, צריך להגדיר את המערכות כך שידחו בקשות עודפות בשכבת ה-קצה קדמי. דחיית חלק מהבקשות מונעת כשלים גלובליים ומאפשרת למערכת להתאושש בצורה חלקה יותר.בגישה הזו, חלק מהמשתמשים עלולים להיתקל בשגיאות. עם זאת, אפשר למזער את ההשפעה של הפסקות זמניות בשירות, בניגוד לגישה כמו ניתוק מעגל, שבה כלל התנועה נדחית במהלך עומס יתר.
טיפול בשגיאות חלקיות וניסיונות חוזרים
כדאי לבנות את האפליקציות כך שיטפלו בשגיאות חלקיות ובניסיונות חוזרים בצורה חלקה. העיצוב הזה עוזר להבטיח שכמה שיותר תנועה תטופל בתרחישים של עומס גבוה.
בדיקת תרחישי עומס יתר
כדי לוודא שמנגנוני ההגבלה וההפלה של הבקשות פועלים בצורה יעילה, מומלץ לדמות באופן קבוע תנאי עומס יתר במערכת. הבדיקות עוזרות לוודא שהמערכת מוכנה לעלייה חדה בתנועה בעולם האמיתי.
מעקב אחרי עליות חדות בתנועת הגולשים
כדאי להשתמש בניתוח נתונים ובכלי מעקב כדי לחזות עליות פתאומיות בתנועה ולהגיב להן לפני שהן הופכות לעומסים. זיהוי ותגובה מוקדמים יכולים לעזור לשמור על זמינות השירות בתקופות של ביקוש גבוה.
ביצוע בדיקות לשחזור מכישלונות
העיקרון הזה, שנכלל בעמודה 'מהימנות' בGoogle Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לתכנן ולהריץ בדיקות לשחזור במקרה של כשלים.
העיקרון הזה רלוונטי לתחום ההתמקדות למידה של אמינות.
סקירה כללית של העקרונות
כדי לוודא שהמערכת יכולה להתאושש מכשלים, צריך להריץ מעת לעת בדיקות שכוללות מעבר לגיבוי באזור אחר, חזרה לגרסה קודמת ושחזור נתונים מגיבויים.
הבדיקות האלה עוזרות לכם להתאמן בתגובה לאירועים שמציבים סיכונים משמעותיים למהימנות, כמו הפסקה זמנית בשירות של אזור שלם. הבדיקות האלה גם עוזרות לכם לוודא שהמערכת מתנהגת כמו שרציתם במהלך שיבוש.
במקרה הנדיר שאזור שלם מושבת, צריך לבצע מעבר לגיבוי (failover) של כל התעבורה לאזור אחר. במהלך פעולה רגילה של עומס העבודה, כשנתונים משתנים, צריך לסנכרן אותם מהאזור הראשי לאזור היתירות כשל. צריך לוודא שהנתונים המשוכפלים תמיד עדכניים מאוד, כדי שהמשתמשים לא יחוו אובדן נתונים או ניתוק של הסשן. מערכת איזון העומסים צריכה גם להיות מסוגלת להעביר את התנועה לאזור הגיבוי בכל שלב, בלי הפרעות בשירות. כדי למזער את זמן ההשבתה אחרי הפסקה זמנית בשירות אזורית, מהנדסי תפעול צריכים גם להיות מסוגלים להסיט באופן ידני ויעיל את תעבורת הנתונים של המשתמשים מאזור מסוים, תוך כמה שפחות זמן. הפעולה הזו נקראת לפעמים ריקון אזור, כלומר עצירה של התנועה הנכנסת לאזור והעברת כל התנועה למקום אחר.
המלצות
כשמעצבים ומריצים בדיקות לשחזור אחרי כשל, כדאי להביא בחשבון את ההמלצות שבקטעי המשנה הבאים.
הגדרת היעדים וההיקף של הבדיקה
הגדירו בבירור מה אתם רוצים להשיג מהבדיקה. לדוגמה, המטרות שלכם יכולות לכלול את הדברים הבאים:
- מאמתים את משך ההתאוששות (RTO) ואת היעד להתאוששות מאסון (RPO). פרטים נוספים מופיעים במאמר בנושא היסודות של תכנון התאוששות מאסון.
- הערכת העמידות של המערכת והסבילות שלה לכשלים בתרחישי כשל שונים.
- בודקים את היעילות של מנגנוני מעבר אוטומטי לגיבוי.
מחליטים אילו רכיבים, שירותים או אזורים ייכללו בהיקף הבדיקה. ההיקף יכול לכלול רמות ספציפיות של אפליקציות כמו קצה קדמי, בק-אנד ומסד נתונים, או שהוא יכול לכלול משאבים ספציפיים כמו מופעי Cloud SQL או אשכולות GKE. Google Cloud בנוסף, בהיקף צריך לציין תלות חיצונית, כמו ממשקי API של צד שלישי או קישורי ענן.
הכנת הסביבה לבדיקה
בוחרים סביבה מתאימה, רצוי סביבת Staging או סביבת Sandbox, שמשכפלת את הגדרת הייצור. אם אתם מבצעים את הבדיקה בסביבת הייצור, ודאו שיש לכם אמצעי בטיחות מוכנים, כמו ניטור אוטומטי ונהלים ידניים לביטול השינויים.
יוצרים תוכנית גיבוי. כדי למנוע אובדן נתונים במהלך הבדיקה, כדאי לצלם תמונות או לגבות מסדי נתונים ושירותים קריטיים. מוודאים שהצוות מוכן לבצע התערבויות ידניות אם מנגנוני היתירות כשל האוטומטיים נכשלים.
כדי למנוע שיבושים בבדיקה, צריך לוודא שהגדרות התפקידים, כללי המדיניות והמעבר לגיבוי (failover) ב-IAM מוגדרות בצורה נכונה. בנוסף, צריך לוודא שההרשאות הנדרשות קיימות עבור כלי הבדיקה והסקריפטים.
מודיעים לבעלי עניין, כולל צוות התפעול, צוות DevOps ובעלי האפליקציות, על לוח הזמנים של הבדיקה, על היקף הבדיקה ועל ההשפעה הפוטנציאלית שלה. מספקים לבעלי העניין ציר זמן משוער ואת ההתנהגויות הצפויות במהלך הבדיקה.
סימולציה של תרחישי כשל
תכנון והרצה של כשלים באמצעות כלים כמו Chaos Monkey. אפשר להשתמש בסקריפטים בהתאמה אישית כדי לדמות כשלים בשירותים קריטיים, כמו השבתה של צומת ראשי באשכול GKE מרובה אזורים או השבתה של מופע Cloud SQL. אפשר גם להשתמש בסקריפטים כדי לדמות הפסקה זמנית בשירות ברשת באזור מסוים באמצעות כללי חומת אש או הגבלות של API בהתאם להיקף הבדיקה. להגביר בהדרגה את תרחישי הכשל כדי לבחון את התנהגות המערכת בתנאים שונים.
כדאי להריץ בדיקות עומס לצד תרחישי כשל כדי לשכפל את השימוש בעולם האמיתי במהלך הפסקות זמניות בשירות. מומלץ לבדוק את ההשפעות של כשלים מדורגים, למשל איך מערכות קצה קדמי פועלות כששירותי קצה עורפי לא זמינים.
כדי לאמת שינויים בהגדרות ולבדוק את עמידות המערכת מפני טעויות אנוש, כדאי להריץ תרחישי בדיקה שכוללים הגדרות שגויות. לדוגמה, אפשר להריץ בדיקות עם הגדרות שגויות של מעבר לגיבוי במקרה של כשל ב-DNS או עם הרשאות שגויות של IAM.
מעקב אחר התנהגות המערכת
עוקבים אחרי האופן שבו מאזני עומסים, בדיקות תקינות ומנגנונים אחרים מעבירים את התנועה. משתמשים Google Cloud בכלים כמו Cloud Monitoring ו-Cloud Logging כדי לתעד מדדים ואירועים במהלך הבדיקה.
צריך לעקוב אחרי השינויים בחביון, בשיעורי השגיאות ובקצב העברת הנתונים במהלך הסימולציה של הכשל ואחריה, ולנטר את ההשפעה הכוללת על הביצועים. לזהות שינויים לרעה או חוסר עקביות בחוויית המשתמש.
מוודאים שיומנים נוצרים והתראות מופעלות לגבי אירועים מרכזיים, כמו הפסקות שירות או מעבר לגיבוי בעת כשל. אפשר להשתמש בנתונים האלה כדי לוודא שהמערכות שלכם להתראות ולתגובה לאירועים פועלות בצורה יעילה.
אימות השחזור בהשוואה ל-RTO ול-RPO
בודקים כמה זמן לוקח למערכת לחזור לפעילות רגילה אחרי כשל, משווים את הנתונים האלה ל-RTO שהוגדר ומתעדים את הפערים.
חשוב לוודא שתקינות הנתונים והזמינות שלהם תואמות ל-RPO. כדי לבדוק את העקביות של מסד הנתונים, משווים בין תמונות מצב או גיבויים של מסד הנתונים לפני ואחרי כשל.
הערכת שחזור השירות ואישור שכל השירותים שוחזרו למצב תקין עם הפרעה מינימלית למשתמשים.
תיעוד וניתוח של התוצאות
מתעדים כל שלב בבדיקה, כל תרחיש של כשל והתנהגות המערכת שמתאימה לו. כדאי לכלול חותמות זמן, יומנים ומדדים לניתוחים מפורטים.
הדגשת צווארי בקבוק, נקודות כשל בודדות או התנהגויות לא צפויות שנצפו במהלך הבדיקה. כדי לתעדף את התיקונים, כדאי לחלק את הבעיות לקטגוריות לפי מידת החומרה וההשפעה שלהן.
להציע שיפורים בארכיטקטורת המערכת, במנגנוני יתירות הכשל או בהגדרות המעקב. על סמך ממצאי הבדיקה, לעדכן את כל מדיניות יתירות הכשל ומדריכי הפעולה הרלוונטיים. להציג לבעלי העניין דוח לאחר הבדיקה. בדוח צריך להיות סיכום של התוצאות, הלקחים והשלבים הבאים. מידע נוסף זמין במאמר בנושא עריכת בדיקות מקיפות לאחר הבדיקה.
איטרציה ושיפור
כדי לוודא שהמערכת אמינה ועמידה לאורך זמן, מומלץ לתכנן בדיקות תקופתיות (למשל, אחת לרבעון).
מריצים בדיקות בתרחישים שונים, כולל שינויים בתשתית, עדכוני תוכנה ועומסי תנועה מוגברים.
אפשר להשתמש בפייפליינים של CI/CD כדי לשלב בדיקות אמינות במחזור החיים של הפיתוח, וכך לבצע אוטומציה של בדיקות יתירות כשל.
במהלך ניתוח האירוע, כדאי להשתמש במשוב מבעלי עניין ומשתמשי קצה כדי לשפר את תהליך הבדיקה ואת עמידות המערכת.
ביצוע בדיקות לשחזור נתונים שאבדו
העיקרון הזה, שנכלל בעמודה 'מהימנות' בGoogle Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לתכנן ולהריץ בדיקות לשחזור נתונים שאבדו.
העיקרון הזה רלוונטי לתחום ההתמקדות למידה של אמינות.
סקירה כללית של העקרונות
כדי לוודא שהמערכת יכולה להתאושש ממצבים שבהם נתונים אובדים או נפגמים, צריך להריץ בדיקות לתרחישים האלה. מקרים של אובדן נתונים עשויים להיגרם עקב באג בתוכנה או אסון טבע כלשהו. אחרי אירועים כאלה, צריך לשחזר נתונים מגיבויים ולהפעיל מחדש את כל השירותים באמצעות הנתונים ששוחזרו.
מומלץ להשתמש בשלושה קריטריונים כדי להעריך את ההצלחה או הכישלון של סוג הבדיקה הזה של שחזור: תקינות נתונים, היעד למשך ההתאוששות (RTO) ויעד להתאוששות מאסון (RPO). פרטים על מדדי ה-RTO וה-RPO זמינים במאמר יסודות התכנון של DR.
המטרה של בדיקת שחזור נתונים היא לוודא מעת לעת שהארגון שלכם יכול להמשיך לעמוד בדרישות של המשכיות עסקית. בנוסף למדידת RTO ו-RPO, בדיקת שחזור נתונים צריכה לכלול בדיקה של כל מחסנית האפליקציות וכל שירותי התשתית הקריטיים עם הנתונים ששוחזרו. זה הכרחי כדי לוודא שכל האפליקציה שנפרסה פועלת בצורה תקינה בסביבת הבדיקה.
המלצות
כשמתכננים ומריצים בדיקות לשחזור מ אובדן נתונים, כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
אימות העקביות של הגיבוי ובדיקת תהליכי השחזור
צריך לוודא שהגיבויים מכילים תמונות מצב עקביות ושימושיות של נתונים שאפשר לשחזר כדי להחזיר את האפליקציות לשירות באופן מיידי. כדי לאמת את תקינות הנתונים, מגדירים בדיקות עקביות אוטומטיות שיפעלו אחרי כל גיבוי.
כדי לבדוק גיבויים, משחזרים אותם בסביבה שאינה סביבת ייצור. כדי לוודא שאפשר לשחזר את הגיבויים ביעילות ושנתוני השחזור עומדים בדרישות האפליקציה, מומלץ לדמות באופן קבוע תרחישים של שחזור נתונים. חשוב לתעד את השלבים לשחזור נתונים, ולהכשיר את הצוותים שלכם לבצע את השלבים ביעילות במהלך כשל.
תזמון גיבויים קבועים ותכופים
כדי לצמצם את אובדן הנתונים במהלך השחזור ולעמוד ביעדי ה-RPO, חשוב לתזמן גיבויים באופן קבוע. צריך לקבוע תדירות גיבוי שתתאים ל-RPO. לדוגמה, אם ה-RPO הוא 15 דקות, צריך לתזמן גיבויים שיפעלו לפחות כל 15 דקות. כדאי לבצע אופטימיזציה של מרווחי הגיבוי כדי להפחית את הסיכון לאובדן נתונים.
להשתמש Google Cloud בכלים כמו Cloud Storage, גיבויים אוטומטיים של Cloud SQL או גיבויים של Spanner כדי לתזמן ולנהל גיבויים. לאפליקציות קריטיות, מומלץ להשתמש בפתרונות גיבוי כמעט רציפים כמו שחזור לנקודת זמן (PITR) ב-Cloud SQL או גיבויים מצטברים למערכי נתונים גדולים.
הגדרה ומעקב של RPO
חשוב להגדיר RPO ברור בהתאם לצרכים העסקיים שלכם, ולעקוב אחרי העמידה בו. אם מרווחי הגיבוי חורגים מה-RPO שהוגדר, צריך להשתמש ב-Cloud Monitoring כדי להגדיר התראות.
מעקב אחר תקינות הגיבוי
כדי לעקוב אחרי תקינות הגיבויים ולוודא שהם מאוחסנים במיקומים מאובטחים ואמינים, אפשר להשתמש בGoogle Cloud שירות גיבוי ושחזור מאסון או בכלים דומים. כדי לשפר את העמידות, חשוב לוודא שהגיבויים משוכפלים בכמה אזורים.
תכנון תרחישים מעבר לגיבוי
כדי לשפר את זמן השחזור במקרים קיצוניים, אפשר לשלב בין גיבויים לבין אסטרטגיות התאוששות מאסון (DR) כמו הגדרות של מעבר פעיל לגיבוי פעיל או שכפול בין אזורים. מידע נוסף זמין במאמר מדריך לתכנון התאוששות מאסון.
עורכים ניתוח מקיף של האירוע
העיקרון הזה, שנכלל בעמודה 'מהימנות' בGoogle Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לבצע ניתוח אפקטיבי של אירועים לאחר כשלים ותקריות.
העיקרון הזה רלוונטי לתחום ההתמקדות למידה של אמינות.
סקירה כללית של העקרונות
דוח פוסט-מורטם הוא תיעוד בכתב של אירוע, ההשפעה שלו, הפעולות שננקטו כדי לצמצם את ההשפעה או לפתור את האירוע, הסיבות הבסיסיות והפעולות שצריך לבצע כדי למנוע את הישנות האירוע. המטרה של דוח פוסט-מורטם היא ללמוד מטעויות ולא להאשים אף אחד.
התרשים הבא מציג את תהליך העבודה של ניתוח לאחר מעשה:
תהליך העבודה של ניתוח לאחר תקלה כולל את השלבים הבאים:
- יצירת ניתוח לאחר המוות
- תיעוד העובדות
- זיהוי וניתוח של שורשי הבעיה
- תכנון לקראת העתיד
- הרצת התוכנית
עורכים ניתוחים לאחר אירועים משמעותיים ואירועים לא משמעותיים, כמו:
- השבתות או שיבושים שגלויים למשתמשים וחורגים מסף מסוים.
- אובדן נתונים מכל סוג.
- התערבויות של מהנדסים בכוננות, כמו ביטול של גרסת תוכנה או ניתוב מחדש של תנועת הגולשים.
- זמני פתרון שחורגים מסף מוגדר.
- מעקב אחרי כשלים, שבדרך כלל מרמזים על גילוי ידני של אירועים.
המלצות
כדאי להגדיר קריטריונים לניתוח לאחר אירוע לפני שמתרחש אירוע, כדי שכולם ידעו מתי צריך לבצע ניתוח כזה.
כדי לבצע ניתוח יעיל של אירועים שהתרחשו, כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
עורכים ניתוח לאחר תקלה ללא האשמה
ניתוח אפקטיבי של אירוע מתמקד בתהליכים, בכלים ובטכנולוגיות, ולא בהטלת אשמה על אנשים או צוותים. המטרה של ניתוח אירוע היא לשפר את הטכנולוגיה ואת העתיד, ולא למצוא את האשם. כולם עושים טעויות. המטרה צריכה להיות ניתוח הטעויות ולמידה מהן.
בדוגמאות הבאות אפשר לראות את ההבדל בין משוב שבו מאשימים מישהו לבין משוב ללא האשמה:
- משוב שכולל האשמות: "צריך לשכתב את כל מערכת ה-backend המורכבת! היא מתקלקלת מדי שבוע כבר שלושה רבעונים, ואני בטוח שכולנו עייפנו מלתקן אותה חלק אחרי חלק. ברצינות, אם יקראו לי עוד פעם לתיקון, אני אשכתב אותה בעצמי…"
- משוב ללא האשמה: "יכול להיות שפריט פעולה לכתיבה מחדש של כל מערכת ה-Backend ימנע את הבעיות האלה בעתיד. מדריך התחזוקה של הגרסה הזו ארוך מאוד וקשה להבין אותו באופן מלא. אני בטוח שהמהנדסים שלנו שיהיו בכוננות בעתיד יודו לנו!"
הדוח שלאחר המוות צריך להיות קריא לכל קהלי היעד
לגבי כל פריט מידע שאתם מתכננים לכלול בדוח, כדאי להעריך אם המידע הזה חשוב והכרחי כדי לעזור לקהל להבין מה קרה. אפשר להעביר נתונים משלימים והסברים לנספח של הדוח. אם נדרש מידע נוסף, בודקים יכולים לבקש אותו.
אל תשתמשו בפתרונות מורכבים או מתוחכמים מדי
לפני שמתחילים לחפש פתרונות לבעיה, חשוב להעריך את חשיבות הבעיה ואת הסיכוי שהיא תחזור על עצמה. הוספת מורכבות למערכת כדי לפתור בעיות שלא סביר שיקרו שוב עלולה להוביל לחוסר יציבות.
משתפים את סיכום האירוע עם כמה שיותר אנשים
כדי לוודא שהבעיות לא יישארו ללא פתרון, כדאי לפרסם את תוצאות הבדיקה לקהל רחב ולקבל תמיכה מההנהלה. הערך של ניתוח לאחר מעשה הוא ביחס ישר ללמידה שמתרחשת אחרי הניתוח. ככל שיותר אנשים לומדים מאירועים, כך קטן הסיכוי שיהיו כשלים דומים בעתיד.