Latency כבעיה ארגונית, לא טכנית

אחרי שמבינים ש-Production הוא נקודת האמת של המערכת, יש תופעה אחת שחוזרת כמעט תמיד ראשונה:

Latency.

והטעות הגדולה ביותר לגביה היא לא איך מודדים אותה - אלא איך מסבירים אותה לעצמנו.

האשליה: “אם זה איטי - הקוד אשם”

Latency גבוהה נתפסת כמעט אוטומטית ככשל טכני:

• משהו איטי
• משהו לא אופטימלי
• משהו שצריך “לטפל בו”

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

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

איפה Latency באמת נולדת

Latency נולדת ברגעים שקטים, רחוקים מה-CPU:

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

אף אחת מההחלטות האלה אינה טעות. כולן הגיוניות בזמן קבלתן.

אבל Latency אינה תוצאה של החלטה אחת גרועה - היא תוצר של הצטברות החלטות סבירות.

Latency היא מחיר של תיאום

Latency גבוהה אינה מופיעה כי משהו “איטי”. היא מופיעה כי משהו מחכה.

מחכה ל:

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

ככל שמערכת דורשת יותר:

• הסכמה
• תיאום
• ותלות בזמן אמת

כך זמן התגובה מתארך.

Latency אינה תקלה. היא תשלום.

כאן נכנס הארגון

וזו הנקודה הקריטית.

Latency גדלה לא רק כשיש עוד רכיבים - אלא כשיש עוד גבולות:

• גבולות בין צוותים
• גבולות אחריות לא ברורים
• שירותים שאין להם בעל בית אחד
• זרימות שאף אחד לא “מחזיק בראש”

כל handoff מוסיף:

• המתנה
• זהירות
• ובדיקות חוזרות

Latency לעיתים אינה בעיה ארכיטקטונית - אלא צילום רנטגן של הארגון.

דוגמה פשוטה: למה כפתור נהיה איטי

יש כפתור אחד באפליקציה: “שלח בקשה”.

המשתמש לוחץ. ומחכה.

בהתחלה הכול היה מהיר.

ואז, עם הזמן, הכפתור נהיה איטי יותר.

לא נשבר. לא נתקע. פשוט… מחכה.

מה קרה? לא שינינו את הקוד של הכפתור.

אבל לאורך הדרך נוספו החלטות:

מישהו אמר: “צריך לבדוק הרשאות לפני שממשיכים”

מישהו אחר אמר: “בואו נרשום לוג מלא, שיהיה trace”

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

כל החלטה בפני עצמה:

• הגיונית
• אחראית
• “רק עוד בדיקה קטנה”

אף אחד לא אמר: “בואו נוסיף Latency”.

אבל בפועל: כל החלטה הוסיפה המתנה קטנה.

וההמתנות האלו:

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

עד שיום אחד - הכפתור מרגיש איטי.

למה זה לא באג טכני

אין פונקציה איטית במיוחד. אין שרת עמוס במיוחד. אין “אשם”.

יש רצף של החלטות אנושיות סבירות, שמצטברות לזמן המתנה מורגש.

Latency כאן לא נוצרה בגלל ביצועים - אלא בגלל אופן קבלת החלטות.

הנקודה

Latency לא תמיד אומרת: “צריך לייעל”.

לפעמים היא אומרת: “יותר מדי אנשים ביקשו להיות מעורבים בדרך”.

וזו כבר לא בעיית קוד - אלא בעיית תיאום.

למה אופטימיזציה מקומית לא רק שלא עוזרת - אלא מזיקה

בשלב הזה קורה דבר צפוי: כל צוות מנסה “לשפר את שלו”.

• Cache מקומי
• Parallelism פנימי
• Timeout קצר “כדי להיות מהירים”

וכל צוות באמת משתפר - במטריקות שלו.

אבל המערכת כולה:

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

Latency ירדה מקומית - והחמירה גלובלית.

כי Latency אינה סכום של חלקים. היא התנהגות מערכתית.

ההיפוך החשיבתי

ברגע הזה צריך להפוך את השאלה.

לא: “איפה הקוד האיטי?”

אלא:

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

מי שממשיך לטפל ב-Latency כבעיה טכנית - מגרד סימפטום.

מי שמבין שזו בעיית מבנה והחלטות - יכול באמת לשנות אותה.

השורה התחתונה

Latency אינה מדד. היא תוצאה.

לא של קוד גרוע - אלא של מערכת שלא הגדירה איפה מותר לחכות, ואיפה אסור.

מבט קדימה

וכאן מגיעה הבעיה הבאה.

כי גם כשה-Latency כבר גבוהה - לעיתים כל המדדים נראים “בסדר”.

ממוצעים ירוקים. Dashboards רגועים.

ובדיוק אז - מערכות נופלות בהפתעה.

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