הערה
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות להיכנס או לשנות מדריכי כתובות.
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות לשנות מדריכי כתובות.
חלות על המלצה זו של רשימת משימות לביצוע של Well Architected Framework Reliability של Power Platform:
| RE:06 | בדקו תרחישי התאוששות מהירה וזמינות על-ידי יישום העקרונות של הנדסת כאוס בסביבות הבדיקה והייצור שלכם. ניתן השתמש בבדיקות כדי להבטיח שאסטרטגיות יישום הירידה בביצועים החינניות שלך יעילות על ידי ביצוע תקלה אקטיבית ובדיקת עומס מדומה. |
|---|
מדריך זה מתאר את ההמלצות לתכנון אסטרטגיית בדיקת מהימנות כדי לאמת ולייעל את המהימנות של עומס העבודה שלכם. בדיקות מהימנות מתמקדות בחוסן ובזמינות של עומס העבודה שלכם, במיוחד בזרימות הקריטיות שאתם מזהים בעת עיצוב הפתרון. מדריך זה מספק הנחיות כלליות לבדיקות והכוונה ספציפית להנדסת כאוס ובדיקת תקלות יזומות.
הגדרות
| מונח | הגדרה |
|---|---|
| זמינות | משך הזמן שבו עומס עבודה של אפליקציה פועל במצב תקין ללא השבתה משמעותית. |
| הנדסת כאוס | הפרקטיקה של בדיקת אפליקציות ושירותים בתנאים של לחצים וכשלים בעולם האמיתי. המטרה של הנדסת כאוס היא לבנות ולאמת עמידות לתנאים לא אמינים ויחסי תלות חסרים. |
| בדיקת תקלות יזומות | הפעולה של הוספת שגיאה למערכת כדי לבדוק את חוסנה של המערכת. |
| יכולת השחזור | מילה נרדפת לחוסן. |
| חוסן | היכולת של עומס עבודה של אפליקציה לעמוד במצבי כשל ולהתאושש מהם. |
אסטרטגיות מרכזיות בתכנון
הבדיקות חיוניות כדי להבטיח שעומס העבודה שלכם עומד ביעדי המהימנות שלו ויכול להתמודד עם כשלים בהצלחה. בדיקת תקלות יזומות היא סוג של בדיקה שמכניסה בכוונה תקלות או לחץ למערכת כדי לדמות תרחישים מהעולם האמיתי. על-ידי שימוש בטכניקות הנדסת תקלות וכאוס, אפשר לגלות ולתקן באופן יזום בעיות לפני שהן משפיעות על סביבת הייצור שלכם. סעיף זה מספק הדרכה כללית על בדיקות, הנדסת כאוס ובדיקת תקלות יזומות עבור עומס העבודה שלכם.
הנחיות כלליות לבדיקות
בדקו באופן שגרתי כדי לאמת ערכי סף, הנחות ויעדים קיימים. כאשר מתרחש שינוי משמעותי בעומס העבודה, הפעילו בדיקות רגילות. בצעו את רוב הבדיקות בסביבות בדיקה ואחסון זמני. כדאי גם להפעיל תת-קבוצה של בדיקות מול מערכת הייצור.
בצעו אוטומציה של בדיקות כדי להבטיח כיסוי עקבי של בדיקות ויכולת שחזור. הפכו משימות בדיקה נפוצות לאוטומטיות ושלבו אותן בתהליכי הבנייה שלכם. בדיקה ידנית של תוכנה היא מייגעת וחשופה לשגיאות, אבל אפשר לבצע בדיקות חקירה ידניות. במקרים שבהם צריך לפתח בדיקות אוטומטיות, השתמשו בבדיקות ידניות כדי לקבוע את היקף הבדיקות שיש לפתח.
אמצו גישה של 'הסטה שמאלה' לביצוע בדיקות גמישות וזמינות בשלב מוקדם של מחזור הפיתוח.
התאימו תבנית פשוטה לתיעוד כדי לאפשר לכולם להבין את התהליך ואת התוצאות של כל בדיקה רגילה.
שתפו את התוצאות המתועדות עם הצוותים המתאימים, כמו צוותים תפעוליים, מנהיגות טכנולוגית, בעלי עניין עסקיים ובעלי עניין להתאוששות לאחר אסון. התוצאות צריכות להביא לשיפור של יעדי מהימנות, כגון יעדי רמת שירות (SLOs), הסכמי רמת שירות (SLAs), יעדי זמן התאוששות (RTOs) ויעדי נקודת התאוששות (RPOs).
קבעו קצב בדיקה קבוע עבור הגיבויים שלכם. שחזרו את הנתונים למערכות מבודדות כדי להבטיח שהגיבויים תקפים ושהשחזורים פונקציונליים.
תעדו ושתפו מדדי זמן התאוששות עם בעלי העניין להתאוששות מאסון כדי להבטיח שהציפיות להתאוששות הולמות.
השתמשו בהליכי בדיקות פריסה סטנדרטיים בתעשייה כדי להבטיח שיש לכם תהליך פריסה אוטומטי, צפוי ויעיל.
בדקו את יכולת עומס העבודה שלכם לעמוד בתקלות חולפות. למידע נוסף ראו המלצות לטיפול בתקלות חולפות.
בדקו כיצד עומס העבודה שלכם מתמודד עם תקלות בשירותים תלויים או ביחסי תלות אחרים על-ידי שימוש בבדיקת תקלות יזומות.
בדקו את התוכנית להתאוששות מאסון כדי להגיב לכשלים קטסטרופליים ולאירועים גדולים אחרים.
בדקו האם הביצועים של עומס העבודה יכולים להיפגע כמה שפחות ולמזער את רדיוס הפגיעה של תקלה ברכיבים על-ידי שימוש בבדיקת תקלות יזומות.
נצלו את ההפסקות המתוכננות והלא מתוכננות
כאשר עומס העבודה שלכם נמצא במצב לא מקוון עקב תחזוקה מתוכננת או הפסקה לא מתוכננת, יש לכם הזדמנות ייחודית לבצע בדיקות ולשפר את ההיכרות שלכם עם עומס העבודה. הסעיפים הבאים מספקים המלצות לכל תרחיש.
תחזוקה מתוכננת
כאשר תכננתם חלונות תחזוקה עבור עדכונים או תיקונים, תוכלו לבדוק רכיבים וזרימות שאינם מעורבים בעבודת התחזוקה. בצעו בדיקות ללא סיכון פוטנציאלי לפגיעה בלתי צפויה בעומס העבודה או השבתתו המוחלטת. אם יש לכם מספיק זמן במהלך חלון התחזוקה, תוכלו גם לבדוק את הרכיבים והזרימות המעורבים בתחזוקה לאחר סיום עבודת התחזוקה.
השבתה לא מתוכננת
השתמשו בכל מקרה הפסקה כהזדמנות ללמוד יותר על עומס העבודה שלכם ולשפר את חוסנו על-ידי ביצוע השלבים הבאים, לפי סדר עדיפות:
החזירו את עומס העבודה למצב מקוון עבור המשתמשים. ייתכן שתצטרכו לבצע פתרון שעוקף את הבעיה, לפתור את הבעיה או להתחיל בתהליכי השחזור.
קבעו את סיבת ההשבתה וטפלו בה. אם תוכלו לתקן את סיבת השורש כחלק מהחקירה, תעדו את סיבת השורש ואת האמצעים שנקטתם כדי לתקן אותה. אם הבעיה דורשת שימוש בחלון תחזוקה נוסף מאוחר יותר, ודא שאמצעי הצמצום יכולים להתמודד עם העומס הצפוי על-ידי בדיקה יסודית שלהם. ודאו שהגדרתם ניטור מספיק כדי לכסות את אמצעי הצמצום.
אם רלוונטי, חפשו את אותה בעיה, או חולשות בתצורה שעלולות להיות מושפעות מבעיות דומות, בכל הרכיבים בעומס העבודה שלכם. השתמשו בהזדמנות זו כדי לטפל באופן יזום ברכיבים אלה. עיינו בהיסטוריית האירועים כדי לזהות דפוסים של בעיות דומות בכל עומס העבודה שלכם.
השתמשו בממצאים כדי לשפר את אסטרטגיית הבדיקה שלכם. ודאו שטיפלתם בהצלחה בסיבת השורש ובבעיות דומות על-ידי בדיקה ישירה של אותה תקלה.
הדרכה בנושא הנדסת כאוס ובדיקת תקלות יזומות
בדיקת תקלות יזומות פועלת לפי העקרונות של הנדסת כאוס על-ידי הדגשת יכולתו של עומס העבודה להגיב לתקלות ברכיבים. בצע בדיקות של תקלות יזומות בסביבות טרום ייצור ובסביבות ייצור. יישמו את המידע שלמתם מביצוע ניתוח של מצבי כשל כדי להבטיח שאתם בודקים רק תקלות בעלות עדיפות ושיש לכם אסטרטגיות צמצום המטפלות בתקלות.
הקווים המנחים העיקריים של הנדסת כאוס הם:
פעלו באופן יזום. אל תחכו לתקלות שיקרו. נסו לצפות כישלונות על-ידי עריכת ניסויי כאוס כדי לגלות ולתקן בעיות לפני שהן משפיעות על סביבת הייצור.
אמצו את הכישלון. קבלו את התקלות שקורות במערכת ולמדו מהן. יש לראות את התקלות כחלק טבעי ממערכות מורכבות ולהשתמש בהן כהזדמנויות ללמוד ולשפר את מהימנות המערכת.
שברו את המערכת. הוסיפו בכוונה תקלות או מתח למערכת כדי לבדוק את עמידותה. בצעו סימולציה של תקלות או שיבושים בעולם האמיתי כדי לבדוק ולשפר את יכולות השחזור של עומס העבודה.
בנו חסינות. השתמשו בניסויים של הנדסת כאוס כדי לשפר את יכולת עומס העבודה למנוע תקלות ולהתאושש מהן.
הנדסת כאוס היא חלק בלתי נפרד מתרבות של צוות עומס העבודה ומפרקטיקה מתמשכת. זה לא מאמץ טקטי לטווח קצר בתגובה להשבתה אחת. פעלו בשיטה הסטנדרטית הזו בעיצוב ניסויי הכאוס:
התחילו בהשערה. לכל ניסוי צריכה להיות מטרה ברורה, כמו בדיקת היכולת של זרימה לעמוד באובדן של רכיב מסוים.
מדדו התנהגות בסיסית. ודאו שיש לכם מדדי מהימנות וביצועים עקביים של הזרימה והרכיבים המעורבים בניסוי כדי להשוות עם המצב הירוד בעת הפעלת הניסוי.
הוסיפו תקלה או מספר תקלות. הניסוי צריך להתמקד בכוונה ברכיבים ספציפיים שניתן לשחזר במהירות, וצריכה להיות לכם ציפייה מושכלת של ההשפעה שתגרום החדרת התקלה, כדי לשלוט ברדיוס הפגיעה של הניסוי.
עקבו אחר ההתנהגות המתקבלת. אספו נתוני מדידת שימוש לגבי רכיבי הזרימה הבודדים והתנהגות הזרימה מקצה לקצה שאליה מכוון הניסוי כדי להבין בצורה נכונה את ההשפעות של התקלה. השוו את המדדים שאספתם עם מדדי הבסיס לקבלת תמונה מלאה של בדיקת התקלה היזומה.
תעדו את התהליך ואת התצפיות. שמירת תיעוד מפורט של הניסויים שלכם יעזור בקבלת החלטות עתידיות לגבי עיצוב עומס העבודה – מה שיבטיח טיפול בפערים שיתגלו לאורך זמן.
זהו את התוצאה ופעלו בהתאם. תכננו שלבי תיקון שניתן להוסיף למצבור של עומס העבודה כשיפורים. ודאו שתוכניות שיפור התכנון נבחנות ונבדקות בסביבות שאינן סביבות ייצור בתהליכים זהים לתהליכי פריסות אחרות.
אמתו מדי פעם את התהליך, את בחירות הארכיטקטורה ואת הקוד שלכם כדי לזהות במהירות חובות טכניים, לשלב טכנולוגיות חדשות ולהסתגל לדרישות המשתנות.
כשאתם עורכים ניסויים בתקלות יזומות, עליכם:
לאשר שהניטור קיים וההתראות מוגדרות.
לאמת את התהליך להקצאת אדם אחראי ישירות (DRI) לנטילת בעלות על מקרה.
לוודא שתהליכי התיעוד והחקירה מעודכנים.
לשלב את ההמלצות והשיקולים הבאים כדי לייעל את אסטרטגיית בדיקת הכאוס:
מאתגרים הנחות לגבי המערכת. בעזרת בדיקות, יש לנסות לשפר את הגמישות של עומס העבודה ואת אסטרטגיות עיצוב עומס העבודה. חפשו הזדמנויות להחדיר תקלות לרכיבים ולזרימות שאתם מניחים שהם בטוחים בהתבסס על חוויות העבר. ייתכן שהם לא יהיו אמינים בעומס העבודה החדש.
אמתו את השינויים. ללא בדיקה יסודית, כולל בדיקת תקלות יזומות, ייתכן שתהיה לכם תמונה לא מלאה של עומס העבודה לאחר ביצוע שינויים. לדוגמה, ייתכן שתוסיפו יחסי תלות חדשים שאינם ניכרים מיד.
השתמשו במאגרי SLA. הגבילו את בדיקות הכאוס למסגרת ה-SLA והימנעו מהשפעות שליליות אפשריות שנגרמות על-ידי השבתות. יעדי הזרימה ושחזור הרכיבים שלכם עוזרים להגדיר את היקף הבדיקות.
קבעו תקציב לשגיאות כהשקעה בבדיקות כאוס ותקלות יזומות. תקציב השגיאות שלכם הוא ההבדל בין השגת 100% מה-SLO לבין השגת ה-SLO המוסכם.
עצרו את הניסוי אם הוא חורג מההיקף. תוצאות לא ידועות הן תוצאה צפויה של ניסויי כאוס. שאפו להגיע לאיזון בין איסוף נתוני תוצאות משמעותיים לבין השפעה על כמה שפחות משתמשים בסביבת ייצור.
יש לעבוד בשיתוף פעולה הדוק עם צוותי פיתוח כדי להבטיח את הרלוונטיות של התקלות שהוחדרו. השתמשו בתקריות או בעיות מהעבר כבמדריך. בדקו יחסי תלות והעריכו את התוצאות המתקבלות מהסרת יחסי התלות הללו.
זהו ותעדו יחסי שטרם התגלו בין רכיבים שונים בעומס העבודה שנחשפו באמצעות בדיקות כאוס.
התאימו את תוכניות ההתאוששות לפי הצורך כדי להביא בחשבון את יחסי התלות שמתגלים במהלך בדיקות כאוס.
השתמשו בתוצאות המתקבלות מהניסויים והבדיקות כבסיס לניסויים ומבחנים חדשים. כאשר מתעוררות התנהגויות בלתי צפויות, בדיקות חדשות עשויות למקד את ההתנהגויות הללו ישירות ולתת לכם הזדמנות לתכנן אסטרטגיות לתיקון.
פשרות: בדיקה על ידי החדרת פגמים בייצור עלולה לגרום לשיבושים ולהשבתה של המערכת. הסבירו בשקיפות למחזיקי העניין לגבי אפשרות זו והבטיחו שיש לכם אמצעי הגנה להפסקת ניסויים ותוכניות לחזרה לגרסה קודמת כדי לבטל במהירות את התקלות היזומות.
סיוע של Power Platform
אפשר להשתמש בתוצאות סטטיות ב- Power Automate כדי להחזיר תוצאה קבועה ולבדוק את עומס העבודה.
Power AppsTest Engine (גירסת Preview) הוא רכיב CLI של Power Platform שבו אפשר להשתמש כדי לבדוק יישומי בד ציור עצמאיים ב- Power Apps.
Azure Test Plans הוא פתרון קל לשימוש על בסיס דפדפן לניהול בדיקות, המספק את כל היכולות הנדרשות לבדיקות ידניות מתוכננות, בדיקות קבלת משתמשים, בדיקות מחקר ואיסוף משוב מבעלי עניין.
אם עומס העבודה שלכם כולל משאבי Azure, אפשר להשתמש ב- Azure Chaos Studio, שירות מנוהל המשתמש בהנדסת כאוס כדי לעזור לכם למדוד, להבין ולשפר את החוסן של אפליקציות הענן והשירות שלכם.
אם עומס העבודה כולל סוכן של Microsoft Copilot Studio, אפשר להשתמש בערכת Copilot Studio Power CAT כדי להגדיר סוכנים ובדיקות. על ידי הפעלת בדיקות נפרדות מול ממשקי ה- API של Copilot Studio (Direct Line), מבוצעת הערכה של תגובות הסוכן מול התוצאות הצפויות.
רשימת פעולות לביצוע מבחינת מהימנות
עיין במכלול ההמלצות המלא.