הגישה של 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 מתבצע במונוריפו, מאגר הקוד המשולב הגדול בעולם. המונו-רפו מכיל מיליוני קובצי מקור, מיליארדי שורות קוד והיסטוריה של מאות מיליוני קומיטים שנקראים רשימות שינויים. הוא ממשיך לגדול במהירות, ונוספות אליו עשרות אלפי רשימות שינויים חדשות בכל יום עבודה. היתרונות העיקריים של מונוריפו הם שהוא מאפשר שימוש חוזר בקוד, מקל על ניהול התלות ואוכף תהליכי עבודה עקביים למפתחים במוצרים ובשירותים שונים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת fuzz

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

ניתוח סטטי

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

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

מחברים:

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