אינטגרציה של בוט HTX API: היכן האוטומציה נשברת
בוט הפועל דרך API של הבורסה מחזיק שני מצבים בו-זמנית: מודל מקומי של פוזיציות ויומן הזמנות בצד HTX. כל עוד הערוץ יציב, הם תואמים, והאינטגרציה של בוט HTX API נראית פורמלית. הניתוק הראשון מהבורסה מראה את ההיפך: המודל המקומי מתיישן תוך שניות, והחלטות המסחר כבר התקבלו על בסיסו.
תרחיש קלאסי — הבוט שלח הזמנה, התשובה לא הגיעה בגלל timeout, הבוט שלח שוב, ובבורסה נפתחו שתי פוזיציות במקום אחת. שכפול הזמנות נולד כמעט תמיד לא בלוגיקת האסטרטגיה, אלא בממשק בין 'נשלח' ל'אושר'. рядом עומדת סיבה שנייה: מגבלות קצב בקשות.
בזינוק תנודתיות הבוט נכנס לשרשרת דחיות, חלק מההזמנות הולכות לאיבוד, והשאר נשלחות באיחור שתחזית האסטרטגיה לא מוכנה לו.
נקודת כשל שלישית — שחזור לאחר ניתוק. אם בעת חיבור בוט מסחר לבורסה לא משווים פוזיציות פתוחות והיסטוריית עסקאות, הבוט ממשיך לחיות במצב מיושן, והפער מצטבר בכל התחברות מחדש.
זה נסגר באופן קונסטרוקטיבי: מזהה לקוח ייחודי לכל הזמנה, כדי ששליחה חוזרת לא תיצור כפילות; השוואת מצב לפי יומן עסקאות בכל שחזור של הערוץ; תור שליחה שמכבד מגבלות וחוזר על עצמו בלי לאבד סדר.
להלן — כיצד אנו בונים אוטומציה למסחר שבה הכשלים הללו נמנעים ברמת הארכיטקטורה, ולא על ידי טיפול בחריגים.
מה נותנת אוטומציה מנוהלת של מסחר
אוטומציה שתוכננה בקפידה מסירה לא את העבודה הידנית ככזו, אלא את ההשהיה בין האות להזמנה. ב-HTX התגובה של הבוט לשינוי מחיר היא שברירי שנייה לעומת עשרות שניות אצל סוחר שברגע זה מסתכל על מכשיר אחר.
בזוגות נזילים ההבדל הזה קובע אם ההזמנה תיכנס לספר הפקודות במחיר הצפוי או תלך בהחלקה, ולאורך מאה עסקאות הפער מצטבר.
התוצאה המדידה השנייה — שיעור ההזמנות הנדחות. לפני שליחה ההזמנה עוברת בדיקות: האם יש מספיק מרג'ין, האם גודל הפוזיציה לא חורג מהמגבלה שנקבעה, האם לא הופר קצב הבקשות המותר לבורסה. הזמנה שלא עברה בדיקה כלל לא נשלחת לבורסה — במקום דחייה בתשובה ובדיקה ידנית ביומן נשאר רשומת עם הסיבה.
השלישי — עמידות של קו המסחר. ניתוק קשר, התחברות מחדש, השוואת המצב המקומי לזה שבבורסה, שליחה חוזרת עם אותו מזהה הזמנה, כדי שלא יופיעו כפילויות ופוזיציות 'רפאים'. בקו כזה כשל רשת מוביל להשהיה של דקות, ולא לבירור לילי ידני של עסקאות פתוחות.
בנפרד — בקרת מגבלות ונראות. גודל הפוזיציה המקסימלי, מספר ההזמנות ליחידת זמן, ההחלקה המותרת הוצאו לקונפיגורציה ומשתנים בלי לערוך את הלוגיקה; היומן שומר כל הזמנה עם פרמטרים וסיבת דחייה. זמן השבתה נמדד לא בשעות שיקום, אלא במספר העסקאות שקו המסחר לא ביצע.
דרכי התחברות: API ישיר, שכבת פרוקסי, מצב ידני
חיבור ישיר דרך API — מינימום חוליות: הבוט פונה ל-HTX ישירות, ההזמנות נשלחות לספר הפקודות שלה, ומפתחות המסחר נמצאים על אותו מארח.
ההשהיה מינימלית, אבל גם השליטה: בעת תקלה בבוט המפתחות נשארים פעילים, וכמה אסטרטגיות בחשבון אחד מתחרות על אותו יתרה פנויה, ואף אחד לא מסדר את ההזמנות שלהן בתור משותף.
שכבת ביניים מסירה חלק מהסיכונים האלה: היא מחזיקה את החיבור, עוקבת אחר מגבלות קצב הבקשות וחוזרת על קריאות שלא צלחו, והמפתחות של הבורסה לא יוצאים מהקו שלך. המחיר — חוליה מיותרת שצריך לתחזק ולנטר.
שלושה מצבים והגבולות שלהם
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חיבור ישיר דרך API | אסטרטגיה אחת, שרת קרוב לבורסה, חשובה השהיה מינימלית | מפתחות על מארח הייצור; אין תור משותף להזמנות עבור כמה אסטרטגיות; בעת ניתוק הקשר ההזמנות שנשלחו לא מבוטלות בעצמן |
| שכבת ביניים | מספר אסטרטגיות בחשבון אחד, נדרשת בקרת מגבלות ויומן פעולות | נקודת כשל נוספת; השהיה גבוהה יותר; נדרש ניטור של השכבה עצמה והעדכונים שלה |
| אישור ידני של עסקאות | דיבוג אסטרטגיה, עסקאות גדולות, דרישות מחמירות לבקרת סיכון | מהירות התגובה מוגבלת על ידי המפעיל; לא מתאים לתרחישים עם כניסות תכופות |
הבחירה כאן אינה בין 'מהיר יותר או אמין יותר' — את הגבולות קובעת התשתית שלך: היכן נשמרים המפתחות, כמה אסטרטגיות פועלות במקביל ואיזו רמת בקרה מחייבת לפי הנוהל.
שלבי הטמעה: מניתוח האסטרטגיה ועד המסירה
העבודה מתנהלת בצעדים עוקבים, וכל אחד נסגר בארטיפקט שאפשר לבדוק לפני המעבר לבא. סדר כזה מסיר את הסיכון העיקרי — כשהבוט כבר שולח הזמנות בחשבון אמיתי, והלוגיקה לחישוב נפח, המגבלות וטיפול בניתוקים לא מתועדות בשום מקום. להלן — המסלול מהאסטרטגיה שלך ועד לקו מסחר עובד.
- ביקורת תשתית. בודקים היכן הבוט יתארח, כיצד מאורגנת הגישה לרשת, האם יש מספיק משאבים לבקשות תכופות לבורסה וכיצד בנויים היומנים — בלעדיהם בירור תקלה הופך לניחוש.
- תרשים אינטראקציה בין שירותים. מתעדים מי יוזם הזמנות, היכן נשמר מצב הפוזיציות, כיצד מטופלים ביצועים חלקיים, דחיות וניתוק קשר ברגע העסקה.
- הגדרת מפתחות ומדיניות. עבור HTX פותחים מפתח נפרד עם הרשאה למסחר בלבד, בלי משיכת כספים, עם הגבלה על נפח וקבוצת זוגות — חשיפה של מפתח כזה לא מאפשרת למשוך את היתרה.
- סביבת בדיקה. מריצים את הלוגיקה על נתוני שוק חיים בלי ביצוע אמיתי: בודקים תגובה להזמנות נדחות, שינוי מגבלות ואובדן קשר.
- בדיקת חישובים. משווים עמלות, עיגול נפח, גודל לוט ורישום עסקאות חלקיות — המספרים של הבוט והדוח של הבורסה צריכים להתאים עד הספרה האחרונה.
- מסירה לתפעול. פורסים בסביבת ייצור עם נפח מוגבל, מפעילים התראות על שגיאות גישה וירידה, מוסרים הרשאות, תרשים ונוהל חזרה לאחור.
- ליווי. בשבועות הראשונים בוחנים התנהגות בפועל, מדייקים מגבלות ורק לאחר מכן מסירים את ההגבלות על הנפח.
מכאן המערכת עובדת בלי מעורבות מתמדת שלנו — לצוות נשארת תיעוד ונקודת כניסה ברורה להמשך פיתוח.
מה נשאר אצלך לאחר מסירת הפרויקט
לאחר מסירת הפרויקט נשאר אצלך לא 'בוט עובד על השרת שלנו', אלא ערכה שלפיה הצוות שלך יכול להקים את המערכת מאפס, להעביר אותה עדכון ולבצע בירור תקלה בלעדינו. להלן — מה שמועבר לפי פרוטוקול, עם הרצה של כל סעיף בסביבה שלך.
- תרשים פריסה — מפת תהליכים, קישורים לבורסה, נקודות כשל וסדר ההפעלה בסביבה נקייה: מהכנת הסביבה ועד להזמנת בדיקה ראשונה.
- מדיניות גישה למפתחות — מפתחות מסחר בלי הרשאת משיכה, הפרדה לפי אסטרטגיות, רוטציה ואחסון בכספת סודות במקום קבצי קונפיגורציה במאגר.
- קונפיגורציות אסטרטגיות — פרמטרים הוצאו בנפרד מהקוד: מגבלות נפח ומספר הזמנות פעילות, ספי עצירה, מתגי מצב 'קריאה בלבד'.
- רישום פעולות — כל בקשה ותגובה של הבורסה, הזמנות נדחות ופערים בפוזיציה עם חתימת זמן; מהיומן משחזרים את סיבת חוסר הסנכרון.
- נוהל תגובה — תרחישים לסירוב גישה לבורסה, הזמנה תקועה והפעלת מגבלה: מי מגיב, בתוך כמה זמן, כיצד עוצרים את המסחר.
- התראות וניטור מצב — ספי הפעלה, ערוץ מסירת אות, בדיקה על אירוע ניסוי, כדי שההתראה לא תימצא שותקת.
- תיעוד המערכת — מפת רכיבים, סדר עדכון ההגדרות, הוראות חזרה לקונפיגורציה קודמת וצ'קליסט להעלאה לפעולה עבור הצוות שלך.
המסירה אינה 'תיקייה עם קבצים': המהנדסים שלך חוזרים על הפריסה לפי המסמכים שלנו, אנחנו מתעדים היכן ההוראה התבררה כלא שלמה, ומשלימים אותה עד למצב שבו המערכת מתוחזקת בלי תמיכה חיצונית. תאר את המשימה שלך — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: אוטומציה בבורסה עם בקרת סיכון
נקודת התחלה
הלקוח סחר ב-HTX בכמה זוגות באופן ידני, מהטרמינל: 30-40 פעולות ביממה לתורנות, זמן ממוצע מהאות לעסקה — 3-5 דקות, ובתנועה חדה — עד 15. התרחיש הגרוע ביותר התברר כלא טכני: המשמרת הסתיימה, וסטופ ההגנה על פוזיציה פתוחה לא הספיק להיקבע. כשלים כאלה חזרו על עצמם באופן קבוע ואכלו את התוצאה של השבוע.
מה שינו
חיברנו את הבוט לבורסה דרך API: מפתחות עם הרשאת מסחר ובלי הרשאת משיכה, מנוי לזרם מחירים במקום סקרים, מגבלות קצב בקשות ושליחה חוזרת עם מזהי הזמנה ייחודיים — כפילויות לא פותחות פוזיציה פעמיים. כללי כניסה, נפח וסטופי הגנה הוצאו לקונפיגורציה, ומצב הפוזיציות מושווה לבורסה כל כמה שניות.
עצירת חירום של המסחר מופעלת בירידה מעל הסף, ניתוק קשר או אי-התאמה של היתרה מול המחושבת: הבוט מסיר הזמנות פעילות, סוגר פוזיציות לפי השוק ועובר להמתנה. התערבות ידנית נשארה — אבל כהחלטה מודעת, לא כהגנה היחידה.
מדדים לפני ואחרי
פעולות ידניות — מ-30-40 ל-4-6 ביממה, וזה רק בקרת פרמטרים. תגובה לאות — מ-3-5 דקות לעשיריות שנייה. סטופי הגנה שהוחמצו: סוג התקלות נעלם לחלוטין — הסטופ נקבע יחד עם הפוזיציה, לא אחריה. הירידה החודשית הצטמצמה בערך פי שלושה.
במה חיבור ישיר שונה ממתווך
חיבור ישיר — הקוד שלנו מחזיק את המפתחות ושולח הזמנות לשער המסחר של הבורסה. מתווך עומד בין הבוט לבורסה: מקבל את האות, מנהל תור משלו ורישום פוזיציות, ומעביר הלאה. ההבדל אינו במערך הפונקציות, אלא במי שאחראי לתוצאה בכל קטע.
כל חוליה מיותרת מוסיפה השהיית ביצוע — סריאליזציה, תור בקשות, מגבלות משותפות לכל לקוחות השירות. בשוק רגוע זה לא מורגש, אבל בתנועה חדה ההזמנה מגיעה במחיר אחר, וההחלקה אוכלת את תוצאת האסטרטגיה. אות חוזר על ביצוע הולך באותה השהיה, ולכן ניהול הפוזיציה פועל לפי תמונה מיושנת.
אזור האחריות של הקבלן בתכנית ישירה סגור עלינו: מפתחות, לוגים, בירור תקלה, ניסיונות חוזרים בעת ניתוק קשר — קו אחד. עם מתווך חלק מהתקלות עוברות לתמיכה זרה, שבה אין גישה ללוגים שלנו ואין לוחות זמנים צפויים לתגובה.
גישה לנתונים היסטוריים — קו פרשת המים השני. מפתחות ישירים נותנים ייצוא מלא של עסקאות ותמונות של ספר הפקודות: עליהם בודקים אסטרטגיה בתקופות קודמות, כולל הזמנות שבוטלו ובוצעו חלקית.
מתווכים לעתים קרובות מוסרים היסטוריה מצטברת או מקוצרת, ולפיה אי אפשר להעריך ביושר את התנהגות האסטרטגיה בימים תנודתיים.
עצמאות מצד שלישי — עניין של שרידות הפתרון: שינוי תנאים או עצירת שירות עוצרים את הבוט כליל, ומעבר דורש לכתוב מחדש את הלוגיקה. מתווך מוצדק כשצריך להשיק מהר בלי תשתית משל עצמך או כשהבורסה מגבילה גישה אוטומטית — אבל זהו פשרה מודעת, לא בסיס הארכיטקטורה.
ספקות טכניים לפני ההתחלה
לפני חיבור הבוט לבורסה צפות שאלות, שבהן תלוי אם תפקיד בידיו פוזיציות אמיתיות. להלן — מה שאנחנו בדרך כלל מסירים בשלב התכנון, ולא אחרי הכשל הראשון.
אילו הרשאות לתת למפתח והאם אפשר להסתפק במינימום?
למפתח משאירים רק הרשאת מסחר — משיכת כספים מושבתת ברמת הגדרות הבורסה, ואי אפשר פיזית למשוך נכסים דרך הבוט. בנוסף, מצמידים את המפתח לרשימת כתובות מורשות ופותחים תת-חשבון נפרד לאוטומציה: בעת דליפה המפתח נותן גישה רק למסחר בתוך תת-החשבון הזה. את המפתחות עצמם שומרים בכספת סודות, ולא בקונפיג במאגר, ומבצעים רוטציה לפי הנוהל.
מה יקרה לפוזיציות פתוחות בעת כשל בקשר?
מקור האמת הוא הבורסה, לא מסד הנתונים המקומי של הבוט. לאחר אתחול מחדש הבוט שולח בקשה לפוזיציות ולהזמנות בפועל, משווה אותן למצבו וממשיך לעבוד לפי התמונה האמיתית, ולכן לא נותרות כניסות 'נשכחות'. לכל הזמנה מוקצה מזהה משלה: שליחה חוזרת לאחר ניתוק לא יוצרת כפילות.
כמה מהר מבוטלת הגישה ומה יקרה לפוזיציות?
המפתח מבוטל בחשבון הבורסה בפעולה אחת — הבוט לאחר מכן לא ישלח אף בקשה, והפוזיציות נשארות בחשבון וזמינות לניהול ידני. ניתוק מתוכנן עושים באותו אופן: קודם עוצרים את הלוגיקה, ממתינים לסגירה או העברה של הפוזיציות, ואז מכבים את המפתח.
האם אפשר לסחור ידנית במקביל לבוט?
אפשר, אבל צריך כללי הפרדה ברורים: כלי היד והבוט לא חופפים, או שלמטרות אוטומציה מוקצה תת-חשבון נפרד. הבוט לא נוגע בפוזיציות שנפתחו ידנית ולא הופך אותן, ומגבלות הסיכון מחושבות לפי תיק כולל. כך עסקה ידנית לא הופכת להכפלה בלתי צפויה של הנפח.
נדון במשימה שלך ונחזור עם הערכה
כדי שהבירור יהיה ענייני ולא כללי, התחל בנתוני פתח: איזו אסטרטגיה מבוצעת, ספוט או נגזרים, כמה זוגות מסחר והזמנות בדקה, מהן הדרישות להשהיה בין האות להצבת ההזמנה. צרף תיאור של לוגיקת כניסה ויציאה — סקריפט, טבלה או אפילו הערות, זה מספיק כדי להבין את סוג המשימה.
מסור מפתחות עם הרשאות מוגבלות: קריאת יתרה ומסחר, בלי משיכת כספים. אם לאסטרטגיה יש סביבת בדיקה, גישה אליה מזרזת בדיקה על תגובות אמיתיות של הבורסה — עם מגבלות קצב בקשות וטיפול בדחיות. זה מסיר חצי מהשאלות לפני תחילת העבודה.
בתגובה תקבל לא מילים כלליות, אלא חבילת עבודה:
- תוכנית עבודה לפי שלבים — מחיבור מפתחות וניתוח האינטגרציה של בוט HTX API ועד להרצה בחשבון חי.
- סדר ההערכה: אילו נתוני פתח משפיעים על עלות העבודה ואילו אנחנו מקבלים כברירת מחדל.
- לוחות זמנים להטמעה לפי שלבים, עם אבן דרך נפרדת להרצת ניסיון ומעקב אחר ביצוע.
- הרכב התיעוד: תרשים האינטראקציה של הבוט עם הבורסה, תיאור ההגדרות, הוראות תפעול ושחזור לאחר תקלה.
- רשימת החומרים הנמסרים — קוד, קונפיגורציות ומפתחות נשארים בשליטתך.
- נוהל תמיכה וסדר השיפורים לאחר ההרצה.
תאר את המשימה בצורה חופשית — נדון בה ונחזור עם הערכה ותוכנית עבודה. ככל שתשלח יותר נתוני פתח, כך יהיו מדויקים יותר לוחות הזמנים להטמעה והרכב התיעוד.