Неліктен банкке AIOps және қолшатыр мониторингі қажет немесе клиенттік қарым-қатынастар неге негізделген?

Хабредегі жарияланымдарда мен өз командаммен серіктестік орнату тәжірибесі туралы жаздым (осында бизнес ыдырап кетпеуі үшін жаңа бизнесті бастағанда серіктестік шартын қалай жасау керектігі туралы айтады). Енді мен клиенттермен серіктестік орнату туралы айтқым келеді, өйткені оларсыз бұзылатын ештеңе болмайды. Бұл мақала өз өнімдерін ірі бизнеске сата бастаған стартаптар үшін пайдалы болады деп сенемін.

Мен қазір MONQ Digital зертханасы деп аталатын стартапты басқарамын, онда менің командам және мен корпоративтік АТ-ны қолдау және пайдалану процестерін автоматтандыруға арналған өнімді әзірлеудеміз. Нарыққа шығу оңай шаруа емес және біз үй тапсырмасын орындаудан бастадық, нарық сарапшыларын, серіктестерімізді аралап, нарықты сегменттеуді жүргіздік. Негізгі сұрақ: «Кімнің ауруын жақсы емдей аламыз?»

Банктер ТОП-3 сегментке енді. Және, әрине, тізімде бірінші болып Tinkoff және Сбербанк болды. Банк нарығының мамандарына барғанымызда, олар: өз өніміңді сонда таныстыр, банк нарығына жол ашық болады деп айтты. Біз сонда да, сол жерде де кіруге тырыстық, бірақ Сбербанкте бізді сәтсіздік күтіп тұрды, ал Тинкоффтың жігіттері ресейлік стартаптармен өнімді қарым-қатынасқа әлдеқайда ашық болды (мүмкін сол кезде Сбер болғандықтан болуы мүмкін). сатып алған миллиардқа жуық батыстық бәсекелестеріміз). Бір айдың ішінде пилоттық жобаны қолға алдық. Бұл қалай болды, оқыңыз.

Біз көптеген жылдар бойы пайдалану және мониторинг мәселелерімен айналысып келеміз, қазір біз өз өнімімізді мемлекеттік секторда, сақтандыруда, банктерде, телекоммуникация компанияларында енгізіп жатырмыз, бір іске асыру авиакомпаниямен болды (жобаға дейін біз тіпті жоқ едік) Авиация IT-тәуелді сала болды деп ойлаймын, және қазір біз COVID-ке қарамастан, компания пайда болып, көтеріледі деп үміттенеміз).

Біз жасайтын өнім кәсіпорын бағдарламалық жасақтамасына, AIOps (IT операцияларына арналған жасанды интеллект немесе ITOps) сегментіне жатады. Кәсіпорында процестің жетілу деңгейінің жоғарылауы сияқты жүйелерді енгізудің негізгі мақсаттары:

  1. Өрттерді сөндіру: ақауларды анықтау, дабыл ағынын қоқыстан тазарту, жауапты адамдарға тапсырмалар мен оқиғаларды тағайындау;
  2. АТ қызметінің тиімділігін арттыру: инциденттерді шешу уақытын қысқарту, сәтсіздіктердің себептерін көрсету, АТ күйінің ашықтығын арттыру;
  3. Бизнестің тиімділігін арттыру: қол еңбегінің көлемін азайту, тәуекелдерді азайту, тұтынушылардың адалдығын арттыру.

Біздің тәжірибемізге сүйенсек, банктердің барлық ірі АТ-инфрақұрылымдарымен бірдей мониторингпен байланысты мынадай «ауыртпалықтары» бар:

  • «кім біледі»: көптеген техникалық бөлімдер бар, барлығында дерлік кем дегенде бір бақылау жүйесі бар, ал көпшілігінде біреуден көп;
  • Ескертулердің «масалардың тобыры»: әрбір жүйе жүздегенді жасайды және олармен жауаптылардың барлығын бомбалайды (кейде бөлімдер арасында да). Әрбір хабарлама бойынша бақылаудың назарын үнемі ұстап тұру қиын, олардың өзектілігі мен маңыздылығы санының көптігіне байланысты теңестіріледі;
  • ірі банктер – сектор көшбасшылары өз жүйелерін үздіксіз бақылап қана қоймай, қай жерде сәтсіздіктер бар екенін білгісі келеді, сонымен қатар АИ-нің нағыз сиқыры – жүйелердің өзін-өзі бақылайтын, өзін-өзі болжайтын және өзін-өзі түзететінін қалайды.

Тинкоффтағы алғашқы кездесуге келгенде, бізге олардың бақылауда ешқандай проблемалары жоқ екенін және оларға ештеңе зиян келтірмейтінін бірден айтты және негізгі сұрақ: «Қазірдің өзінде жақсы жұмыс істейтіндерге не ұсына аламыз?»

Әңгіме ұзаққа созылды, біз олардың микросервистері қалай құрылғанын, бөлімдер қалай жұмыс істейтінін, қандай инфрақұрылымдық мәселелер сезімтал, қайсысы пайдаланушылар үшін сезімтал емес, «соқыр нүктелер» қайда және олардың мақсаттары мен SLA-сы қандай екенін талқыладық.

Айтпақшы, банктің SLA шарттары өте әсерлі. Мысалы, бірінші кезектегі желінің қол жетімділігі оқиғасын шешуге тек бірнеше минут кетуі мүмкін. Мұндағы қателік пен тоқтап қалу құны, әрине, әсерлі.

Нәтижесінде біз ынтымақтастықтың бірнеше бағыттарын анықтадық:

  1. бірінші кезең - оқиғаны шешу жылдамдығын арттыру үшін қолшатыр мониторингі
  2. екінші кезең – тәуекелдерді азайту және АТ бөлімін масштабтау үшін шығындарды азайту үшін процестерді автоматтандыру.

Бірнеше «ақ дақтарды» ескертулердің ашық түстеріне тек бірнеше бақылау жүйелеріндегі ақпаратты өңдеу арқылы бояуға болады, өйткені метрикаларды тікелей қабылдау мүмкін болмады; сонымен қатар әртүрлі бақылау жүйелеріндегі деректерді «бір экранға» орталықтандыру қажет болды. не болып жатқанының жалпы бейнесін түсіну. «Қолшатырлар» бұл тапсырманы орындауға жарамды және біз сол кезде бұл талаптарды орындадық.

Біздің ойымызша, клиенттермен қарым-қатынаста өте маңызды нәрсе - адалдық. Бірінші әңгімеден және лицензияның құнын есептегеннен кейін, құны өте төмен болғандықтан, лицензияны бірден сатып алуға тұрарлық болуы мүмкін екендігі айтылды (жоғарыдағы жасыл банк туралы мақаладағы Dynatrace Klyuch-Astrom-мен салыстырғанда, біздің лицензия миллиардтың үштен бірі емес, айына 12 гигабайт үшін 1 мың рубльді құрайды, Сбер үшін бұл бірнеше есе арзанырақ болады). Бірақ біз оларға бізде не бар, не жоқ екенін бірден айттық. Мүмкін, ірі интегратордың сату өкілі «иә, біз бәрін жасай аламыз, әрине лицензиямызды сатып аламыз» деп айтуы мүмкін, бірақ біз барлық карталарымызды үстелге қоюды шештік. Іске қосу кезінде біздің қорапта Prometheus-пен интеграция болмады, ал автоматтандыру ішкі жүйесі бар жаңа нұсқасы шығарылғалы тұр еді, бірақ біз оны әлі тұтынушыларға жіберген жоқпыз.

Пилоттық жоба басталып, оның шекарасы анықталып, бізге 2 ай уақыт берілді. Негізгі міндеттер мыналар болды:

  • платформаның жаңа нұсқасын дайындаңыз және оны банктің инфрақұрылымында орналастырыңыз
  • 2 бақылау жүйесін қосу (Zabbix және Prometheus);
  • жауаптыларға Slack және SMS арқылы хабарламалар жіберу;
  • автосауықтыру сценарийлерін іске қосыңыз.

Пилоттық жобаның бірінші айы пилоттық жобаның қажеттіліктері үшін супер-жылдам режимде платформаның жаңа нұсқасын дайындауға жұмсалды. Жаңа нұсқа бірден Prometheus-пен интеграцияны және автоматты емдеуді қамтиды. Біздің әзірлеушілер тобымыздың арқасында олар бірнеше түн ұйықтамады, бірақ бұрын қабылданған басқа міндеттемелерді орындау мерзімін өткізіп алмай, уәде еткендерін шығарды.

Біз пилотты орнату кезінде жобаны мерзімінен бұрын жабуы мүмкін жаңа мәселеге тап болдық: жедел хабаршыларға және SMS арқылы ескертулер жіберу үшін бізге Microsoft Azure серверлеріне кіріс және шығыс қосылымдары қажет болды (ол кезде біз бұл платформаны пайдаландық. Slack-ке ескертулер жіберу үшін) және сыртқы жіберу қызметі SMS. Бірақ бұл жобада қауіпсіздікке ерекше назар аударылды. Банк саясатына сәйкес мұндай «тесіктерді» ешбір жағдайда ашу мүмкін емес еді. Барлығы жабық циклден жұмыс істеу керек болды. Бізге Slack және SMS арқылы ескертулер жіберетін өзіміздің ішкі қызметтеріміздің API интерфейсін пайдалану ұсынылды, бірақ бізде мұндай қызметтерді қораптан тыс қосу мүмкіндігі болмады.

Әзірлеушілер тобымен пікірталас кеші шешімді сәтті іздеумен аяқталды. Артта қалған кезеңді зерттей келе, бізде ешқашан уақыт пен басымдық болмаған бір тапсырманы таптық - енгізу топтары немесе клиент платформаның мүмкіндіктерін кеңейте отырып, қондырмаларды өздері жаза алатындай плагин жүйесін жасау.

Бірақ бізге тура бір ай қалды, оның ішінде барлығын орнатуға, автоматтандыруды конфигурациялауға және енгізуге тура келді.

Біздің бас сәулетшіміз Сергейдің айтуынша, плагин жүйесін енгізу үшін кемінде бір ай қажет.

Уақытымыз болмады...

Бір ғана шешім болды - клиентке барыңыз және бәрін сол күйінде айтыңыз. Мерзімді ауыстыруды бірге талқылаңыз. Және ол жұмыс істеді. Бізге қосымша 2 апта уақыт берілді. Олардың да өз мерзімдері мен нәтижелерді көрсету үшін ішкі міндеттемелері болды, бірақ оларда 2 резервтік апта болды. Соңында біз бәрін жолға қойдық. Бұзылу мүмкін емес еді. Адалдық пен серіктестік көзқарас тағы да өз жемісін берді.

Пилоттық тәжірибе нәтижесінде бірнеше маңызды техникалық нәтижелер мен қорытындылар алынды:

Біз ескертулерді өңдеуге арналған жаңа функцияны сынадық

Орналастырылған жүйе Прометейден ескертулерді дұрыс қабылдап, оларды топтай бастады. Прометей клиентінен мәселе туралы ескертулер әрбір 30 секунд сайын ұшып тұрды (уақыт бойынша топтау қосылмаған) және біз оларды «қолшатырдың» өзінде топтастыру мүмкін бе деп ойладық. Бұл мүмкін екені белгілі болды - платформада ескертулерді өңдеуді орнату сценарий арқылы жүзеге асырылады. Бұл оларды өңдеудің кез келген дерлік логикасын жүзеге асыруға мүмкіндік береді. Біз платформада үлгілер түрінде стандартты логиканы енгіздік - егер сіз өзіңіздің бірдеңе ойлап тапқыңыз келмесе, дайынды пайдалана аласыз.

Неліктен банкке AIOps және қолшатыр мониторингі қажет немесе клиенттік қарым-қатынастар неге негізделген?

«Синтетикалық триггер» интерфейсі. Қосылған бақылау жүйелерінен ескертулерді өңдеуді орнату

Жүйенің «денсаулық» күйін құрды

Ескертулердің негізінде конфигурация бірліктерінің (CU) денсаулығына әсер еткен бақылау оқиғалары жасалды. Біз ресурс-қызмет үлгісін (RSM) іске асырып жатырмыз, ол не ішкі CMDB-ны пайдалана алады, не сыртқыын қоса алады - пилоттық жоба кезінде клиент өзінің CMDB-ге қосылмады.

Неліктен банкке AIOps және қолшатыр мониторингі қажет немесе клиенттік қарым-қатынастар неге негізделген?

Ресурс-сервис моделімен жұмыс істеуге арналған интерфейс. Ұшқыш RSM.

Шындығында, клиентте әртүрлі жүйелердегі оқиғалар көрінетін жалғыз бақылау экраны бар. Қазіргі уақытта «қолшатырға» екі жүйе қосылған - Zabbix және Prometheus және платформаның ішкі бақылау жүйесі.

Неліктен банкке AIOps және қолшатыр мониторингі қажет немесе клиенттік қарым-қатынастар неге негізделген?

Аналитикалық интерфейс. Бірыңғай бақылау экраны.

Процесті автоматтандыру іске қосылды

Оқиғаларды бақылау алдын ала конфигурацияланған әрекеттерді іске қосуға түрткі болды - ескертулерді жіберу, сценарийлерді іске қосу, инциденттерді тіркеу/байыту - соңғысы осы клиентпен қолданылмады, себебі пилоттық жобада қызмет көрсету үстелімен интеграция болған жоқ.

Неліктен банкке AIOps және қолшатыр мониторингі қажет немесе клиенттік қарым-қатынастар неге негізделген?

Әрекет параметрлерінің интерфейсі. Slack-ке ескертулер жіберіп, серверді қайта жүктеңіз.

Өнімнің кеңейтілген функционалдығы

Автоматтандыру сценарийлерін талқылау кезінде клиент bash қолдауын және осы сценарийлерді ыңғайлы конфигурациялауға болатын интерфейсті сұрады. Жаңа нұсқа тағы біраз жұмыс жасады (cURL, SSH және SNMP қолдауымен Луада толыққанды логикалық құрылымдарды жазу мүмкіндігі) және сценарийдің өмірлік циклін басқаруға мүмкіндік беретін функционалдық (жасау, өңдеу, нұсқаны басқару) , жою және мұрағаттау).

Неліктен банкке AIOps және қолшатыр мониторингі қажет немесе клиенттік қарым-қатынастар неге негізделген?

Автосауықтыру сценарийлерімен жұмыс істеуге арналған интерфейс. SSH арқылы серверді қайта жүктеу сценарийі.

Негізгі нәтижелер

Пилоттық кезеңде ағымдағы функционалдылықты жақсартатын және клиент үшін құндылықты арттыратын пайдаланушы оқиғалары жасалды, олардың кейбіреулері:

  • айнымалы мәндерді ескертуден автоматты қалпына келтіру сценарийіне тікелей жіберу мүмкіндігін іске асыру;
  • платформаға Active Directory арқылы авторизация қосыңыз.

Бізге көбірек жаһандық міндеттер қойылды - өнімді басқа мүмкіндіктермен «құрастыру»:

  • ережелер мен агенттерге емес, ML негізіндегі ресурс-қызмет үлгісін автоматты түрде құру (қазіргі басты мәселе болуы мүмкін);
  • қосымша сценарийлер мен логикалық тілдерді қолдау (және бұл JavaScript болады).

Меніңше, ең бастысыБұл ұшқыш екі нәрсені көрсетеді:

  1. Нәтижелі қарым-қатынас адалдық пен ашықтық негізінде құрылып, клиент қысқа мерзімде айтарлықтай нәтижелерге қол жеткізетін команданың бір бөлігі болған кезде клиентпен серіктестік тиімділіктің кілті болып табылады.
  2. Ешбір жағдайда «балдақтарды» «баптау» және құру қажет емес - тек жүйелік шешімдер. Біраз уақыт жұмсаған дұрыс, бірақ басқа клиенттер пайдаланатын жүйелік шешім жасаңыз. Айтпақшы, осылай болды, плагин жүйесі және Azure-ге тәуелділікті жою басқа клиенттерге қосымша мән берді (сәлеметсіз бе, Федералдық заң 152).

Ақпарат көзі: www.habr.com

пікір қалдыру