אינטגרציה של Tenderly: היכן נשבר דיבוג טרנזקציות
טרנזקציה מוחזרת ברשת הייצור, ובסייר הבלוקצ'יין נשאר רק סטטוס «failed» עם גז שנצרך. הסיבה חסרה: חוזה חכם יכול היה להחזיר בלי טקסט שגיאה, יכול היה ליפול בקריאה מקוננת של פרוטוקול זר, ויכול היה לסטות מהלוגיקה הצפויה לאחר שינוי מצב. הצוות רואה את עצם הכישלון ולא מבין באיזה שלב שרשרת הקריאות סטתה מהדרך.
מכאן מתחיל שחזור ידני. מהנדס מרים צומת ארכיוני, חוזר על הטרנזקציה באותו גובה בלוק, עובר על הקריאות המקוננות, מפענח יומני אירועים ומצליב אותם עם קוד המקור של החוזה. אם המסלול עובר דרך פרוקסי, ספרייה ומחלף חיצוני, מצטברים עשרות פריימים, וכל רמה שהוחמצה היא סבב חיפוש חדש בקוד.
המחיר של דיבוג כזה הוא שעות לטרנזקציה אחת. בזמן שמנתחים קריאה אחת שנכשלה, הבאה שוברת את אותו מסלול, והמצב בגובה הנדרש אינו נשמר: אם הצומת כבר קיצץ את ההיסטוריה, אין במה לשחזר את הכישלון.
מעקב קריאות וניתוח היפוכים נדרשים ברגע האירוע, ולא נאספים בדיעבד מקטעים מיומני הצומת — נבחן כיצד זה נסגר.
מה נותנים דיבוג רציף וניטור חוזים
תקלה בחוזה בדרך כלל עולה מתלונה: הטרנזקציה מוחזרת, וביומן הצומת נשארים רק סטטוס והאש. הסיבה עמוקה יותר — בקריאות פנימיות שהספיקו לשנות מצב לפני ההחזרה הסופית. אנו מחברים את Tenderly לפרויקט, וכל קריאה הופכת גלויה: ארגומנטים, ערכים מוחזרים, המקום שבו הלוגיקה סטתה מהציפייה.
אבחון קריאות במקום בדיקת גרסאות
מעקב קריאות מציג את כל שרשרת הקריאות, ולא רק את פריים המחסנית האחרון. המהנדס רואה את הקריאה הפנימית המדויקת שבה החוזה הוחזר, ומתקן את הסיבה במקום לבדוק השערות — זמן ההתאוששות מצטמצם משעות של ניסוי וטעייה לעשרות דקות.
התראות על שגיאות לפני התלונה
חוקי הניטור של החוזים מוגדרים לפי תנאים: שיעור החזרות מעל הסף, זינוק בצריכת המשאבים לקריאה, פניות למתודות ניהוליות. התראות כאלה נשלחות לערוץ התורן, ולכן חלק מהאירועים נסגרים לפני שהלקוח נתקל בשגיאה.
שלמות תמונת הקריאות
נראות לא רק החזרות אלא גם טרנזקציות מוצלחות: באיזו תדירות נקראת המתודה, עם אילו ארגומנטים, כיצד השתנה המצב. זה מסיר את הטענה «הכול אצלנו עבד» — נשארת קבוצת קלט ניתנת לשחזור לבדיקת גרסה חדשה של החוזה.
ניתוח אירוע ועומס על צוות התורנות
ניתוח האירוע מתבצע לפי היסטוריה מוכנה: מעקב קריאות שמור, מצב לפני ואחרי, רשימת כתובות שנפגעו. התורן לא מרים צומת ארכיוני ולא אוסף נתונים ידנית — בדיקות שגרה הוחלפו בשאילתה אחת, וקריאות לילה נשארות לתקלות אמת. את תצורת החוקים שומרים במאגר לצד החוזים: היא מנוהלת בגרסאות ועוברת סקירה כמו קוד.
צורות חיבור: עותק רשת, סביבת בדיקות, רשת ראשית
מצב החיבור קובע על איזה מצב מורצת הטרנזקציה, ומכך נגזרת ערכו של הטרייס.
Tenderly מתחבר לרשת בשלושה מצבים: פורק מקומי מרים אצלנו תמונת מצב של הרשת הראשית — חוזים אמיתיים, יתרות ועומק מאגרי נזילות בבלוק הנבחר, אך מבודדים; סביבת בדיקות נותנת סביבת הרצה אמיתית עם מצב בדיקה — אותם חוזים, אבל אורקלים סינתטיים; הרשת הראשית עונה בנתונים עדכניים, אך לקריאה בלבד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פורק מקומי | ניתוח נפילות על נתונים אמיתיים, תרחישים נדירים: ליקווידציה חלקית, הפעלת מגבלה, מרוץ קריאות באותו בלוק | תמונת המצב סטטית, המצב לא מתקדם מעצמו, יש להחליף קריאות חיצוניות |
| סביבת בדיקות | בדיקת פריסה, הרשאות גישה, מחזור אינטגרציה מקצה לקצה לפני שחרור | נתונים ומחירים סינתטיים — פערים מול הרשת הראשית מתגלים מאוחר יותר |
| סימולציה ברשת הראשית | בדיקה סופית לפני שליחה, צריכת גז מדויקת ותוצאת הקריאה | לא ניתן לשנות מצב, משוחזר רק מצב העניינים הנוכחי |
במה נבדלות יכולות הדיבוג
בפורק אנו מגדירים מחדש את המצב לפני ההרצה: יתרת חשבון, חריצי אחסון, חותמת זמן, תגובת שירות חיצוני. מעקב צעד-אחר-צעד מלא עם שינויי אחסון זמין גם שם וגם בסביבת הבדיקות — ההבדל הוא בנאמנות הנתונים, לא ברמת הפירוט.
ברשת הראשית גם ניתן לראות צעד עם דיבוג, אך התרחיש מוגבל למצב הנוכחי: אי אפשר להציב תנאים שאינם קיימים ברשת כעת. לכן ההרצה הסופית נעשית על הבלוק העדכני, ותרחישים עם מצב שונה — רק בפורק.
הטמעת אינטגרציה של Tenderly: שלבי עבודה הנדסית
את האינטגרציה של Tenderly בונים כחלק ממסלול הנראות, ולא ככלי מפתח נפרד: צוות התורנות צריך לראות את סיבת כשל הטרנזקציה לפני שהמשתמש יכתוב עליה. העבודה מתבצעת בשלבים — מביקורת המצב הנוכחי ועד מסירת תיעוד.
כיצד מתבצעת העבודה
- ביקורת אינטגרציה. בודקים אילו חוזים ורשתות כבר בעבודה, היכן טרנזקציות נופלות בתדירות הגבוהה ביותר, אילו אירועים אינם נרשמים ביומן ואיזו שלמות נתונים חסרה לניתוח.
- סכמת חיבור. קובעים נקודות איסוף: צמתי רשת, שירותי חתימה, תורים פנימיים. מתעדים אילו נתונים יוצאים לדיבאגר חיצוני ואילו נשארים בתוך המסלול.
- איסוף נתונים. מגדירים רישום קריאות בעומק שמספיק לניתוח קריאות מקוננות, אך בלי נפח מיותר — מכך תלויה ישירות מהירות איתור הסיבה.
- הגדרת התראות. מקצים חוקים לסוגי כשל מסוימים: קריאה לא מוצלחת, זינוק בצריכת גז, היפוך חוזר. האות נשלח לערוץ העבודה של התורן, ולא למייל.
- בדיקת מעקב. מריצים טרנזקציות כושלות שנאספו מראש ומצליבים: המערכת מציגה את אותה סיבה כמו ניתוח ידני, ואינה מאבדת קריאות מקוננות.
- מסירת תיעוד. מוסרים סכמת חיבור, רשימת חוקים וניתוח כשלים אופייניים עם ציון מה לבדוק ראשון.
צוות התורנות מקבל לא אוסף גרפים, אלא נוהל: לפי איזה אות מה לבדוק ובאיזה סדר. הדרך מתקלה לסיבה מובנת מצטמצמת משעות לדקות.
הרכב האספקה: תצורות, התראות, נהלים
האספקה של אינטגרציית דיבוג היא לא גישה ללוח זר ולא ניתוח חד-פעמי של תקלה. אצל צוות הלקוח נשארים תוצרי עבודה שלפיהם אפשר לנתח טרנזקציה בכוחות עצמם, בלי לפנות אלינו. להלן מה בדיוק מתועד ובאיזו צורה.
מה נשאר במאגר
- תצורות דיבוג פעילות: פרופילים לרשת הראשית ולסביבות הבדיקות, סקריפטים להרצה חוזרת של טרנזקציה שנפלה בפורק מקומי.
- מפת חוזים ותלויות: כתובות, קשרי «מי קורא למי», נקודות קריאה חיצוניות ותפקידים מהימנים — בעת תקלה רואים היכן נשברה השרשרת.
- חוקי התראות: אילו אירועים נחשבים לתקלות, למי ולאן נשלח האות, אילו ספים הוגדרו כדי שהתורן לא ייטבע ברעש.
- סכמת אינטגרציה של Tenderly עם המערכות שלכם: זרימות נתונים, נקודות כשל, התנהגות כאשר שירות חיצוני אינו זמין.
- מערך בדיקות על תרחישים מאומתים: אילו מסלולים נסגרים אוטומטית לפני שחרור וכיצד לקרוא דוח על פערים.
גישות, תפקידים ונוהל
- מטריצת גישות: מי רק צופה, מי עורך תצורות, למי יש זכות להרצה חוזרת ברשת הראשית.
- נוהל תגובה: איתור, מיקום, החזרה או תיקון, ניתוח סיבות — עם מועדים מוגדרים לכל שלב.
- סדר מסירה: הדרכת משמרת תורנות, ניתוח משותף של שני כשלים מדגימים, ליווי בתקופה הראשונה בצד שלכם.
כל סעיף נמסר בעבודה על התשתית שלכם, ולא כהסבר כתוב.
מקרה בוחן: כיצד קיצרנו את זמן ניתוח כשלי חוזים
ניתוח כשל בחוזה מתחיל תמיד אותו דבר: המשתמש רואה שהטרנזקציה לא עברה, ולתורן אין דבר מלבד האש וציון החזרה. לפני הטמעת הדיבוג, המשמרת הייתה צריכה לשחזר את הקריאה ידנית — להרים עותק מקומי של הרשת ולחזור על אותו רצף פעולות.
מה השתנה במשמרת התורנות
הסיבה נמצאה תוך 40–60 דקות, וחלק מהנפילות לא שוחזרו כלל: המצב שבו נפלה הקריאה כבר השתנה עד רגע הניתוח. חיברנו את Tenderly והעברנו את האבחון למעקב אחר קריאות בפועל — התורן פותח את הטרנזקציה שנפלה ורואה מיד את השלב שבו פעלה ההחזרה, ואת ערכי המשתנים באותו רגע.
הזמן עד לסיבה הצטמצם מ-40–60 ל-5–8 דקות. הניתוח הפסיק לדרוש את מפתח החוזה בשלב הראשון: הסלמה נשארה רק במקום שבו צריך לשנות קוד, ולא להתמודד עם החזרה שכבר קרתה.
מה זה נתן
נעלם סוג של כשלים שהגיע קודם למשתמשים: שגיאות בשרשרת הקריאות בין חוזים, שלא נתפסו בבדיקות על מצבים קבועים. הגדרנו התראות על צריכת גז חריגה ועל החזרות של מתודות מסוימות — המשמרת לומדת על הבעיה לפני המשתמש.
שיעור האירועים שיצאו מגבולות הצוות הצטמצם פי שלושה בערך. הניתוח הפך לשחזורי: לכל מעקב אפשר לחזור כעבור שבוע ולהראות היכן בדיוק הלוגיקה של הקריאה סטתה.
במה נבדל דיבוג מקומי מניטור ברשת?
דיבוג מקומי עונה על השאלה «למה הקריאה הזו נפלה». המהנדס לוקח פורק של הרשת בבלוק הנדרש, חוזר על הטרנזקציה עם אותם נתוני קלט ועובר שלב-שלב: היכן השתנה המצב, באיזו קריאה מקוננת פעלה ההחזרה, מה נרשם בלוגים. כל עוד הכשל ניתן לשחזור, זו הדרך המהירה ביותר לסיבה — אבל רק לתרחיש שכבר קרה ושאותו הצלחנו לחזור.
| קריטריון | דיבוג מקומי בפורק | ניטור ברשת |
|---|---|---|
| משימה | לנתח כשל שכבר קרה | לתפוס בעיה ברגע הופעתה |
| מה נראה | מעקב צעד-אחר-צעד, מצב לפני ואחרי הקריאה | זרימת קריאות חיות וסטיות מהנורמה |
| זמן תגובה | שעות: לשחזר ולבודד | שניות: התראה בעת סטייה |
| כיסוי | תרחיש אחד לכל הרצה | כל קריאות החוזה ללא יוצא מן הכלל |
| מגבלה | לא תופס מה שלא שוחזר | לא נותן ניתוח בתוך הקריאה |
ניטור ברשת פותר משימה הפוכה: הוא לא מסביר את העבר, אלא מבחין בהווה. הקריאות זורמות ברצף, והתראות בזמן אמת פועלות על סטייה מהפרופיל הרגיל — עלייה בשיעור הטרנזקציות הכושלות, החלפת הכתובת הקוראת, צריכת גז לא אופיינית בפעולה שגרתית.
את הסדר קובע מחיר הטעות: ניטור מפעילים לפני שהכשל קורה, ודיבוג — ברגע הניתוח. הגישות מזינות זו את זו: התראה שפעלה נותנת טרנזקציה לניתוח בפורק, והסיבה שנמצאה הופכת לחוק חדש להתראות. את שני הצדדים סוגר Tenderly — פורק לדיבוג וניטור קריאות חיות במסלול אחד.
ספקות טכניים לפני חיבור דיבוג
אינטגרציה עם Tenderly היא שכבת ניטור מעל חוזים שכבר עובדים, ולא כתיבה מחדש של הפרויקט. ספקות לגבי אינטגרציה מצטמצמים בדרך כלל לארבע שאלות: האם הדיבוג יגיע לרשתות סגורות, האם יהיה צורך לבנות משהו מחדש, האם הצמתים יעמדו בזרימת הקריאות ומה קורה לאחר ההפעלה.
האם הדיבוג עובד ברשת סגורה?
כן. את כלי המעקב מרימים במסלול שלכם לצד הצמתים, הנתונים עוברים בערוץ פנימי ואינם מפורסמים החוצה. גישה ניתנת לפי תפקידים ומוגבלת ברמת הפרויקט.
האם צריך לבנות מחדש חוזים שכבר נפרסו?
לא. הניתוח נבנה לפי בייט-קוד ונתוני הקלט של הקריאות שבוצעו; הכתובת והאחסון נשארים כשהיו. שמות פונקציות ומשתנים קריאים נמשכים אם יש מפת קוד מקור; בלעדיה נראים כתובות, סלקטורים ושינויי מצב.
מה יקרה לצמתים בזרימת קריאות גבוהה?
המעקב מתבצע לאחר סגירת הבלוק, מחוץ למסלול ההרצה, ולכן זמן התגובה אינו גדל. אנו מגבילים את עומק הניתוח ואת נפח האחסון, ומכווננים את הסינון לקריאות בעייתיות — תחת עומס נשמר ניתוח הכשלים, ולא ההיסטוריה של כל פנייה.
מי מתחזק את הדיבוג לאחר ההפעלה?
אנו מוסרים גישות, מפת קשרים והוראות לקריאת מעקבים לצוות שלכם. נשארים בקשר לאירועים: ניתוח קריאות תקועות וכושלות, כיוונון חוקי הסינון, עדכון סכמות בעת שינוי חוזים.
תארו את הרשת והחוזים שלכם — נחזור עם הערכה ותוכנית חיבור.נדון במשימה: מה מבררים ומה שולחים בתגובה
את השיחה מתחילים לא במצגת, אלא במשימה שלכם: האינטגרציה עם Tenderly אינה נתקעת בכלי עצמו, אלא באופן שבו הוא משתלב בניתוח אירועים ובבדיקות לפני פריסת חוזים. בדרך כלל די ב-40–60 דקות עם מהנדס שמוביל חיבורים כאלה — זה מספיק כדי להבין את ההיקף ולא לחזור עם הבהרות במשך שבועות.
בשיחה הראשונה מבררים:
- אילו רשתות וסביבות צריך לכסות — רשת ייצור, סביבת בדיקות, ענפי מצב נפרדים;
- כיצד אתם תופסים כעת טרנזקציות שנפלו וכמה זמן לוקח לנתח אחת;
- מי בצוות עובד עם הדיבאגר ואילו הרשאות נדרשות לכל משתתף;
- דרישות לאחסון היסטוריית קריאות ולייצוא לניתוח פעולות שנויות במחלוקת;
- מגבלות על גישות, סודות ותשתית שלכם;
- עדיפות השלב הראשון: תגובה לאירועים או בדיקות לפני פריסה;
- מי מצד הלקוח מקבל את התוצאה ובאיזו צורה.
בתגובה נשלח הערכה ותוכנית עבודה, סכמת חיבור עם נקודות השתלבות בתהליכים שלכם, לוחות זמנים להטמעה לפי שלבים ותנאי עבודה — מה אנו עושים ומה נשאר בצד שלכם.
תארו את המשימה בכתב או בשיחה קצרה — נחזור עם הערכה ותוכנית ונציין את מועד ההתחלה הריאלי הקרוב ביותר.