Nima uchun bank AIOps va soyabon monitoringiga muhtoj yoki mijozlar bilan munosabatlar nimaga asoslanadi?

Habré-dagi nashrlarda men o'z jamoam bilan hamkorlik qilish tajribam haqida yozganman (shu yerda biznes parchalanmasligi uchun yangi biznesni boshlashda hamkorlik shartnomasini qanday tuzish haqida gapiradi). Va endi men mijozlar bilan qanday hamkorlikni yo'lga qo'yish haqida gapirmoqchiman, chunki ularsiz buzilmaydigan hech narsa bo'lmaydi. Umid qilamanki, ushbu maqola o'z mahsulotlarini yirik korxonalarga sotishni boshlagan startaplar uchun foydali bo'ladi.

Men hozirda MONQ Digital lab nomli startapga rahbarlik qilyapman, u yerda men va mening jamoam korporativ ITni qo‘llab-quvvatlash va boshqarish jarayonlarini avtomatlashtirish uchun mahsulot ishlab chiqmoqdamiz. Bozorga kirish oson ish emas va biz ozgina uy vazifasi bilan boshladik, bozor mutaxassislari, hamkorlarimizdan o'tdik va bozor segmentatsiyasini amalga oshirdik. Asosiy savol “kimning dardini yaxshiroq davolay olamiz?” degan savolni tushunish edi.

Banklar TOP 3 segmentiga kirdi. Va, albatta, ro'yxatda Tinkoff va Sberbank birinchi bo'ldi. Bank bozori mutaxassislariga tashrif buyurganimizda, ular: o‘sha yerda mahsulotingizni tanishtiring, bank bozoriga yo‘l ochiq bo‘ladi, deyishdi. Biz u erga ham, u erga ham kirishga harakat qildik, lekin bizni Sberbankda muvaffaqiyatsizlik kutdi va Tinkoff yigitlari rus startaplari bilan samarali muloqotga ko'proq ochiq bo'lishdi (ehtimol o'sha paytda Sber bo'lganligi sababli). sotib oldi deyarli bir milliard g'arbiy raqobatchilarimiz). Bir oy ichida biz sinov loyihasini boshladik. Bu qanday sodir bo'ldi, o'qing.

Biz ko'p yillardan buyon ekspluatatsiya va monitoring masalalari bilan shug'ullanamiz, endi biz o'z mahsulotimizni davlat sektorida, sug'urtada, banklarda, telekom kompaniyalarida joriy qilmoqdamiz, bitta amalga oshirish aviakompaniya bilan amalga oshirilgan (loyihadan oldin biz hatto yo'q edik) O'ylaymanki, aviatsiya IT-ga bog'liq bo'lgan sanoat edi va endi biz haqiqatan ham COVID-ga qaramay, kompaniya paydo bo'ladi va ko'tariladi deb umid qilamiz).

Biz ishlab chiqaradigan mahsulot korporativ dasturiy ta'minot, AIOps (IT Operatsiyalari uchun sun'iy intellekt yoki ITOps) segmentiga tegishli. Kompaniyadagi jarayonlarning etuklik darajasining oshishi kabi tizimlarni joriy etishning asosiy maqsadlari:

1. Yong'inlarni o'chirish: nosozliklarni aniqlash, ogohlantirishlar oqimini vayronalardan tozalash, mas'ul shaxslarga vazifalar va hodisalarni belgilash;
2. AT xizmati samaradorligini oshirish: hodisalarni bartaraf etish vaqtini qisqartirish, nosozliklar sabablarini ko'rsatish, AT holatining shaffofligini oshirish;
3. Biznes samaradorligini oshirish: qo'l mehnati miqdorini kamaytirish, xavflarni kamaytirish, mijozlarning sodiqligini oshirish.

Bizning tajribamizga ko‘ra, banklar barcha yirik IT infratuzilmalari bilan bir qatorda monitoring bilan bog‘liq quyidagi “og‘riqlar”ga ega:

• "kim biladi": ko'plab texnik bo'limlar mavjud, deyarli har bir kishi kamida bitta monitoring tizimiga ega va ko'pchilikda bir nechta;
• Ogohlantirishlarning "chivin to'dasi": har bir tizim yuzlab odamlarni hosil qiladi va ular bilan mas'ul bo'lganlarning barchasini bombardimon qiladi (ba'zan bo'limlar o'rtasida ham). Har bir bildirishnoma ustidan doimiy nazorat e'tiborini saqlab turish qiyin, ularning sonining ko'pligi sababli ularning dolzarbligi va ahamiyati tenglashtiriladi;
• yirik banklar - sektor rahbarlari nafaqat o'z tizimlarini doimiy ravishda kuzatib borishni, qayerda nosozliklar borligini bilishni, balki sun'iy intellektning haqiqiy sehrini ham - tizimlarni o'z-o'zini nazorat qilish, o'zini o'zi bashorat qilish va o'z-o'zini tuzatishni xohlaydi.

Tinkoffdagi birinchi uchrashuvga kelganimizda, biz darhol ularning monitoring bilan bog'liq muammolari yo'qligini va ularga hech narsa zarar bermasligini aytishdi va asosiy savol: "Allaqachon yaxshi ishlayotganlar uchun nima taklif qilishimiz mumkin?"

Suhbat uzoq davom etdi, biz ularning mikroservislari qanday qurilgani, bo'limlar qanday ishlashi, qaysi infratuzilma muammolari sezgir, qaysilari foydalanuvchilar uchun kamroq sezgir, "ko'r nuqtalar" qayerda va ularning maqsadlari va SLAlari nima ekanligini muhokama qildik.

Aytgancha, bankning SLA'lari haqiqatan ham ta'sirli. Masalan, XNUMX-tarmoq mavjudligi muammosini hal qilish bir necha daqiqa vaqt olishi mumkin. Bu erda xatolik va ishlamay qolish narxi, albatta, ta'sirchan.

Natijada biz hamkorlikning bir nechta yo'nalishlarini aniqladik:

1. birinchi bosqich - bu hodisani hal qilish tezligini oshirish uchun soyabon monitoringi
2. ikkinchi bosqich - bu risklarni kamaytirish va IT bo'limini masshtablash xarajatlarini kamaytirish uchun jarayonlarni avtomatlashtirish.

Bir nechta "oq dog'larni" ogohlantirishlarning yorqin ranglariga faqat bir nechta monitoring tizimlaridan ma'lumotlarni qayta ishlash orqali bo'yash mumkin edi, chunki ko'rsatkichlarni to'g'ridan-to'g'ri qabul qilishning iloji yo'q edi; shuningdek, turli monitoring tizimlaridan ma'lumotlarni "bitta ekranda" markazlashtirish kerak edi. nima sodir bo'layotganining umumiy rasmini tushunish uchun. Ushbu vazifa uchun "soyabonlar" mos keladi va biz o'sha paytda bu talablarga javob berdik.

Bizning fikrimizcha, mijozlar bilan munosabatlarda juda muhim narsa halollikdir. Birinchi suhbatdan va litsenziyaning narxini hisoblashdan so'ng, uning narxi juda past bo'lganligi sababli, darhol litsenziyani sotib olish kerak bo'lishi mumkinligi aytildi (yuqoridagi yashil bank haqidagi maqoladagi Dynatrace Klyuch-Astrom bilan solishtirganda, bizning litsenziya milliardning uchdan bir qismi emas, balki 12 gigabayt uchun oyiga 1 ming rublni tashkil qiladi, Sber uchun bu bir necha baravar arzon bo'ladi). Lekin biz darhol ularga nima bor va nima yo'qligini aytdik. Ehtimol, yirik integratorning savdo vakili "ha, biz hamma narsani qila olamiz, albatta, litsenziyamizni sotib olamiz", deb aytishi mumkin, ammo biz barcha kartalarimizni stolga qo'yishga qaror qildik. Ishga tushirish vaqtida bizning qutimiz Prometey bilan integratsiyaga ega emas edi va avtomatlashtirish quyi tizimiga ega yangi versiya chiqarilishi kerak edi, ammo biz uni hali mijozlarga jo'natmadik.

Pilot loyiha boshlandi, uning chegaralari aniqlandi va bizga 2 oy vaqt berildi. Asosiy vazifalar quyidagilar edi:

• platformaning yangi versiyasini tayyorlang va uni bank infratuzilmasiga joylashtiring
• 2 ta monitoring tizimini ulash (Zabbix va Prometey);
• mas'ul shaxslarga Slack va SMS orqali bildirishnomalar yuborish;
• autohealing skriptlarini ishga tushiring.

Pilot loyihaning birinchi oyi tajriba loyihasi ehtiyojlari uchun platformaning yangi versiyasini super-tez rejimda tayyorlashga sarflandi. Yangi versiya darhol Prometey bilan integratsiyani va avtomatik shifolashni o'z ichiga oladi. Rivojlanish guruhimiz tufayli ular bir necha kecha uxlamadilar, lekin ilgari qabul qilingan boshqa majburiyatlar uchun belgilangan muddatlarni o'tkazib yubormasdan va'da qilgan narsalarni ozod qilishdi.

Biz uchuvchini o'rnatayotganda, loyihani muddatidan oldin yopishi mumkin bo'lgan yangi muammoga duch keldik: tezkor messenjerlarga va SMS orqali ogohlantirishlar yuborish uchun bizga Microsoft Azure serverlariga kiruvchi va chiquvchi ulanishlar kerak edi (o'sha paytda biz ushbu platformadan foydalanganmiz. Slack-ga ogohlantirishlar yuborish) va tashqi SMS yuborish xizmati. Ammo bu loyihada xavfsizlikka alohida e'tibor qaratildi. Bank siyosatiga ko'ra, bunday "teshiklarni" hech qanday sharoitda ochib bo'lmaydi. Hamma narsa yopiq tsikldan ishlashi kerak edi. Bizga Slack-ga va SMS orqali ogohlantirishlar yuboradigan o'z ichki xizmatlarimiz API-dan foydalanishni taklif qilishdi, ammo bizda bunday xizmatlarni qutidan tashqarida ulash imkoni yo'q edi.

Rivojlanish guruhi bilan kechgan munozaralar yechimni muvaffaqiyatli izlash bilan yakunlandi. Ortiqcha vaqtni ko'rib chiqib, biz hech qachon vaqtimiz va ustuvorligimiz bo'lmagan bitta vazifani topdik - plagin tizimini yaratish, shunda amalga oshirish guruhlari yoki mijoz platformaning imkoniyatlarini kengaytirib, qo'shimchalarni o'zlari yozishi mumkin.

Ammo bizda roppa-rosa bir oy qoldi, bu vaqt ichida biz hamma narsani o'rnatishimiz, avtomatlashtirishni sozlashimiz va joylashtirishimiz kerak edi.

Bizning bosh arxitektorimiz Sergeyning so'zlariga ko'ra, plagin tizimini joriy qilish uchun kamida bir oy kerak bo'ladi.

Vaqtimiz yo'q edi...

Bitta yechim bor edi - mijozga borib, hamma narsani qanday bo'lsa, shunday qilib ayting. Belgilangan muddatni birgalikda muhokama qiling. Va u ishladi. Bizga qo'shimcha 2 hafta vaqt berildi. Ularning natijalarni ko'rsatish uchun o'z muddatlari va ichki majburiyatlari ham bor edi, ammo ularda 2 ta zahira haftasi bor edi. Oxir-oqibat, biz hamma narsani chiziqqa qo'yamiz. Xato qilish mumkin emas edi. Halollik va sheriklik yondashuvi yana o'z samarasini berdi.

Sinov natijasida bir nechta muhim texnik natijalar va xulosalar olindi:

Biz ogohlantirishlarni qayta ishlash uchun yangi funksiyani sinab ko'rdik

O'rnatilgan tizim Prometeydan ogohlantirishlarni to'g'ri qabul qila boshladi va ularni guruhlashtirdi. Prometey mijozidan muammo bo'yicha ogohlantirishlar har 30 soniyada uchib turardi (vaqt bo'yicha guruhlash yoqilmagan) va biz ularni "soyabon" ning o'zida guruhlash mumkinmi, deb qiziqdik. Ma'lum bo'lishicha, bu mumkin - platformada ogohlantirishlarni qayta ishlashni sozlash skript orqali amalga oshiriladi. Bu ularni qayta ishlash uchun deyarli har qanday mantiqni amalga oshirish imkonini beradi. Biz allaqachon platformada standart mantiqni shablonlar ko'rinishida joriy qildik - agar siz o'zingizning biror narsangizni o'ylab topishni xohlamasangiz, tayyor mantiqdan foydalanishingiz mumkin.

"Sintetik tetik" interfeysi. Ulangan monitoring tizimlaridan ogohlantirishlarni qayta ishlashni sozlash

Tizimning "salomatlik" holatini yaratdi

Ogohlantirishlar asosida konfiguratsiya birliklarining (CU) sog'lig'iga ta'sir ko'rsatadigan monitoring hodisalari yaratildi. Biz resurs-xizmat modelini (RSM) joriy qilmoqdamiz, u ichki CMDB-dan foydalanishi yoki tashqi modelni ulashi mumkin - pilot loyiha davomida mijoz o'z CMDB-ni ulamadi.

Resurs-xizmat modeli bilan ishlash uchun interfeys. Uchuvchi RSM.

Aslida, mijoz nihoyat bitta monitoring ekraniga ega bo'lib, unda turli tizimlardagi voqealar ko'rinadi. Hozirgi vaqtda "soyabon" ga ikkita tizim - Zabbix va Prometey va platformaning ichki monitoring tizimi ulangan.

Analytics interfeysi. Yagona monitoring ekrani.

Jarayonni avtomatlashtirish ishga tushirildi

Hodisalarni kuzatish oldindan tuzilgan harakatlarni ishga tushirishga turtki bo'ldi - ogohlantirishlarni yuborish, skriptlarni ishga tushirish, hodisalarni ro'yxatga olish/boyitish - ikkinchisi ushbu mijoz bilan sinab ko'rilmadi, chunki pilot loyihada xizmat ko'rsatish stoli bilan integratsiya yo'q edi.

Harakat sozlamalari interfeysi. Slack-ga ogohlantirishlar yuboring va serverni qayta yoqing.

Kengaytirilgan mahsulot funksionalligi

Avtomatlashtirish skriptlarini muhokama qilishda mijoz bash qo'llab-quvvatlashini va ushbu skriptlarni qulay tarzda sozlash mumkin bo'lgan interfeysni so'radi. Yangi versiya biroz ko'proq narsani amalga oshirdi (cURL, SSH va SNMP-ni qo'llab-quvvatlagan holda Lua-da to'liq huquqli mantiqiy konstruktsiyalarni yozish qobiliyati) va skriptning hayot aylanishini (yaratish, tahrirlash, versiyani boshqarish) boshqarish imkonini beruvchi funksionallikni amalga oshirdi. , o'chirish va arxivlash).

Autohealing skriptlari bilan ishlash uchun interfeys. SSH orqali serverni qayta ishga tushirish skripti.

Asosiy topilmalar

Tajriba davomida joriy funksionallikni yaxshilaydigan va mijoz uchun qiymatni oshiradigan foydalanuvchi hikoyalari ham yaratildi, ulardan ba'zilari:

• o'zgaruvchilarni ogohlantirishdan to'g'ridan-to'g'ri avtomatik tuzatish skriptiga yo'naltirish qobiliyatini amalga oshirish;
• Active Directory orqali platformaga avtorizatsiya qo'shing.

Va biz ko'proq global muammolarni oldik - mahsulotni boshqa imkoniyatlar bilan "yaratish":

• qoidalar va agentlarga emas, balki MLga asoslangan resurs-xizmat modelini avtomatik qurish (ehtimol, hozir asosiy muammo);
• qo'shimcha skript va mantiqiy tillarni qo'llab-quvvatlash (va bu JavaScript bo'ladi).

Mening fikrimcha, eng asosiysiBu uchuvchi ikki narsani ko'rsatadi:

1. Samarali muloqot halollik va ochiqlik asosida qurilsa va mijoz qisqa vaqt ichida sezilarli natijalarga erishadigan jamoaning bir qismiga aylanganda mijoz bilan hamkorlik samaradorlikning kalitidir.
2. Hech qanday holatda "sozlash" va "tayoqchalar" ni qurish shart emas - faqat tizim echimlari. Bir oz ko'proq vaqt sarflaganingiz ma'qul, lekin boshqa mijozlar foydalanadigan tizim echimini yarating. Aytgancha, bu sodir bo'ldi, plagin tizimi va Azure-ga qaramlikni yo'q qilish boshqa mijozlarga qo'shimcha qiymat berdi (salom, Federal qonun 152).

Manba: www.habr.com