Зашто је банци потребан АИОпс и кровно праћење, или на чему се заснивају односи са клијентима?

У публикацијама на Хабре, већ сам писао о свом искуству изградње партнерства са мојим тимом (овде говори о томе како се саставља уговор о ортаклуку при покретању новог посла да се посао не би распао). А сада бих желео да причам о томе како изградити партнерство са клијентима, јер без њих неће бити шта да се распадне. Надам се да ће овај чланак бити користан стартапима који почињу да продају своје производе великим предузећима.

Тренутно водим стартуп под називом МОНК Дигитал лаб, где мој тим и ја развијамо производ за аутоматизацију процеса подршке и управљања корпоративним ИТ. Улазак на тржиште није лак задатак и почели смо са малим домаћим задатком, прошли кроз тржишне стручњаке, наше партнере и извршили сегментацију тржишта. Главно питање је било разумети „чије болове можемо најбоље излечити?“

Банке су ушле у ТОП 3 сегмента. И наравно, први на листи били су Тинкофф и Сбербанк. Када смо посетили стручњаке за банкарско тржиште, рекли су: уведите свој производ тамо и пут до банкарског тржишта ће бити отворен. Покушали смо да уђемо и тамо и тамо, али у Сбербанки нас је чекао неуспех, а момци из Тинкофа су се испоставили много отворенији за продуктивну комуникацију са руским стартапима (можда због чињенице да је Сбер у то време купио скоро милијарду наших западних конкурената). За месец дана започели смо пилот пројекат. Како се то догодило, прочитајте даље.

Дуги низ година се бавимо питањима рада и праћења, сада имплементирамо наш производ у јавном сектору, у осигурању, у банкама, у телеком компанијама, једна имплементација је била код авио компаније (пре пројекта нисмо ни мислим да је авијација била индустрија зависна од ИТ-а, и сада се заиста надамо, упркос ЦОВИД-у, да ће се компанија појавити и полетети).

Производ који правимо припада пословном софтверу, сегменту АИОпс (Вештачка интелигенција за ИТ операције или ИТОпс). Главни циљеви имплементације таквих система како се ниво зрелости процеса у компанији повећава:

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

Према нашем искуству, банке имају следеће „муке“ са праћењем које су заједничке свим великим ИТ инфраструктурама:

• „ко зна шта“: постоји много техничких одељења, скоро свако има бар један систем за праћење, а већина их има више од једног;
• „рој комараца“ упозорења: сваки систем генерише стотине и њиме бомбардује све одговорне (понекад и између одељења). Тешко је стално одржавати фокус контроле на сваком обавештењу, због великог броја;
• велике банке – лидери сектора желе не само да континуирано прате своје системе, да знају где има кварова, већ и праву магију вештачке интелигенције – да учине системе само-надгледајућим, самопредвиђеним и самоисправљајућим.

Када смо дошли на први састанак у Тинкофу, одмах нам је речено да немају проблема са праћењем и да их ништа не боли, а главно питање је било: „Шта можемо да понудимо онима који већ раде добро?“

Разговор је био дуг, разговарали смо о томе како се граде њихови микросервис, како функционишу одељења, који инфраструктурни проблеми су осетљивији, који мање осетљиви за кориснике, где су „слепе тачке“, и који су им циљеви и СЛА.

Иначе, СЛА банке су заиста импресивне. На пример, проблем доступности мреже приоритета 1 може да потраје само неколико минута да се реши. Цена грешке и застоја овде је, наравно, импресивна.

Као резултат тога, идентификовали смо неколико области сарадње:

1. прва фаза је кровно праћење како би се повећала брзина решавања инцидената
2. друга фаза је аутоматизација процеса за смањење ризика и смањење трошкова за скалирање ИТ одељења.

Неколико „белих тачака” могло је да се обоји у светле боје упозорења само обрадом информација из више система за праћење, пошто је било немогуће директно узети метрику, такође је било потребно централизовати податке из различитих система за праћење на „један екран” по реду да би разумели целокупну слику онога што се дешавало. "Кишобрани" су погодни за овај задатак и тада смо испунили ове услове.

Веома важна ствар, по нашем мишљењу, у односима са клијентима је искреност. Након првог разговора и обрачуна цене лиценце, речено је да, пошто је цена толико ниска, можда би вредело одмах купити лиценцу (у поређењу са Динатраце Клиуцх-Астром из горњег чланка о зеленој банци, наш лиценца кошта не трећину милијарде, већ 12 хиљада рубаља месечно за 1 гигабајт, за Сбер би то коштало неколико пута јефтиније). Али одмах смо им рекли шта имамо, а шта немамо. Можда би продајни представник великог интегратора могао да каже „да, можемо све, наравно да купимо нашу лиценцу“, али смо одлучили да све наше карте положимо на сто. У тренутку лансирања, наша кутија није имала интеграцију са Прометхеусом, а нова верзија са подсистемом за аутоматизацију је требало да буде објављена, али је још нисмо испоручили клијентима.

Пилот пројекат је почео, његове границе су одређене и добили смо 2 месеца. Главни задаци су били:

• припремите нову верзију платформе и примените је у инфраструктури банке
• повезати 2 система за праћење (Заббик и Прометхеус);
• слати обавештења одговорним у Слацк-у и путем СМС-а;
• покрените скрипте за аутохеалинг.

Први месец пилот пројекта протекао је у припреми нове верзије платформе у супербрзом режиму за потребе пилот пројекта. Нова верзија одмах укључује интеграцију са Прометејем и ауто-исцељење. Захваљујући нашем развојном тиму, нису спавали неколико ноћи, али су пустили оно што су обећали, а да нису пропустили рокове за друге раније преузете обавезе.

Док смо постављали пилот, наишли смо на нови проблем који би могао да затвори пројекат пре рока: да бисмо слали обавештења инстант месинџерима и путем СМС-а, биле су нам потребне долазне и одлазне везе са Мицрософт Азуре серверима (у то време смо користили ову платформу за слање упозорења у Слацк) и екстерну услугу слања СМС-а. Али у овом пројекту, безбедност је била посебан фокус. У складу са политиком банке, такве „рупе“ се ни под којим условима нису могле отварати. Све је морало да ради из затворене петље. Понуђено нам је да користимо АПИ сопствених интерних сервиса који шаљу упозорења Слацк-у и путем СМС-а, али нисмо имали прилику да повежемо такве сервисе ван кутије.

Вече дебате са развојним тимом завршено је успешном потрагом за решењем. Претурајући по заостатку, пронашли смо један задатак за који никада нисмо имали довољно времена и приоритета - да направимо систем додатака како би тимови за имплементацију или клијент сами могли да пишу додатке, проширујући могућности платформе.

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

Према Сергеју, нашем главном архитекти, потребно је најмање месец дана за имплементацију плуг-ин система.

Нисмо имали времена...

Постојало је само једно решење – идите код клијента и испричајте све како јесте. Разговарајте о промени рока заједно. И успело је. Добили смо додатне 2 недеље. Имали су и своје рокове и интерне обавезе да покажу резултате, али су имали 2 резервне недеље. На крају смо све ставили на коцку. Било је немогуће забрљати. Искреност и партнерски приступ поново су се исплатили.

Као резултат пилота, добијено је неколико важних техничких резултата и закључака:

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

Распоређени систем је почео исправно да прима упозорења од Прометеја и групише их. Упозорења о проблему од Прометхеус клијента су летела сваких 30 секунди (груписање по времену није омогућено), а ми смо се питали да ли би их било могуће груписати у самом „кишобрану“. Испоставило се да је то могуће - подешавање обраде упозорења на платформи се спроводи помоћу скрипте. Ово омогућава имплементацију готово сваке логике за њихову обраду. Већ смо имплементирали стандардну логику у платформу у облику шаблона - ако не желите да смислите нешто своје, можете користити готов.

„Синтетички окидач“ интерфејс. Подешавање обраде упозорења са повезаних система за праћење

Конструисано стање „здравља“ система

На основу упозорења креирани су догађаји праћења који су утицали на здравље конфигурационих јединица (ЦУ). Имплементирамо ресурсно-сервисни модел (РСМ), који може да користи или интерни ЦМДБ или да повеже екстерни – током пилот пројекта клијент није повезао сопствени ЦМДБ.

Интерфејс за рад са моделом ресурс-сервис. Пилот РСМ.

Па, у ствари, клијент коначно има један екран за праћење, где су видљиви догађаји из различитих система. Тренутно су два система повезана са „кишобраном“ - Заббик и Прометхеус, и интерни систем за праћење саме платформе.

Интерфејс аналитике. Један екран за праћење.

Покренута аутоматизација процеса

Праћење догађаја је покренуло покретање унапред конфигурисаних радњи – слање упозорења, покретање скрипти, регистровање/обогаћивање инцидената – ово последње није испробано са овим конкретним клијентом, јер у пилот пројекту није било интеграције са сервисном службом.

Интерфејс подешавања акције. Пошаљите упозорења у Слацк и поново покрените сервер.

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

Када се расправљало о скриптама за аутоматизацију, клијент је тражио подршку за басх и интерфејс у ​​којем би се ове скрипте могле погодно конфигурисати. Нова верзија је урадила мало више (могућност писања пуноправних логичких конструкција у Луа-и са подршком за цУРЛ, ССХ и СНМП) и имплементирала функционалност која вам омогућава да управљате животним циклусом скрипте (креирање, уређивање, контрола верзија , избришите и архивирајте).

Интерфејс за рад са скриптама за аутохеалинг. Скрипта за поновно покретање сервера преко ССХ-а.

Главни налази

Током пилота, креиране су и корисничке приче које побољшавају тренутну функционалност и повећавају вредност за клијента, ево неких од њих:

• имплементирати могућност прослеђивања променљивих директно из упозорења у скрипту за аутоматско лечење;
• додајте ауторизацију платформи преко Ацтиве Дирецтори-а.

И добили смо више глобалних изазова - да „надоградимо“ производ другим могућностима:

• аутоматска конструкција модела услуге ресурса заснованог на МЛ, а не на правилима и агентима (вероватно главни изазов сада);
• подршка за додатне језике за скриптовање и логику (а ово ће бити ЈаваСцрипт).

По мом мишљењу најважнија стварОно што овај пилот показује су две ствари:

1. Партнерски односи са клијентом су кључ ефикасности, када се ефективна комуникација гради на основу искрености и отворености, а клијент постаје део тима који за кратко време постиже значајне резултате.
2. Ни у ком случају није потребно „прилагођавати“ и правити „штаке“ – само системска решења. Боље је потрошити мало више времена, али направити системско решење које ће користити други клијенти. Иначе, ево шта се догодило, систем додатака и елиминисање зависности од Азуре-а пружили су додатну вредност другим клијентима (здраво, Савезни закон 152).

Извор: ввв.хабр.цом