פיתוח מערכת לוח מובילים לסוחרים מקצה לקצה

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

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

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

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

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

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

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

אפקט הליבה האחודה של חישוב הדירוג והוויטרינות

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

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

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

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

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

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

לוח המובילים של הסוחרים: מצבי חישוב ומגבלותיהם

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

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

כיצד אנו מטמיעים את המערכת: מביקורת נתונים ועד מסירה

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

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

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

מה נשאר אצלכם לאחר מסירת הפרויקט

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

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

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

מקרה בוחן: התאמת הדירוג הואצה מיממה לדקות

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

מה שינינו

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

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

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

במה נבדלת ויטרינת הדירוג מליבת החישוב?

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

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

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

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

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

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

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

שאלות טכניות בנוגע לחישוב, להגנה ולעדכון הדירוג

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

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

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

כיצד נלקחים בחשבון מינוף ומכשירים שונים?

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

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

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

האם אפשר לסגור את הדירוג מפני אחרים?

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

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

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

מה לשלוח לחישוב מדויק:

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

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

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