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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדיקות אוטומטיות לפני שליחה אוכפות תקני תכנות

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

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

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

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

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

בדיקת fuzz

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

ניתוח סטטי

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

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

ניתוח דינמי

ניתוח סטטי מתמקד בזיהוי דפוסי קוד מוכרים שיכולים לגרום לבעיות, אבל ניתוח דינמי מתבסס על גישה שונה. התהליך כולל קומפילציה והרצה של קוד כדי לגלות בעיות שצצות רק במהלך ההרצה, כמו הפרות של זיכרון ותנאי מירוץ. ל-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 המוצרים הם אזוריים או של תחום מוגדר. המשמעות היא שמוצר אזורי שפועל באזור א' הוא בלתי תלוי באותו מוצר שפועל באזור ב'. באופן דומה, מוצר של תחום מוגדר שפועל בתחום C באזור A הוא בלתי תלוי באותו מוצר של תחום מוגדר שפועל בתחום D באזור A. הארכיטקטורה הזו מצמצמת את הסיכון להפסקת שירות שמשפיעה על אזורים אחרים או על אזורים אחרים באותו אזור. שירותים מסוימים, כמו IAM אוGoogle Cloud Console, מספקים שכבה עקבית ברמה הגלובלית שמשתרעת על כל האזורים, ולכן אנחנו קוראים להם שירותים גלובליים. שירותים גלובליים משוכפלים באזורים שונים, כדי למנוע נקודות כשל בודדות ולצמצם את זמן האחזור. פלטפורמת ההשקה המשותפת של Google Cloud יודעת אם שירות הוא אזורי, אזורי או גלובלי, ומבצעת את השינויים בהתאם.

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

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

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

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

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

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

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

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

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

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

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

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

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

בכל פעם שצוותים מבצעים שינויים, אנחנו משתמשים בבדיקת אבטחה שנקראת Binary Authorization for Borg (‏BAB) כדי להגן על שרשרת אספקת התוכנות שלנו ועל לקוחות Cloud מפני סיכוני פנים. Google 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

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

מחברים:

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