מדוע פרויקטי העברת תוכנה משעממים יכולים להיות הנשק הסודי שלך

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

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

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

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

1. אבל האם אתה באמת צריך הגירה?

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

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

1. האם העסק (או חווית הלקוח) מושפע לרעה או שהוא יושפע בעתיד אם לא נפתור את הבעיה הזו והאם הצוות מיצה את כל האפשרויות לפתור זאת ללא התחייבות גדולה של פרויקט הגירה גדול? בחר בביקורת ממהנדס בכיר אחר שאינו בצוות שלך ואשר יכול לפעול כסנגור השטן כדי לבדוק את ההיגיון שלך בלחץ. כמה דוגמאות להצדקות יכולות להיות שיפור הזריזות ב-4 חודשים למפתחים עבור כל השקת פיצ'ר, שימוש בערימות טכנולוגיות שונות עבור שירותים שונים כדי לשפר את זמן האחזור של p99 ב-400ms, הסרת צווארי בקבוק בקנה מידה מעבר ל-X TPS וכו'. חפש תמיד חילוקי דעות כדי לשבור את הטיית האישור שלך במצבים כאלה.

   
   

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

   • הצוות שלי החזיק בשתי מערכות נפרדות המשרתות שני סטים שונים של בסיסי לקוחות, וכל השקת תכונה חדשה חייבה את הצוות לבצע שינויים דומים, אך לא מדויקים, במערכות הנפרדות הללו. בסך הכל, השכפול הוביל למאמץ נוסף של מפתח אחד בחודש לכל תכונה. השקנו כ-4 פיצ'רים כאלה מדי שנה, מה שהוביל ל-4 חודשים של מפתחים של מאמץ כפול או מבוזבז. זה היה מתסכל למהנדסים. אחד המהנדסים העלה הצעה לשלב בין שתי המערכות הללו והעריך את המאמץ ב-24 חודשי מפתח. יידרשו לצוות 24 השקות ו-6 שנים (בהנחה ש-4 תכונות יושקו בשנה) עד שהצוות יתחיל לקצור את היתרונות של ההגירה. לא ביצענו את ההעברה ועברנו לגישה חלופית של שימוש בספריות משותפות כדי לצמצם את מאמצי השכפול ב-50%, ובהמשך הוצאנו משימוש את המערכת לאחר 3 שנים לטובת שירות אחר.

     
     

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

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

2. פריסה דרישות פונקציונליות ולא פונקציונליות של מערכת

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

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

• החלטנו להתרחק ממסד נתונים מקומי של SQL עקב קנה מידה של צווארי בקבוק ובעיות תחזוקה. הסיבה לכך היא שהשירות שלנו השתמש במסד נתונים של SQL כמנוע תזמון כדי לעקוב אחר עדכונים הקשורים למלאי. הרצנו כמה שאילתות מורכבות מול מסד הנתונים של SQL בכל שנייה, וזה היה בזבזני. המהנדסים שלנו הציגו עיצוב להחלפת מסד הנתונים של SQL שלנו במסד נתונים של SQL בענן . ההצדקה הייתה ש-SQL בענן היה ניתן להרחבה יותר, אבל מה שעשינו למעשה היה לדחוף את הבעיה שלנו הנובעת מדפוסים גרועים לטכנולוגיית ענן. היינו צריכים לתקן את הדפוס הגרוע במקום לדחוף את הבעיה לטכנולוגיית ענן. מהנדס ראשי כיוון את הגישה שלנו לבנות מערכת מונעת אירועים תוך שימוש בהודעת פאב/תת ותור סטרימינג (למשל, Kafka או AWS Kinesis וכו') שהגדילו כמה סדרי גודל טוב יותר מההצעה המקורית שלנו.

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

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

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

P(A) * P (B) = 0.999 * 0.999 = 99.8% זמינות

יצירת מיקרו-שירותים ממונוליט הובילה להפחתה בזמינות מ-99.9% ל-99.8%.

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

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

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

3. האם לקוחות צריכים לבצע פעולות כלשהן?

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

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

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

4. האם כבר בוצעו הגירות דומות?

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

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

רוב ההגירות הן בדרך כלל באחת משתי הקטגוריות שלהלן או שילוב כלשהו של שתיהן:

1. העברות שירות: ביטול שירות קיים לטובת ארכיטקטורה חדשה אשר עשויה להיות מורכבת משימוש בחלקים מהשירות הנוכחי ושירות חדש או השקת מיקרו-שירותים חדשים להחלפת מערכת קיימת.

   
   

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

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

5. הפעלת מערכות ישנות וחדשות במקביל

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

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

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

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

6. צפה שדברים ישתבשו: האם אתה יכול לחזור לעולם הקודם?

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

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

במקרים שבהם זה לא אפשרי, נקודת ההסתמכות היחידה שלך היא להיות יסודי בשלב 5. (הפעלת מערכות ישנות וחדשות במקביל). לאחר מכן, השקה הדרגתית איטית של המערכת החדשה. אתה יכול להגדיר השקה הדרגתית איטית באמצעות טכניקות כמו העברת אחוז קטן (1% ואחריו 5%, 10%, 25%, 50%, 100%) מהתנועה שתוגש על ידי שירות חדש, או בחירת יד של כמה לקוחות שיוגשו על ידי שירות חדש שאיתם אתה עובד בצמוד במהלך ההעברה וכו'.

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

מַסְקָנָה

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

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