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

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

למה כמעט אף אחד לא מגייס "מהנדס/ת ביצועים"

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

המסקנה הנכונה הפוכה. העבודה קיימת בהיקף גדול, אבל היא אורזת בתוך תפקידים אחרים. הראיה לכך היא הפער בין המספרים: 30 משרות מסווגות בקטגוריית תצפיתיות, ובצד הכלים פתוחות 20 משרות שמזכירות Grafana, 20 שמזכירות Prometheus ו-110 שמזכירות Kubernetes. אף אחת מהן אינה "מהנדס ביצועים", וכולן דורשות בדיוק את המיומנות הזו.

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

למדוד נכון: למה הממוצע משקר

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

לכן מודדים באחוזונים. p95 הוא הערך שמתחתיו נמצאות 95 אחוז מהבקשות, ו-p99 הוא הגבול של האחוז הגרוע. מה שנקרא "זנב ההשהיה" הוא בדיוק האזור הזה, והוא מקור רוב תלונות המשתמשים.

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

פרופיילינג ו-flame graphs

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

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

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

לתכנן מבחן עומס שלא משקר

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

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

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

תכנון קיבולת

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

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

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

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

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

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

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

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

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

שכר - הערכת שוק

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

התפקיד שבו העבודה יושבת	שכר חודשי ברוטו (הערכת שוק)
מפתח/ת בקאנד עם התמחות בביצועים	25,000 - 40,000 ש"ח
SRE או מהנדס/ת תשתיות	28,000 - 45,000 ש"ח
QA ביצועים	18,000 - 30,000 ש"ח

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

איך נכנסים לתחום

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

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

לקריאה משלימה על שכבת המדידה: מה זה Observability.

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

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

שאלות נפוצות

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

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

אז איפה כדאי לחפש?

בכלים ולא בכותרת. 20 משרות Grafana, 20 משרות Prometheus ו-110 משרות Kubernetes הן המקומות שבהם המיומנות הזו נדרשת בפועל.

מה ההבדל בין p95 ל-p99?

p95 הוא הסף שמתחתיו נמצאות 95 אחוז מהבקשות, ו-p99 הסף של 99 אחוז. ההבדל ביניהם מעיד על חומרת הזנב: פער גדול אומר שיש מיעוט בקשות שמתנהג שונה לגמרי מהשאר.

האם צריך לדעת לתכנת?

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

מה הכלי הכי חשוב ללמוד ראשון?

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

האם עבודה בביצועים היא מסלול קידום טוב?

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

למה מבחן עומס מקומי לרוב חסר ערך?

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