איך לתכנן תקציב timeout מקצה לקצה בתהליך שחוצה כמה מערכות

קטגוריה: אינטגרציות | תאריך: אוקטובר 2026

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

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

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

למה timeouts מקומיים יוצרים בעיה מערכתית?

נניח שלכל שכבה יש זמן המתנה עצמאי:

• המסך ממתין לתשובה מה-API.
• ה-gateway ממתין לשירות האינטגרציה.
• שירות האינטגרציה ממתין ל-workflow.
• ה-workflow ממתין ל-SAP או למערכת אחרת.
• לקוח ה-HTTP הפנימי מבצע retry לפי כלל משלו.

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

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

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

להתחיל מה-deadline העסקי

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

1. שאילתה אינטראקטיבית: המשתמש צריך תשובה כדי להמשיך במסך.
2. פקודה עסקית קצרה: המשתמש צריך לדעת אם הבקשה התקבלה, אך התוצאה יכולה להגיע מאוחר יותר.
3. עיבוד רקע: אין צורך להחזיק חיבור פתוח, אבל יש זמן יעד לסיום.
4. פעולה מתוזמנת: יש חלון עבודה או מועד אחרון עסקי, לא רק timeout של קריאת API.
5. פעולה עם תלות אנושית: שלב האישור אינו חלק מזמן המתנה טכני, אך הוא כן חלק מה-SLA העסקי.

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

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

למפות את מסלול הבקשה המלא

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

text

משתמש → מסך → gateway → API פנימי → workflow → מערכת ליבה → תשובה

לכל תחנה מתעדים:

• זמן עיבוד רגיל וזמן עיבוד בעת עומס.
• זמן המתנה לחיבור, לתור או למשאב פנימי.
• timeout של client ושל server.
• retries אוטומטיים ומי מפעיל אותם.
• גבולות transaction ונקודות שבהן כבר נוצר side effect.
• האם אפשר לבטל פעולה שכבר התחילה.
• מה נשמר כדי לברר את המצב לאחר timeout.
• מי הבעלים של הרכיב ומהי התלות הבאה.

חשוב לכלול גם שכבות שלא נראות בקוד העסקי: load balancer, proxy, API gateway, connector, queue ו-driver של בסיס נתונים. timeout קצר באחת מהן יכול לקטוע את התשובה אף שהשירותים עצמם מוגדרים להמתין יותר.

לחלק תקציב ולא להעתיק אותו לכל רכיב

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

חלוקה רעיונית יכולה להיראות כך:

text

T כולל

├── זמן קבלה וניתוב

├── זמן עיבוד בשירות האינטגרציה

├── זמן פעולה במערכת היעד

├── מרווח להחזרת תשובה

└── מרווח בטיחות ותיעוד כשל

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

כדאי להפריד בין:

• Connect timeout: כמה זמן ממתינים לפתיחת חיבור.
• Read או response timeout: כמה זמן ממתינים לתשובה לאחר שהחיבור נוצר.
• Queue wait: כמה זמן בקשה יכולה להמתין לפני תחילת עיבוד.
• Execution timeout: כמה זמן מותר לעבודה עצמה לרוץ.
• Business deadline: עד מתי התוצאה עדיין רלוונטית לתהליך.

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

להעביר deadline ולא רק timeout קבוע

כאשר שירות A קורא לשירות B אחרי שכבר צרך חלק מהזמן, B צריך לקבל את הזמן שנותר ולא timeout חדש. אפשר להעביר timestamp של deadline או משך זמן שנותר במטא-דאטה מוסכם. כל רכיב מפחית את זמן העיבוד שכבר עבר ומשאיר מרווח להחזרת תשובה.

לדוגמה רעיונית:

text

deadline מקורי: D

זמן נוכחי: now

זמן שנותר: D - now

timeout לקריאה הבאה: מינימום של הזמן שנותר ומגבלת הרכיב

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

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

לתכנן retries בתוך אותו תקציב

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

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

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

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

timeout אינו cancellation

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

לכן צריך להגדיר לכל פעולה:

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

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

להחזיר למשתמש סטטוס שימושי

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

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

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

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

לטפל בתורים ובתהליכים אסינכרוניים

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

• זמן יצירה ו-deadline עסקי.
• עדיפות, אם קיימת הצדקה עסקית.
• מזהה פעולה ו-idempotency key.
• correlation ID למעקב.
• מספר ניסיונות והכשל האחרון.
• מדיניות כאשר ההודעה פגה.

consumer צריך לבדוק את ה-deadline לפני התחלת side effect. הודעה שפג תוקפה אינה בהכרח נמחקת בשקט: ייתכן שצריך להעביר אותה לרשימת חריגים, לעדכן סטטוס או לבצע reconciliation. במקביל מודדים queue age, לא רק את זמן העיבוד לאחר שה-worker אסף את ההודעה.

למדוד את הזמן בכל hop

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

• זמן התחלה וה-deadline המקורי.
• הזמן שנותר בכניסה וביציאה מכל רכיב.
• משך המתנה בתור ומשך עיבוד.
• שם הפעולה והמערכת הבאה.
• תוצאת הקריאה וסיבת timeout מסווגת.
• מספר ניסיונות.
• correlation ID ומזהה עסקי מתאים.

אין צורך לרשום payload מלא או secrets כדי להבין latency. המאמר על correlation ID למעקב בין מערכות מסביר כיצד לקשר את הרשומות לאורך המסלול.

מדדים מועילים כוללים את התפלגות זמני התגובה, אחוז הבקשות שמסיימות קרוב ל-deadline, queue age, retries, פעולות שמסתיימות לאחר שה-caller התנתק ומקרים שבהם המצב נשאר לא ידוע. ממוצע בלבד עלול להסתיר זנב איטי שמשפיע בדיוק על ה-timeouts.

לבדוק תרחישים ולא רק ערך קונפיגורציה

בדיקת timeout טובה מאטה בכוונה תחנות שונות ובוחנת את התוצאה העסקית. עבור flow אחד אפשר לבדוק:

1. עיכוב לפני שהפעולה התחילה.
2. עיכוב לאחר שנוצר side effect במערכת היעד.
3. תשובה שמגיעה רגע לפני ה-deadline.
4. תשובה שמגיעה לאחר שה-caller הפסיק להמתין.
5. retry כאשר נשאר מספיק זמן.
6. מניעת retry כאשר התקציב כמעט נגמר.
7. הודעה שפג תוקפה בזמן המתנה בתור.
8. ביטול לפני התחלה וביטול אחרי התחלה.
9. סטייה בשעון בין רכיבים.
10. בירור מצב ו-reconciliation אחרי תוצאה לא ידועה.

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

מי צריך להיות הבעלים של תקציב הזמן?

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

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

כל צוות עדיין אחראי לרכיב שלו, אך שינוי timeout מקומי צריך להיבדק מול השרשרת. הגדלת זמן ב-gateway בלבד אינה פותרת שירות downstream שממשיך לעבוד אחרי deadline, וקיצור timeout ב-client עלול להגדיל retries ועומס.

POC ממוקד לתקציב timeout

אפשר להתחיל מפעולה אחת שחוצה שתיים או שלוש מערכות:

1. מגדירים מה המשתמש צריך לקבל ובאיזה זמן.
2. ממפים את כל ה-hops, התורים וה-retries.
3. מזהים היכן נוצרים side effects.
4. מגדירים deadline ומחלקים תקציב לכל תחנה.
5. מעבירים את הזמן שנותר בין השירותים.
6. מוסיפים correlation ID ומדידת זמן בכל hop.
7. מגדירים סטטוס לא ידוע ודרך לברר תוצאה.
8. מוסיפים idempotency לפעולת הכתיבה.
9. מדמים עיכוב לפני ואחרי העדכון במערכת היעד.
10. מוודאים שהמשתמש אינו נדרש לשלוח בקשה חדשה בלי בדיקת מצב.

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

שאלות נפוצות

האם פשוט להגדיל את ה-timeout?

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

האם timeout קצר תמיד טוב יותר?

לא. fail fast מתאים כאשר אפשר לנסות יעד אחר או להחזיר תשובה שימושית. בפעולה עסקית שכבר התחילה, timeout קצר ללא בירור מצב עלול ליצור חוסר ודאות ו-retries כפולים.

מה ההבדל בין timeout ל-SLA?

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

האם צריך אותו deadline לכל סוגי הבקשות?

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

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

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

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

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

כך timeout מפסיק להיות מספר מקומי בקובץ קונפיגורציה והופך לחוזה תפעולי של התהליך כולו. Adaptico מסייעת לארגונים לתכנן אינטגרציות ואוטומציות בין מערכות קיימות, כולל זמני תגובה, חריגים, בקרה ומעקב. אפשר [ליצור קשר](/#contact) כדי למפות flow אחד ולבנות עבורו תקציב זמן מקצה לקצה.