הגדרת Tenderly Alerting: ניטור חוזים חכמים והתראות

הגדרת Tenderly Alerting: היכן ניטור החוזים מתעוור

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

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

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

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

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

מה נותן ניטור רציף של חוזים חכמים

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

קיצור הזמן עד לגילוי האירוע

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

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

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

סגירת מחלקה שלמה של כשלים

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

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

מצבי התראות: השוואת גישות טכניות

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

התאמת מצב למשימה

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

רעש והתראות שווא

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

שלבי ההגדרה: מתרשים ועד מסירה לתפעול

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

מלאי חוזים ותפקידים

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

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

ניתוב הפעלות

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

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

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

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

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

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

מקרה בוחן: איך הפסיקו להחמיץ טרנזקציות אנומליות

עם מה הגיעו: התראות היו, תגובה לא הייתה

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

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

מה הוגדר נוסף לאחר ההשקה

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

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

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

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

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

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

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

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

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

ספקות לגבי אינטגרציה והתראות שווא

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

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

איך להסיר התראות שווא?

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

איך להוציא התראות למסנג'ר ולמערכת תורנויות?

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

מי מטפל בהפעלה?

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

מה לעשות עם אירוע שקרה לפני ההגדרה?

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

נדון בתרשים ניטור לחוזים שלכם

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

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

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