שירותים מדור קודם בתשתית שלך

שלום! שמי פאשה צ'רניאק, אני מפתח מוביל ב-QIWI, והיום אני רוצה לדבר על הבלתי נמנע. על מורשת.

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

לפני שנעבור לאופן שבו אנו ב-QIWI עובדים עם שירותי Legacy שלנו, אספר לכם כיצד הכנסנו סדר בשירותים בארנק. כבר שנתיים שאני אחראי על הביצועים שלו. אם יש בעיה, תמיד מתקשרים אליי קודם. בדרך כלל אין לי את החוצפה להתקשר למישהו אחר בשעה 11:XNUMX, אז הייתי צריך לשבת ולהבין את כל השירותים בדומיין שלנו.

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

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

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

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

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

איך זה קורה

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

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

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

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

מאיפה מתחילים?

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

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

מה לעשות

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

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

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

כתוצאה מכך, אני רוצה להמציא תוכנית מה לעשות עם שירותי Legacy.

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

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

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

מה אתה עושה עם המורשת שלך?

• 31.5%אני משכתב מאפס, זה יותר נכון 12

• 52.6%כמעט כמוך 20

• 10.5%אין לנו מורשת, אנחנו מעולים4

• 5.2%אני אכתוב בתגובות2

38 משתמשים הצביעו. 20 משתמשים נמנעו.

מקור: www.habr.com