סיפור השקה שהשפיע על הכל

אויבי המציאות לפי 12f-2

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

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

רקע + איזו פונקציונליות זו?

אנחנו בונים פלטפורמת ענן פתרונות ענן של Mail.ru (MCS), שם אני עובד כמנהל טכני. ועכשיו הגיע הזמן להוסיף את IAM (ניהול זהות וגישה) לפלטפורמה שלנו, המספקת ניהול אחיד של כל חשבונות המשתמש, המשתמשים, הסיסמאות, התפקידים, השירותים ועוד. מדוע זה נחוץ בענן זו שאלה מתבקשת: כל מידע המשתמש מאוחסן בו.

בדרך כלל דברים כאלה מתחילים להיבנות ממש בתחילת כל פרויקט. אבל מבחינה היסטורית הדברים היו קצת שונים ב-MCS. MCS נבנה בשני חלקים:

• Openstack עם מודול הרשאות Keystone משלו,
• Hotbox (אחסון S3) מבוסס על פרויקט Mail.ru Cloud,

שסביבם הופיעו אז שירותים חדשים.

בעיקרו של דבר, אלה היו שני סוגים שונים של הרשאות. בנוסף, השתמשנו בכמה פיתוחים נפרדים של Mail.ru, למשל, אחסון סיסמאות כללי של Mail.ru, כמו גם מחבר openid שנכתב בעצמו, שבזכותו סופק SSO (הרשאת מקצה לקצה) בחלונית Horizon של מכונות וירטואליות (ממשק משתמש מקורי של OpenStack).

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

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

מה אנחנו הולכים לגלגל?

בניסוח גס מאוד, תוך כ-4 חודשים הכנו את הדברים הבאים:

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

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

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

אסטרטגיית השקה

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

סטייה: מהי השקה?

<זהירות, פילוסופיה>

כל מומחה IT יכול לענות בקלות מהי השקה. אתה מתקין CI/CD, והכל נשלח אוטומטית לחנות. 🙂

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

והתמונה כולה היא כזו. ההשקה מורכבת מארבעה היבטים עיקריים:

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

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

מערכה 1..נ, הכנה לשחרור

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

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

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

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

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

וכך…

המערכה האחרונה, לפני היציאה

... הגיע הזמן להתגלגל.

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

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

1. להשפיע (הקדושה לנו, היקרה ביותר) על תשתית המשתמשים,
2. פונקציונליות: השימוש בשירות שלנו לאחר ההשקה צריך להיות כמו לפניו.

מתגלגל החוצה

שני רול, 8 אל תפריע

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

• ההפעלה עצמה אורכת כ-3 שעות.
• שעתיים לבדיקה.
• שעתיים - שמור לביטול אפשרי של שינויים.

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

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

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

כרוניקה של אירועים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

07:00. בעיות בעומס API
מתברר שתכננו מעט את העומס ב-API שלנו ובדקנו את העומס הזה, שלא הצליח לזהות את הבעיה. כתוצאה מכך, ≈5% מהבקשות נכשלות. בואו נתגייס ונחפש את הסיבה.

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

08:00. תקן API
פרסמנו תיקון לעומס, התקלות נעלמו. אנחנו מתחילים ללכת הביתה.

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

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

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

בסך הכל

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

במהלך ההשקה:

• שדים חדשים ושונים - 5 חלקים, מחליפים 2 מונוליטים;
• שינויים בתוך מסדי הנתונים - כל 6 מסדי הנתונים שלנו עם נתוני משתמשים הושפעו, הורדות בוצעו משלושה מסדי נתונים ישנים לאחד חדש;
• חזית שעוצבה מחדש לחלוטין;
• כמות הקוד שהורד - 33 אלף שורות קוד חדש, ≈ 3 אלף שורות קוד בבדיקות, ≈ 5 אלף שורות קוד הגירה;
• כל הנתונים שלמים, אף מכונה וירטואלית של לקוח אחד לא נפגעה. 🙂

שיטות עבודה טובות להשקה טובה

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

1. הדבר הראשון שעליך לעשות הוא להבין כיצד ההשקה יכולה או תשפיע על המשתמשים. האם תהיה השבתה? אם כן, מה זמן ההשבתה? איך זה ישפיע על המשתמשים? מהם התרחישים הטובים והרע האפשריים? ולכסות את הסיכונים.
2. תכננו הכל. בכל שלב, עליך להבין את כל ההיבטים של השקה:
   • מסירת קוד;
   • החזרת קוד לאחור;
   • זמן כל פעולה;
   • פונקציונליות מושפעת.
3. שחק דרך התרחישים עד שכל שלבי ההפצה, כמו גם הסיכונים בכל אחד מהם, הופכים ברורים. אם יש לך ספק, אתה יכול לקחת הפסקה ולבחון את השלב המפוקפק בנפרד.
4. ניתן וצריך לשפר כל שלב אם הוא עוזר למשתמשים שלנו. לדוגמה, זה יקטין את זמן ההשבתה או יסיר כמה סיכונים.
5. בדיקת החזרה היא הרבה יותר חשובה מבדיקת מסירת קוד. יש לבדוק שבעקבות החזרה המערכת תחזור למצבה המקורי ולאשר זאת בבדיקות.
6. כל מה שאפשר לעשות אוטומטי צריך להיות אוטומטי. כל מה שלא ניתן לאוטומטי צריך להיות כתוב מראש על דף צ'יטים.
7. רשום את קריטריון ההצלחה. איזו פונקציונליות צריכה להיות זמינה ובאיזה שעה? אם זה לא קורה, הפעל תוכנית החזרה.
8. והכי חשוב - אנשים. כל אחד צריך להיות מודע למה שהוא עושה, למה ומה תלוי בפעולות שלו בתהליך ההפעלה.

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

מקור: www.habr.com