Well-Architected Framework: עקרון האמינות

Last reviewed 2025-02-14 UTC

העמודה 'מהימנות' ב-Google Cloud Well-Architected Framework כוללת עקרונות והמלצות שיעזרו לכם לתכנן, לפרוס ולנהל עומסי עבודה מהימנים ב- Google Cloud.

המסמך הזה מיועד למומחי Cloud Architect, למפתחים, למהנדסי פלטפורמות, לאדמינים ולמהנדסי Site Reliability.

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

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

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

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

מנטליות ארגונית

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

חשוב להבהיר שכל הארגון אחראי על האמינות, כולל צוותי הפיתוח, ניהול המוצר, התפעול, הנדסת הפלטפורמה ו-Site Reliability Engineering (SRE). גם קבוצות שמתמקדות בעסקים, כמו שיווק ומכירות, יכולות להשפיע על המהימנות.

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

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

תחומי המיקוד בנושא מהימנות

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

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

עקרונות ליבה

ההמלצות בעמודת המהימנות של Well-Architected Framework ממופות לעקרונות הליבה הבאים:

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים:

הגדרת מהימנות על סמך יעדים של חוויית משתמש

העיקרון הזה, שנכלל בעמודה 'מהימנות' של Google Cloud Well-Architected Framework, עוזר לכם להעריך את חוויית המשתמשים, ואז למפות את הממצאים למדדים וליעדים של מהימנות.

העיקרון הזה רלוונטי לתחום ההתמקדות של האמינות, שהוא הגדרת ההיקף.

סקירה כללית של העקרונות

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

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

העיקרון הזה רלוונטי לתחום ההתמקדות של האמינות, שהוא הגדרת ההיקף.

סקירה כללית של העקרונות

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

המלצות

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

זיהוי של דומיינים של כשלים ושכפול של שירותים

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

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

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

זיהוי בעיות וטיפול בהן באופן מיידי

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

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

תרחישים של מעבר לשירות גיבוי

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

מידע נוסף זמין במאמרים בנושא הדמיה של הפסקת שירות זמנית באזור עבור MIG אזורי והדמיה של כשל באזור באשכולות אזוריים של GKE.

ליהנות מהיתרונות של מדרגיות אופקית

העיקרון הזה, שמופיע בעמודה 'מהימנות' בGoogle Cloud מסגרת Well-Architected Framework, כולל המלצות שיעזרו לכם להשתמש בהרחבה אופקית. שימוש בהרחבת יכולת ההתאמה האופקית יכול לעזור לכם לוודא שעומסי העבודה ב-Google Cloud יכולים להתרחב ביעילות ולשמור על הביצועים.

העיקרון הזה רלוונטי לתחום ההתמקדות של האמינות, שהוא הגדרת ההיקף.

סקירה כללית של העקרונות

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

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

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

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

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

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

המלצות

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

שימוש בשירותים מנוהלים

שירותים מנוהלים מייתרים את הצורך בניהול ידני של התאמה אופקית לעומס. לדוגמה, באמצעות קבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine, אתם יכולים להוסיף או להסיר מכונות וירטואליות כדי להרחיב את האפליקציה באופן אופקי. לגבי אפליקציות בקונטיינרים, Cloud Run היא פלטפורמה בלי שרת שיכולה לשנות באופן אוטומטי את גודל הקונטיינרים בלי שמירת מצב בהתאם לתעבורת הנתונים הנכנסת.

קידום עיצוב מודולרי

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

הטמעה של עיצוב בלי שמירת מצב

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

זיהוי כשלים פוטנציאליים באמצעות יכולת התבוננות

העיקרון הזה, שנכלל בעמודה 'מהימנות' בGoogle Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לזהות מראש תחומים שבהם עלולות להתרחש שגיאות וכשלים.

העיקרון הזה רלוונטי לתחום ההתמקדות בתצפית על מהימנות.

סקירה כללית של העקרונות

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

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

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

המלצות

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

קבלת תובנות מקיפות

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

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

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

ביצוע פתרון בעיות יזום

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

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

אופטימיזציה של ניצול המשאבים

כדי לזהות משאבים שהוקצו להם יותר מדי או פחות מדי משאבים בשירותים כמו GKE,‏ Compute Engine ו-Dataproc, כדאי לעקוב אחרי נתוני הצריכה של CPU, מדדי קלט/פלט ברשת ומדדי קלט/פלט בדיסק. רשימה מלאה של השירותים הנתמכים זמינה במאמר סקירה כללית על Cloud Monitoring.

קביעת סדרי עדיפויות להתרעות

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

תכנון להפחתה חיננית (graceful degradation)

העיקרון הזה, שנכלל בעמודה 'אמינות' ב-Google Cloud Well-Architected Framework, כולל המלצות שיעזרו לכם לתכנן את Google Cloud עומסי העבודה כך שהם יפסיקו לפעול בצורה מסודרת.

העיקרון הזה רלוונטי לתגובה בתחום המיקוד של מהימנות.

סקירה כללית של העקרונות

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

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

המלצות

כדי לתכנן את המערכות כך שיפעלו בהפחתה חיננית (graceful degradation), כדאי לעיין בהמלצות שבקטעי המשנה הבאים.

הטמעה של ויסות נתונים

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

אפשר להשתמש בכלים כמו Apigee כדי לשלוט בקצב של בקשות ה-API בזמנים של תנועה גבוהה. אתם יכולים להגדיר כללי מדיניות שישקפו את האופן שבו אתם רוצים לצמצם את הבקשות.

הפסקת בקשות עודפות מוקדם

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

טיפול בשגיאות חלקיות וניסיונות חוזרים

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

בדיקת תרחישי עומס יתר

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

מעקב אחרי עליות חדות בתנועה

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

ביצוע בדיקות לשחזור מכישלונות

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

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

ביצוע בדיקות לשחזור נתונים שאבדו

העיקרון הזה, שנכלל בעמודה 'מהימנות' של 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. אם מרווחי הגיבוי חורגים מה-RPO שהוגדר, אפשר להשתמש ב-Cloud Monitoring כדי להגדיר התראות.

מעקב אחר תקינות הגיבוי

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

תכנון תרחישים מעבר לגיבוי

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

עורכים ניתוח מקיף של האירוע

העיקרון הזה, שנכלל בעמודה 'מהימנות' בGoogle Cloud מסגרת Well-Architected Framework, כולל המלצות שיעזרו לכם לבצע ניתוח יעיל של אירועים לאחר כשלים ותקריות.

העיקרון הזה רלוונטי לתחום ההתמקדות למידה בנושא אמינות.

סקירה כללית של העקרונות

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

בתרשים הבא מוצג תהליך העבודה של ניתוח לאחר אירוע:

תהליך העבודה של ניתוח לאחר אירוע.

תהליך העבודה של ניתוח לאחר תקלה כולל את השלבים הבאים:

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

עורכים ניתוחים לאחר אירועים משמעותיים ואירועים לא משמעותיים, כמו:

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

המלצות

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

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

עריכת ניתוח לאחר תקלה ללא האשמה

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

בדוגמאות הבאות אפשר לראות את ההבדל בין משוב שבו מאשימים מישהו לבין משוב ללא האשמה:

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

הדוח שלאחר המוות צריך להיות קריא לכל קהלי היעד

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

אל תשתמשו בפתרונות מורכבים או מתוחכמים מדי

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

משתפים את סיכום האירוע עם כמה שיותר אנשים

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