מדוע בנק צריך AIOps וניטור מטריה, או על מה מבוססים קשרי לקוחות?

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

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

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

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

המוצר שאנו מייצרים שייך לתוכנה ארגונית, פלח AIOps (בינה מלאכותית עבור IT Operations, או ITOps). המטרות העיקריות של הטמעת מערכות כגון רמת בשלות התהליך בחברה עולה:

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

מניסיוננו, לבנקים יש את ה"כאבים" הבאים עם ניטור המשותף לכל תשתיות ה-IT הגדולות:

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

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

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

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

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

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

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

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

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

• להכין גרסה חדשה של הפלטפורמה ולפרוס אותה בתשתית הבנק
• לחבר 2 מערכות ניטור (Zabbix ו-Prometheus);
• לשלוח הודעות לאחראים ב-Slack וב-SMS;
• להריץ סקריפטים לריפוי אוטומטי.

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

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

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

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

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

לא היה לנו זמן...

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

כתוצאה מהפיילוט התקבלו מספר תוצאות ומסקנות טכניות חשובות:

בדקנו את הפונקציונליות החדשה לעיבוד התראות

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

ממשק "טריגר סינתטי". הגדרת עיבוד התראות ממערכות ניטור מחוברות

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

בהתבסס על התראות, נוצרו אירועי ניטור שהשפיעו על תקינות יחידות התצורה (CUs). אנו מיישמים מודל שירות משאבים (RSM), שיכול להשתמש ב-CMDB פנימי או לחבר חיצוני - במהלך פרויקט הפיילוט הלקוח לא חיבר CMDB משלו.

ממשק לעבודה עם מודל משאבים-שירות. טייס RSM.

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

ממשק אנליטיקס. מסך ניטור יחיד.

השיקה אוטומציה של תהליכים

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

ממשק הגדרות פעולה. שלח התראות ל-Slack והפעל מחדש את השרת.

פונקציונליות מוצר מורחבת

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

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

ממצאים עיקריים

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

• ליישם את היכולת להעביר משתנים ישירות מההתראה לסקריפט הריפוי האוטומטי;
• הוסף הרשאה לפלטפורמה באמצעות Active Directory.

וקיבלנו עוד אתגרים גלובליים - "לבנות" את המוצר עם יכולות אחרות:

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

לדעתי הדבר החשוב ביותרמה שהפיילוט הזה מראה זה שני דברים:

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

מקור: www.habr.com