עכשיו הנושא של DevOps הוא בהייפ. אינטגרציה מתמשכת וצנרת אספקה CI / CD כולם מיישמים את זה. אבל רובם לא תמיד מקדישים תשומת לב ראויה להבטחת אמינות מערכות המידע בשלבים שונים של צינור ה-CI/CD. במאמר זה אני רוצה לדבר על הניסיון שלי באוטומציה של בדיקות איכות תוכנה ויישום תרחישים אפשריים ל"ריפוי עצמי" שלה.

מקור

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

בהתבסס על התוצאות של שיחות רבות עם לקוחות, אני יכול לומר שבקרת איכות השחרור, בעיית אמינות האפליקציה והאפשרות ל"ריפוי עצמי" שלה (למשל, חזרה לגרסה יציבה) בשלבים שונים של ה-CI /CD pipeline הם בין הנושאים המרגשים והרלוונטיים ביותר.

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

"ניסוח הבעיה"

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

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

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

המשימה מחולקת לשני מרכיבים:

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

כלי לניטור ואיסוף מדדים

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

כדי לאסוף מדדים, אתה יכול להשתמש בסט של מערכות שונות (Prometheus, ELK Stack, Zabbix וכו'), אבל לדעתי, פתרונות מסוג APM מתאימים ביותר למשימות אלו (ניטור ביצועי יישומים), מה שיכול מאוד לפשט את חייך.

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

מקור. בנייה אוטומטית של כל התלות בין רכיבי המערכת

מקור. זיהוי ובנייה אוטומטית של נתיב תפעול השירות

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

לאחר מכן, הבה נעבור למבט מפורט יותר כיצד לפתור בעיות אלו באמצעות מערכת Dynatrace.

משימה 1. אוטומציה של בקרת איכות מכלולים בשלב הבדיקה

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

בואו נסתכל שלב אחר שלב כיצד ליישם זאת ולהפוך את התהליך הזה לאוטומטי:

מקור

האיור מציג את הזרימה של שלבי בדיקת איכות תוכנה אוטומטית:

1. פריסת מערכת ניטור (התקנת סוכנים);
2. זיהוי אירועים להערכת איכות התוכנה שלך (מדדים וערכי סף) והעברתם למערכת הניטור;
3. יצירת מבחני עומס וביצועים;
4. איסוף נתוני ביצועים וזמינות במערכת הניטור;
5. העברת נתוני בדיקה המבוססים על אירועי הערכת איכות תוכנה ממערכת הניטור למערכת CI/CD. ניתוח אוטומטי של מכלולים.

שלב 1. פריסת מערכת הניטור

ראשית עליך להתקין את הסוכנים בסביבת הבדיקה שלך. יחד עם זאת, לפתרון Dynatrace יש תכונה נחמדה - הוא משתמש בסוכן האוניברסלי OneAgent, שמותקן על מופע של מערכת הפעלה (Windows, Linux, AIX), מזהה אוטומטית את השירותים שלך ומתחיל לאסוף נתוני ניטור עליהם. אינך צריך להגדיר סוכן נפרד עבור כל תהליך. המצב יהיה דומה עבור פלטפורמות ענן ומכולות. במקביל, אתה יכול גם להפוך את תהליך התקנת הסוכן לאוטומטי. Dynatrace משתלב בצורה מושלמת במושג "תשתית כקוד" (תשתית כקוד או IaC): יש סקריפטים מוכנים והוראות לכל הפלטפורמות הפופולריות. אתה מטמיע את הסוכן בתצורת השירות שלך, וכאשר אתה פורס אותו, אתה מקבל מיד שירות חדש עם סוכן שכבר עובד.

שלב 2: הגדר את אירועי איכות התוכנה שלך

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

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

עבור אוטומציה וקלות שימוש על ידי צוות DevOps, מופיע הרעיון של "ניטור כקוד". מה שאני מתכוון בזה הוא שמפתח/בודק יכול לכתוב קובץ JSON פשוט שמגדיר מדדי אבטחת איכות תוכנה.

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

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

הקובץ הוא מערך של הגדרות של סדרות זמן:

• timeseriesId - המדד הנבדק, לדוגמה, זמן תגובה, ספירת שגיאות, זיכרון בשימוש וכו';  
• צבירה - רמת צבירה של מדדים, במקרה שלנו avg, אבל אתה יכול להשתמש בכל אחד שאתה צריך (ממוצע, min, max, sum, count, אחוזון);
• תגיות - תג אובייקט במערכת הניטור, או שאתה יכול לציין מזהה אובייקט ספציפי;
• חמור ואזהרה - אינדיקטורים אלה מסדירים את ערכי הסף של המדדים שלנו; אם ערך הבדיקה חורג מהסף החמור, אז הבנייה שלנו מסומנת כלא מוצלחת.

האיור הבא מציג דוגמה לשימוש בספים כאלה.

מקור

שלב 3: יצירת עומסים

לאחר שקבענו את רמות האיכות של השירות שלנו, עלינו ליצור עומס בדיקה. אתה יכול להשתמש בכל אחד מכלי הבדיקה שאתה מרגיש בנוח איתם, כגון Jmeter, Selenium, Neotys, Gatling וכו'.

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

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

מקור

כאשר אתה מפעיל כל מבחן עומס, אתה שולח מידע הקשרי נוסף אל Dynatrace באמצעות ה-API של Event משרת ה-CI/CD. כך המערכת יכולה להבדיל בין בדיקות שונות.

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

שלב 4-5. אסוף נתוני ביצועים והעברת נתונים למערכת CI/CD

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

אירוע על הצורך בבדיקת איכות התוכנה המופקת בשרת ה-CI/CD לשליחה למערכת הניטור

בדוגמה שלנו, אירוע בדיקת האיכות נקרא perfSigDynatraceReport (חתימה_ביצועים) - זה מוכן плагин לאינטגרציה עם Jenkins, שפותחה על ידי החבר'ה מ-T-Systems Multimedia Solutions. כל אירוע השקת בדיקה מכיל מידע על השירות, מספר הבנייה וזמן הבדיקה. התוסף אוסף ערכי ביצועים בזמן הבנייה, מעריך אותם ומשווה את התוצאה עם בנייה קודמת ודרישות לא פונקציונליות.

אירוע במערכת הניטור על תחילת בדיקת איכות הבנייה. מקור

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

התוצאה של סטטיסטיקות על הרכבות בשרת ה-CI/CD. מקור

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

הצג נתונים סטטיסטיים מפורטים על הרכבות בשרת ה-CI/CD. מקור

השוואה מפורטת של שני מכלולים

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

השוואה של סטטיסטיקות בנייה ב-Dynatrace. מקור
 
ממצאים

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

משימה 2. אוטומציה של בקרת איכות תוכנה בסביבת ייצור

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

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

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

תיקון אוטומטי כקוד

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

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

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

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

ניתן להשתמש בכל מערכת או סט מערכות: פרומתאוס, ELK Stack, Zabbix וכו'. אבל אני אתן כמה דוגמאות המבוססות על פתרון APM (Dynatrace תהיה דוגמה שוב) שגם יעזור להפוך את החיים שלך לקלים יותר.

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

• רמת המשתמש (דפדפנים, יישומים ניידים, מכשירי IoT, התנהגות משתמשים, המרה וכו');
• רמת השירות והתפעול (ביצועים, זמינות, שגיאות וכו');
• רמת תשתית האפליקציה (מדדי מערכת ההפעלה המארח, JMX, MQ, שרת אינטרנט וכו');
• רמת הפלטפורמה (וירטואליזציה, ענן, קונטיינר וכו').

ניטור רמות ב-Dynatrace. מקור

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

להלן דוגמה לאינטראקציה עם Ansible.

מקור

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

1. פריסה גרועה - החזרת גרסה

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

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

ירידה בביצועי התפעול לאחר הפריסה. מקור

2. טעינת משאבים ב-100% - הוסף צומת לניתוב

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

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

קנה מידה לאחר תקרית

3. חוסר מקום בכונן הקשיח - ניקוי דיסק

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

טעינת דיסק 100%
 
4. פעילות משתמש נמוכה או המרה נמוכה - מעבר בין סניפים כחולים לירוקים

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

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

מנגנונים לאיתור בעיות אוטומטי

לבסוף, אני אתן לך עוד דוגמה אחת למה אני הכי אוהב את Dynatrace.

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

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

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

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

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

הדמיה של בעיה מתהווה עם הצגת כל הרכיבים והאירועים עליהם

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

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

מסקנה

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

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

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

מקור

מקור: www.habr.com