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

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

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

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

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

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

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

מה נותנת האוטומציה: מהירות הוצאה, נזילות, דיווח

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

מהירות הוצאת הזוג והפחתת פעולות ידניות

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

שקיפות הדיווח ודרישות חיצוניות

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

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

אפשרויות מימוש: מצב ידני, פעולות מרוכזות, קו ייצור

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

פעולות מרוכזות עם אישור

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

קו ייצור אוטומטי ומגבלותיו

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

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

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

ביקורת ליסטינג וסכמת נתונים

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

ריצת בדיקה ללא השפעה על המסחר

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

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

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

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

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

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

מקרה בוחן: הוצאת 40 זוגות מסחר ללא השבתת שירותי הבורסה

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

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

כיצד התקדמנו בשלבים

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

הטמענו בקבוצות של 8-10 זוגות, כך שבכל שלב נשארה נקודת נסיגה. הגמר היה נוהל למשמרת תורנית והתראות אוטומטיות על מהלך ההוצאה.

מה הראו המדידות לאחר ההטמעה

• שיעור פעולות ידניות: 100% → 15% (אישור הפעלה וטיפול בזוגות שנויים במחלוקת).
• זמן הסרת 40 זוגות: כשלושה שבועות → מחזור לילה אחד.
• אירועים בדליסטינג: 11 → 0 קריטיים.
• פניות לתמיכה: 60+ → 7, כולן על ציפיות לקוחות, לא על תקלות.

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

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

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

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

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

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

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

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

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

ספקות טכניים: אמינות, נסיגות, הפרדת גישות

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

האם ניתן לבטל דליסטינג של זוג?

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

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

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

מה קורה בעת כשל בתקשורת עם שירות המסחר?

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

במה מאומתת התוצאה של הסרת זוג?

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

נדון במשימה שלכם: מה נדייק ומה נחזיר

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

מה נדייק בשיחה:

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

מה נשלח לאחר מכן:

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

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