הגישה של Google Cloud לשינויים

מיליארדי משתמשים מתקשרים עם המוצרים והשירותים של Google מדי שנה. מוצרים מרכזיים כמו חיפוש Google,‏ Gmail, מפות Google,‏ YouTube,‏ Chrome ועכשיו גםGoogle Cloudמשולבים בצורה חלקה כל כך בחיי היומיום, שהם עוזרים להגדיר את חוויית המאה ה-21. ההשפעה הזו על פני כדור הארץ היא תוצאה של האיכות המוכחת של המוצרים שלנו והציפייה ש-Google תמיד תהיה זמינה.

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

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

המחזור של שינוי ב Google Cloud

Google Cloud צוותי המוצר חולקים חלק גדול מתהליך הניהול ומערכות הכלים עם צוותי הנדסה אחרים ב-Google. אנחנו מיישמים גישה סטנדרטית לפיתוח תוכנה לניהול שינויים, שבה יש עדיפות לאינטגרציה רציפה (CI) ולפיתוח רציף (CD). ‫CI כולל הצעות, בדיקות ושליחת שינויים בתדירות גבוהה, לעיתים מספר פעמים ביום לכל מוצר או שירות נתון. פיתוח רציף הוא הרחבה של שילוב רציף, שבו מהנדסים מכינים באופן רציף גרסאות מועמדות להפצה על סמך התמונה היציבה העדכנית ביותר של בסיס קוד.

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

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

הבטיחות מוטמעת מהיסוד

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

דיאגרמה מפורטת של השלבים שקשורים לשלב העיצוב.

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

בטוח לשימוש כמו שהוא

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

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

דיאגרמה מפורטת של השלבים שקשורים לשלב הפיתוח.

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

סטנדרטים של קידוד מבטיחים שינויים באיכות גבוהה

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

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

Google Cloud שירותים שמבוססים על תוכנות קוד פתוח באיכות גבוהה עשויים להשתמש במאגר נוסף – בדרך כלל Git – בנוסף למאגר המשותף, כדי להשתמש בהסתעפות לניהול תוכנות הקוד הפתוח.

הערה לגבי אימון

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

הקדמת בדיקות משפרת את המהירות בצורה בטוחה

העיקרון Shift left (הזזה שמאלה) מעביר את הבדיקות והאימות לשלב מוקדם יותר בתהליך הפיתוח. העיקרון הזה מבוסס על התצפית שלנו שלפיה העלויות עולות באופן משמעותי ככל שאנחנו מוצאים ותיקנו באג בשלב מאוחר יותר בתהליך ההפצה. במקרה קיצוני, נניח שלקוח מוצא באג בייצור. יכול להיות שהבאג הזה ישפיע לרעה על עומסי העבודה והאפליקציות של הלקוח, ויכול להיות שהלקוח יצטרך לעבור את התהליך של Cloud Customer Care לפני שצוות ההנדסה הרלוונטי יוכל לטפל בבאג. אם המהנדס שהוקצה לטיפול בבעיה הוא אדם אחר מזה שהכניס במקור את השינוי שהכיל את הבאג, המהנדס החדש יצטרך להכיר את שינויי הקוד, וסביר להניח שזה יגדיל את הזמן שיידרש לשחזור הבאג ובסופו של דבר לתיקון שלו. התהליך הזה דורש הרבה זמן מהלקוחות ומהתמיכה של Google Cloud, ומהנדסים צריכים להפסיק את העבודה שלהם כדי לתקן משהו.

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

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

בדיקות אוטומטיות לפני שליחת קוד (presubmit) מאכפות תקני תכנות

בדיקות לפני שליחה הן בדיקות שמופעלות לפני ששולחים שינויים בספרייה מסוימת. בדיקות לפני שליחה יכולות להיות בדיקות יחידה ובדיקות שילוב שספציפיות לשינוי מסוים, או בדיקות כלליות (לדוגמה, ניתוח סטטי ודינמי) שמופעלות לכל שינוי. בעבר, בדיקות לפני שליחה הופעלו כשלב האחרון לפני שמישהו שלח שינוי לבסיס קוד. כיום, בין היתר בגלל העיקרון של Shift Left וההטמעה שלנו של CI, אנחנו מריצים בדיקות לפני שליחה באופן רציף בזמן שמהנדס מבצע שינויים בקוד בסביבת פיתוח ולפני מיזוג השינויים לתוך המאגר המשותף שלנו. מהנדס יכול גם להריץ באופן ידני חבילת בדיקות לפני שליחה בלחיצה אחת בממשק המשתמש של הפיתוח, וכל בדיקה לפני שליחה מורצת באופן אוטומטי עבור כל רשימת שינויים לפני בדיקת קוד על ידי אדם.

חבילת מקרים לבדיקה לפני השליחה כוללת בדרך כלל בדיקות יחידה, בדיקות fuzz (פירצה), בדיקות אינטגרציה הרמטיות וניתוח קוד סטטי ודינמי. במקרה של שינויים בספריות ליבה או בקוד שנמצא בשימוש נרחב ב-Google, המפתחים מריצים בדיקה גלובלית לפני שליחת הקוד. בדיקה גלובלית לפני שליחה בודקת את השינוי מול כל בסיס הקוד של Google, וכך מצמצמת את הסיכון לכך שהשינוי המוצע ישפיע באופן שלילי על פרויקטים או מערכות אחרים.

בדיקות יחידה ובדיקות שילוב

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

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

בדיקת fuzz

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

ניתוח סטטי

כלים לניתוח סטטי ממלאים תפקיד קריטי בשמירה על איכות הקוד בתהליכי העבודה שלנו לפיתוח. הניתוח הסטטי התפתח מאוד מאז הימים הראשונים שלו, שבהם הוא שימש לניתוח קוד (linting) באמצעות ביטויים רגולריים כדי לזהות דפוסי קוד בעייתיים ב-C++. כיום, ניתוח סטטי מכסה את כל שפות התכנות Google Cloud בסביבת הייצור ומאתר דפוסי קוד שגויים, לא יעילים או שיצאו משימוש.

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

ניתוח דינמי

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

  • ‫AddressSanitizer: מזהה שגיאות זיכרון כמו buffer overflows ו-use-after-free
  • ‫ThreadSanitizer‏ (C++‎,‏ Go): מוצא באגים שקשורים למירוצי נתונים ולשרשורים
  • ‫MemorySanitizer: מגלה שימוש בזיכרון שלא אותחל

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

בדיקות קוד אנושיות מאמתות שינויים ותוצאות בדיקה

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

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

בשלב הזה בתהליך הפיתוח, מתערב אדם נוסף. בודק אחד או יותר בוחנים בקפידה את רשימת השינויים כדי לוודא שהיא נכונה וברורה, בעזרת הבדיקות המצורפות והתוצאות של בדיקות לפני שליחה. לכל ספריית קוד יש קבוצה של בודקי קוד ייעודיים שאחראים לוודא את האיכות של קבוצת המשנה הזו של ה-codebase, והאישור שלהם נדרש כדי לבצע שינויים בספרייה הזו. הבודקים והמהנדסים משתפים פעולה כדי לזהות ולפתור בעיות שעלולות להתעורר בשינוי קוד מוצע. אם רשימת השינויים עומדת בתקנים שלנו, בודק מאשר אותה (בקיצור: LGTM, שפירושו 'נראה לי טוב'). אבל אם המהנדס עדיין בתהליך הכשרה בשפת התכנות שבה נעשה שימוש, הוא צריך אישור נוסף ממומחה שקיבל ציון קריאות בשפת התכנות.

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

מתן אישור לשחרור בטוח

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

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

דיאגרמה מפורטת של השלבים שקשורים לשלב ההסמכה.

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

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

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

השקות בטוחות

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

שינוי ההפצה והפיקוח

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

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

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

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

בתרשים הבא מוצגת דוגמה לתהליך עבודה שממחיש את הלוגיקה של השקת מוצרים ושירותים אזוריים ב- Google Cloud :

דיאגרמה מפורטת של השלבים שקורים בשלב ההשקה.

Google Cloud תהליך ההשקה משתמש בשירות ניתוח קנרי (CAS) כדי לבצע אוטומטית בדיקות A/B לאורך משך ההשקה. חלק מהרפליקות הופכות ל-canaries (כלומר, פריסה חלקית ומוגבלת בזמן של שינוי בשירות), והרפליקות הנותרות מרכיבות את קבוצת הבקרה שלא כוללת את השינוי. לכל שלב בתהליך ההשקה יש זמן המתנה כדי לזהות בעיות שמתפתחות לאט לפני שמתקדמים לשלב הבא. כך אפשר לוודא שכל הפונקציות של השירות נבדקות היטב ושהמערכת לניתוח אבטחה בענן (CAS) מזהה אנומליות פוטנציאליות. זמן ההרצה מוגדר בקפידה כדי ליצור איזון בין זיהוי בעיות שמתפתחות לאט לבין מהירות הפיתוח. Google Cloud ההשקות מתבצעות בדרך כלל תוך שבוע.

בתרשים הזה מוצגת סקירה כללית של תהליך העבודה עם CAS:

דיאגרמה של השלבים בתהליך העבודה של CAS.

תהליך העבודה מתחיל בכך שכלי ההשקה פורס את השינוי בעותק הקנרי. לאחר מכן, כלי ההשקה מבקש פסיקה מ-CAS. מערכת CAS מעריכה את העותק המשוכפל של קנרי בהשוואה לקבוצת הבקרה ומחזירה את התוצאה PASS או FAIL. אם אחד מאותות הבריאות נכשל, נוצרת התראה לבעלי השירות והשלב הפעיל של ההשקה מושהה או מבוטל. אם השינוי גורם לשיבוש אצל לקוחות חיצוניים, מוכרז על תקרית חיצונית והלקוחות המושפעים מקבלים הודעה באמצעות השירות Personalized Service Health. אירועים גם מפעילים בדיקה פנימית. הפילוסופיה של Google לגבי ניתוח לאחר מעשה מבטיחה שייקבעו הפעולות המתקנות הנכונות ושהן ייושמו כדי למזער את הסיכוי לכשלים דומים בעתיד.

מעקב אחר אותות ובטיחות אחרי ההשקה

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

המעקב אחרי ההשקה מתבסס על אותה קבוצה של אותות מעקב שבה אנחנו משתמשים לניתוחי A/B אוטומטיים במהלך חלון ההשקה. הפילוסופיה של Google Cloud מעקב והתראות משלבת שני סוגים של מעקב: אינטרוספקטיבי (נקרא גם 'מעקב מתוך האפליקציה') וסינתטי (נקרא גם 'מעקב מחוץ לאפליקציה'). בניטור רטרוספקטיבי נעשה שימוש במדדים כמו ניצול CPU, ניצול זיכרון ונתונים פנימיים אחרים של השירות. מעקב סינתטי בודק את התנהגות המערכת מנקודת המבט של הלקוח, ועוקב אחרי שיעורי השגיאות בשירותים ותגובות לתנועה סינתטית משירותי בדיקה. המעקב הסינתטי מתמקד בסימפטומים ומזהה בעיות פעילות, בעוד שהמעקב הרטרוספקטיבי מאפשר לנו לאבחן בעיות מאומתות, ובמקרים מסוימים לזהות בעיות קרובות.

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

הגנה על שרשרת האספקה של תוכנות

בכל פעם ש Google Cloud צוותים מבצעים שינויים, אנחנו משתמשים בבדיקת אבטחה שנקראת Binary Authorization for Borg (‏BAB) כדי להגן על שרשרת אספקת התוכנות שלנו ועל לקוחות Cloud מפני סיכוני פנים. בדיקת BAB מתחילה בשלב של סקר קוד ויוצרת נתיב ביקורת של הקוד וההגדרות שנפרסו בסביבת הייצור. כדי לשמור על תקינות הייצור, BAB מאפשר רק שינויים שעומדים בקריטריונים הבאים:

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

אם אתם רוצים להחיל חלק מהמושגים האלה על מחזור החיים של פיתוח התוכנה שלכם, הוספנו מושגים מרכזיים בנושא BAB למפרט הפתוח Supply-chain Levels for Software Artifacts (SLSA). ‫SLSA משמשת כמסגרת אבטחה לפיתוח ולהרצה של קוד בסביבות ייצור.

סיכום

‫Google Cloud builds on the decades of Google's investment in development excellence. התפיסות של תקינות הקוד ותקינות הייצור הן עקרונות תרבותיים שמושרשים בכל צוותי ההנדסה ב-Google. תהליך בדיקת העיצוב שלנו מבטיח שנקדיש מחשבה מוקדמת להשלכות על הקוד ועל תקינות הייצור. תהליך הפיתוח שלנו מבוסס על העיקרון של Shift Left (הזזה שמאלה) ועל בדיקות מקיפות, כדי להבטיח שהרעיונות העיצוביים יוטמעו בצורה בטוחה ונכונה. תהליך ההסמכה שלנו מרחיב את הבדיקות כך שיכללו שילובים בקנה מידה גדול ותלות חיצונית. לבסוף, פלטפורמת ההשקה שלנו מאפשרת לנו לבנות בהדרגה את הביטחון ששינוי מסוים מתנהג בפועל כמו שציפינו. הגישה שלנו, שמתחילה בשלב הרעיון ומסתיימת בשלב הייצור, מאפשרת לנו לעמוד בציפיות הלקוחותGoogle Cloud לגבי מהירות הפיתוח והאמינות.

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: