מדוע פריסת חוזים חכמים ב-Sui נכשלת בשלב הפרסום
פרסום חבילה הוא הפעולה היחידה במחזור החיים של החוזה שלא ניתן לבטל. טעות בהרשאות או בתלויות מתגלה רק לאחר שהאובייקטים נוצרו ברשת, והמצב התפצל מהעותק המקומי. נבחן את פריסת החוזים החכמים ב-Sui דרך שלושה כשלים שחוזרים מפרויקט לפרויקט.
הראשון — אובדן הרשאות המנהל. הפרסום יוצר אובייקט עם הרשאות עדכון, ואם הוא נמצא בכתובת שהמפתח שלה אינו זמין, לא ניתן עוד להוציא גרסה חדשה לפי אותו מזהה — מדיניות החבילה אוסרת זאת. הפתרון הוא הוצאה מחדש בכתובת חדשה והעברת מצב ידנית: עבודה יקרה בסדר גודל מבדיקת ההרשאות לפני הפרסום.
השני — קונפליקט בין גרסאות של מודולים: החבילה נבנתה מול רוויזיה אחת של תלות, וברשת פרוסה אחרת, והקריאה נכשלת בשל אי-התאמת טיפוסים.
השלישי — העברה ידנית של קונפיגורציה בין סביבות: מזהי חבילות, כתובות אובייקטים ופרמטרי רשת נערכים במניפסט מהזיכרון, וסביבת הבדיקות מפסיקה להתאים לזו הראשית.
המחיר של כל כשל כזה הוא לא בנייה מחדש, אלא פער במצב ושעות של השוואה. בהמשך נפרט כיצד זה נסגר: קיבוע ההרשאות לפני הפרסום, נעילת רוויזיות של תלויות והעברה משוחזרת של קונפיגורציה בין סביבות.
מה משתנה כששחרור החוזים מפסיק להיות ידני
שחרור ידני נשען על אדם: הבנייה, ההעלאה לרשת, קישור הכתובת ובדיקת ההרשאות מתבצעים מהזיכרון ובסדר שונה. כל עוד יש מעט עריכות, זה לא מורגש; בזרימה מתגלות בנייות שאינן משוחזרות, פרסומים לרשת הלא נכונה ובדיקות נשכחות — מחלקות כשל שחוזרות בכל שחרור.
שחרור חוזים מנוהל מכנס את כל זה למחזור אחד מהעריכה ועד הפרסום. ב-Sui החבילה מתפרסמת פעם אחת, והעדכונים עוברים דרך הרשאת עדכון — לכן את התצורה בונים סביב גרסת החבילה, ולא סביב פעולות המהנדס.
רשימת הבדיקה שלפיה אנו בונים את התצורה:
- מסלול עריכה אחיד: בנייה, בדיקת טיפוסים, בדיקות ברשת המקומית, בדיקה בידי מהנדס נוסף — בלי צעדים «לפי סיכום».
- הרשאות העדכון והכתובות מאוחסנות במאגר מאובטח, והגישה ניתנת לפי תפקידים.
- פרסום תחילה לרשת הבדיקות, ואחר כך לרשת הראשית — באותה קבוצת פקודות.
- גרסת החבילה והכתובת נרשמות ביומן הפרסומים: רואים מה יצא ומתי.
- הגרסה הקודמת נשארת זמינה — החזרה לאחור אינה מחייבת לכתוב מחדש ולבנות מחדש את הקוד.
את האפקט מודדים לפני ואחרי: המחזור מהעריכה ועד הפרסום מתקצר מימים למעבר אחד, שיעור הפרסומים המוצלחים עולה, ומחלקות הכשל — רשת לא נכונה, בדיקה נשכחת, הרשאה שאבדה — יוצאות מהתהליך במקום להיות מטופלות אחרי השחרור.
דרכי פרסום ועדכון של חבילות: השוואה
חבילה ב-Sui היא אוסף מודולים המתפרסם לכתובת, ואחרי הפרסום הראשון מזהי האובייקטים אינם מקושרים מחדש. מה בדיוק מותר לשנות בהמשך קובעת מדיניות העדכון של החוזה במניפסט החבילה: לא ניתן להקל אותה בהמשך, רק להחמיר. לכן מצב הפרסום נבחר בתחילת הפרויקט, ולא בשלב השחרור.
פרסום ברשת הבדיקות עובר את אותו מסלול כמו ברשת הראשית: אותה מדיניות, אותן תלויות, אותן בדיקות בעת הפריסה. המצב אינו מועבר — החבילה נפרסת מחדש לפי הכתובת שלה, ואת מיגרציות הנתונים יש לתאר בתרחיש נפרד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חבילה בלתי ניתנת לשינוי | הלוגיקה יציבה, נבדקה, מחזיקה נכסים | תיקונים בלתי אפשריים — רק כתובת חדשה והעברת מצב |
| ניתנת לעדכון, מדיניות «הוספה בלבד» | המוצר מתפתח בלי לשבור את הלוגיקה הקיימת | לא ניתן לכתוב מחדש חתימות ומבנים קיימים |
| ניתנת לעדכון, הרשאות מלאות | שלבים מוקדמים, שירותים פנימיים, איטרציות מהירות | בעל החבילה יכול לשנות לוגיקה שמתחת לאובייקטים חיים |
| פרסום ברשת הבדיקות | הרצת המדיניות והמיגרציות לפני הרשת הראשית | כתובת נפרדת, המצב אינו מועבר לרשת הראשית |
בפועל: את המדיניות מקבעים לפני הפרסום, ואת יכולת העדכון מתכננים כך שלא יהיה צורך לכתוב מחדש מבנים קריטיים עם גידול העומס.
סדר העבודות: מביקורת הקוד ועד מסירת התצורה
פריסת חוזים חכמים ב-Sui אינה פקודת פרסום אחת, אלא שרשרת שלבים, שכל אחד מהם נסגר בארטיפקט שניתן לבדוק לפני המעבר הלאה. אם מדלגים על התכנון, טעות בהרשאות הבעלות על אובייקט צפה כבר ברשת הראשית, כשהתיקון מחייב מיגרציית מצב ובדיקה חוזרת של כל התלויות.
שלבי העבודה
- ניתוח הלוגיקה וביקורת החוזים. קוראים את הדרישות יחד עם הצוות שלכם, מקבעים תפקידים, הרשאות ותרחישי החזרה לאחור. בפלט — רשימת אינווריאנטים שהקוד מחויב לשמור בכל סדר קריאות, ומחלקות פגיעויות שנסגרות בשלב התכנון.
- תכנון סכימת המודולים. מפרקים את הלוגיקה כך שגבולות המודולים יתאימו לאזורי האחריות: בנפרד אחסון המצב, בנפרד כללי הגישה, בנפרד החישובים. הסכימה מסוכמת לפני כתיבת הקוד — עריכה בשלב זה זולה מכתיבה מחדש של מודולים מוכנים.
- הגדרת הסביבות. מרימים צומת מקומי, רשת בדיקות וארנקים עם מפתחות נפרדים לבנייה ולניהול. הקונפיגורציות מנוהלות בגרסאות, כדי שניתן יהיה לשחזר את הסביבה מאפס בכל מכונה.
- מימוש ובדיקות מקומיות. מריצים בדיקות יחידה לכל מתודה ציבורית, כולל תרחישים שליליים: בעלים זר, קריאה חוזרת, חריגה מהמכסה.
- בדיקה ברשת הבדיקות. מפרסמים את החבילה, מודדים את צריכת המשאבים לפעולה, מריצים תרחישים תחת עומס ובודקים את ההתנהגות בקריאות מקבילות לאותו אובייקט. התוצאה — דוח עם טרנזקציות והגבולות שנמצאו.
- מסירת התצורה. מוסרים קוד מקור, סכימת מודולים, סקריפטים לפרסום ולעדכון, נוהל פעולה בעת תקרית וסדר החזרה לגרסה הקודמת.
כל שלב נסגר בקבלה: בלעדיה השלב הבא לא מתחיל. כך שלרגע ההשקה יש לצוות שלכם עותק עובד של התצורה והבנה כיצד לבצע שינויים בעצמם.
ערכת האספקה: קונפיגורציות, סכימות, נהלים
חוזה עובד ברשת הוא רק חלק מהתוצאה. בלי תיאור של האופן שבו הוא נבנה, מי רשאי לשנות אותו ומה לעשות בעת תקלה, כל עדכון הופך לניתוח תלויות מהזיכרון. לכן ערכת התיעוד נאספת במקביל לקוד ונמסרת יחד איתו, ולא «תושלם אחר כך».
- מפת החבילות והתלויות: אילו מודולים נכללים בבנייה, מה מחובר מבחוץ, באיזה סדר מתפרסם, אילו כתובות כבר תפוסות.
- סכימות של חבילות וקשרים בין מודולים — דיאגרמות עם נקודות כניסה, שלפיהן מהנדס חדש נכנס לפרויקט בלי שיחות.
- קונפיגורציות של סביבות: פרופילים לרשת הבדיקות ולרשת הראשית, כתובות של רישומים, מכסות לפעולות, פרמטרי בנייה.
- מדיניות גישה: מי ובאמצעות אילו מפתחות יכול לעדכן מודולים, אילו פעולות דורשות כמה חתימות, כיצד מופרדים התפקידים.
- נוהל עבודה עם מפתחות: יצירה, אחסון, רוטציה וסדר שחזור הגישה אם הבעלים יוצא.
- נוהל עדכון: המסלול משינוי בענף ועד הפרסום, מי מאשר את השחרור וכיצד לחזור לגרסה הקודמת.
- הוראות ניטור החוזה: אילו אירועים מנוטרים, אילו נחשבים לתקלה, למי נשלחת ההתראה.
על כל ארטיפקט אנחנו עוברים יחד עם הצוות שלכם לפני המסירה — שאלות לגבי ההרכב עדיף להסיר בשלב זה. תארו את המשימה, ואנחנו נחזור עם אומדן ותוכנית: פריסת החוזים החכמים ב-Sui תפסיק להיות תלויה בספק יחיד.
מקרה בוחן: כיצד קיצרנו את מחזור שחרור החוזים פי ארבעה
איך זה היה: השחרור היה תלוי באדם אחד
המוצר — כמה חבילות חוזים מקושרות ב-Sui, הצוות מפוזר, ארבעה מהנדסים באזורי זמן שונים. פרסום עדכון ארך עד שלושה ימים: את הבנייה הריצו ממכונות מקומיות, הזכות לעדכן את החבילה הייתה בארנק יחיד, וסדר הצעדים חי בהתכתבות. כל פרסום שלישי נכשל — גרסאות התלויות התפצלו, ואת החוזים היה צריך לבנות ולפרסם מחדש.
מה שינינו
את השחרור העברנו לבנייה אוטומטית: קבוצת צעדים זהה לכולם, הרצה ברשת הבדיקות לפני הרשת הראשית, גרסאות תלויות מקובעות. את הזכות לעדכון העברנו לחתימה מרובה — שלושה מפתחות מתוך חמישה — ולמדיניות החבילה הגדרנו מצב עדכון תואם, כדי שכתובות ואובייקטים לא ייווצרו מחדש בכל שחרור. לפני הפרסום חובה עכשיו בדיקות וניתוח סטטי של הקוד, ותוצאת הבדיקות גלויה לכל הצוות.
מה היה בסוף
מחזור השחרור התקצר פי ארבעה — משלושה ימים לשמונה עשרה שעות כולל הבדיקות. שיעור הפרסומים המוצלחים עלה משני שלישים ל-98%: פערים נתפסים ברשת הבדיקות, ולא ברשת הראשית.
הרשאות העדכון אינן תלויות יותר באדם אחד — עזיבה של מהנדס אינה משמעה אובדן השליטה על החבילה, והחזרה למצב הקודם אורכת דקות במקום פרסום מחדש.
מה עושים אם החוזה כבר פרוס ב-Sui ודורש תיקונים?
קוד שפורסם ב-Sui אינו ניתן לשינוי: החוזה נפרס כאובייקט-חבילה, ולא כקובץ על שרת, ולכן «לתקן כמה שורות ולהעלות מחדש» לא עובד כאן. כל עריכה של הלוגיקה עוברת הליך עדכון חבילה, ומה שמותר בו נקבע על ידי מדיניות העדכון שנקבעה ברגע הפרסום הראשון.
מצב העדכון קובע את גבול האפשרי: תואם מאפשר להוסיף פונקציות ולשנות את גוף הקיימות, אך אוסר לשבור חתימות ולמחוק ממשקים ציבוריים; אדיטיבי — רק להוסיף לחבילה מודולים חדשים; מצב לתלויות בלבד — רק להחליף גרסאות של חבילות חיצוניות.
אם המדיניות צרה מדי מלכתחילה, הדרך היחידה היא פרסום בכתובת חדשה, וזה כבר העברת מצב והחלפת כל האינטגרציות לחוזה החדש.
הנתונים חיים באובייקטים, ולא בקוד החבילה, ולכן עדכון הלוגיקה כשלעצמו אינו נוגע במצב. אך אם מבנה השדות השתנה, הקוד החדש לא יקרא אובייקטים ישנים: יש צורך בהעברת מצב — פירוק האובייקט הישן, יצירת חדש עם המבנה המעודכן וסימון גרסה, כדי שניתן יהיה להריץ את המיגרציה בחלקים. עבור אובייקטים משותפים זו עבודה נפרדת עם הרשאות עדכון וסדר קריאות קפדני.
לכן בחירת המצב נגזרת מהיקף העריכות: תיקון שגיאה בגוף הפונקציה נסגר בעדכון חבילה רגיל, ואילו החלפת מודל הנתונים והממשקים הציבוריים — בגרסה חדשה בתוספת מיגרציה.
לפני כל אפשרות אנחנו מקבעים את המצב הנוכחי, בודקים חבילות תלויות וקוראים חיצוניים, מכינים תוכנית החזרה לאחור ובדיקות על נתונים אמיתיים.
סדר העבודה הוא בדרך כלל כזה: ספירת מלאי של ממשקים ואובייקטים, בדיקת הרשאות העדכון, בחירת המצב בעל הסיכון הנמוך ביותר, העברת המצב והוצאת הקוד הישן. תארו מה כבר פרוס ואילו תיקונים דרושים — נחזור עם אומדן ותוכנית.
ספקות טכניים נפוצים לפני ההתחלה
הספקות לפני ההתחלה הם בדרך כלל אותם ספקות: מי מחזיק בהרשאות המנהל, כיצד להשתכנע בבטיחות הלוגיקה, מה לעשות בעת שגיאה בגרסה חדשה והאם התיעוד יספיק. להלן תשובות קצרות לכל אחד, בצורה שבה אנחנו סוגרים אותם לפני פרסום החוזה ברשת הראשית של Sui.
מי מקבל גישה למפתחות המנהל?
ניהול המפתחות נבנה על סכימת חתימות סף: פעולה רגישה עוברת רק באישור של כמה מאגרים בלתי תלויים, ולכל צד יש ארנק חומרה משלו. אין גישה מלאה ביחיד לאף מהנדס, ולכן פגיעה בזוג מפתחות אחד אינה מאפשרת להוציא כספים.
כיצד נבדקת בטיחות הלוגיקה של החוזה?
ביקורת האבטחה של החוזים מתבצעת לפני הפריסה: ניתוח סטטי, תרחישים עם שימוש חוזר באובייקטים, בדיקת הרשאות לקריאה לפונקציות רגישות, הרצה ברשת הבדיקות. בפלט — דוח עם חלוקת הממצאים לפי קריטיות ורשימת הערות שנסגרו.
מה יקרה אם תימצא שגיאה בגרסה החדשה?
את מדיניות העדכון בוחרים לפני השחרור. בחוזה הניתן לעדכון הגרסאות מתפרסמות אחת לאחת, והחזרת גרסה היא החזרת החבילה הקודמת בלי לאבד את הנתונים שנצברו. אם החוזה בלתי ניתן לשינוי, את הלוגיקה העסקית מוציאים לשכבה נפרדת שניתן להחליף.
עד כמה מפורט צריך להיות התיעוד של החוזה?
התיעוד של החוזה מתאר את המודולים והקשרים ביניהם, את התפקידים ומטריצת ההרשאות, נקודות כניסה, הליך הוצאת גרסה חדשה וסדר הפעולה בעת תקרית. זה מספיק כדי שהצוות שלכם יתחזק את החוזה בלעדינו, ושמבקר חיצוני יבין אותו במעבר אחד.
נדון במשימה ונחזור עם אומדן ותוכנית
כדי שאומדן העבודה יתבסס על עובדות, אנחנו זקוקים למינימום נתוני פתיחה: תיאור הלוגיקה של החוזה והתפקידים, גישה לקוד הנוכחי או לאב-טיפוס, רשימת התרחישים שאמורים לעבוד, ודרישות לרשת היעד — בדיקות או ראשית.
אם החוזה כבר פרוס, הוסיפו את היסטוריית השינויים ואת המגבלות הידועות: זה מסיר מחצית מהשאלות בנוגע לתאימות ולהעברת מצב.
תוכנית הפריסה מגיעה כמסמך עם שלבים, לוחות זמנים, אחראים ונקודות שבהן נדרשת ההחלטה שלכם. בבלוק נפרד — תחזוקת החוזים לאחר ההשקה וסדר התגובה לתקלות.
השלב הראשון של שיתוף הפעולה כולל:
- ניתוח הלוגיקה של החוזה ובדיקת מודל הרשאות הגישה לפונקציות שלו;
- תיאור סכימת אחסון הנתונים ואומדן עלות הפעולות ברשת;
- תוכנית פריסה: רצף הצעדים מרשת הבדיקות ועד לרשת הראשית;
- אסטרטגיית עדכונים והחזרה לאחור — כיצד החוזה יעבור עריכת לוגיקה;
- מערכת בדיקות אוטומטיות לתרחישים המרכזיים ובדיקות לפני השחרור;
- נוהל תחזוקה: כיצד מועברות הפניות ומי עונה עליהן;
- תיעוד החוזה והוראות לצוות שלכם לעבודה איתו.
תארו את המשימה בצורה חופשית וצרפו את מה שכבר קיים — נחזור עם אומדן העבודה ותוכנית לשלב הראשון.