Ing publikasi ing HabrΓ©, aku wis nulis babagan pengalaman mbangun kemitraan karo timku ( ngomong babagan carane nggawe perjanjian kemitraan nalika miwiti bisnis anyar supaya bisnis ora ambruk). Lan saiki aku arep ngomong babagan carane mbangun kemitraan karo klien, amarga tanpa wong-wong mau ora bakal ana sing bakal rusak. Muga-muga artikel iki migunani kanggo para pemula sing wiwit adol produke menyang bisnis gedhe.
Saiki aku mimpin wiwitan sing diarani lab MONQ Digital, ing ngendi aku lan tim ngembangake produk kanggo ngotomatisasi proses ndhukung lan ngoperasikake IT perusahaan. Mlebet pasar dudu tugas sing gampang lan kita miwiti kanthi peer cilik, ngliwati pakar pasar, mitra lan nindakake segmentasi pasar. Pitakonan utama yaiku ngerti "sakit sapa sing bisa kita waras?"
Bank-bank mlebu ing TOP 3 segmen. Lan mesthi, sing pisanan ing dhaptar yaiku Tinkoff lan Sberbank. Nalika kita ngunjungi ahli pasar perbankan, dheweke kandha: ngenalake produk sampeyan ing kana, lan dalan menyang pasar perbankan bakal mbukak. Kita nyoba mlebu ing kana lan ing kana, nanging kegagalan nunggu kita ing Sberbank, lan wong lanang saka Tinkoff dadi luwih mbukak kanggo komunikasi produktif karo startup Rusia (bisa uga amarga kasunyatane Sber ing wektu kasebut. meh milyar saingan Barat kita). Ing sasi kita miwiti proyek pilot. Carane kedaden, maca ing.
Kita wis ngatasi masalah operasi lan ngawasi nganti pirang-pirang taun, saiki kita ngetrapake produk ing sektor publik, ing asuransi, ing bank, ing perusahaan telekomunikasi, siji implementasine karo maskapai (sadurunge proyek kasebut, kita malah ora nindakake. mikir yen penerbangan minangka industri sing gumantung karo IT, lan saiki kita ngarep-arep, sanajan ana COVID, perusahaan kasebut bakal muncul lan mateni).
Produk sing digawe kalebu piranti lunak perusahaan, segmen AIOps (Artificial Intelligence for IT Operations, utawa ITOps). Tujuan utama kanggo ngetrapake sistem kasebut minangka tingkat kadewasan proses ing perusahaan mundhak:
- Pateni kobongan: ngenali kegagalan, mbusak stream tandha saka lebu, nemtokake tugas lan kedadeyan kanggo sing tanggung jawab;
- Nambah efisiensi layanan IT: nyuda wektu kanggo ngrampungake kedadeyan, nuduhake panyebab kegagalan, nambah transparansi status IT;
- Nambah efisiensi bisnis: nyuda jumlah tenaga kerja manual, nyuda risiko, nambah kesetiaan pelanggan.
Ing pengalaman kita, bank-bank duwe "nyeri" ing ngisor iki kanthi pemantauan sing padha karo kabeh infrastruktur IT sing gedhe:
- "sing ngerti apa": ana akeh departemen teknis, meh saben wong duwe paling ora siji sistem ngawasi, lan paling akeh duwe luwih saka siji;
- "Gerombolan nyamuk" tandha: saben sistem ngasilake atusan lan ngebom kabeh sing tanggung jawab karo dheweke (kadhangkala uga antarane departemen). Iku angel kanggo terus-terusan njaga fokus kontrol ing saben kabar, urgency lan pentinge wis leveled amarga nomer akeh;
- bank-bank gedhe - pimpinan sektor pengin ora mung kanggo terus-terusan ngawasi sistem sing, ngerti ngendi ana gagal, nanging uga Piandel nyata AI - kanggo nggawe sistem poto-monitor, poto-prediksi lan poto-bener.
Nalika kita teka ing patemon pisanan ing Tinkoff, kita langsung dikandhani manawa ora ana masalah karo pemantauan lan ora ana sing lara, lan pitakonan utama yaiku: "Apa sing bisa ditawakake kanggo wong-wong sing wis apik?"
Obrolan kasebut dawa, kita ngrembug babagan carane microservices dibangun, cara kerja departemen, masalah infrastruktur sing luwih sensitif, sing kurang sensitif kanggo pangguna, ing ngendi "titik wuta", lan apa tujuane lan SLA.
Miturut cara, SLA bank pancen nyengsemaken. Contone, insiden kasedhiyan jaringan prioritas XNUMX mung butuh sawetara menit kanggo ngrampungake. Biaya kesalahan lan downtime kene, mesthi, nyengsemaken.
AkibatΓ©, kita nemtokake sawetara wilayah kerjasama:
- tataran kapisan punika payung ngawasi kanggo nambah kacepetan rΓ©solusi kedadean
- tataran kapindho iku automation proses kanggo nyuda resiko lan nyuda biaya kanggo njongko departemen IT.
Sawetara "titik putih" bisa dicet ing werna padhang tandha mung kanthi ngolah informasi saka sawetara sistem pemantauan, amarga ora bisa langsung njupuk metrik; uga perlu kanggo sentralisasi data saka sistem pemantauan sing beda menyang "siji layar" supaya kanggo mangerteni gambaran sakabehe kedadeyan. "Payung" cocok kanggo tugas iki lan kita ketemu syarat iki banjur.
Bab sing penting banget, miturut pendapat kita, ing hubungan karo klien yaiku kejujuran. Sawise pacelathon pisanan lan pitungan biaya lisensi kasebut, amarga regane murah banget, bisa uga kudu tuku lisensi langsung (dibandhingake karo Dynatrace Klyuch-Astrom saka artikel ing ndhuwur babagan bank ijo, kita biaya lisensi ora katelu saka milyar, nanging 12 ewu rubles saben sasi kanggo 1 gigabyte, kanggo Sber bakal biaya kaping pirang-pirang luwih murah). Nanging kita langsung ngandhani apa sing kita duwe lan apa sing ora. Mbok wakil sales saka integrator gedhe bisa ngomong "ya, kita bisa nindakake kabeh, mesthi tuku lisensi kita,"Nanging kita mutusakΓ© kanggo lay kabeh kertu ing meja. Nalika diluncurake, kothak kita ora duwe integrasi karo Prometheus, lan versi anyar kanthi subsistem otomatis bakal diluncurake, nanging durung dikirim menyang pelanggan.
Proyek pilot diwiwiti, watese ditemtokake lan kita diwenehi 2 sasi. Tugas utama yaiku:
- nyiyapake versi anyar saka platform lan masang ing infrastruktur bank
- nyambungake 2 sistem ngawasi (Zabbix lan Prometheus);
- ngirim kabar menyang sing tanggung jawab ing Slack lan liwat SMS;
- mbukak skrip autohealing.
Sasi kapisan proyek percontohan ditindakake kanggo nyiapake versi anyar saka platform ing mode super-cepet kanggo kabutuhan proyek pilot. Versi anyar langsung kalebu integrasi karo Prometheus lan marasake awakmu otomatis. Thanks kanggo tim pangembangan kita, dheweke ora turu pirang-pirang bengi, nanging ngeculake apa sing dijanjekake tanpa ngilangi tenggat wektu kanggo komitmen liyane sing wis digawe sadurunge.
Nalika kita nyiyapake pilot, kita nemoni masalah anyar sing bisa nutup proyek luwih dhisik tinimbang jadwal: kanggo ngirim tandha menyang utusan cepet lan liwat SMS, kita butuh sambungan mlebu lan metu menyang server Microsoft Azure (ing wektu iku kita nggunakake platform iki. kanggo ngirim tandha menyang Slack) lan SMS layanan ngirim eksternal. Nanging ing proyek iki, safety minangka fokus khusus. Sesuai karo kabijakan bank kasebut, "bolongan" kasebut ora bisa dibukak ing kahanan apa wae. Kabeh kudu bisa saka loop tertutup. Kita ditawakake nggunakake API saka layanan internal dhewe sing ngirim tandha menyang Slack lan liwat SMS, nanging kita ora duwe kesempatan kanggo nyambungake layanan kasebut metu saka kothak.
Debat sore karo tim pangembangan dipungkasi kanthi sukses golek solusi. Sawise nggoleki backlog, kita nemokake siji tugas sing ora nate cukup wektu lan prioritas - nggawe sistem plug-in supaya tim implementasi utawa klien bisa nulis tambahan dhewe, ngembangake kemampuan platform kasebut.
Nanging kita duwe persis sewulan, sajrone kita kudu nginstal kabeh, ngatur lan masang otomatisasi.
Miturut Sergei, pangareping arsitek kita, butuh paling sethithik sasi kanggo ngleksanakake sistem plug-in.
Kita ora duwe wektu ...
Mung ana siji solusi - pindhah menyang klien lan ngomong kabeh sing ana. Ngrembug babagan shift deadline bebarengan. Lan makarya. Kita diwenehi tambahan 2 minggu. Dheweke uga duwe tenggat wektu lan kewajiban internal kanggo nuduhake asil, nanging duwe 2 minggu cadangan. Ing pungkasan, kita sijine kabeh ing baris. Ora mungkin ngrusak. Kejujuran lan pendekatan kemitraan maneh dibayar.
Minangka asil saka pilot, sawetara asil teknis penting lan kesimpulan dijupuk:
Kita nyoba fungsi anyar kanggo ngolah tandha
Sistem sing disebarake wiwit nampa tandha kanthi bener saka Prometheus lan nglumpukake. Tandha ing masalah saka klien Prometheus mabur saben 30 detik (nglompokakΓ© miturut wektu ora aktif), lan kita kepingin weruh yen iku bisa kanggo klompok ing "payung" dhewe. Ternyata bisa - nyetel pangolahan tandha ing platform ditindakake kanthi skrip. Iki ndadekake iku bisa kanggo ngleksanakake meh kabeh logika kanggo proses mau. Kita wis ngetrapake logika standar ing platform ing bentuk template - yen sampeyan ora pengin nggawe apa-apa, sampeyan bisa nggunakake sing wis siap.
Antarmuka "pemicu sintetis". Nyetel pangolahan tandha saka sistem pemantauan sing disambungake
Dibangun negara "kesehatan" sistem
Adhedhasar tandha, acara pemantauan digawe sing mengaruhi kesehatan unit konfigurasi (CU). Kita ngetrapake model layanan sumber daya (RSM), sing bisa nggunakake CMDB internal utawa nyambungake eksternal - sajrone proyek pilot klien ora nyambungake CMDB dhewe.
Antarmuka kanggo nggarap model layanan sumber daya. Pilot RSM.
Inggih, nyatane, klien pungkasane duwe layar ngawasi siji, ing ngendi acara saka macem-macem sistem katon. Saiki, rong sistem disambungake menyang "payung" - Zabbix lan Prometheus, lan sistem pemantauan internal platform kasebut dhewe.
Antarmuka Analytics. Layar monitor tunggal.
Dibukak proses otomatisasi
Acara ngawasi nyebabake peluncuran tumindak sing wis dikonfigurasi - ngirim tandha, skrip sing mlaku, ndhaptar / nambah insiden - sing terakhir ora dicoba karo klien tartamtu iki, amarga ing proyek pilot ora ana integrasi karo meja layanan.
Antarmuka setelan tumindak. Kirimi tandha menyang Slack lan urip maneh server.
Fungsi produk sing ditambahi
Nalika ngrembug skrip otomatisasi, klien njaluk dhukungan bash lan antarmuka sing skrip kasebut bisa dikonfigurasi kanthi gampang. Versi anyar wis rampung luwih sithik (kemampuan kanggo nulis konstruksi logis lengkap ing Lua kanthi dhukungan kanggo cURL, SSH lan SNMP) lan fungsionalitas sing diimplementasikake sing ngidini sampeyan ngatur siklus urip skrip (nggawe, ngowahi, kontrol versi. , mbusak lan arsip).
Antarmuka kanggo nggarap skrip autohealing. Skrip urip maneh server liwat SSH.
Penemuan Kunci
Sajrone pilot, crita pangguna uga digawe sing nambah fungsi saiki lan nambah nilai kanggo klien, ing ngisor iki sawetara:
- ngleksanakake kemampuan kanggo nerusake variabel langsung saka tandha menyang skrip autohealing;
- nambah wewenang kanggo platform liwat Active Directory.
Lan kita nampa luwih akeh tantangan global - kanggo "mbangun" produk kanthi kapabilitas liyane:
- construction otomatis model sumber-layanan adhedhasar ML, tinimbang aturan lan agen (mbokmenawa tantangan utama saiki);
- dhukungan kanggo basa skrip lan logika tambahan (lan iki bakal dadi JavaScript).
Ing pendapatku sing paling pentingApa sing dituduhake pilot iki ana rong perkara:
- Kemitraan karo klien minangka kunci efektifitas, nalika komunikasi efektif dibangun kanthi dhasar kejujuran lan keterbukaan, lan klien dadi bagian saka tim sing entuk asil sing signifikan ing wektu sing cendhak.
- Ing kahanan apa wae, ora perlu "ngatur" lan mbangun "kruk" - mung solusi sistem. Iku luwih apik kanggo nglampahi wektu sethitik liyane, nanging nggawe solusi sistem sing bakal digunakake dening klien liyane. Miturut cara, iki kedadeyan, sistem plugin lan penghapusan katergantungan ing Azure nyedhiyakake nilai tambahan kanggo klien liyane (halo, Hukum Federal 152).
Source: www.habr.com