Защо една банка се нуждае от AIOps и чадър мониторинг или на какво се основават взаимоотношенията с клиентите?

В публикации на Habré вече писах за моя опит в изграждането на партньорства с моя екип (тук говори за това как да съставите споразумение за партньорство при започване на нов бизнес, така че бизнесът да не се разпадне). И сега бих искал да говоря за това как да изградим партньорства с клиенти, тъй като без тях няма да има какво да се разпадне. Надявам се, че тази статия ще бъде полезна за стартиращи фирми, които започват да продават продукта си на големи фирми.

В момента оглавявам стартъп, наречен MONQ Digital lab, където с екипа ми разработваме продукт за автоматизиране на процесите по поддръжка и управление на корпоративни ИТ. Навлизането на пазара не е лесна задача и ние започнахме с малко домашна работа, преминахме през пазарни експерти, нашите партньори и извършихме сегментиране на пазара. Основният въпрос беше да разберем „чии болки можем да излекуваме най-добре?“

Банките попаднаха в ТОП 3 сегмента. И разбира се, първите в списъка бяха Tinkoff и Sberbank. Когато посетихме експерти на банковия пазар, те казаха: въведете вашия продукт там и пътят към банковия пазар ще бъде отворен. Опитахме се да влезем и там, и там, но провалът ни очакваше в Сбербанк, а момчетата от Tinkoff се оказаха много по-отворени за продуктивна комуникация с руски стартиращи компании (може би поради факта, че Sber по това време закупени почти един милиард наши западни конкуренти). В рамките на месец стартирахме пилотен проект. Как се случи, прочетете нататък.

Занимаваме се с проблемите на работата и мониторинга от много години, сега внедряваме нашия продукт в публичния сектор, в застраховането, в банки, в телеком компании, едно внедряване беше с авиокомпания (преди проекта дори не смятам, че авиацията беше толкова зависима от ИТ индустрията и сега наистина се надяваме, въпреки COVID, че компанията ще се появи и ще излети).

Продуктът, който произвеждаме, принадлежи към корпоративния софтуер, сегмента AIOps (Artificial Intelligence for IT Operations, или ITOps). Основните цели на внедряването на такива системи като повишаване на нивото на зрялост на процесите в компанията:

1. Гасете пожари: идентифицирайте повреди, изчистете потока от сигнали от отломки, възложете задачи и инциденти на отговорните;
2. Увеличете ефективността на ИТ услугата: намалете времето за разрешаване на инциденти, посочете причините за повреди, повишете прозрачността на ИТ състоянието;
3. Увеличете ефективността на бизнеса: намалете количеството ръчен труд, намалете рисковете, повишете лоялността на клиентите.

Според нашия опит банките имат следните „болки“ с мониторинга, общи за всички големи ИТ инфраструктури:

• „кой знае какво“: има много технически отдели, почти всеки има поне една система за наблюдение, а повечето имат повече от една;
• „рояк от комари“ от предупреждения: всяка система генерира стотици и бомбардира всички отговорни с тях (понякога и между отделите). Трудно е постоянно да се поддържа фокусът на контрол върху всяко уведомление, тяхната спешност и важност се изравнява поради големия брой;
• големите банки - лидерите в сектора искат не само непрекъснато да наблюдават системите си, да знаят къде има повреди, но и истинската магия на AI - да накара системите да се самонаблюдават, самопредсказват и самокоригират.

Когато дойдохме на първата среща в Tinkoff, веднага ни казаха, че нямат проблеми с наблюдението и нищо не ги боли, а основният въпрос беше: „Какво можем да предложим на тези, които вече се справят добре?“

Разговорът беше дълъг, обсъдихме как са изградени техните микроуслуги, как работят отделите, кои инфраструктурни проблеми са по-чувствителни, кои са по-малко чувствителни за потребителите, къде са „слепите петна“ и какви са техните цели и SLA.

Между другото, SLA на банката са наистина впечатляващи. Например разрешаването на инцидент с наличност на мрежа с приоритет XNUMX може да отнеме само няколко минути. Цената на грешките и прекъсванията тук, разбира се, е впечатляваща.

В резултат на това идентифицирахме няколко области на сътрудничество:

1. първият етап е чадър мониторинг за увеличаване на скоростта на разрешаване на инциденти
2. вторият етап е автоматизация на процесите за намаляване на рисковете и намаляване на разходите за мащабиране на ИТ отдела.

Няколко „бели петна“ можеха да бъдат боядисани в ярките цветове на предупрежденията само чрез обработка на информация от няколко системи за наблюдение, тъй като беше невъзможно директно да се вземат показатели; беше необходимо също да се централизират данните от различни системи за наблюдение на „един екран“, за да за да разбере цялостната картина на случващото се. „Чадърите“ са подходящи за тази задача и тогава изпълнихме тези изисквания.

Много важно нещо според нас в отношенията с клиентите е коректността. След първия разговор и изчисляване на цената на лиценза беше казано, че тъй като цената е толкова ниска, може би си струва да закупите лиценз веднага (в сравнение с Dynatrace Klyuch-Astrom от статията по-горе за зелената банка, нашата лицензът струва не една трета от милиард, а 12 хиляди рубли на месец за 1 гигабайт, за Sber ще струва няколко пъти по-евтино). Но веднага им казахме какво имаме и какво не. Може би търговски представител от голям интегратор би могъл да каже „да, можем да направим всичко, разбира се, купете нашия лиценз“, но ние решихме да сложим всичките си карти на масата. По време на стартирането нашата кутия нямаше интеграция с Prometheus и предстои да бъде пусната нова версия с подсистема за автоматизация, но все още не сме я изпратили на клиентите.

Пилотният проект започна, границите му бяха определени и ни бяха дадени 2 месеца. Основните задачи бяха:

• подготви нова версия на платформата и я внедри в инфраструктурата на банката
• свържете 2 системи за наблюдение (Zabbix и Prometheus);
• изпращайте известия до отговорните лица в Slack и чрез SMS;
• стартирайте скриптове за автоматично лечение.

Първият месец от пилотния проект премина в подготовка на нова версия на платформата в супер бърз режим за нуждите на пилотния проект. Новата версия веднага включва интеграция с Prometheus и автоматично лечение. Благодарение на нашия екип за разработка, те не спаха няколко нощи, но пуснаха това, което обещаха, без да пропускат сроковете за други поети преди това ангажименти.

Докато настройвахме пилотния проект, се сблъскахме с нов проблем, който можеше да затвори проекта предсрочно: за изпращане на предупреждения до месинджъри и чрез SMS се нуждаехме от входящи и изходящи връзки към сървърите на Microsoft Azure (по това време използвахме тази платформа за изпращане на предупреждения до Slack) и външна услуга за изпращане на SMS. Но в този проект безопасността беше особен фокус. В съответствие с политиката на банката такива „дупки” не могат да бъдат отваряни при никакви обстоятелства. Всичко трябваше да работи от затворен цикъл. Беше ни предложено да използваме API на нашите собствени вътрешни услуги, които изпращат предупреждения до Slack и чрез SMS, но нямахме възможност да свържем такива услуги веднага.

Вечер на дебат с екипа за разработка завърши с успешно търсене на решение. След като претърсихме натрупаните неща, открихме една задача, за която никога не ни достигаше време и приоритет - да създадем плъгин система, така че екипите за внедряване или клиентът да могат сами да пишат добавки, разширявайки възможностите на платформата.

Но ни оставаше точно месец, през който трябваше да инсталираме всичко, да конфигурираме и разположим автоматизацията.

Според Сергей, нашия главен архитект, внедряването на plug-in системата отнема поне месец.

Нямахме време...

Имаше само едно решение - отидете при клиента и кажете всичко както е. Обсъдете заедно изместването на крайния срок. И се получи. Дадоха ни допълнителни 2 седмици. Те също имаха свои срокове и вътрешни задължения за показване на резултати, но имаха 2 резервни седмици. В крайна сметка поставяме всичко на карта. Беше невъзможно да се обърка. Коректността и партньорският подход отново се отплатиха.

В резултат на пилотния проект бяха получени няколко важни технически резултата и заключения:

Тествахме новата функционалност за обработка на сигнали

Разгърнатата система започна правилно да получава сигнали от Prometheus и да ги групира. Сигнали за проблема от клиента на Prometheus летяха на всеки 30 секунди (групирането по време не е активирано) и се чудехме дали ще е възможно да ги групираме в самия „чадър“. Оказа се, че това е възможно - настройката на обработката на сигнали в платформата се осъществява чрез скрипт. Това дава възможност да се приложи почти всяка логика за обработката им. Вече сме внедрили стандартна логика в платформата под формата на шаблони - ако не искате да измислите нещо свое, можете да използвате готов.

Интерфейс „Синтетичен тригер“. Настройка на обработка на сигнали от свързани системи за наблюдение

Конструира състоянието на „здравословно състояние“ на системата

Въз основа на предупреждения бяха създадени събития за наблюдение, които повлияха на изправността на конфигурационните единици (CU). Внедряваме ресурсно-услуген модел (RSM), който може да използва или вътрешна CMDB, или да свърже външна - по време на пилотния проект клиентът не е свързал своя собствена CMDB.

Интерфейс за работа с модела ресурс-услуга. Пилотен RSM.

Е, всъщност клиентът най-накрая има единен екран за наблюдение, където се виждат събития от различни системи. В момента към „чадъра“ са свързани две системи - Zabbix и Prometheus, както и вътрешна система за мониторинг на самата платформа.

Интерфейс за анализ. Един екран за наблюдение.

Стартира автоматизация на процесите

Събитията за наблюдение задействаха стартирането на предварително конфигурирани действия - изпращане на предупреждения, изпълнение на скриптове, регистриране/обогатяване на инциденти - последното не беше изпробвано с този конкретен клиент, т.к. в пилотния проект нямаше интеграция със сервизното бюро.

Интерфейс за настройки на действие. Изпратете предупреждения до Slack и рестартирайте сървъра.

Разширена функционалност на продукта

Когато обсъждаше скриптове за автоматизация, клиентът поиска поддръжка на bash и интерфейс, в който тези скриптове могат да бъдат удобно конфигурирани. Новата версия направи малко повече (възможност за писане на пълноценни логически конструкции в Lua с поддръжка на cURL, SSH и SNMP) и имплементирана функционалност, която ви позволява да управлявате жизнения цикъл на скрипт (създаване, редактиране, контрол на версиите , изтриване и архивиране).

Интерфейс за работа със скриптове за автоматично лечение. Скрипт за рестартиране на сървъра чрез SSH.

Основни констатации

По време на пилота бяха създадени и потребителски истории, които подобряват текущата функционалност и увеличават стойността за клиента, ето някои от тях:

• прилагане на способността за препращане на променливи директно от предупреждението към скрипта за автоматично възстановяване;
• добавете оторизация към платформата чрез Active Directory.

И получихме още глобални предизвикателства - да „изградим“ продукта с други възможности:

• автоматично изграждане на ресурсно-услуген модел, базиран на ML, а не на правила и агенти (вероятно основното предизвикателство сега);
• поддръжка за допълнителни скриптови и логически езици (и това ще бъде JavaScript).

По мое мнение най-важното нещоТова, което този пилот показва, са две неща:

1. Партньорството с клиента е ключът към ефективността, когато ефективната комуникация се изгражда на базата на честност и откритост, а клиентът става част от екип, който постига значителни резултати за кратко време.
2. При никакви обстоятелства не е необходимо „персонализиране“ и изграждане на „патерици“ - само системни решения. По-добре е да отделите малко повече време, но да направите системно решение, което ще се използва от други клиенти. Между другото, това се случи, системата за плъгини и премахването на зависимостта от Azure предоставиха допълнителна стойност на други клиенти (здравей, Федерален закон 152).

Източник: www.habr.com