הגדרת תיעוד לוגים לעסקאות של בוט קריפטו במסלול מלא עם דיווח

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: ניתוח תקלה ושלמות ההיסטוריה

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

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

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

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

מצבי כתיבה: זרם מלא, ברירת אירועים, שגיאות בלבד

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

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

שלבי ההטמעה: מניתוח הסכמה ועד מסירת הנהלים

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

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

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

סכמות אחסון, כללי סינון אירועים, תיעוד

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

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

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

ניתוח ההטמעה: איך חוסלו פערים בדוחות

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

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

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

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

מדדים לפני ואחרי:

• שיעור העסקאות שאושרו בבדיקה: 93% → 100%;
• פער נפח ליממה: עד 7% → אפס מעבר לעיגול;
• זמן איתור סיבת הפער: שעות של ייצוא ידני → פחות מדקה לפי היומן;
• הוראות חלקיות ומבוטלות ששוקפו נכון: כ-60% → 100%;
• דוח: חתך יומי מתואם עם הבורסה בלי עריכות ידניות.

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

במה שונה תיעוד לוגים של בוט קריפטו מיומן הבורסה?

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

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

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

אובדן רשומות, גידול נפח והרשאות: שאלות נפוצות

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

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

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

התיעוד יאט את הבוט או יהפוך לנקודת כשל?

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

איך בודקים שהרשומות לא מוחלפות?

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

נדון במשימה: נבנה סכמת תיעוד עסקאות לבוט שלכם

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

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

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