שתף באמצעות

המלצות לטיפול בתקלות חולפות

  • מאמר

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

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

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

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

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

אתגרים

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

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

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

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

הנחיות כלליות

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

יש לקבע אם יש מנגנון מובנה של ניסיון חוזר

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

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

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

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

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

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

כדאי לקבוע ספירת ניסיונות חוזרים ומרווח מתאים

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

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

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

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

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

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

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

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

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

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

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

הימנעות מדפוסי אנטי

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

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

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

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

בדיקת האסטרטגיה והיישום של ניסיונות חוזרים

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

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

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

  • עבור שירותים מותאמים אישית שיצרת ופרסת, יש לכפות על שגיאות חולפות להתרחש על ידי השבתה זמנית או גרימה לעומס יתר של השירות. (לא לנסות להעמיס משאבים משותפים או שירותים משותפים ב- Azure.)

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

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

נהל תצורות של מדיניות בנושא ניסיונות חוזרים

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

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

תיעוד ומעקב אחר תקלות חולפות ולא חולפות

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

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

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

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

ניהול פעולות שנכשלות ללא הרף

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

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

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

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

שיקולים אחרים

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

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

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

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

סיוע של Power Platform

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

Power Automate

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

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

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

Power Apps

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

ניתן גם להשתמש בפונקציות Error, IfError, IsError ו-IsBlankOrError ביישומי בד ציור כדי להחליט מה לעשות אחרי שמתרחשת שגיאה.

מידע נוסף על טיפול בתקלות חולפות ב- Power Apps:

Azure ומחברים מותאמים אישית

אם עומס העבודה שלך מתחבר לשירותי Azure, כאן נסביר כיצד לטפל בתקלות חולפות באמצעות Azure Well-Architected Framework.

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

Application Insights

יש להשתמש בשילובי Application Insights כדי לתעד שגיאות ב- Power Automate וב- Power Apps:

למידע נוסף

המשכיות עסקית ושחזור לאחר אסון עבור יישומי SaaS של Dynamics 365

רשימת בדיקה לאמינות

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

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