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