פיתוח מערכת רישום עסקאות של בוט מסחר AI

מדוע תיעוד העסקאות של הבוט נשבר בשיאי עומס

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

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

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

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

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

להלן נבחן כיצד זה נסגר.

מה נותן עקבה עוקבת של העסקה במערכת המסחר

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

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

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

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

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

מצבי כתיבה של התיעוד: השוואת חלופות

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

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

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

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

כיצד אנחנו בונים תיעוד עסקאות: שלבי העבודה

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

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

נכסי התיעוד: סכימות, כללים, תקנונים

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

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

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

מקרה בוחן: כיצד מצאו פער בעסקאות לפי התיעוד

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

מה שינו בסכימת התיעוד

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

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

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

התוצאה במטריקות

חלק הפערים הבלתי מוסברים ירד מ-9% ל-0.4%, זמן איתור הסיבה — מ-36 שעות ל-20 דקות. שוחזרו 340 פעולות ברבעון, ואף אחת לא נדרשה להשוואה ידנית.

מה לעשות אם הבוט כבר כותב אירועים לקבצים?

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

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

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

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

ספקות טכניים לפני תחילת ההטמעה

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

מה לעשות עם אירועים שהוחמצו לאחר תקלה?

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

כיצד מופרדת הגישה לתיעוד העסקאות?

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

כיצד לוודא שהרשומות אינן מוכפלות?

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

האם ניתן להטמיע בלי לעצור את המסחר?

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

נדון במשימה ונחזור עם הערכה ותכנית

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

להערכה עניינית נדרשים נתוני מקור:

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

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