פיתוח כלי Go CLI לאוטומציה של משימות DevOps

כלי CLI ב-Go במקום פעולות DevOps ידניות

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

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

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

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

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

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

האפקט של הכלים: בנייה, פריסה, חזרה לאחור

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

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

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

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

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

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

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

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

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

כיצד לבחור פורמט

סדר העבודה: מניתוח משימות ועד מסירה לצוות

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

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

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

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

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

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

מקרה בוחן: איך הפריסה הפסיקה להיות תלויה במהנדס אחד

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

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

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

מדדים לפני ואחרי

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

במה שונה אוטומציה חד־פעמית מכלי מתוחזק?

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

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

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

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

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

שאלות טכניות נפוצות לפני ההתחלה

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

כיצד מוגנות פעולות הרסניות?

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

האם הכלי ישתלב עם הסביבה הקיימת?

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

למי שייך קוד המקור?

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

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

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

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

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