Dalam penerbitan di HabrΓ©, saya sudah menulis tentang pengalaman saya membina perkongsian dengan pasukan saya ( bercakap tentang cara merangka perjanjian perkongsian apabila memulakan perniagaan baru supaya perniagaan tidak runtuh). Dan sekarang saya ingin bercakap tentang cara membina perkongsian dengan pelanggan, kerana tanpa mereka tidak akan ada yang berantakan. Saya harap artikel ini berguna kepada pemula yang mula menjual produk mereka kepada perniagaan besar.
Saya kini mengetuai permulaan yang dipanggil makmal Digital MONQ, di mana saya dan pasukan saya sedang membangunkan produk untuk mengautomasikan proses menyokong dan mengendalikan IT korporat. Memasuki pasaran bukanlah satu tugas yang mudah dan kami bermula dengan sedikit kerja rumah, melalui pakar pasaran, rakan kongsi kami dan menjalankan segmentasi pasaran. Persoalan utama adalah untuk memahami "sakit siapakah yang boleh kita sembuhkan dengan sebaiknya?"
Bank berjaya masuk ke dalam 3 segmen TOP. Dan sudah tentu, yang pertama dalam senarai ialah Tinkoff dan Sberbank. Apabila kami melawat pakar pasaran perbankan, mereka berkata: perkenalkan produk anda di sana, dan laluan ke pasaran perbankan akan terbuka. Kami cuba masuk ke sana dan ke sana, tetapi kegagalan menanti kami di Sberbank, dan lelaki dari Tinkoff ternyata lebih terbuka kepada komunikasi yang produktif dengan syarikat pemula Rusia (mungkin disebabkan oleh fakta bahawa Sber pada masa itu hampir satu bilion pesaing Barat kita). Dalam masa sebulan kami memulakan projek perintis. Bagaimana ia berlaku, baca terus.
Kami telah menangani isu operasi dan pemantauan selama bertahun-tahun, kini kami melaksanakan produk kami di sektor awam, dalam insurans, di bank, di syarikat telekomunikasi, satu pelaksanaan adalah dengan syarikat penerbangan (sebelum projek, kami tidak berpendapat bahawa penerbangan adalah industri yang bergantung kepada IT, dan Sekarang kami sangat berharap, walaupun COVID, syarikat itu akan muncul dan berlepas).
Produk yang kami buat adalah milik perisian perusahaan, segmen AIOps (Kecerdasan Buatan untuk Operasi IT, atau ITOps). Matlamat utama melaksanakan sistem seperti tahap kematangan proses dalam syarikat meningkat:
- Padamkan kebakaran: kenal pasti kegagalan, bersihkan aliran amaran daripada serpihan, serahkan tugas dan insiden kepada mereka yang bertanggungjawab;
- Meningkatkan kecekapan perkhidmatan IT: mengurangkan masa untuk menyelesaikan insiden, menunjukkan punca kegagalan, meningkatkan ketelusan status IT;
- Meningkatkan kecekapan perniagaan: mengurangkan jumlah buruh manual, mengurangkan risiko, meningkatkan kesetiaan pelanggan.
Mengikut pengalaman kami, bank mengalami "sakit" berikut dengan pemantauan yang sama dengan semua infrastruktur IT yang besar:
- "siapa tahu apa": terdapat banyak jabatan teknikal, hampir semua orang mempunyai sekurang-kurangnya satu sistem pemantauan, dan kebanyakannya mempunyai lebih daripada satu;
- "kawanan nyamuk" amaran: setiap sistem menjana ratusan dan mengebom semua pihak yang bertanggungjawab dengannya (kadang-kadang juga antara jabatan). Sukar untuk sentiasa mengekalkan fokus kawalan pada setiap pemberitahuan yang mendesak dan kepentingannya disamakan kerana jumlah yang besar;
- bank besar - pemimpin sektor mahu bukan sahaja memantau sistem mereka secara berterusan, untuk mengetahui di mana terdapat kegagalan, tetapi juga keajaiban sebenar AI - untuk menjadikan sistem memantau sendiri, meramalkan sendiri dan membetulkan diri.
Apabila kami datang ke mesyuarat pertama di Tinkoff, kami segera diberitahu bahawa mereka tidak mempunyai masalah dengan pemantauan dan tiada apa-apa yang mencederakan mereka, dan soalan utama ialah: "Apa yang boleh kami tawarkan untuk mereka yang sudah melakukannya dengan baik?"
Perbualan itu panjang, kami membincangkan cara perkhidmatan mikro mereka dibina, cara jabatan berfungsi, masalah infrastruktur mana yang lebih sensitif, yang kurang sensitif untuk pengguna, di manakah "titik buta", dan apakah matlamat dan SLA mereka.
Dengan cara ini, SLA bank sangat mengagumkan. Contohnya, insiden ketersediaan rangkaian keutamaan 1 mungkin hanya mengambil masa beberapa minit untuk diselesaikan. Kos kesilapan dan masa henti di sini, sudah tentu, mengagumkan.
Hasilnya, kami mengenal pasti beberapa bidang kerjasama:
- peringkat pertama ialah pemantauan payung untuk meningkatkan kelajuan penyelesaian insiden
- peringkat kedua ialah automasi proses untuk mengurangkan risiko dan mengurangkan kos untuk skala jabatan IT.
Beberapa "bintik putih" boleh dicat dalam warna terang isyarat hanya dengan memproses maklumat daripada beberapa sistem pemantauan, kerana adalah mustahil untuk mengambil metrik secara langsung juga perlu untuk memusatkan data daripada sistem pemantauan yang berbeza ke "satu skrin" mengikut urutan untuk memahami gambaran keseluruhan tentang apa yang berlaku. "Payung" sesuai untuk tugas ini dan kami memenuhi keperluan ini kemudian.
Perkara yang sangat penting, pada pendapat kami, dalam hubungan dengan pelanggan adalah kejujuran. Selepas perbualan pertama dan pengiraan kos lesen, dikatakan bahawa memandangkan kosnya sangat rendah, ia mungkin berbaloi untuk membeli lesen dengan segera (berbanding dengan Dynatrace Klyuch-Astrom dari artikel di atas tentang bank hijau, kami kos lesen bukan satu pertiga daripada satu bilion, tetapi 12 ribu rubel sebulan untuk 1 gigabait, untuk Sber kosnya beberapa kali lebih murah). Tetapi kami segera memberitahu mereka apa yang kami ada dan apa yang tidak kami miliki. Mungkin wakil jualan daripada penyepadu besar boleh berkata "ya, kami boleh melakukan segala-galanya, sudah tentu membeli lesen kami," tetapi kami memutuskan untuk meletakkan semua kad kami di atas meja. Pada masa pelancaran, kotak kami tidak mempunyai penyepaduan dengan Prometheus, dan versi baharu dengan subsistem automasi akan dikeluarkan, tetapi kami masih belum menghantarnya kepada pelanggan.
Projek perintis bermula, sempadannya ditentukan dan kami diberi masa 2 bulan. Tugas utama adalah:
- sediakan versi baharu platform dan gunakannya dalam infrastruktur bank
- menyambung 2 sistem pemantauan (Zabbix dan Prometheus);
- menghantar pemberitahuan kepada mereka yang bertanggungjawab dalam Slack dan melalui SMS;
- jalankan skrip autohealing.
Bulan pertama projek perintis telah dibelanjakan untuk menyediakan versi baharu platform dalam mod sangat pantas untuk keperluan projek perintis. Versi baharu serta-merta termasuk penyepaduan dengan Prometheus dan penyembuhan automatik. Terima kasih kepada pasukan pembangunan kami, mereka tidak tidur selama beberapa malam, tetapi melepaskan apa yang mereka janjikan tanpa terlepas tarikh akhir untuk komitmen lain yang dibuat sebelum ini.
Semasa kami menyediakan juruterbang, kami menghadapi masalah baharu yang boleh menutup projek lebih awal daripada jadual: untuk menghantar makluman kepada pemesej segera dan melalui SMS, kami memerlukan sambungan masuk dan keluar ke pelayan Microsoft Azure (pada masa itu kami menggunakan platform ini untuk menghantar makluman kepada Slack) dan SMS perkhidmatan penghantaran luaran. Tetapi dalam projek ini, keselamatan menjadi tumpuan khusus. Selaras dengan polisi bank, "lubang" sedemikian tidak boleh dibuka dalam apa jua keadaan. Segala-galanya terpaksa bekerja dari gelung tertutup. Kami ditawarkan untuk menggunakan API perkhidmatan dalaman kami sendiri yang menghantar makluman kepada Slack dan melalui SMS, tetapi kami tidak berpeluang untuk menyambungkan perkhidmatan sedemikian di luar kotak.
Satu malam perdebatan dengan pasukan pembangunan berakhir dengan pencarian penyelesaian yang berjaya. Setelah menyelongkar tunggakan, kami menemui satu tugas yang kami tidak pernah mempunyai masa dan keutamaan yang mencukupi - untuk mencipta sistem pemalam supaya pasukan pelaksana atau pelanggan boleh menulis alat tambah sendiri, mengembangkan keupayaan platform.
Tetapi kami mempunyai masa sebulan lagi, di mana kami perlu memasang segala-galanya, mengkonfigurasi dan menggunakan automasi.
Menurut Sergei, ketua arkitek kami, ia mengambil masa sekurang-kurangnya sebulan untuk melaksanakan sistem plug-in.
Kami tidak sempat...
Terdapat hanya satu penyelesaian - pergi ke pelanggan dan beritahu semuanya sebagaimana adanya. Bincangkan anjakan tarikh akhir bersama-sama. Dan ia berjaya. Kami diberi tambahan 2 minggu. Mereka juga mempunyai tarikh akhir dan kewajipan dalaman mereka sendiri untuk menunjukkan keputusan, tetapi mereka mempunyai 2 minggu simpanan. Pada akhirnya, kami meletakkan segala-galanya dalam talian. Ia adalah mustahil untuk mengacaukan. Kejujuran dan pendekatan perkongsian kembali membuahkan hasil.
Hasil daripada perintis, beberapa keputusan teknikal penting dan kesimpulan diperoleh:
Kami menguji fungsi baharu untuk memproses makluman
Sistem yang digunakan mula menerima makluman dengan betul daripada Prometheus dan mengumpulkannya. Makluman tentang masalah daripada pelanggan Prometheus terbang setiap 30 saat (penghimpunan mengikut masa tidak didayakan), dan kami tertanya-tanya sama ada mungkin untuk mengumpulkannya dalam "payung" itu sendiri. Ternyata mungkin - menyediakan pemprosesan amaran dalam platform dilaksanakan oleh skrip. Ini memungkinkan untuk melaksanakan hampir semua logik untuk memprosesnya. Kami telah pun melaksanakan logik standard dalam platform dalam bentuk templat - jika anda tidak mahu menghasilkan sesuatu sendiri, anda boleh menggunakan yang sudah siap.
Antara muka "pencetus sintetik". Menyediakan pemprosesan makluman daripada sistem pemantauan yang disambungkan
Membina keadaan "kesihatan" sistem
Berdasarkan makluman, peristiwa pemantauan telah dibuat yang menjejaskan kesihatan unit konfigurasi (CU). Kami sedang melaksanakan model perkhidmatan sumber (RSM), yang boleh menggunakan sama ada CMDB dalaman atau menyambungkan model luaran - semasa projek perintis pelanggan tidak menyambungkan CMDBnya sendiri.
Antara muka untuk bekerja dengan model perkhidmatan sumber. Juruterbang RSM.
Sebenarnya, pelanggan akhirnya mempunyai skrin pemantauan tunggal, di mana peristiwa dari sistem yang berbeza dapat dilihat. Pada masa ini, dua sistem disambungkan kepada "payung" - Zabbix dan Prometheus, dan sistem pemantauan dalaman platform itu sendiri.
Antara muka analitis. Skrin pemantauan tunggal.
Automasi proses dilancarkan
Pemantauan peristiwa mencetuskan pelancaran tindakan prakonfigurasi - menghantar makluman, menjalankan skrip, mendaftar/memperkayakan insiden - yang terakhir tidak dicuba dengan pelanggan tertentu ini, kerana dalam projek perintis tiada integrasi dengan meja perkhidmatan.
Antara muka tetapan tindakan. Hantar makluman kepada Slack dan but semula pelayan.
Fungsi produk diperluaskan
Apabila membincangkan skrip automasi, pelanggan meminta sokongan bash dan antara muka di mana skrip ini boleh dikonfigurasikan dengan mudah. Versi baharu telah melakukan lebih sedikit lagi (keupayaan untuk menulis binaan logik sepenuhnya dalam Lua dengan sokongan untuk cURL, SSH dan SNMP) dan melaksanakan fungsi yang membolehkan anda mengurus kitaran hayat skrip (buat, edit, kawalan versi , padam dan arkib).
Antara muka untuk bekerja dengan skrip autohealing. Skrip but semula pelayan melalui SSH.
Penemuan Utama
Semasa perintis, cerita pengguna juga dicipta yang meningkatkan fungsi semasa dan meningkatkan nilai untuk pelanggan, berikut adalah beberapa daripadanya:
- melaksanakan keupayaan untuk memajukan pembolehubah terus daripada amaran kepada skrip autohealing;
- tambah kebenaran pada platform melalui Active Directory.
Dan kami menerima lebih banyak cabaran global - untuk "membina" produk dengan keupayaan lain:
- pembinaan automatik model perkhidmatan sumber berdasarkan ML, bukannya peraturan dan ejen (mungkin cabaran utama sekarang);
- sokongan untuk bahasa skrip dan logik tambahan (dan ini akan menjadi JavaScript).
Pada pendapat saya perkara yang paling pentingApa yang ditunjukkan oleh juruterbang ini ialah dua perkara:
- Perkongsian dengan pelanggan adalah kunci kepada keberkesanan, apabila komunikasi yang berkesan dibina atas dasar kejujuran dan keterbukaan, dan pelanggan menjadi sebahagian daripada pasukan yang mencapai keputusan yang ketara dalam masa yang singkat.
- Dalam apa jua keadaan tidak perlu untuk "menyesuaikan" dan membina "tongkat" - hanya penyelesaian sistem. Lebih baik luangkan sedikit masa lagi, tetapi buat penyelesaian sistem yang akan digunakan oleh pelanggan lain. By the way, inilah yang berlaku, sistem pemalam dan penghapusan pergantungan pada Azure memberikan nilai tambahan kepada pelanggan lain (hello, Undang-undang Persekutuan 152).
Sumber: www.habr.com