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

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

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

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

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

Продуктът, който разработваме, попада в обхвата на AIOps (Изкуствен интелект за ИТ операции, или ITOps) - корпоративен софтуер. Основните цели на внедряването на такива системи с развитието на процесите в компанията са:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имаше само едно решение: да отидем при клиента и да му обясним всичко както е било. Обсъдихме заедно удължаване на срока. И то проработи. Дадоха ни допълнителни две седмици. Те имаха свои собствени срокове и вътрешни ангажименти за постигане на резултати, но имаха две седмици резерва. В крайна сметка заложихме всичко на карта. Нямаше как да се объркаме. Честността и съвместният подход отново се отплатиха.

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

Тествахме нова функционалност за обработка на предупреждения

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

Интерфейс за синтетичен тригер. Конфигуриране на обработка на предупреждения от свързани системи за мониторинг

Изградихме здравословното състояние на системата

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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