פיתוח מחליף אוטומטי: צווארי בקבוק וכשלים
המחליף עובד בביטחה במאות ההזמנות הראשונות, אך נשבר בעת גידול. צוואר הבקבוק הראשון — אישור ידני: בעוד המפעיל משווה תשלום ושער בעיניים, זרם ההזמנות גדל, זמן התגובה הולך לעשרות דקות, והלקוח עובר למקום שבו ענו מהר יותר.
השני — אי-סנכרון השער. הוויטרינה מחשבת מחיר לפי מקור אחד, הביצוע מתבצע לפי מקור אחר, ובין הציטוט לעסקה עובר זמן. בשוק רגוע אלו שברי אחוזים, בתנודתיות — הפסד ישיר על פער הציטוטים, והוא מצטבר עם כל עסקה.
השלישי — הזמנות תקועות. ניתוק קשר עם הבורסה, עסקה שנתקעה ברשת, ביצוע חלקי — וההזמנה נשארת בסטטוס "בעיבוד". הלקוח רואה חיוב בלי זיכוי, התמיכה מטפלת בזה ידנית, חלק מהכספים קפואים, והאמון בשירות נמס.
החלפת מטבעות קריפטוגרפיים אוטומטית סובלת לא מהיעדר קוד, אלא מהיעדר לוגיקת שחזור. לכן פיתוח מחליף אוטומטי מתחיל לא בממשק, אלא בניתוח צווארי הבקבוק של המחליף: כיצד הזמנה מקבלת סטטוס חד-משמעי ושורדת הפעלה מחדש של השירות.
להלן — כיצד השער נקבע לרגע העסקה וכיצד המערכת בעצמה מביאה את הפעולה לסיומה או מבטלת אותה ללא התערבות ידנית. בהמשך נפרט כיצד זה נסגר.
מה נותנת אוטומציה של ההחלפה: השפעות מדידות
מחליף אוטומטי הוא לא טופס לקבלת הזמנה, אלא קו ייצור: פקודה, בדיקת סיכונים, איתור נזילות, ביצוע ומשיכה עבור כל נכס עוברים ללא מפעיל.
זמן עיבוד ההזמנה מפסיק להיות תלוי במשמרת התורן ונקבע לפי עומק התור ומספר האישורים ברשת — בזוגות נזילים אלו שניות, בנכסים נדירים הגבול נקבע על ידי השרשרת עצמה כמו Bitcoin, ולא על ידי הצד שלנו. אנחנו מודדים חציון ואחוזון 95 עבור כל זוג בנפרד, לכן צוואר הבקבוק נראה לפני שהלקוח מבחין בו.
מה משתנה בגדלים מדידים:
- חלק הפעולות הידניות יורד מ"כל הזמנה" לבדיקות בודדות — רק מקרים שנויים במחלוקת וסכומים גדולים הדורשים אישור ידני;
- זמינות השירות מגיעה לאזור שבו עבודות מתוכננות והפעלה מחדש של צומת אינן מפריעות לקבלת הזמנות;
- נעלם סוג שלם של כשלים: אובדן הזמנה בעת ניתוק קשר, ביצוע כפול בשליחה חוזרת, עסקה תקועה ללא סטטוס;
- פער השער בין החישוב הפנימי למקור הנזילות נסגר אוטומטית, ולא בתיקון ידני.
עמידות המחליף בכשלים נשענת על שלושה דברים: אידמפוטנטיות של פעולות, כדי שבקשה חוזרת לא תיצור עסקה שנייה; הפרדה בין קו המשיכה החם לאחסון הקר; השהיה אוטומטית לפי זוג בעת פער יתרה או שער מעל סף מוגדר. כל פעולה נרשמת ביומן עם מזהה הזמנה, לכן שחזור לאחר תקלה הוא הרצת יומן, ולא ניתוח התכתבות.
להלן — כיצד זה בנוי בארכיטקטורה מסוימת ואילו בדיקות סוגרות את הסיכונים כבר בהתחלה.
פורמטים של השקה: ליבה מוכנה, מודול משלנו, היברידי
בחירת פורמט ההשקה נקבעת לא לפי גודל העסק, אלא לפי מי שאחראי על ניתוב ההזמנות ועד כמה לא סטנדרטית לוגיקת ההתאמה. ליבת מחליף מוכנה מכסה את הזרימה הסטנדרטית: קבלת הזמנה, שריון נזילות, ביצוע, משיכה.
מודול התאמה משלנו נלקח במקום שבו לא ניתן לבטא את כלל התמחור בקונפיגורציה — לדוגמה, כאשר השער תלוי בו-זמנית בנפח, במקור הנזילות וברמת הרזרבה.
תכנית החלפה היברידית לרוב מנצחת: הליבה אחראית על חשבונאות ואבטחת כספים, ואילו ניתוב ההזמנות וכללי ההתאמה חיים בשירות נפרד שמתקשר עם הליבה דרך תור אירועים. להלן — מתי איזה פורמט מתאים ובמה משלמים עליו.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| ליבת מחליף מוכנה | השקה מהירה של זרימת החלפה, זוגות סטנדרטיים וכללי חישוב | תמחור לא סטנדרטי מטופל בסקריפטים חיצוניים, שיש לתחזק אותם |
| מודול התאמה משלנו | לוגיקת ההתאמה היא יתרון תחרותי, נדרש שליטה מלאה בביצוע | זמן ארוך יותר לעלייה לפרודקשן, דרישות גבוהות יותר לבדיקות עומס ולניתוח כשלים |
| תכנית החלפה היברידית | נדרשים גם התחלה מהירה וגם ניתוב הזמנות משלנו בו-זמנית | דורש חוזה מפורש בין הליבה לשירות וגרסאות לאירועים |
יהיה אשר יהיה, את החוזה להצבת הזמנות מקבעים לפני תחילת העבודה — אחרת החלפת פורמט באמצע הפרויקט הופכת לכתיבה מחדש של הליבה.
שלבי הטמעה: מביקורת הזרימה ועד מסירה להפעלה
כל איטרציה הבאה נשענת על תוצר של הקודמת: בלי סכמת ניתוב אי אפשר לכוונן רזרבות, בלי רזרבות מכווננות — לבדוק תרחישים באופן משוחזר. להלן — רצף העבודות שבו אנחנו מובילים פרויקט של מחליף אוטומטי.
- ביקורת זרימת ההזמנות. מנתחים את המצב הנוכחי: כיוונים מבוקשים, כיצד מגיעות הזמנות, היכן הן הולכות לאיבוד, איזה נפח המערכת מחזיקה בשעות שיא. בתוצר — רשימת צווארי בקבוק עם הערכת עומס.
- סכמת ניתוב. מקבעים את מסלול ההזמנה מהכניסה ועד הביצוע: כללי בחירת כיוון, עדיפויות, התנהגות בעת פער ציטוטים בין פלטפורמות. את הסכמה מאשרים לפני הקוד — מקומות שנויים במחלוקת צפים על הנייר, לא בעבודה.
- כיול רזרבות. קובעים כמה נזילות להחזיק בכל כיוון, כיצד לאזן יתרות ומה לעשות בעת ירידה. ספים, שאחריהם המחליף עוצר קבלת הזמנות במקום לבצע בהפסד, מתארים מראש.
- בדיקת תרחישים. מריצים את המערכת על נתונים היסטוריים וסינתטיים: תנועות חדות בשוק, ביצוע חלקי, אי-זמינות של פלטפורמה חיצונית. כל תרחיש מסתיים באופן צפוי — החזרת כספים או סירוב תקין.
- נהלים וניטור. כותבים הוראות למפעילים: כיצד לקרוא את לוח הניטור, מה לעשות בעת הפעלת התראה, כיצד לעצור ידנית כיוון. התראות שמים על סטיית יתרה ועלייה בזמן הביצוע.
- מסירה להפעלה. פורסים בתשתית שלכם, מריצים החלפת בקרה, מוסרים גישות, סכמה ותיעוד. נשארים בקשר בשבועות הראשונים — תיקונים נעשים לפי זרימת הזמנות אמיתית.
קונפיגורציות, נהלים ותיעוד המחליף
לאחר השקת המחליף נשאר אצל המזמין סט מלא של חומרים, שלפיהם אפשר לתחזק ולפתח את המערכת בלעדינו. אנחנו מוסרים אותו לפי רשימה, עם גרסאות וסימון "מה משתנה בעת עדכון הליבה" — כדי שמהנדס חדש או קבלן לא ינתח את התנהגות המחליף בניסוי וטעייה. להלן — מה בדיוק נכלל בסט.
- תיעוד המחליף — סכמה ארכיטקטונית, מודל נתונים, מחזור חיים של הזמנה מיצירה ועד סטטוס סופי, סדר עדכונים וחזרה לגרסה קודמת.
- סכמות אינטגרציות — זרימות בין ליבת המחליף, מקורות שערים, מודול קופה ומסילות תשלום, עם נקודות כשל והתנהגות מתוארת בעת אי-זמינות של כל קו.
- קונפיגורציות — פרמטרים לכל זוג: מגבלות, צעד עיגול, ספי פער שער מותר, רמות עמלות. עבור כל ערך מצוין למה נבחר דווקא הוא ובמה הוא משפיע בעת שינוי.
- מדיניות גישה — תפקידים והרשאות מינימליות, הפרדת חובות בין מפעיל למנהל, אימות דו-גורמי חובה, סדר מתן ושלילת גישות, יומן פעולות עם שמירת היסטוריה.
- נהל תגובה — רמות אירועים, אזור אחריות של כל אחד, סדר עצירת זוג, הפעלת מסלול נזילות חלופי, תבניות התראות וקריטריון לסגירת אירוע.
- הוראות למשמרת — תרחישים שלב-אחר-שלב: תיקון שער ידני, טיפול בהזמנה תקועה, התאמת יתרות ורזרבות, בדיקת פערים בין חשבונאות פנימית לספקים.
- הדרכת משמרת — הרצת התרחישים האלה על ידי מפעילים בקו בדיקה תחת השגחתנו, עם רשימת קבלה וניתוח טעויות אופייניות.
הסט מתעדכן יחד עם המערכת: שינויים בקונפיגורציות ובנהלים עוברים את אותו בקרת גרסאות כמו הקוד.
מקרה בוחן: כיצד גדלה תפוקת ההחלפה
מה היה לפני העיבוד מחדש
הזמנות התקבלו דרך טופס ווב, והשוואת תקבולים ותשלומים הופעלה ידנית על ידי מפעיל — עם גידול הזרימה התור התפנה לאט יותר משהתמלא. כל אי-סנכרון של אישורים ברשת יצר הזמנה תקועה: הלקוח ראה סטטוס "בעיבוד", התמיכה — פנייה. בשעות שיא הזמן החציוני הגיע לדקות, ובעדכונים השירות עצר קבלה.
מה שינו
את ההחלפה פיצלו לשלבים בלתי תלויים: קבלת הזמנה, שריון נזילות, אישור עסקה נכנסת, תשלום, ביקורת סופית. לכל שלב יש מעבד משלו עם מפתח אידמפוטנטי — הפעלה חוזרת לא יוצרת תשלום שני, ושלב תקוע עובר לניסיון חוזר עם הסלמה לתמיכה. תזמור קונטיינרים על Kubernetes נתן עדכון בלי לעצור קבלת הזמנות וסקייל צפוי לעומסי שיא.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן עיבוד חציוני של הזמנה | 4-6 דקות, בשיא — יותר מ-20 | 12-18 שניות |
| חלק הפעולות הידניות | כשליש מההזמנות דרך מפעיל | פחות מ-2%, רק מקרים שנויים במחלוקת |
| אירועים עם הזמנות תקועות | 8-12 בחודש | 0-1, נסגרים בהחזרה אוטומטית |
| זמן השבתה בעדכון | עד 40 דקות | קבלת הזמנות אינה נעצרת |
בדיקת כתובת ומגבלות עכשיו מתבצעת לפני שריון, לכן סירובים בשלב התשלום כמעט נעלמו. האידמפוטנטיות הסירה סוג של תשלומים כפולים, שקודם לכן נתפס רק בהתאמה בסוף היום.
מה לעשות אם ההחלפה כבר עובדת על סקריפטים מפוזרים?
סקריפטים מפוזרים נשברים לא מעומס, אלא ממצב: לכל אחד יש חשבונאות הזמנות משלו, דרך משלו לניסיונות חוזרים ופרשנות משלו לסטטוס הפקודה. כשאחד נופל באמצע החלפה, איש לא יודע אם הכספים יצאו, לכן ההתאמה נעשית ביד, והפער צף רק אחרי תלונת הלקוח.
מתחילים בביקורת של הפתרון הנוכחי: רושמים את כל נקודות הכניסה והיציאה, משחזרים את הלוגיקה בפועל של חישוב שער, מגבלות ועמלות, מסמנים מקומות ללא אידמפוטנטיות וללא יומן פעולות אחיד.
ככלל, העברת לוגיקת ההחלפה נוגעת בחלק החישובי ובכללי הניתוב, ומחדש נכתב שכבת הביצוע — טיפול בסטטוסים, ניסיונות חוזרים, חשבונאות יתרות ומפתחות גישה.
הגירה ללא השבתה בנויה על מצב צל: המערכת החדשה מקבלת את אותן הזמנות, מחשבת תוצאה וכותבת יומן, אך אינה שולחת כספים. במשך כמה ימים משווים את תשובותיה למה שהסקריפטים עושים — פערים מנותחים לפני המיתוג, לא אחריו.
לאחר מכן מתבצעת מעבר הדרגתי לפי כיוונים: תחילה זוג מטבעות אחד או חלק מהזרימה, אחר כך השאר. מתג חזרה לקו הישן מחזיקים עד סוף התצפית, ואת הסקריפטים עצמם משאירים במצב קריאה, עד שהיסטוריית הפעולות והיתרות יתאמו.
בסופו של דבר, במקום סט סקריפטים שבו כל צעד נשען על הזיכרון של התורן, מופיעה מערכת אחת מנוהלת עם יומן וניתוח מובן של פעולות שנויות במחלוקת.
שאלות טכניות נפוצות: רזרבות, גישות, תקלות
ספקות הנדסיות לגבי מחליף אוטומטי הן כמעט תמיד אותן ספקות: התנהגות תחת עומס שיא, עיכובי אישור, אחסון מפתחות ומגבלות על פעולות. להלן — תשובות קצרות, ניתוח מלא עם סכמות נמצא בתיעוד הפרויקט.
רזרבות נזילות אנחנו מחשבים לא "בעין": השירות מנהל חשבונאות נפרדת לכל נכס ומחזיק חוצץ לתחזית יומית, והמגבלות על פעולות נקבעות לפי מדיניות — לזוג, ללקוח, למרווח. זה מחליש זרימה חריגה בלי להפריע להחלפות רגילות, והנראות נבנית על מדדי תור, חלק סירובים ופערי יתרות.
מה קורה בעומס שיא?
הזמנות עוברות לתור עם עדיפויות, הכניסה מוגבלת לפי מפתח גישה. הפיק מרחיב את זמן העיבוד, אך אינו יוצר עסקאות שבוצעו חלקית: ההחלפה או עוברת במלואה, או מבוטלת.
כיצד נשמרים מפתחות הארנקים?
הנפח העיקרי — באחסון קר על מודולים חומרתיים ברמת Ledger, הקו החם מחזיק רק מלאי תפעולי בגבול המגבלה. חתימת עסקאות הועברה לשירות נפרד בלי גישה לשאר הנתונים.
מה אם הרשת לא אישרה עסקה?
ההחלפה אינה נחשבת להסתיימה עד למספר האישורים הנדרש, ניסיון חוזר מתבצע עם הגנה מכפילות. אם עסקה נתקעה יותר מחלון הזמן, היא מגיעה לתור נפרד ומנותחת לפי היומן, בלי חיפוש ידני.
כיצד אנחנו לומדים על תקלות לפני הלקוח?
התראות מכוונות לסטיית שער, תור תקוע ופערי יתרות, ולא רק לנפילת שירות. התורן מקבל אות לפני שהבעיה נראית בהזמנות.
נדון במשימה: מה צריך לשם הערכה ותכנית עבודה
כדי שהערכת פרויקט המחליף תהיה מדויקת ולא "בעין", אנחנו צריכים חתך של המצב הנוכחי: כיצד ההחלפה בנויה כיום ואיך היא צריכה להיות. להלן — נתוני מוצא שלעיתים קרובות קובעים את הרכב העבודות ומועדי ההשקה. אם בנקודה כלשהי אין בהירות, גם זו תשובה: מכניסים אותה כשלב נפרד בתכנית.
- כיווני החלפה וביקוש: אילו זוגות ומסלולים נותנים את עיקר המחזור, כמה הזמנות עוברות ביום ובשעות שיא.
- תנועת כספים: כיצד מתקבלים ומונפקים נכסים, האם אדם משתתף באישור, היכן צווארי הבקבוק של פעולות ידניות.
- נזילות: רזרבה עצמית, ספקים חיצוניים, מה קורה לשער ולהזמנה בעת כשל של המקור הראשי.
- מפתחות ואחסון: היכן נמצאים הכספים, למי יש גישה, כיצד מופרדים תפקידים של מפעיל, מנהל ותמיכה.
- בדיקות וכללים: דרישות לזיהוי לקוחות, בקרת הלבנת הון, מגבלות ורשימות חסימה.
- אינטגרציות: עם מה המחליף צריך להחליף נתונים — קבלת תשלומים, אנליטיקה, תמיכה, הנהלת חשבונות.
- מגבלות השקה: תחום שיפוט ודרישות רגולטור, תאריך שעד אליו ההחלפה צריכה לעבוד, מי אחראי לקבלה.
לפי הנתונים האלה אנחנו חוזרים עם סכמת זרימות כספים, הערכה, תכנית עבודה לפי שלבים ומועדי השקה מציאותיים — עם סימון מפורש מה נעשה ראשון ומה אפשר להעביר לשני.
תארו את המשימה בצורה חופשית: גם אם חלק מהתשובות עדיין בסימן שאלה, זה מספיק כדי להתחיל דיון ולהציע את גרסת הארכיטקטורה הראשונה.