הגדרת פריסה ב-Google Cloud: היכן משתחרר גרסה נשבר
שחרור גרסה נשבר לא בשלב הפיתוח, אלא ברגע העברת השינויים לסביבת העבודה. תמונה טיפוסית: האימג' נבנה באופן מקומי, המיגרציות מורצות ידנית, משתני הסביבה מועתקים מהערות — וכעבור שבוע סביבת הבדיקות והפרודקשן נפרדות עד כדי כך שאותו קוד מתנהג אחרת.
פער בין סביבות לעיתים נדירות נראה מיד: הוא עולה לפני השטח בשחרור הבא, כשהסיבה כבר אבדה בהיסטוריית עריכות של מישהו אחר.
מקור שני לתקלות — סדר השלבים. מיגרציה שמיושמת אחרי עליית הגרסה החדשה נועלת טבלאות, והקונטיינר הישן ממשיך לשרת בקשות עם הסכימה החדשה ומחזיר שגיאות לחלק מהמשתמשים. סיפור נפרד — סודות ופרמטרים שמתקנים ביד בפאנל ולא מתעדים במאגר: בפריסה הבאה הם נדרסים בשקט בערכי ברירת מחדל.
היקר מכול הוא החזרה לאחור. אם הבילד הקודם לא נשמר כארטיפקט משוחזר, החזרה נעשית בניחוש: בונים מחדש מהענף שכבר התקדם קדימה, ומקבלים גרסה שלישית שאיש אינו מכיר. זמן ההשבתה ברגע השחרור נמתח לא לדקות, אלא לשעות.
הגדרת פריסה ב-Google Cloud סוגרת בדיוק את שלושת סוגי הכשל הללו: ההצבה הולכת לפי תרחיש אחד, הסביבות נבנות מתיאור משותף, והגרסה הקודמת נשארת מוכנה לחזרה בשלב אחד.
מה נותן שחרור מנוהל: מהירות, חזרות לאחור, פחות השבתה
שחרור ידני נשען על האדם: הוא זוכר את סדר הפעולות, מתקן ידנית את התצורה בשרת ונשאר זמין בערב. שחרור כזה אורך שעות, וזמן שחרור הגרסה גדל יחד עם מספר השירותים — כל עריכה מחייבת לעבור מחדש את כל השרשרת.
כשהתשתית מתוארת ב-Terraform, וההצבה הולכת בפקודה אחת, אותו שחרור נכנס לדקות ואינו תלוי במי בדיוק מריץ אותו.
חזרה לאחור צפויה מפסיקה להיות פעולה נפרדת. הגרסה הקודמת נשארת זמינה, והחזרת התעבורה אליה אורכת שניות, בלי לפרוס גיבוי ובלי להמתין לשחזור בסיס הנתונים. זה משנה את מחיר הטעות: שחרור כושל מוחזר לאחור לפני שהמשתמשים מספיקים להבחין בו.
מספר סביבות מתוארות בקבוצת חוקים אחת: סביבת הבדיקות, סביבת הטרום-פרודקשן וסביבת העבודה נבדלות בפרמטרים, ולא בעריכות ידניות "רק כאן". השינוי עובר את אותו מסלול בדיקות, ולכן הפער "בבדיקות זה עבד" מפסיק להיות הנורמה ומפסיק לאכול יום שלם של בירור.
עלות ההשבתה נמדדת לא באופן מופשט, אלא בדקות של אי-זמינות ובבקשות שאבדו. כששחרור אינו דורש חלון לילה והפוגות ידניות, אי-הזמינות מתכווצת לזמן החלפת התעבורה, וחלק מהעדכונים עוברים כלל בלי לעצור את השירות.
בסופו של דבר השחרור הופך לחזרתי: אותה תוצאה באותם נתוני קלט, היסטוריית גרסאות ונקודת חזרה ברורה. בהמשך נפרק ממה מורכב תהליך כזה.
אפשרויות פריסה: קונטיינרים, מכונות, אורקסטרטור
בחירת אפשרות האחסון קובעת לא רק איך האפליקציה שורדת עומסי שיא, אלא גם כמה זמן הנדסי מושקע בתפעול. קונטיינרים מנוהלים מסירים מהצוות את תחזוקת השרתים, מכונה וירטואלית ייעודית נותנת שליטה מלאה על הסביבה, ואורקסטרציה נדרשת במקום שיש שירותים רבים והם קשורים ביניהם. להלן — השוואה מעשית של אפשרויות פריסה ב-Google Cloud, שלפיה אנחנו בדרך כלל בוחרים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| קונטיינרים מנוהלים | שירות עם עומס לא אחיד: צניחות בלילה, שיאים ביום. סקיילינג עד אפס, עדכון — בהחלפת אימג' | אין דיסק מקומי קבוע, גישה מוגבלת להגדרות הסביבה, לא מתאים למשימות רקע ארוכות |
| מכונה וירטואלית ייעודית | מונוליט, אפליקציה מורשת, תוכנה ברישוי, דרישות מיוחדות לליבה ולמחסנית הרשת | טלאים, סקיילינג ועדכונים ידניים, משאבים עומדים בטלים בין שיאים |
| אורקסטרציה של קונטיינרים | עשרות שירותים, מדיניות רשת משותפת, דרישות משלכם למתזמן ולבידוד | רף תפעול גבוה: צמתים, מכסות, עדכונים וניטור האשכול — עבודה מתמדת של הצוות |
| פונקציות ללא שרת | אירועים בודדים: וובהוקים, עיבוד קבצים, טריגרים נדירים לפי לוח זמנים | התנעה קרה, מגבלת זמן ריצה, לא מחזיקים עומס קבוע |
בפועל, הסכימה לעיתים נדירות היא אחת: הממשק וה-API עוברים לקונטיינרים מנוהלים, בסיס הנתונים והמעבדים הכבדים נשארים על מכונה ייעודית או בתוך האורקסטרטור. אנחנו מתארים את הגבולות הללו בקוד, כדי שניתן יהיה להרכיב את התצורה מאפס ולשחזר אותה בסביבת בדיקות בלי עריכות ידניות. מכאן נפרק כיצד זה נסגר בהמשך — בבנייה, בסביבות ובחזרות לאחור.
ביקורת תשתית, סכימת סביבות, הגדרה, מסירה
העבודות הולכות מהמצב הנוכחי אל תקנונים שהצוות שלכם מיישם בלעדינו. מתחילים בביקורת תשתית בפרויקט הענן: ספירת משאבים, הרשאות גישה, מקומות אחסון הסודות ופעולות ידניות בשחרור — דווקא הם נשברים ראשונים בעת החלפת האחראי. לא נוגעים בפרודקשן עד שמאושרת סכימת הסביבות.
- ביקורת תשתית. מפת משאבים, תלויות והרשאות, רשימת השלבים הידניים ונקודות הכשל; מסמנים מה עובר לתיאור דקלרטיבי ומה דורש בנייה מחדש.
- סכימת סביבות. מפרידים בין פיתוח, טרום-פרודקשן ופרודקשן: תצורות נפרדות, סודות מבודדים, מכסות משלהם — נעלם סוג השגיאות עם מפתחות ונתונים מהסביבה הלא-נכונה.
- תיאור התשתית כקוד. המשאבים עוברים לתצורה עם מצב באחסון מאובטח ונעילה: עריכות ידניות בקונסולה מפסיקות להיות הנורמה, הסביבה עולה באופן חזרתי.
- הגדרת ההצבה. בניית הארטיפקט, רישום האימג'ים עם מדיניות שמירה, חלוקת התעבורה בין מהדורות השירות, מיגרציות של בסיס הנתונים בשלב נפרד.
- בדיקה לפני שחרור. הרצה בטרום-פרודקשן, תרגול חזרה לאחור למהדורה הקודמת, מדדים והתראות על שגיאות והשהיות — לפני התעבורה החיה.
- מסירת תקנונים. תיעוד לשחרור ולחזרה לאחור, סקירה עם המהנדסים שלכם, ליווי השחרור העצמאי הראשון.
מה נשאר אצל הצוות שלכם לאחר המסירה
אנחנו מוסרים לא "שרת עובד", אלא ערכה מלאה שלפיה הצוות שלכם יכול לפתח ולהרכיב מחדש את הסביבה בלעדינו. התשתית מתוארת דקלרטיבית, ולא נבנתה ביד בקונסולה של Google Cloud: ניתן להקים את הסביבה מאפס ולקבל את אותם שירותים, רשתות והרשאות. להלן — מה בדיוק עובר למאגר שלכם ולוויקי בקבלה.
- תצורה כקוד — תיאור כל הסביבות, השירותים והרשתות בקבצי המאגר עם היסטוריית שינויים. סביבת הבדיקות וסביבת העבודה נבנות מקבוצת תיאורים אחת, פערים נראים בשלב הבדיקה ולא בקרב.
- סכימות תשתית — מפת השירותים, מאזני העומס, התורים, בסיסי הנתונים והקשרים ביניהם, עם סימון אילו רכיבים משתנים יחד. נדרשת כדי שעריכה של רכיב אחד לא תשבור את שכנו.
- מדיניות גישה — תפקידי חשבונות שירות, ההרשאות המינימליות הנדרשות, הפרדה בין הסביבות זו מזו, סדר הנפקת מפתחות והחלפתם.
- תקנון חזרה לאחור — כיצד להחזיר את המהדורה הקודמת של השירות, כמה זה אורך, מי מקבל את ההחלטה, אילו בדיקות מורצות לאחר החזרה.
- תקנון שחזור — סדר צעד-אחר-צעד להקמת הסביבה מאפס: מה נפרס ראשון, היכן נמצאים הגיבויים, כיצד נבדקת שלמות הנתונים לאחר מכן.
- הוראות שחרור — רצף הבנייה וההצבה, משתני הסביבה, עבודה עם סודות, מה עושים בעת כישלון הבדיקות לפני הפרסום.
- נראות — רשימת המדדים והיומנים, ספי ההתראות והמסלולים שאליהם הם נשלחים לתורן.
כל זה נמצא במאגרים ובחשבונות שלכם, הגישות הועברו לצוות שלכם. המהנדסים שלנו נשארים זמינים, אך המשך העבודה אינו דורש את השתתפותנו בפעולות היומיומיות.
קייס: הצבה ידנית הפכה לשחרור צפוי
הלקוח הגיע עם הצבה ידנית: אפליקציה על מכונות וירטואליות, הוראות בוויקי, שחרור ישירות על השרת — העתקת קבצים, בנייה "במקום", תיקון התצורה ביד.
שחרור אחד ארך 40–50 דקות של זמן הנדסי, וכל הצבה חמישית הסתיימה באירוע חריג: פרמטר סביבה נשכח, פער בין גרסאות התלויות, פורט שלא נסגר.
היקר מכול היה השיקום: חיפשו מה בדיוק שינו, השוו את התצורה למצב הקודם והרכיבו את הגרסה הקודמת מחדש. מדדים לפני — 45 דקות לשחרור, 20% מההצבות עם חזרה לאחור, זמן שיקום ממוצע 2.5 שעות.
מה השתנה
הפלטפורמה הורכבה מחדש על Google Cloud: הבנייה הועברה לצינור, הסביבות תוארו דקלרטיבית, המצב — לשירות מנוהל, הסודות — לאחסון. ההצבה הולכת למופע חדש, התעבורה מוחלפת רק לאחר בדיקת מוכנות, והגרסה הקודמת נשארת ברישום כנקודת חזרה מוכנה.
מדדים אחרי: שחרור — 6 דקות בלי השתתפות מהנדס, תקלות — הצבה אחת מתוך עשרים, חזרה לאחור לגרסה הקודמת — 90 שניות, שיקום השירות — 4 דקות במקום 2.5 שעות.
אפקט נפרד — תדירות השחרורים. קודם צברו שינויים במשך שבועות כדי לא להסתכן; כעת משחררים בהתאם למוכנות, וכל שקטן יותר הפער בין הגרסאות, כך פוחתות התקלות ומהיר יותר הבירור אם משהו השתבש.
מה לעשות אם הפרויקט כבר נפרס ידנית?
אין צורך לכתוב מחדש את האפליקציה — אנחנו מתארים ומאוטמטים את מה שכבר עובד. מיגרציה של הצבה ידנית הולכת בשלבים ולפי שירותים, ולא בהחלפה אחת: סכימת השחרור הישנה נשארת עובדת עד שהחדשה הוכיחה אמינות על חלקים בודדים.
הצעד הראשון — ספירה. מתעדים את המצב האמיתי: אילו שירותים פועלים, מהיכן מגיעים האימג'ים, היכן נמצאים משתני הסביבה והסודות, אילו כללי גישה חשופים החוצה. הסיכון העיקרי כאן אינו בקוד, אלא בפער בין התיעוד לסביבת העבודה: חלק מההגדרות בדרך כלל הוזנו ביד ואינן רשומות בשום מקום.
בהמשך מתארים את התשתית כקוד ב-Google Cloud, החל מהפריפריה — רשת, הרשאות חשבונות שירות, כללי גישה, רישום האימג'ים. יישום התיאורים הללו אינו מפעיל מחדש קונטיינרים פעילים, ולכן המוצר ממשיך לשרת בקשות בלי השבתה.
את הבנייה והפריסה האוטומטית מעבירים אחרונים. תחילה התהליך החדש פורס גרסה בסביבה נפרדת, הבדיקות הולכות עליה, ורק לאחר מכן התעבורה מועברת במנות מהמהדורה הנוכחית, עם חזרה לאחור לפקודה אחת לקודמת. את בסיס הנתונים לא יוצרים מחדש: מיגרציות הסכימה מבוצעות בשלב נפרד והן הפיכות.
סדר כזה מסיר בהדרגה עריכות ידניות על השרתים ובלי לכתוב מחדש את הפרויקט.
ספקות טכניים נפוצים לפני תחילת העבודות
הספקות בשלב הזה כמעט תמיד אותם: היכן יימצאו הסודות, מי יקבל גישה לפרודקשן, האם באמת אפשר להחזיר גרסה קודמת במהירות והאם יהיה צורך לכתוב מחדש את הפרויקט. להלן — תשובות הנדסיות בלי מילים כלליות.
היכן יאוחסנו הסודות ומפתחות הגישה?
סיסמאות, טוקנים ותעודות חיים במנהל הסודות של Google Cloud, ובמאגר נשארות רק הפניות אליהם. הערכים מוזרקים ברגע יישום התצורה, ולכן לא נשארות עותקים של מפתחות במכונות המהנדסים. החלפה — היא החלפת ערך אחד, בלי עריכות בקוד ובלי בנייה מחדש של אימג'ים.
כיצד מופרדות ההרשאות והתפקידים?
גישה ניתנת לפי עקרון המינימום הנדרש: חשבון השירות של האפליקציה יודע לעשות רק את מה שהוא צריך לעבודתו, וסביבת הבדיקות וסביבת העבודה מבודדות. המהנדס מקבל תפקיד לסביבה ספציפית ולמשך המשימה. כל שינויי התצורה נכנסים ליומן הביקורת — נראה מי, מה ומתי שינה.
כמה מהר מוחזרת גרסה מקולקלת לאחור?
כל שחרור — אימג' בלתי-משתנה עם תג נפרד, ולכן חזרה לגרסה הקודמת היא החלפת תעבורה למהדורה הקודמת, ולא בנייה מחדש. אורכת פחות מדקה. מיגרציות הסכימה נכתבות תואמות לאחור, כדי שהגרסה הקודמת של האפליקציה תמשיך לעבוד עם בסיס הנתונים החדש.
האם זה תואם למחסנית הנוכחית?
אין צורך להעביר את הפרויקט בשלמותו: בדרך כלל מספיק לארוז את הבנייה וההרצה בקונטיינר, והפריימוורק, בסיס הנתונים והתורים נשארים כשהיו. שירותים שכבר פועלים על מכונות וירטואליות ממשיכים לפעול. את הניתוב מגדירים ברמת מאזן העומס ומחליפים בהדרגה.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
תארו כיצד שחרור השינויים עובד כעת: במה נבנים הארטיפקטים, מי מציב לסביבות, היכן נמצאות התצורות והסודות, כמה זמן אורכת חזרה לאחור לשחרור הקודם. זה מספיק כדי להבין את צווארי הבקבוק — שלבים ידניים, פערים בין סביבות, היעדר היסטוריית הצבות.
בתגובה נשלח תוכנית הטמעה עם שלבים, היקף העבודות וסדר ההתקשרות. בכל סעיף נציין מה אנחנו עושים ומה נשאר בצד שלכם — כדי שהערכת העבודה תהיה ניתנת לבדיקה, ולא "מפתח-עד-מפתח לפי סיכום".
- ניתוח סכימת השחרור הנוכחית: בנייה, סביבות, הרשאות, נקודות התערבות ידנית.
- הערכת עבודות לפי שלבים עם גבולות אחריות ותלויות בצוות שלכם.
- תוכנית הטמעה: סדר העברת הסביבות, נקודות חזרה לאחור, חלונות לשינויים.
- תיאור התשתית כקוד: תצורות, משתני סביבה, כללי סקיילינג.
- סדר ההתקשרות: נקודת קשר אחת, דיווח לפי שלבים, ערוץ לשאלות דחופות.
- קריטריוני קבלה בכל צעד: מה נחשב להושלם וכיצד נבדוק זאת.
- תקנון תמיכה בהצבה לאחר העלייה: כיצד משחררים שינויים, כיצד מטפלים בתקלות.
תארו את המשימה כפי שהיא — נחזור עם הערכה ותוכנית עבודה.
