הגדרת בוט קריפטו על VPS: systemd, ניטור ואבטחה

הגדרת VPS לבוט: היכן הסביבה נשברת

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

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

כשלים אופייניים: ניתוק סשן, אתחול, תהליכים תלויים

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

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

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

מה נותנת סביבה מנוהלת: אפקט מדיד

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

אתחול אוטומטי ושחזור עצמי

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

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

נראות: לוגים והתראות

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

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

אפשרויות פריסת הבוט: השוואת מצבים

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

מתי מספיק תהליך אחד

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

מתי צריך לפצל תפקידים ונתונים

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

הגדרת VPS לבוט: שלבי עבודות הנדסיות

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

ביקורת וסכמת פריסה

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

בדיקת עמידות בכשלים

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

תצורות, units ונהלים: הרכב המסירה

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

מה נמצא במאגר

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.

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

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

מה היה לפני

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

מה השתנה אחרי

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

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

מה לעשות אם הבוט כבר פרוס באחסון משותף?

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

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

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

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

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

ספקות טכניים: שאלות בנוגע לתפעול הבוט

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

כיצד אדע שהבוט נפל?

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

האם אפשר להעביר את הבוט בלי השבתה?

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

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

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

כיצד לעדכן לוגיקה בלי סיכון לגרסת העבודה?

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

נדון במשימה: מה לשלוח להערכה ותוכנית

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

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

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