In publicazioni nantu à Habré, aghju digià scrittu annantu à a mo sperienza di custruisce partenarii cù a mo squadra ( parla di cumu fà un accordu di partenariatu quandu principia una nova impresa per chì l'affari ùn cascà micca). È avà vogliu parlà di cumu custruisce partenarii cù i clienti, postu chì senza elli ùn ci sarà nunda di fallu. Spergu chì questu articulu serà utile à i startups chì cumincianu à vende u so pruduttu à e grande imprese.
Attualmente dirigu una startup chjamata MONQ Digital lab, induve a mo squadra è eiu sviluppemu un pruduttu per l'automatizazione di i prucessi di supportu è operazione di l'IT corporativu. Entra in u mercatu ùn hè micca un compitu faciule è avemu principiatu cù un pocu di travagliu in casa, passava per sperti di u mercatu, i nostri partenarii è realizatu a segmentazione di u mercatu. A quistione principale era di capisce "quale dolore pudemu guarisce megliu?"
I banche anu fattu in i segmenti TOP 3. E sicuru, i primi nantu à a lista eranu Tinkoff è Sberbank. Quandu avemu visitatu l'esperti di u mercatu bancariu, anu dettu: intruduce u vostru pruduttu quì, è u percorsu à u mercatu bancariu serà apertu. Avemu pruvatu à entre in là è quì, ma u fallimentu ci aspittava à Sberbank, è i picciotti di Tinkoff si sò rivelati assai più aperti à a cumunicazione produttiva cù startups russi (forse per u fattu chì Sber in quellu tempu). quasi un miliardo di i nostri cuncurrenti occidentali). In un mese avemu principiatu un prughjettu pilotu. Cumu hè accadutu, leghjite.
Avemu trattatu di prublemi di funziunamentu è monitoraghju per parechji anni, avà avemu implementatu u nostru pruduttu in u settore publicu, in l'assicuranza, in i banche, in l'imprese di telecomunicazioni, una implementazione hè stata cù una compagnia aerea (prima di u prugettu, ùn avemu micca ancu. pensate chì l'aviazione era una industria cusì dipendente da l'informatica, è avà speremu veramente, malgradu COVID, chì a cumpagnia emergerà è decolla).
U pruduttu chì facemu appartene à u software di l'impresa, u segmentu AIOps (Intelligenza Artificiale per Operazioni IT, o ITOps). I scopi principali di implementà tali sistemi cum'è u livellu di maturità di u prucessu in a cumpagnia aumenta:
- Spegne l'incendii: identificà i fallimenti, sguassate u flussu di alerti da i detriti, assignate compiti è incidenti à i rispunsevuli;
- Aumentà l'efficienza di u serviziu di l'IT: riduce u tempu per risolve incidenti, indicà e cause di fallimenti, aumenta a trasparenza di u statutu IT;
- Aumentà l'efficienza cummerciale: riduce a quantità di travagliu manuale, riduce i risichi, aumenta a fidelizazione di i clienti.
In a nostra sperienza, i banche anu i seguenti "dolori" cù u monitoraghju in cumunu cù tutte e grandi infrastrutture IT:
- "quale sà chì": ci sò parechji dipartimenti tecnichi, quasi tutti anu almenu un sistema di surviglianza, è a maiò parte anu più di unu;
- "mosquito swarm" di alerti: ogni sistema genera centinaie è bombarda tutti i rispunsevuli cun elli (à volte ancu trà dipartimenti). Hè difficiuli di mantene constantemente u focu di cuntrollu nantu à ogni notificazione, a so urgenza è l'impurtanza hè livellu per u grande numaru;
- grandi banche - i capi di u settore ùn volenu micca solu monitorà continuamente i so sistemi, per sapè induve ci sò fallimenti, ma ancu a vera magia di l'AI - per fà i sistemi auto-monitor, auto-predict è auto-corrette.
Quandu simu ghjunti à a prima riunione in Tinkoff, ci hè statu immediatamente dettu chì ùn avianu micca prublemi cù u monitoraghju è nunda ùn li fece male, è a quistione principale era: "Chì pudemu offre per quelli chì sò digià bè?"
A conversazione hè stata longa, avemu discututu cumu sò custruiti i so microservizi, cumu travaglianu i dipartimenti, quali prublemi di l'infrastruttura sò più sensibili, chì sò menu sensibili per l'utilizatori, induve sò i "punti cecchi", è quali sò i so scopi è SLA.
Per via, i SLA di u bancu sò veramente impressiunanti. Per esempiu, un incidente di dispunibilità di a rete di priorità 1 pò piglià solu uni pochi di minuti per risolve. U costu di l'errore è u tempu di inattività quì, sicuru, hè impressiunanti.
In u risultatu, avemu identificatu parechji spazii di cooperazione:
- a prima tappa hè u monitoraghju umbrella per aumentà a velocità di risoluzione di incidenti
- a seconda tappa hè l'automatizazione di u prucessu per riduce i risichi è riduce i costi per a scala di u dipartimentu IT.
Diversi "spots bianchi" puderanu esse dipinti in i culori brillanti di l'alerta solu per trasfurmà l'infurmazioni da parechji sistemi di surviglianza, postu chì era impussibile di piglià metrica direttamente, era ancu necessariu di centralizà e dati da diversi sistemi di monitoraghju nantu à "una schermu". per capiscenu a stampa generale di ciò chì era successu. "Umbrellas" sò adattati per questu compitu è avemu scontru sti esigenze allora.
Una cosa assai impurtante, in u nostru parè, in relazioni cù i clienti hè l'onestà. Dopu à a prima cunversazione è u calculu di u costu di a licenza, si dicia chì, postu chì u costu hè cusì bassu, puderia vale a pena cumprà una licenza subitu (paragunatu à Dynatrace Klyuch-Astrom da l'articulu sopra à u bancu verde, u nostru a licenza ùn costa micca un terzu di un miliardo, ma 12 mila rubles per mese per 1 gigabyte, per Sber costava parechje volte più prezzu). Ma avemu dettu immediatamente ciò chì avemu è ciò chì ùn avemu micca. Forsi un rappresentante di vendita da un grande integratore puderia dì "sì, pudemu fà tuttu, sicuru cumprà a nostra licenza", ma avemu decisu di mette tutte e nostre carte nantu à a tavula. À u mumentu di u lanciu, a nostra scatula ùn hà micca integrazione cù Prometheus, è una nova versione cù un subsistema di automatizazione era per esse liberata, ma ùn l'avemu micca speditu à i clienti.
U prughjettu pilotu principia, i so cunfini sò stati determinati è ci sò stati dati 2 mesi. I travaglii principali eranu:
- preparanu una nova versione di a piattaforma è implementate in l'infrastruttura di u bancu
- cunnette 2 sistemi di monitoraghju (Zabbix è Prometheus);
- mandate notifiche à i rispunsevuli in Slack è via SMS;
- eseguite script di autoguarigione.
U primu mese di u prughjettu pilotu hè statu passatu per preparà una nova versione di a piattaforma in modu super-rapidu per i bisogni di u prughjettu pilotu. A nova versione include immediatamente integrazione cù Prometheus è auto-guarigione. Grazie à a nostra squadra di sviluppu, ùn anu micca dormitu per parechje notti, ma hà liberatu ciò chì anu prumessu senza missà i termini per altri impegni previamente fattu.
Mentre stavamu a stallazione di u pilotu, avemu scontru un novu prublema chì puderia chjude u prugettu prima di u calendariu: per mandà avvisi à i messaggeri istantanei è via SMS, avemu bisognu di cunnessione in entrata è in uscita à i servitori Microsoft Azure (à quellu tempu avemu usatu sta piattaforma). per mandà alerti à Slack) è un serviziu di mandatu esternu SMS. Ma in stu prughjettu, a sicurità era un focusu particulare. In cunfurmità cù a pulitica di u bancu, tali "buchi" ùn pò micca esse apertu in ogni circustanza. Tuttu avia da travaglià da un ciclu chjusu. Ci hè statu prupostu di utilizà l'API di i nostri servizii internu chì mandanu alerti à Slack è via SMS, ma ùn avemu micca avutu l'uppurtunità di cunnette tali servizii fora di a scatula.
Una sera di dibattitu cù a squadra di sviluppu hè finita cù una ricerca riescita di una suluzione. Dopu avè rummaged through the backlog, truvamu un compitu per quale ùn avemu mai avutu abbastanza tempu è priorità - per creà un sistema di plug-in in modu chì i squadre di implementazione o u cliente puderanu scrive add-ons elli stessi, espansione e capacità di a piattaforma.
Ma avemu avutu esattamente un mesi, durante u quale duvemu installà tuttu, cunfigurà è implementà l'automatizazione.
Sicondu Sergei, u nostru architettu capu, ci vole almenu un mesi per implementà u sistema di plug-in.
Ùn avemu micca tempu...
Ci era una solu suluzione - andate à u cliente è dite tuttu ciò chì hè. Discutete u cambiamentu di scadenza inseme. È hà travagliatu. Ci hè statu datu 2 settimane extra. Anu ancu avutu i so propri termini è obbligazioni internu per vede risultati, ma avianu 2 settimane di riserva. In fine, mettemu tuttu nantu à a linea. Era impussibile di miss up. L'onestà è un accostu di partenariatu hà tornatu pagatu.
In u risultatu di u pilotu, parechji risultati tecnichi impurtanti è cunclusioni sò stati ottenuti:
Avemu pruvatu a nova funziunalità per trattà l'alerte
U sistema implementatu hà cuminciatu à riceve avvisi currettamente da Prometheus è u gruppu. L'alerte nantu à u prublema da u cliente Prometheus volavanu ogni 30 seconde (u raggruppamentu per u tempu ùn hè micca attivatu), è ci dumandavamu s'ellu puderia esse raggruppatu in u "umbrella" stessu. Hè risultatu chì hè pussibule - a creazione di u processu di alerti in a piattaforma hè implementata da un script. Questu permette di implementà quasi ogni logica per u processu. Avemu digià implementatu a logica standard in a piattaforma in forma di mudelli - se ùn vulete micca vene cun qualcosa di u vostru propiu, pudete aduprà una pronta.
Interfaccia "triggeru sinteticu". Configurazione di trasfurmazioni di avvisi da i sistemi di surviglianza cunnessi
Custruitu u statu di "salute" di u sistema
Basatu nantu à l'alerta, l'avvenimenti di monitoraghju sò stati creati chì anu affettatu a salute di unità di cunfigurazione (CU). Implementemu un mudellu di serviziu di risorsa (RSM), chì pò utilizà sia un CMDB internu, sia cunnessu un esternu - durante u prughjettu pilotu u cliente ùn hà micca cunnessu u so propiu CMDB.
Interfaccia per travaglià cù u mudellu di serviziu di risorse. Pilot RSM.
Eppo, in fattu, u cliente hà infine una sola schermu di monitoraghju, induve l'avvenimenti da diversi sistemi sò visibili. Attualmente, dui sistemi sò cunnessi à u "umbrella" - Zabbix è Prometheus, è un sistema di monitoraghju internu di a piattaforma stessu.
Interfaccia analítica. Unicu schermu di monitoraghju.
Lanciata l'automatizazione di u prucessu
L'avvenimenti di monitoraghju hà attivatu u lanciamentu di l'azzioni pre-configurate - l'inviu di avvisi, l'esecuzione di script, l'incidentu di registrazione / arricchimentu - l'ultimu ùn hè statu pruvatu cù stu cliente particulari, perchè in u prughjettu pilotu ùn ci era micca integrazione cù u serviziu di serviziu.
Interfaccia di paràmetri di azzione. Mandate avvisi à Slack è riavviate u servitore.
Funzionalità di u produttu allargata
Quandu si discute di script d'automatizazione, u cliente hà dumandatu u supportu bash è una interfaccia in quale questi script puderanu esse cunfigurati convenientemente. A nova versione hà fattu un pocu di più (a capacità di scrive custruzzione logica cumpleta in Lua cù supportu per cURL, SSH è SNMP) è implementatu funziunalità chì permette di gestisce u ciclu di vita di un script (creà, edità, cuntrollu di versione). , sguassà è archiviu).
Interfaccia per travaglià cù script di autohealing. Script di reboot di u servitore via SSH.
Risultati chjave
Durante u pilotu, sò stati creati ancu storie d'utilizatori chì migliurà a funziunalità attuale è aumentanu u valore per u cliente, eccu alcuni di elli:
- implementà a capacità di trasmette variabili direttamente da l'alerta à l'script di autohealing;
- aghjunghje l'autorizazione à a piattaforma via Active Directory.
È avemu ricevutu più sfide glubale - per "custruisce" u pruduttu cù altre capacità:
- custruzzione autumàticu di un mudellu risorsa-serviziu basatu nantu ML, piuttostu cà regule è agenti (probabilmente u principale sfida avà);
- supportu per scripting supplementari è lingue logiche (è questu serà JavaScript).
A mo parè u più impurtanteCiò chì mostra stu pilotu hè duie cose:
- Partenariati cù u cliente sò a chjave per l'efficacità, quandu a cumunicazione efficace hè custruita nantu à a basa di l'onestà è l'apertura, è u cliente diventa parte di una squadra chì ottene risultati significativi in pocu tempu.
- In nisuna circustanza hè necessariu di "personalizà" è di custruisce "crutches" - solu suluzioni di u sistema. Hè megliu passà un pocu di più tempu, ma fate una suluzione di sistema chì serà utilizata da altri clienti. A strada, questu hè ciò chì hè accadutu, u sistema di plugins è l'eliminazione di a dependenza di Azure furnisce un valore supplementu à l'altri clienti (salutu, a Legge Federale 152).
Source: www.habr.com