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

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

מאת: אביתר מוצפי ועומר דורון

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

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

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

אז מה זה בכלל אומר לשדרג framework?

במקרה של אפליקציה עם web application שיש לו client side ו-server side – מדובר על שדרוג של ה-server side application. מבחינה טכנולוגית המצב שלנו התבסס על מונולית, גרסה גדולה, עם המון קוד, גרסה שכבר רצה הרבה שנים באופן ספציפי בטכנולוגיה שנקראת Ruby on Rails. כש-Ruby זו שפת תכנות, Rails היא ה-framework, כלומר, המסגרת מעל שמביאה את כל היכולות של ה-web application. בנוסף לכך, micro services, שכתובים בשפת Node JS. כאן נתמקד בסיפור שדרוג ה-framework של Rails בתוך המונולית. השדרוג נעשה על ידי שלושה אנשים ונמשך כחודשיים.

איך לא עושים תאונה? סיכונים ופועלות נגדיות

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

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

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

הכל מתחיל בתכנון

לגרום לסביבה לעבוד – להוציא את המקסימום מהקיים לפני החדש. על מנת שהסביבה תעבוד, לפעמים חייבים לשדרג את חלק מהתלויות (dependencies), במקרה של ruby on rails את ה-gems שהם חלק מחבילת הקוד בruby, כדאי לשדרג רק את התלויות שחייבים לעדכן כדי שהסביבה תעבוד. החוכמה הייתה למצוא את הגרסה הכי דומה לגרסה המקורית של כל gem, שעובדת עם הגרסה החדשה ולעבוד לפי עקרון מנחה של ביצוע כל שדרוג אפשרי בגרסה הישנה, ואז להביא למצב שהשינוי לגרסה החדשה הוא יותר קטן. ברגע שהפער בין השינויים בגרסה הישנה והחדשה קטן יותר – גם הסיכון קטן וזה מצב מצוין. למשל, אם אפשר לקחת גרסה של package שעובדת גם בגרסה הישנה של rails וגם בגרסה החדשה, צריך לעדכן אותו בגרסה הישנה, ואז השינוי במעבר לגרסה החדשה יורד למינימום.

לעקוב אחרי מדריכי השדרוג – חשוב לעקוב אחרי המדריך ולגרום לכל הסביבה לעבוד במחשב הלוקלי.

טסטים – לנגן בקשות לפי הסדר – אחד הכלים החשובים ביותר להפחתת סיכונים היה עבורנו הטסטים שפיתחנו. בשלב הראשון, אם נסתכל על דוגמה ברמה הכי בסיסית, לעשות log in, לשנות סטטוס, לשכפל, למחוק. עכשיו כשהבקשות שמורות בקובץ בצד, עשינו שימוש ב-request replayer שמושך את כל הבקשות ומנגן אותן לפי הסדר. כשמגיעה בקשה, מנגנים אותה ועושים לה משלוח כפול: פעם אחת ל-local host עם port מסוים ופעם שנייה שולחים אותה ל-local host עם port אחר. כך אנו מקבלים מצב שעל המחשב rails מותקן פעמיים – פעם אחת עם הגרסה הישנה, פעם אחת עם החדשה. אחרי כל כמה בקשות עצרנו, וכתבנו script שמייצא את כל התוכן מה-database ומשווה אותו ממש תו-תו.

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

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

כולם ל-framework החדש, אבל לא בבת אחת  – המתודולוגיה שלנו הייתה לשחרר את הגרסה החדשה רק לכמה לקוחות בקבוצות יחסית קטנות, כדי לבדוק שהכל עובר חלק, ורק אז לעבור לקבוצה הבאה של הלקוחות. גם אחרי שכל הלקוחות הועברו, הגרסה הישנה נשארת זמינה לעוד כמה ימים. במצב הזה כל ה-R&D עובדים בגרסה החדשה, ה-deployments הם רק בגרסה החדשה והגרסה הישנה מתוחזקת למקרה שיש בעיה.

ועוד כמה טיפים לדרך

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

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

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

כמו להחליף גלגל בזמן נסיעה

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

אביתר מוצפי הוא Senior Full Stack Lead, ועומר דורון הוא Staff Software Engineer ב-monday.com

כתב אורח

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

הגב

4 תגובות על "להחליף גלגל תוך כדי נסיעה: איך שידרגנו פלטפורמה בלי שמאות אלפי המשתמשים הרגישו?"

avatar
Photo and Image Files
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
Tabooleist
Guest

פעם ראשונה שאני קורא באותו מאמר את המשפטים “שיא הטכנולוגיה” ואז “RoR”. בהצלחה בלהיות בחזית של הפרונט.

נועם
Guest

מאמר יפה.

אריק
Guest

שדרוג ממונוליט RoR למונוליט RoR עם גרסה חדשה יותר. כמו לשדרג מיונדאי 2004 ליונדאי 2005.

אור
Guest

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

wpDiscuz

תגיות לכתבה: