העיקרון הזה, שנכלל בעמודה 'אמינות' בGoogle Cloud Well-Architected Framework, עוזר לכם להגדיר יעדי אמינות שניתנים להשגה מבחינה טכנית עבור עומסי העבודה שלכם ב- Google Cloud.
העיקרון הזה רלוונטי להגדרת ההיקף של תחום המיקוד בנושא אמינות.
סקירה כללית של העקרונות
כדאי לתכנן את המערכות כך שיהיו אמינות מספיק כדי שהמשתמשים יהיו מרוצים. זה אולי נראה לא הגיוני, אבל יעד של 100% מהימנות הוא לרוב לא האסטרטגיה היעילה ביותר. מהימנות גבוהה יותר עשויה להוביל לעלויות גבוהות משמעותית, גם מבחינת השקעה כספית וגם מבחינת מגבלות פוטנציאליות על חדשנות. אם המשתמשים כבר מרוצים מרמת השירות הנוכחית, יכול להיות שהמאמצים להגברת שביעות הרצון לא יניבו החזר השקעה גבוה. במקום זאת, כדאי להשקיע את המשאבים במקומות אחרים.
אתם צריכים לקבוע את רמת המהימנות שבה המשתמשים מרוצים, ולקבוע את הנקודה שבה העלות של שיפורים מצטברים מתחילה להיות גבוהה מהיתרונות. כשמגיעים לרמת מהימנות מספקת, אפשר להקצות משאבים באופן אסטרטגי ולהתמקד בתכונות ובשיפורים שמספקים ערך רב יותר למשתמשים.
המלצות
כדי להגדיר יעדי מהימנות ריאליים, כדאי לעיין בהמלצות שבקטעי המשנה הבאים.
קבלת כישלון מסוים ותעדוף רכיבים
מומלץ לשאוף לזמינות גבוהה, כמו 99.99% זמן פעולה תקינה, אבל לא להגדיר יעד של 100% זמן פעולה תקינה. חשוב להבין שחלק מהכשלים הם בלתי נמנעים.
הפער בין זמינות של 100% לבין יעד של 99.99% הוא המרווח לטעויות. הפער הזה נקרא לעיתים קרובות תקציב השגיאות. תקציב השגיאות יכול לעזור לכם לקחת סיכונים ולחדש, וזה חיוני לכל עסק שרוצה לשמור על יתרון תחרותי.
לתת עדיפות לאמינות של הרכיבים החשובים ביותר במערכת. רכיבים פחות קריטיים יכולים להיות סובלניים יותר לכשלים.
איזון בין אמינות לעלות
כדי לקבוע את רמת המהימנות האופטימלית למערכת שלכם, מומלץ לבצע ניתוח מקיף של עלות-תועלת.
כדאי לקחת בחשבון גורמים כמו דרישות המערכת, ההשלכות של כשלים ומידת הסיכון שהארגון מוכן לקחת לגבי האפליקציה הספציפית. חשוב לזכור לקחת בחשבון את מדדי תוכנית ההתאוששות מאסון (DR), כמו יעד משך ההתאוששות (RTO) ויעד נקודת ההתאוששות (RPO). קובעים איזו רמת מהימנות מקובלת במסגרת התקציב והאילוצים האחרים.
כדאי לחפש דרכים לשפר את היעילות ולהפחית את העלויות בלי לפגוע בתכונות האמינות החיוניות.