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

למה ניהול גרסאות של קונפיגורציות נשבר בפרודקשן

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

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

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

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

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

מה נותן ניהול גרסאות של קונפיגורציות לבוט מסחר

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

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

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

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

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

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

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

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

איך אנחנו בונים ניהול גרסאות של הגדרות

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

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

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

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

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

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

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

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

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

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

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

מה הראתה הסביבה לפני

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

מה השתנה

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

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

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

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

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

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

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

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

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

ספקות טכניים: יומן שינויים והחזרות

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

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

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

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

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

שניים עורכים הגדרות בו-זמנית — והאם צריך לעצור את המסחר?

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

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

נדבר על המשימה: תוכנית והצעד הבא

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

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

בהמשך הולכים בצעדים קצרים, ובכל אחד רואים תוצאה:

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

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