שירותים יתומים: החיסרון של ארכיטקטורת שירות (מיקרו).

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

מתחת לחיתוך יש גרסת טקסט של הדו"ח.

שלום עמיתים! שמי אנדריי, אני עומד בראש התפעול ב-Banki.ru.

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

יתרונות של שירותים

אעבור במהירות על היתרונות של השירותים.

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

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

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

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

השירותים מאפשרים להשתמש בשפות תכנות שונות המתאימות יותר למשימות שונות. חלק מהשירותים נמצאים ב-Go, חלקם ב-Erlang, חלקם נמצאים ברובי, משהו ב-PHP, משהו ב-Python. באופן כללי, אתה יכול להרחיב מאוד. גם כאן יש ניואנסים.

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

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

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

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

אנו משתמשים ב-Ansible כדי להפוך את הפריסה לאוטומטית, ב-Puppet להתכנסות, בבמבו כדי להפוך את הפריסה לאוטומטית, וב-Confluence כדי לתאר את הכל.

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

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

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

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

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

יש לנו אתרים ושירותים ב-PHP 5.6, אנחנו מתביישים בהם, אבל מה אנחנו יכולים לעשות? זה האתר האחד שלנו. יש אתרים ושירותים ב-PHP 7, יש עוד כאלה, אנחנו לא מתביישים בהם. ולכל מפתח יש בסיס משלו שבו הוא מנסר בשמחה.

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

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

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

לכל שירות יש צוות משלו

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

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

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

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

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

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

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

כיצד מופיעים שירותים יתומים?

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

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

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

איך מזהים יתום?

רשימה זו מתארת ​​היטב את המצב. מי למד משהו על התשתית שלהם?

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

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

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

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

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

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

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

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

יש לבדוק את השירות, לבחון את השירות, לשנות סיסמאות. היה לנו מקרה כשנתנו לנו שירות, יש פאנל ניהול "אם התחברות == 'אדמין' && סיסמה == 'אדמין'...", זה כתוב ממש בקוד. אנחנו יושבים וחושבים, ואנשים כותבים את זה ב-2018?

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

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

היה לנו מקרה כשהחלטנו להוציא פרויקט פיילוט למיקור חוץ.

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

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

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

מה הבעיה עם יתומים?

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

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

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

מדוע שירותים יתומים מסוכנים:

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

מה לעשות עם שירותי יתומים?

אני אחזור על מה לעשות שוב. ראשית, חייב להיות תיעוד. 7 שנים ב-Banki.ru לימדו אותי שבודקים לא צריכים לקבל את דבר המפתחים, ותפעול לא צריך לקבל את דבר כולם. אנחנו צריכים לבדוק.

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

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

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

תוכנית עבודה עם שירות יתום

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

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

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

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

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

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

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

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

למעשה, זה אופציונלי, כמו כל הפרקטיקות. אולי, במקרים מסוימים, זה אפילו לא רצוי. אבל אתה צריך להבין שאם יש לך מחלקה טכנית בחברה של 50 אנשים, 45 מהם מומחי PHP, עוד 3 הם Devops שמכירים Python, Ansible, Puppet ועוד משהו כזה, ורק אחד מהם כותב בחלק סוג של שפה. שירות שינוי גודל של Go, ואז כשהוא עוזב, המומחיות מלווה אותו. ויחד עם זאת, תצטרכו לחפש מפתח ספציפי לשוק שיודע את השפה הזו, במיוחד אם היא נדירה. כלומר מבחינה ארגונית זה בעייתי. מנקודת מבט של devops, לא תצטרכו רק לשכפל כמה סטים מוכנים של ספרי הפעלה שבהם אתם משתמשים כדי לפרוס שירותים, אלא תצטרכו לכתוב אותם שוב.

אנו בונים כעת שירות ב-Node.js, וזו תהיה רק ​​פלטפורמה בקרבת מקום לכל מפתח עם שפה נפרדת. אבל ישבנו וחשבנו שהמשחק שווה את הנר. כלומר, זו שאלה בשבילכם לשבת ולחשוב עליה.

איך אתה מפקח על השירותים שלך? איך אוספים ומנטרים יומנים?

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

איך לחיות עם Puppet ו-Ansible באותה סביבה?

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

איך שומרים על תאימות? האם יש לך הגדרות גם ב-Ansible וגם ב-Puppet?

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

המצגת הייתה על גרסאות שונות של רובי. איזה פתרון?

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

הכנס השנה DevOpsDays מוסקבה יתקיים ב-7 בדצמבר בטכנופוליס. אנו מקבלים בקשות לדוחות עד ה-11 בנובמבר. כתוב לי אותנו אם תרצה לדבר.

ההרשמה למשתתפים נפתחה, הצטרפו אלינו!

מקור: www.habr.com