ממונוליטים למיקרו-שירותים: החוויה של M.Video-Eldorado ו-MegaFon

ב-25 באפריל, קיימנו ב-Mail.ru Group כנס בנושא עננים ומסביב - mailto:CLOUD. כמה דגשים:

• הראשי ספקים רוסים — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center ו-Yandex.Cloud דיברו על הפרטים הספציפיים של שוק הענן שלנו והשירותים שלהם;
• עמיתים מ-Bitrix24 סיפרו כיצד הם הגיע למולטיקלאוד;
• לירוי מרלין, אוטקריטי, בורגר קינג ושניידר אלקטריק סיפקו מעניין צפייה מצרכני ענן - אילו משימות העסק שלהם מציב ל-IT ואילו טכנולוגיות, כולל ענן, הם רואים כמבטיחות ביותר.

אתה יכול לצפות בכל הסרטונים מכנס mailto:CLOUD по ссылке, וכאן תוכלו לקרוא איך התנהל הדיון על שירותי מיקרו. אלכסנדר דאולין, ראש מרכז המחקר והפיתוח של מערכות עסקיות MegaFon, וסרגיי סרגייב, מנהל טכנולוגיית המידע של קבוצת M.Video-Eldorado, שיתפו את המקרים המוצלחים שלהם של היפטרות ממונוליטים. דנו גם בנושאים קשורים של אסטרטגיית IT, תהליכים ואפילו משאבי אנוש.

חברי פאנל

• סרגיי סרגייב, CIO של הקבוצה "M.Video-Eldorado";
• אלכסנדר דאולין, ראש המרכז למחקר ופיתוח מערכות עסקיות מגהפון;
• מנחה - דמיטרי לזרנקו, ראש כיוון PaaS פתרונות ענן של Mail.ru.

לאחר נאומו של אלכסנדר דאולין "כיצד MegaFon מרחיבה את עסקיה באמצעות פלטפורמת שירות מיקרו" אליו מצטרפים לדיון סרגיי סרגייב מ-M.Video-Eldorado ומנחה הדיון דמיטרי לזרנקו, Mail.ru Cloud Solutions.

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

המעבר לשירותי מיקרו הוא מענה לצרכי השוק

דמיטרי:

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

סרגיי:

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

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

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

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

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

כיצד למדוד את הצלחת המעבר לשירותי מיקרו

דמיטרי:

כיצד נקבעת הצלחה במעבר לשירותי מיקרו? מה היה ה"לפני" בכל חברה? באיזה מדד השתמשת כדי לקבוע את הצלחת המעבר, ומי קבע זאת בפועל?

סרגיי:

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

אלכסנדר:

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

סרגיי:

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

שירותי מיקרו יגיעו, אבל הליבה תישאר

דמיטרי:

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

סרגיי:

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

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

דמיטרי:

החיים במצב טוב. (צוחק)

אלכסנדר:

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

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

כיצד למכור שירותי מיקרו לעסקים

דמיטרי:

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

סרגיי:

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

דמיטרי:

רשמת איכשהו את הזמן של השלב הראשון?

סרגיי:

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

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

דמיטרי:

בסדר. אלכסנדר, מה אתה אומר?

אלכסנדר:

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

דמיטרי:

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

אלכסנדר:

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

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

שירותי מיקרו: הייפ או הכרח?

דמיטרי:

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

סרגיי:

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

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

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

אנו רואים את ההתפתחות הזו:

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

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

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

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

אלכסנדר:

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

דמיטרי:

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

כיצד לפתח שירותי מיקרו אמינים

דמיטרי:

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

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

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

אלכסנדר:

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

לא היו לנו תקלות גלובליות בשירותי מיקרו. אנחנו ישנים בשקט, יש לנו משמרת 24/7 המשרתת את כל ה-BSS [מערכת התמיכה העסקית].

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

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

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

שירותי מיקרו ומשאבי אנוש

סרגיי:

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

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

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

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

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

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

דמיטרי:

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

סרגיי:

כן בהחלט.

אלכסנדר:

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

האבולוציה של שירותי מיקרו

דמיטרי:

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

סרגיי:

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

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

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

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

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

דמיטרי:

מגניב. מה יש במגהפון?

אלכסנדר:

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

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

דמיטרי:

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

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

תודה לכל המשתתפים, תודה לסרגיי ואלכסנדר!

שאלות מהקהל

שאלה מהקהל (1):

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

סרגיי:

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

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

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

שאלה מהקהל (2):

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

אלכסנדר:

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

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

והבעיה שלנו היא רק בצוות הקטן. דרוש מהנדס QA אחד למוצר מותנה אחד. וכך, אנו שולחים מוצר של 5-7 מיקרו-שירותים, מתוכם 2-3 ניתנים לפיתוח על ידי צדדים שלישיים. לדוגמה, יש לנו מוצר בפיתוח שבו משתתפות ספק מערכות החיוב שלנו, Mail.ru Group ו-MegaFon R&D. אנחנו צריכים לכסות את זה בבדיקות לפני שליחתו לייצור. מהנדס ה-QA עובד על המוצר הזה כבר חודש וחצי, ושאר הצוות נותר ללא תמיכתו.

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

סרגיי:

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

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

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

אלכסנדר:

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

שאלה מהקהל (3):

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

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

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

אלכסנדר:

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

סרגיי:

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

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

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

אלכסנדר:

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

סרגיי:

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

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

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

סוף הדיון, אבל לא הכל

ועידת mailto:CLOUD אורגנה פתרונות ענן של Mail.ru.

אנחנו עושים גם אירועים אחרים - למשל. @Kubernetes Meetup, שם אנחנו תמיד מחפשים רמקולים מעולים:

• עקוב אחר @Kubernetes וחדשות @Meetup אחרות בערוץ הטלגרם שלנו t.me/k8s_mail
• מעוניין לדבר באחד ממפגשי @Meetup? השאר בקשה ל mcs.mail.ru/speak

מקור: www.habr.com