Pam mae banc angen AIOps a monitro ambarél, neu ar beth mae perthnasoedd cwsmeriaid yn seiliedig?

Mewn cyhoeddiadau ar Habré, ysgrifennais eisoes am fy mhrofiad o adeiladu partneriaethau gyda fy nhîm (yma yn siarad am sut i lunio cytundeb partneriaeth wrth ddechrau busnes newydd fel nad yw’r busnes yn mynd yn ddarnau). Ac yn awr hoffwn siarad am sut i adeiladu partneriaethau gyda chleientiaid, oherwydd hebddynt ni fydd dim byd i ddisgyn ar wahân. Rwy'n gobeithio y bydd yr erthygl hon yn ddefnyddiol i fusnesau newydd sy'n dechrau gwerthu eu cynnyrch i fusnesau mawr.

Ar hyn o bryd rydw i'n arwain cwmni cychwynnol o'r enw MONQ Digital lab, lle mae fy nhîm a minnau'n datblygu cynnyrch ar gyfer awtomeiddio'r prosesau o gefnogi a gweithredu TG corfforaethol. Nid yw mynd i mewn i'r farchnad yn dasg hawdd ac fe wnaethom ddechrau gydag ychydig o waith cartref, aethom trwy arbenigwyr y farchnad, ein partneriaid a chynnal segmentiad marchnad. Y prif gwestiwn oedd deall “pa boenau y gallwn ni eu gwella orau?”

Daeth banciau yn y 3 segment TOP. Ac wrth gwrs, y rhai cyntaf ar y rhestr oedd Tinkoff a Sberbank. Pan wnaethom ymweld ag arbenigwyr marchnad bancio, dywedasant: cyflwynwch eich cynnyrch yno, a bydd y llwybr i'r farchnad fancio ar agor. Fe wnaethon ni geisio mynd i mewn yn y fan a'r lle, ond roedd methiant yn aros i ni yn Sberbank, a daeth y dynion o Tinkoff i fod yn llawer mwy agored i gyfathrebu cynhyrchiol â chwmnïau newydd o Rwsia (efallai oherwydd y ffaith bod Sber bryd hynny brynwyd bron i biliwn o'n cystadleuwyr Gorllewinol). O fewn mis fe ddechreuon ni brosiect peilot. Sut y digwyddodd, darllenwch ymlaen.

Rydym wedi bod yn delio â materion gweithredu a monitro ers blynyddoedd lawer, nawr rydym yn gweithredu ein cynnyrch yn y sector cyhoeddus, mewn yswiriant, mewn banciau, mewn cwmnïau telathrebu, roedd un gweithrediad gyda chwmni hedfan (cyn y prosiect, ni wnaethom hyd yn oed meddwl bod hedfan yn ddiwydiant mor ddibynnol ar TG, a Nawr rydyn ni wir yn gobeithio, er gwaethaf COVID, y bydd y cwmni'n dod i'r amlwg ac yn cychwyn).

Mae'r cynnyrch a wnawn yn perthyn i feddalwedd menter, y segment AIOps (Deallusrwydd Artiffisial ar gyfer Gweithrediadau TG, neu ITOps). Prif nodau gweithredu systemau o'r fath wrth i lefel aeddfedrwydd prosesau yn y cwmni gynyddu:

1. Cynnau tanau: nodi methiannau, clirio llif y rhybuddion o falurion, aseinio tasgau a digwyddiadau i'r rhai sy'n gyfrifol;
2. Cynyddu effeithlonrwydd y gwasanaeth TG: lleihau'r amser i ddatrys digwyddiadau, nodi achosion methiannau, cynyddu tryloywder y statws TG;
3. Cynyddu effeithlonrwydd busnes: lleihau faint o lafur llaw, lleihau risgiau, cynyddu teyrngarwch cwsmeriaid.

Yn ein profiad ni, mae gan fanciau y “poenau” canlynol gyda monitro yn gyffredin â phob seilwaith TG mawr:

• “pwy a wyr beth”: mae yna lawer o adrannau technegol, mae gan bron bawb o leiaf un system fonitro, ac mae gan y mwyafrif fwy nag un;
• “haid mosgito” o rybuddion: mae pob system yn cynhyrchu cannoedd ac yn peledu pawb sy'n gyfrifol gyda nhw (weithiau hefyd rhwng adrannau). Mae'n anodd cynnal ffocws rheolaeth yn gyson ar bob hysbysiad;
• banciau mawr - mae arweinwyr sector eisiau nid yn unig i fonitro eu systemau yn barhaus, i wybod lle mae methiannau, ond hefyd hud gwirioneddol AI - i wneud y systemau hunan-fonitro, hunan-rhagfynegiad a hunan-gywir.

Pan ddaethom i’r cyfarfod cyntaf yn Tinkoff, dywedwyd wrthym ar unwaith nad oedd ganddynt unrhyw broblemau gyda monitro ac nad oedd dim yn eu brifo, a’r prif gwestiwn oedd: “Beth allwn ni ei gynnig i’r rhai sydd eisoes yn gwneud yn dda?”

Roedd y sgwrs yn hir, buom yn trafod sut mae eu microwasanaethau yn cael eu hadeiladu, sut mae adrannau'n gweithio, pa broblemau seilwaith sy'n fwy sensitif, sy'n llai sensitif i ddefnyddwyr, ble mae'r “mannau dall”, a beth yw eu nodau a'u CLGau.

Gyda llaw, mae CLGau y banc yn drawiadol iawn. Er enghraifft, efallai mai dim ond ychydig funudau y bydd digwyddiad argaeledd rhwydwaith blaenoriaeth 1 yn ei gymryd i'w ddatrys. Mae cost gwallau ac amser segur yma, wrth gwrs, yn drawiadol.

O ganlyniad, rydym wedi nodi sawl maes cydweithredu:

1. y cam cyntaf yw monitro ymbarél i gynyddu cyflymder datrys digwyddiadau
2. yr ail gam yw awtomeiddio prosesau i leihau risgiau a lleihau costau ar gyfer graddio'r adran TG.

Dim ond trwy brosesu gwybodaeth o sawl system fonitro y gellid peintio sawl “smotiau gwyn” yn lliwiau llachar rhybuddion, gan ei bod yn amhosibl cymryd metrigau yn uniongyrchol hefyd; i ddeall y darlun cyffredinol o'r hyn sy'n digwydd. Mae “ymbaréls” yn addas ar gyfer y dasg hon ac fe wnaethom gwrdd â’r gofynion hyn bryd hynny.

Peth pwysig iawn, yn ein barn ni, mewn perthynas â chleientiaid yw gonestrwydd. Ar ôl y sgwrs gyntaf a chyfrifo cost y drwydded, dywedwyd gan fod y gost mor isel, efallai y byddai'n werth prynu trwydded ar unwaith (o'i gymharu â Dynatrace Klyuch-Astrom o'r erthygl uchod am y banc gwyrdd, ein trwydded yn costio nid traean o biliwn, ond 12 mil rubles y mis ar gyfer 1 gigabyte, ar gyfer Sber byddai'n costio sawl gwaith yn rhatach). Ond fe wnaethon ni ddweud wrthyn nhw ar unwaith beth sydd gennym ni a beth sydd ddim gyda ni. Efallai y gallai cynrychiolydd gwerthu o integreiddiwr mawr ddweud “ie, gallwn ni wneud popeth, wrth gwrs prynu ein trwydded,” ond fe benderfynon ni osod ein holl gardiau ar y bwrdd. Ar adeg ei lansio, nid oedd gan ein blwch integreiddiad â Prometheus, ac roedd fersiwn newydd gydag is-system awtomeiddio ar fin cael ei ryddhau, ond nid ydym wedi ei anfon at gleientiaid eto.

Dechreuodd y prosiect peilot, pennwyd ei ffiniau a chawsom 2 fis. Y prif dasgau oedd:

• paratoi fersiwn newydd o'r platfform a'i ddefnyddio yn seilwaith y banc
• cysylltu 2 system fonitro (Zabbix a Prometheus);
• anfon hysbysiadau at y rhai sy'n gyfrifol yn Slack a thrwy SMS;
• rhedeg sgriptiau hunaniacháu.

Treuliwyd mis cyntaf y prosiect peilot yn paratoi fersiwn newydd o'r platfform mewn modd cyflym iawn ar gyfer anghenion y prosiect peilot. Mae'r fersiwn newydd yn syth yn cynnwys integreiddio â Prometheus a auto-iachau. Diolch i'n tîm datblygu, ni wnaethant gysgu am sawl noson, ond rhyddhawyd yr hyn a addawyd ganddynt heb golli'r terfynau amser ar gyfer ymrwymiadau eraill a wnaed yn flaenorol.

Tra roeddem yn sefydlu'r peilot, daethom ar draws problem newydd a allai gau'r prosiect yn gynt na'r disgwyl: i anfon rhybuddion at negeswyr gwib a thrwy SMS, roedd angen cysylltiadau sy'n dod i mewn ac yn mynd allan i weinyddion Microsoft Azure (ar y pryd roeddem yn defnyddio'r platfform hwn). i anfon rhybuddion i Slack) a gwasanaeth anfon allanol SMS. Ond yn y prosiect hwn, roedd diogelwch yn ffocws penodol. Yn unol â pholisi’r banc, ni ellid agor “tyllau” o’r fath dan unrhyw amgylchiadau. Roedd yn rhaid i bopeth weithio o ddolen gaeedig. Cynigiwyd i ni ddefnyddio API ein gwasanaethau mewnol ein hunain sy'n anfon rhybuddion i Slack a thrwy SMS, ond ni chawsom gyfle i gysylltu gwasanaethau o'r fath allan o'r bocs.

Daeth noson o ddadlau gyda'r tîm datblygu i ben gyda chwiliad llwyddiannus am ateb. Ar ôl chwilota drwy'r ôl-groniad, daethom o hyd i un dasg nad oedd gennym erioed ddigon o amser a blaenoriaeth ar ei chyfer - creu system plug-in fel y gallai'r timau gweithredu neu'r cleient ysgrifennu ychwanegion eu hunain, gan ehangu galluoedd y platfform.

Ond roedd gennym union fis ar ôl, pan oedd yn rhaid i ni osod popeth, ffurfweddu a defnyddio awtomeiddio.

Yn ôl Sergei, ein prif bensaer, mae'n cymryd o leiaf mis i weithredu'r system plug-in.

Nid oedd gennym amser...

Dim ond un ateb oedd - ewch at y cleient a dywedwch bopeth fel y mae. Trafod y newid dyddiad cau gyda'ch gilydd. Ac fe weithiodd. Cawsom 2 wythnos ychwanegol. Roedd ganddynt hefyd eu terfynau amser eu hunain a rhwymedigaethau mewnol i ddangos canlyniadau, ond roedd ganddynt 2 wythnos wrth gefn. Yn y diwedd, rydyn ni'n rhoi popeth ar y llinell. Roedd yn amhosibl gwneud llanast. Unwaith eto, talodd gonestrwydd a dull partneriaeth ar ei ganfed.

O ganlyniad i'r peilot, cafwyd nifer o ganlyniadau technegol a chasgliadau pwysig:

Fe wnaethon ni brofi'r swyddogaeth newydd ar gyfer prosesu rhybuddion

Dechreuodd y system a ddefnyddiwyd dderbyn rhybuddion yn gywir gan Prometheus a'u grwpio. Roedd rhybuddion am y broblem gan y cleient Prometheus yn hedfan bob 30 eiliad (nid yw grwpio yn ôl amser wedi'i alluogi), ac roeddem yn meddwl tybed a fyddai'n bosibl eu grwpio yn yr “ymbarél” ei hun. Mae'n troi allan ei bod yn bosibl - sefydlu prosesu rhybuddion yn y llwyfan yn cael ei weithredu gan sgript. Mae hyn yn ei gwneud hi'n bosibl gweithredu bron unrhyw resymeg ar gyfer eu prosesu. Rydyn ni eisoes wedi gweithredu rhesymeg safonol yn y platfform ar ffurf templedi - os nad ydych chi am feddwl am rywbeth eich hun, gallwch chi ddefnyddio un parod.

Rhyngwyneb “sbardun synthetig”. Sefydlu prosesu rhybuddion o systemau monitro cysylltiedig

Adeiladwyd cyflwr “iechyd” y system

Yn seiliedig ar rybuddion, crëwyd digwyddiadau monitro a effeithiodd ar iechyd unedau cyfluniad (CUs). Rydym yn gweithredu model gwasanaeth adnoddau (RSM), a all ddefnyddio naill ai CMDB mewnol neu gysylltu un allanol - yn ystod y prosiect peilot ni gysylltodd y cleient ei CMDB ei hun.

Rhyngwyneb ar gyfer gweithio gyda'r model gwasanaeth adnoddau. RSM peilot.

Wel, mewn gwirionedd, mae gan y cleient sgrin fonitro sengl o'r diwedd, lle mae digwyddiadau o wahanol systemau yn weladwy. Ar hyn o bryd, mae dwy system wedi'u cysylltu â'r “ymbarél” - Zabbix a Prometheus, a system fonitro fewnol y platfform ei hun.

Rhyngwyneb dadansoddeg. Sgrin fonitro sengl.

Wedi lansio awtomeiddio proses

Sbardunodd digwyddiadau monitro lansiad gweithredoedd wedi'u ffurfweddu ymlaen llaw - anfon rhybuddion, rhedeg sgriptiau, cofrestru / cyfoethogi digwyddiadau - ni roddwyd cynnig ar yr olaf gyda'r cleient penodol hwn, oherwydd yn y prosiect peilot nid oedd unrhyw integreiddio gyda'r ddesg wasanaeth.

Rhyngwyneb gosodiadau gweithredu. Anfon rhybuddion i Slack ac ailgychwyn y gweinydd.

Ymarferoldeb cynnyrch estynedig

Wrth drafod sgriptiau awtomeiddio, gofynnodd y cleient am gefnogaeth bash a rhyngwyneb lle gellid ffurfweddu'r sgriptiau hyn yn gyfleus. Mae'r fersiwn newydd wedi gwneud ychydig mwy (y gallu i ysgrifennu lluniadau rhesymegol llawn yn Lua gyda chefnogaeth ar gyfer cURL, SSH a SNMP) ac wedi gweithredu ymarferoldeb sy'n eich galluogi i reoli cylch bywyd sgript (creu, golygu, rheoli fersiwn , dileu ac archifo).

Rhyngwyneb ar gyfer gweithio gyda sgriptiau iachau awtomatig. Sgript ailgychwyn gweinydd trwy SSH.

Canfyddiadau Allweddol

Yn ystod y peilot, crëwyd straeon defnyddwyr hefyd sy'n gwella'r ymarferoldeb presennol ac yn cynyddu gwerth i'r cleient, dyma rai ohonynt:

• gweithredu'r gallu i anfon newidynnau ymlaen yn uniongyrchol o'r rhybudd i'r sgript hunaniacháu;
• ychwanegu awdurdodiad i'r platfform trwy Active Directory.

A chawsom fwy o heriau byd-eang - “adeiladu” y cynnyrch gyda galluoedd eraill:

• adeiladu model gwasanaeth-adnodd yn awtomatig yn seiliedig ar ML, yn hytrach na rheolau ac asiantau (mae'n debyg mai'r brif her nawr);
• cefnogaeth ar gyfer ieithoedd sgriptio a rhesymeg ychwanegol (a JavaScript fydd hwn).

Yn fy marn i, y pwysicafMae’r hyn y mae’r peilot hwn yn ei ddangos yn ddau beth:

1. Partneriaethau gyda'r cleient yw'r allwedd i effeithiolrwydd, pan fydd cyfathrebu effeithiol yn cael ei adeiladu ar sail gonestrwydd a didwylledd, a'r cleient yn dod yn rhan o dîm sy'n cyflawni canlyniadau arwyddocaol mewn amser byr.
2. Nid oes angen “addasu” ac adeiladu “baglau” o dan unrhyw amgylchiadau - atebion system yn unig. Mae'n well treulio ychydig mwy o amser, ond gwneud datrysiad system a fydd yn cael ei ddefnyddio gan gleientiaid eraill. Gyda llaw, dyma beth ddigwyddodd, rhoddodd y system ategyn a dileu dibyniaeth ar Azure werth ychwanegol i gleientiaid eraill (helo, Cyfraith Ffederal 152).

Ffynhonnell: hab.com