תמיכה טכנית מקצועית לפרויקט בלוקצ'יין מקצה לקצה

תמיכה טכנית בפרויקט בלוקצ'יין: היכן זה נשבר בעומס

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

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

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

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

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

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

אפקטים מדידים: מה משתנה לאחר יישום נהלים

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

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

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

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

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

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

מצבי ליווי: קו תורנות לעומת התערבויות חד-פעמיות

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

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

כיצד בוחרים מצב

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

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

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

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

מערך המסמכים והקונפיגורציות שנשאר אצלכם

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

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

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

ניתוח מקרה: כיצד הסרנו את התקלות בצמתי הרשת

מה היה לפני ההתערבות

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

זמן השחזור הממוצע החזיק סביב ארבעים דקות, וכל אותו זמן חלק מהבקשות לארנק החזירו שגיאה. פורמלית לכל תקלה היה סיבה משלה, אבל השורש אחד: למערך לא הייתה לא наблюдаемость ולא דרך צפויה להחזיר אותו למצב עבודה.

מה שינינו ומה השגנו

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

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

מה לעשות אם רשת הבלוקצ'יין כבר פרוסה ועובדת?

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

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

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

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

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

ספקות טכניים ותשובות הנדסיות בנושא ליווי

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

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

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

כיצד מעדכנים רכיבים בלי השבתת השירות?

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

היכן מסתיימת האחריות שלכם?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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