Di weşanên li ser Habré de, min berê li ser ezmûna xwe ya avakirina hevkariya bi tîmê xwe re nivîsand ( diaxive ka meriv çawa dema ku karsaziyek nû dest pê dike peymanek hevkariyê çêdike da ku karsaz ji hev dernekevin). Û naha ez dixwazim biaxivim ka meriv çawa bi xerîdaran re hevkariyê ava dike, ji ber ku bêyî wan dê tiştek ji hev veqete. Ez hêvî dikim ku ev gotar dê ji bo destpêkên ku dest bi firotina hilberê xwe ji karsaziyên mezin re dikin kêrhatî be.
Ez naha serokatiyek bi navê MONQ Digital lab, ku ez û tîmê xwe ji bo otomatîkkirina pêvajoyên piştgirî û xebitandina IT-ya pargîdanî hilberek pêşdixin. Ketina bazarê ne karekî hêsan e û me bi hindik karê malê dest pê kir, bi pisporên bazarê, hevkarên xwe re derbas bûn û perçekirina bazarê pêk anî. Pirsa sereke ev bû ku meriv fêm bike "em çêtirîn derdên kê dikarin qenc bikin?"
Bankan ew kirin nav 3 beşên TOP. Û bê guman, di lîsteyê de yekem Tinkoff û Sberbank bûn. Dema ku me serdana pisporên bazara bankê kir, wan got: berhema xwe li wir bidin nasîn, dê rê li ber bazara bankê vebe. Me hewl da ku em hem li wir û hem jî li wir bikevin, lê têkçûn li Sberbank li benda me bû, û xortên ji Tinkoff ji danûstendina hilberîner re bi destpêkek rûsî re pir vekirîtir bûn (dibe ku ji ber vê yekê ku Sber wê demê hema mîlyarek hevrikên me yên rojavayî). Di nava mehekê de me dest bi projeyek pîlot kir. Çawa çêbû, bixwînin.
Bi salan e em bi mijarên xebitandin û çavdêriyê re mijûl bûne, niha em hilberê xwe di sektora giştî de, di bîmeyê de, di bankan de, di pargîdaniyên telekomê de bicîh dikin, yek pêkanîn bi firokeyek re bû (beriya projeyê, me ne jî bifikirin ku hewavanî pîşesaziyek wusa girêdayî IT-ê bû, û Naha em bi rastî hêvî dikin, tevî COVID, ku pargîdanî derkeve û rabe).
Berhema ku em çêdikin aîdî nermalava pargîdaniyê ye, beşa AIOps (Intelligence Artificial for IT Operations, an ITOps). Armancên sereke yên pêkanîna pergalên weha wekî asta gihîştina pêvajoyê di pargîdaniyê de zêde dibe:
- Agir bitemirînin: têkçûnan nas bikin, pêla hişyariyê ji mayînan paqij bikin, peywir û bûyeran bidin berpirsiyaran;
- Karbidestiya karûbarê IT-ê zêde bikin: dema çareserkirina bûyeran kêm bikin, sedemên têkçûnan destnîşan bikin, zelaliya rewşa IT-ê zêde bikin;
- Karbidestiya karsaziyê zêde bikin: mîqdara keda destan kêm bikin, xetereyan kêm bikin, dilsoziya xerîdar zêde bikin.
Di ezmûna me de, bankan bi çavdêrîkirina bi hemî binesaziyên mezin ên IT-ê re "êş"ên jêrîn hene:
- "Kî çi dizane": gelek beşên teknîkî hene, hema hema her kes bi kêmanî yek pergala çavdêriyê heye, û piraniya wan ji yekê zêdetir in;
- "Girê mêş" a hişyariyan: her pergal bi sedan diafirîne û hemî berpirsiyaran bi wan re bombebaran dike (carinan jî di navbera beşan de). Zehmet e ku meriv bi berdewamî baldariya kontrolê li ser her ragihandinê bihêle û girîngiya wan ji ber hejmara mezin;
- bankên mezin - serokên sektorê ne tenê dixwazin ku bi domdarî pergalên xwe bişopînin, zanibin ku li ku derê têkçûn hene, lê di heman demê de sêrbaziya rastîn a AI-yê jî dixwazin - pergalan bikin ku xwe-şopandin, xwe-pêşbînîkirin û xwe rast bikin.
Dema ku em hatin civîna yekem a li Tinkoff, yekser ji me re hat gotin ku di çavdêriyê de ti pirsgirêkek wan tune û tiştek zirarê nade wan, û pirsa sereke ev bû: "Em dikarin çi pêşkêşî wan kesan bikin ku jixwe baş dikin?"
Axaftin dirêj bû, me nîqaş kir ka mîkroxizmetên wan çawa têne çêkirin, ka beş çawa dixebitin, kîjan pirsgirêkên binesaziyê hesastir in, kîjan ji bikarhêneran re kêmtir hesas in, "xizmên kor" li ku ne, û armanc û SLA-yên wan çi ne.
Bi awayê, SLA-yên bankê bi rastî bandorker in. Mînakî, bûyerek hebûna torê ya pêşîn 1 dikare tenê çend hûrdeman bigire ku çareser bibe. Mesrefa xeletî û demdirêj li vir, bê guman, balkêş e.
Di encamê de, me gelek warên hevkariyê destnîşan kirin:
- qonaxa yekem çavdêriya sîwanê ye ku leza çareserkirina bûyerê zêde bike
- qonaxa duyemîn otomasyona pêvajoyê ye ku xetereyan kêm bike û lêçûnên ji bo pîvandina beşa IT kêm bike.
Gelek "lûkên spî" tenê bi hilanîna agahdariya ji çend pergalên çavdêriyê ve dikaribû bi rengên ronî yên hişyariyê were boyax kirin, ji ber ku ne gengaz bû ku meriv rasterast metrîkan bigire, di heman demê de hewce bû ku daneyên ji pergalên çavdêriyê yên cihêreng li ser "yek ekranê" were navend kirin ji bo fêmkirina wêneya giştî ya ku diqewime. "Siwan" ji bo vî karî minasib in û me wê demê van daxwazan bi cih anî.
Tiştek pir girîng, bi dîtina me, di têkiliyên bi xerîdaran re dilsoz e. Piştî sohbeta yekem û hesabkirina lêçûna lîsansê, hate gotin ku ji ber ku lêçûn ew qas kêm e, dibe ku hêjayî kirîna lîsansek tavilê be (li gorî Dynatrace Klyuch-Astrom ji gotara li jor di derbarê banka kesk, me mesrefa lîsansê ne sêyek milyarek, lê 12 hezar ruble mehê ji bo 1 gigabyte, ji bo Sber ew ê çend caran erzantir be). Lê me yekser ji wan re got ku em çi hene û çi ne. Dibe ku nûnerek firotanê ji entegratorek mezin dikare bibêje "erê, em dikarin her tiştî bikin, bê guman destûrnameya xwe bikirin", lê me biryar da ku em hemî kartên xwe deynin ser maseyê. Di dema destpêkirinê de, qutiya me bi Prometheus re entegrasyonek tune bû, û guhertoyek nû ya bi bine-pergala otomasyonê dê were berdan, lê me hîn ew ji xerîdaran re neşandine.
Projeya pîlot dest pê kir, sînorên wê hatin diyarkirin û 2 meh maweya me hat dayîn. Karên sereke ev bûn:
- guhertoyek nû ya platformê amade bike û di binesaziya bankê de bicîh bike
- 2 pergalên çavdêriyê (Zabbix û Prometheus) ve girêdin;
- ji berpirsiyarên Slack re û bi SMS-ê agahdariyan bişînin;
- skrîptên otohealing bimeşînin.
Meha yekem a projeya pîlotê ji bo hewcedariyên projeya pîlotê ji bo amadekirina guhertoyek nû ya platformê di moda super-lez de derbas bû. Guhertoya nû tavilê entegrasyona bi Prometheus û oto-healing vedihewîne. Spas ji tîmê meya pêşkeftinê re, wan çend şevan xew nekir, lê tiştê ku wan soz dabû serbest berdan bêyî ku dev ji muhletên ji bo sozên din ên berê hatine çêkirin berdan.
Dema ku me pîlotê saz dikir, me bi pirsgirêkek nû re rû bi rû ma ku dikaribû projeyê li pêş wextê bigire: ji bo şandina agahiyê ji peyamberên tavilê û bi SMS-ê re, me hewceyê girêdanên hatin û derketinê bi pêşkêşkerên Microsoft Azure re (di wê demê de me ev platform bikar anî ji bo şandina hişyariyan ji Slack re) û karûbarê şandina derve ya SMS. Lê di vê projeyê de, ewlehî girîngiyek taybetî bû. Li gorî polîtîkaya bankê, di bin tu şert û mercan de nedihatin vekirin. Diviyabû her tişt ji xelekek girtî bixebite. Ji me re hate pêşniyar kirin ku em API-ya karûbarên xwe yên hundurîn bikar bînin ku hişyariyan ji Slack û bi SMS-ê re dişînin, lê me fersend tune ku em karûbarên weha ji qutiyê ve girêbidin.
Êvara nîqaşê ya bi tîmê pêşveçûnê re bi lêgerînek serfiraz a çareseriyê bi dawî bû. Piştî ku li paşnavê geriyan, me yek peywirek dît ku ji bo wê tu carî dem û pêşîniya me têr nebû - em pergalek pêvekê biafirînin da ku tîmên pêkanînê an xerîdar karibin xwe pêvekan binivîsin, kapasîteyên platformê berfireh bikin.
Lê me tam mehek mabû, di dema ku me neçar ma ku her tiştî saz bikin, mîheng bikin û otomatê bi cîh bikin.
Li gorî Sergei, mîmarê me yê sereke, ji bo pêkanîna pergala pêvekirinê herî kêm mehek hewce dike.
Wextê me tunebû...
Tenê yek çareserî hebû - herin ba xerîdar û her tiştî wekî ku ye bibêjin. Bi hev re guhertina muhletê nîqaş bikin. Û ew xebitî. Ji me re 2 hefte zêde hat dayîn. Di heman demê de mawe û erkên wan ên navxweyî jî hebûn ku encaman nîşan bidin, lê wan 2 hefteyên rezervan hebûn. Di dawiyê de, em her tiştî li ser rêzê danîn. Ne mimkûn bû ku bişewite. Dilsozî û nêzîkatiya hevkariyê dîsa berdêl da.
Di encama pîlotê de, çend encam û encamên teknîkî yên girîng hatin bidestxistin:
Me fonksiyona nû ya ji bo hilberandina hişyariyan ceriband
Pergala hatî danîn dest pê kir ku ji Prometheus hişyariyan rast werbigire û wan kom bike. Hişyariyên li ser pirsgirêkê ji muwekîlê Prometheus her 30 saniyeyan carekê difiriyan (komkirina li gorî demê ne çalak e), û me meraq dikir gelo ew ê mimkun be ku wan di "sîwanê" bixwe de kom bikin. Derket holê ku ew mimkun e - sazkirina pêvajokirina hişyariyan di platformê de ji hêla skrîptê ve tête bicîh kirin. Ev dihêle ku hema hema her mantiqek ji bo pêvajoykirina wan were bicîh kirin. Me berê jî mantiqa standard di platformê de di forma şablonan de bicîh kiriye - heke hûn nexwazin tiştek ji xwe re derxînin, hûn dikarin yekek amade bikar bînin.
Navbera "teşkîlata sentetîk". Sazkirina pêvajoykirina hişyariyan ji pergalên çavdêriyê yên girêdayî
Rewşa "tenduristî" ya pergalê ava kir
Li ser bingeha hişyariyan, bûyerên çavdêriyê hatin afirandin ku bandor li tenduristiya yekîneyên veavakirinê (CU) kir. Em modelek karûbarê çavkaniyê (RSM) bicîh dikin, ku dikare CMDB-ya hundurîn bikar bîne an jî ya derveyî ve girêbide - di dema projeya pilot de xerîdar CMDB-ya xwe girê neda.
Navbera ji bo xebitandina modela çavkaniyê-xizmetê. Pîlot RSM.
Welê, bi rastî, xerîdar di dawiyê de xwedan ekranek çavdêriyek yekane ye, ku bûyerên ji pergalên cihêreng têne xuyang kirin. Heya nuha, du pergal bi "sîwanê" ve girêdayî ne - Zabbix û Prometheus, û pergalek çavdêriya navxweyî ya platformê bixwe.
Navrûya Analytics. Ekrana çavdêriya yekane.
Otomasyona pêvajoyê dest pê kir
Bûyerên şopandinê dest bi destpêkirina çalakiyên pêş-mîhengkirî kir - şandina hişyariyan, xebitandina nivîsan, tomarkirin / dewlemendkirina bûyeran - ya paşîn bi vê xerîdar re nehat ceribandin, ji ber ku di projeya pîlotê de entegrasyonek bi maseya xizmetê re tune bû.
Navbera mîhengên çalakiyê. Hişyariyan ji Slack re bişînin û serverê ji nû ve bidin destpêkirin.
Karbidestiya hilberê berfirehkirî
Dema ku li ser nivîsarên otomasyonê nîqaş kirin, xerîdar piştgirîya bash û navgînek ku tê de ev nivîsar bi hêsanî werin mîheng kirin xwest. Guhertoya nû piçekî bêtir kiriye (qabiliyeta nivîsandina avahîyên mentiqî yên bêkêmasî li Lua bi piştgirîya cURL, SSH û SNMP) û fonksiyonek bicîh kiriye ku dihêle hûn çerxa jiyanê ya nivîsarekê birêve bibin (afirandin, biguherîne, kontrolkirina guhertoyê , jêbirin û arşîv kirin).
Navbera ji bo xebata bi nivîsarên otohealing. Skrîpta nûvekirina serverê bi SSH.
Lêgerînên Key
Di dema pîlotê de, çîrokên bikarhêner jî hatin afirandin ku fonksiyona heyî çêtir dike û nirxê ji bo xerîdar zêde dike, li vir çend ji wan hene:
- pêkanîna kapasîteya şandina guhêrbaran rasterast ji hişyariyê berbi skrîpta otohealing;
- bi navgîniya Active Directory destûrnameyê li platformê zêde bikin.
Û me bêtir kêşeyên gerdûnî wergirtin - ji bo "avakirina" hilberê bi kapasîteyên din:
- avakirina otomatîkî ya modelek karûbarê çavkaniyê ya ku li ser bingeha ML-yê ye, ne ji rêgez û nûneran (dibe ku naha pirsgirêka sereke);
- piştgirî ji bo zimanên nivîsandinê û mantiqê yên din (û ev ê JavaScript be).
Di raya min de herî girîngYa ku ev pîlot nîşan dide du tişt in:
- Hevkariya bi xerîdar re mifteya bandorkeriyê ye, dema ku pêwendiya bi bandor li ser bingeha rastgoyî û vekirî tête çêkirin, û xerîdar dibe beşek ji tîmek ku di demek kurt de encamên girîng bi dest dixe.
- Di bin ti şert û mercan de ne hewce ye ku meriv "xweserî" û avakirina "kûçikan" - tenê çareseriyên pergalê. Çêtir e ku meriv hinekî bêtir wext derbas bike, lê çareseriyek pergalê ku dê ji hêla xerîdarên din ve were bikar anîn çêbikin. Bi awayê, tiştê ku qewimî ev e, pergala pêvekê û rakirina girêdayîbûna bi Azure re nirxek zêde ji xerîdarên din re peyda kir (silav, Qanûna Federal 152).
Source: www.habr.com