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