בדיקות ביצועים מוקדמות ב-CI/CD: k6, Gatling, Locust

בדיקות ביצועים Shift left: היכן נשבר הצינור

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

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

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

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

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

מה נותנות בדיקות עומס מוקדמות

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

בדיקות עומס מוקדמות מעבירות את אותה הרצה אל מערך הבנייה — למשל, תרחישים ב־k6 — ועונות על השאלה «כמה זה מחזיק» בשלב שבו תיקון שווה תיקון, ולא כתיבה מחדש.

• זמן משוב. פסק הדין לגבי פרופיל העומס מגיע באותה הרצה שבה רצות גם בדיקות היחידה: המהנדס רואה רגרסיה דקות אחרי שליחת התיקון, ולא אחרי ימים של המתנה לסטנד נפרד.
• שיעור פגמי הביצועים שנמצאים לפני השחרור. דליפות חיבורים, שליפות ללא הגבלה, נעילות בגישה מקבילה נתפסים על נתוני בדיקה ונכנסים לטיפול לפני מערך הייצור. מכוונים ל־80% ומעלה.
• עמידות תחת עומס. פרופיל שיא — פרץ עונתי, עיבוד אצווה לילי, תפוצת דיוור — מורץ באופן קבוע, ולכן ההתנהגות בגבול ידועה מראש, ולא מתבררת רק בזמן תקרית.
• עלות זמן ההשבתה. פגם ממערך הבנייה הוא שעות תיקון; אותו פגם במערך הייצור הוא שעות של אי־זמינות השירות וחקירת תקרית.
• רגרסיה לפי קווי בסיס. זמן התגובה של פעולות מפתח ושיעור התגובות השגויות נשמרים לצד הקוד ומושווים בין בנייה לבנייה: ירידה של 10–15% נראית כבדיקה שנכשלה, ולא כתלונת משתמש.
• ערכי סף כתנאי לשחרור. תרחיש עם סף לזמן תגובה ולשיעור שגיאות עוצר את הבנייה — כלל אחד לכולם, ואין מה לפרש.

מצבי הפעלה של בדיקות עומס: השוואה

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

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

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

שלבי הטמעת בדיקות עומס בצינור

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

1. ביקורת המערך. מפרקים מהם השירותים שמהם מורכבת המערכת, אילו תלויות חיצוניות משתתפות בבקשה ואיפה בצינור הנקודה שאליה משתלב ההפעלה. בפלט — מפת המערך ורשימת תרחישים שיש טעם להעמיס עליהם.
2. הפקת פרופיל עומס בסיסי. אוספים סטטיסטיקה של פניות אמיתיות: יחס קריאה לכתיבה, חלונות שיא, התפלגות לפי נקודות קצה. בלי הפרופיל הזה אין למה להשוות את תוצאת ההרצה.
3. תכנון סכימת הבדיקות. קובעים מה רץ על כל קומיט ומה — לפני הפריסה, מגדירים תקציב זמן וספים שבהם הבנייה נעצרת.
4. הגדרת הסטנד והתרחישים. פורסים סביבה מבודדת, דומה לפרודקשן, מתארים תרחישים ב־k6, מגדירים הזנת נתונים ואיסוף מדדים.
5. בדיקה על שחרור אמיתי. מריצים את הסכימה על שינוי ייצורי, משווים את התחזית להתנהגות בפועל ומכיילים את הספים כך שהבדיקות לא יופעלו על תנודות טבעיות.
6. מסירה וליווי. מוסרים קונפיגורציות, לוחות מדדים, נוהל תגובה לנפילה וסדר עדכון תרחישים כשהמוצר משתנה.

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

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

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

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

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

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

מה שינו

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

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

במה shift left שונה ממדידות לפני שחרור?

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

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

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

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

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

ספקות טכניים נפוצים ותשובות

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

מה לעשות עם סטנד לא יציב?

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

איך מכינים את נתוני הבדיקה?

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

כבר פרוס אצלנו מערך משלנו — הכול יצטרך להשתנות?

לא. אנחנו מתחברים למה שכבר קיים — k6, Gatling או Locust — ומשלימים את החסר: ספים, דוחות, שער בקו הבנייה וקישור התוצאה לשינוי מסוים בקוד.

מה יהיה אחרי המסירה?

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

נדון במשימה שלכם ונחזור עם תוכנית

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

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

אנחנו מנתחים את מה שנשלח וחוזרים עם תכנים קונקרטיים:

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

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