המלצות להגדרת יעדי מהימנות

חלות על המלצה זו של רשימת משימות לביצוע של Well Architected Framework Reliability של Power Platform:

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

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

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

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

כדאי להשתמש במדדים הבאים כדי לכמת את הדרישות העסקיות.

מונח	הגדרה
הסכם רמת שירות (SLO)	יעד באחוזים המייצג את תקינות הרכיב ואת רובד המהימנות. ככל שהרמה גבוהה יותר, הפריט מהימן יותר. SLO מורכב מייצג את היעד המצטבר של עומס העבודה כולו וחשבונות עבור SLO של הרכיבים.
אינדיקטור רמת-שירות (SLI)	מדד של השירות. מדדי SLI מצטברים כדי לכמת ערך SLO.
הסכם רמת שירות (SLA)	הסכם חוזי בין נותן השירות ללקוח השירות. ההסכם מגדיר את ה-SLO. אי עמידה בהסכם עלולה להיות בעלת השלכות כספיות על נותן השירות.
זמן ממוצע להתאוששות (MTTR)	הזמן שנדרש לשחזור רכיב לאחר זיהוי כשל.
זמן ממוצע בין כשל (MTBF)	משך הזמן שבו עומס העבודה יכול לבצע את הפונקציה הצפויה ללא הפרעה, עד שהוא נכשל.
יעד זמן התאוששות (RTO)	הזמן המקסימלי המקובל שבו אפליקציה לא יכולה להיות זמינה לאחר תקרית.
יעד נקודת התאוששות (RPO)	משך הזמן המרבי המקובל של אובדן נתונים במהלך תקרית.

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

אסטרטגיות מרכזיות בתכנון

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

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

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

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

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

מדדי זמינות

יעדי זמינות תואמים למדדי SLO, SLA ו-SLI.

SLO ו- SLA

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

כדי לבסס את ה- SLO שלך, חשוב על:

• דרישות לא פונקציונליות של עומס העבודה (לדוגמה, שיעורי בקשות שיא, כמות משתמשים במקביל) במהלך 1-2 השנים הבאות.

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

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

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

ערכי SLA

הטבלה הבאה מגדירה ערכי SLA נפוצים.

SLA	שעות השבתה בשבוע	ימי השבתה בחודש	השבתה בשנה
99%	1.68 שעות	7.2 שעות	3.65 ימים
99.9%	10.1 דקות	43.2 דקות	8.76 שעות
99.95%	5 דקות	21.6 דקות	4.38 שעות
99.99%	1.01 דקות	4.32 דקות	52.56 דקות
99.999%	6 שניות	25.9 שניות	5.26 דקות

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

SLI

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

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

מדדי שחזור

יעדי שחזור תואמים למדדי RTO, RPO, MTTR ו-MTBF. בניגוד ליעדי זמינות, יעדי שחזור למדידות אלו אינם תלויים במידה רבה בשירותי ה-SLA של Microsoft. Microsoft מפרסמת אחריות RTO ו-RPO רק עבור חלק מהמוצרים, כמו SQL Database.

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

הערה

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

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

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

האופן שבו אתה מגדיר את המצבים תלוי ביעדי המהימנות שלך. הנה כמה דוגמאות לדרכים שבהן תוכל להגדיר את המצבים:

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

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

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

הערה

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

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

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

תצוגה חזותית

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

סיוע של Power Platform

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

ה- SLA של Power Platform כולל נהלים לקבלת זיכוי שירות אם ה-SLA אינו מתקיים, יחד עם הגדרות זמינות עבור כל שירות. היבט זה של SLA פועל כמדיניות אכיפה.

Microsoft Business Applications מספקות יכולות של המשכיות עסקית והתאוששות מאסון (BCDR) לכל סביבות הייצור ב- Dynamics 365 ובתוכנה כשירות (SAAS) של Power Platform. מידע על האופן שבו Microsoft מבטיחה שנתוני הייצור שלך עמידים במהלך הפסקות פעילות אזוריות.

יישור ארגוני

Cloud Adoption Framework מספק הנחיות להמלצות עבור SLO ו-SLI הקשורים לניטור ברחבי הארגון.

למידע נוסף, ראה SLO לניטור בענן.

רשימת פעולות לביצוע מבחינת מהימנות

עיין במכלול ההמלצות המלא.

רשימת פעולות לביצוע מבחינת מהימנות