Dalam publikasi di Habré, saya sudah menulis tentang pengalaman saya membangun kemitraan dengan tim saya ( membahas tentang cara membuat perjanjian kemitraan pada saat memulai usaha baru agar usahanya tidak berantakan). Dan sekarang saya ingin berbicara tentang bagaimana membangun kemitraan dengan klien, karena tanpa mereka tidak akan ada yang berantakan. Saya harap artikel ini bermanfaat bagi para startup yang mulai menjual produknya ke bisnis besar.
Saat ini saya memimpin sebuah startup bernama MONQ Digital lab, di mana saya dan tim sedang mengembangkan produk untuk mengotomatisasi proses mendukung dan mengoperasikan TI perusahaan. Memasuki pasar bukanlah tugas yang mudah dan kami memulai dengan sedikit pekerjaan rumah, melalui pakar pasar, mitra kami dan melakukan segmentasi pasar. Pertanyaan utamanya adalah untuk memahami “rasa sakit siapa yang paling bisa kita sembuhkan?”
Bank berhasil masuk dalam TOP 3 segmen. Dan tentu saja, yang pertama dalam daftar adalah Tinkoff dan Bank Tabungan. Saat kami mengunjungi pakar pasar perbankan, mereka berkata: perkenalkan produk Anda di sana, dan jalan menuju pasar perbankan akan terbuka. Kami mencoba masuk ke sana dan ke sana, tetapi kegagalan menunggu kami di Sberbank, dan orang-orang dari Tinkoff ternyata jauh lebih terbuka untuk komunikasi produktif dengan startup Rusia (mungkin karena Sber pada saat itu hampir satu miliar pesaing kita di Barat). Dalam sebulan kami memulai proyek percontohan. Bagaimana hal itu terjadi, baca terus.
Kami telah menangani masalah operasi dan pemantauan selama bertahun-tahun, sekarang kami menerapkan produk kami di sektor publik, di asuransi, di bank, di perusahaan telekomunikasi, salah satu implementasinya adalah dengan maskapai penerbangan (sebelum proyek ini, kami bahkan tidak melakukannya). Saya pikir penerbangan adalah industri yang bergantung pada TI, dan sekarang kami sangat berharap, meskipun ada COVID, perusahaan ini akan bangkit dan lepas landas).
Produk yang kami buat termasuk dalam perangkat lunak perusahaan, segmen AIOps (Artificial Intelligence for IT Operations, atau ITOps). Tujuan utama penerapan sistem tersebut seiring dengan meningkatnya tingkat kematangan proses di perusahaan:
- Memadamkan api: mengidentifikasi kegagalan, membersihkan aliran peringatan dari puing-puing, menugaskan tugas dan insiden kepada mereka yang bertanggung jawab;
- Meningkatkan efisiensi layanan TI: mengurangi waktu penyelesaian insiden, menunjukkan penyebab kegagalan, meningkatkan transparansi status TI;
- Meningkatkan efisiensi bisnis: mengurangi jumlah tenaga kerja manual, mengurangi risiko, meningkatkan loyalitas pelanggan.
Berdasarkan pengalaman kami, bank memiliki “kesulitan” berikut dalam hal pemantauan yang umum terjadi pada semua infrastruktur TI besar:
- “entah apa”: terdapat banyak departemen teknis, hampir setiap orang memiliki setidaknya satu sistem pemantauan, dan sebagian besar memiliki lebih dari satu;
- peringatan “gerombolan nyamuk”: masing-masing sistem menghasilkan ratusan dan membombardir semua pihak yang bertanggung jawab terhadap sistem tersebut (terkadang juga antar departemen). Sulit untuk terus-menerus mempertahankan fokus pengendalian pada setiap notifikasi; urgensi dan pentingnya notifikasi tersebut menjadi sama karena banyaknya notifikasi;
- bank-bank besar - para pemimpin sektor tidak hanya ingin terus memantau sistem mereka, mengetahui di mana terdapat kegagalan, namun juga keajaiban AI yang sesungguhnya - membuat sistem dapat memantau, memprediksi, dan mengoreksi diri sendiri.
Ketika kami menghadiri pertemuan pertama di Tinkoff, kami langsung diberitahu bahwa mereka tidak memiliki masalah dengan pemantauan dan tidak ada yang merugikan mereka, dan pertanyaan utamanya adalah: “Apa yang bisa kami tawarkan kepada mereka yang sudah melakukannya dengan baik?”
Pembicaraannya panjang, kami membahas bagaimana layanan mikro mereka dibangun, bagaimana departemen bekerja, masalah infrastruktur mana yang lebih sensitif, mana yang kurang sensitif bagi pengguna, di mana “titik buta”, dan apa tujuan dan SLA mereka.
Omong-omong, SLA bank tersebut sangat mengesankan. Misalnya, insiden ketersediaan jaringan prioritas XNUMX mungkin hanya memerlukan waktu beberapa menit untuk diselesaikan. Kerugian akibat kesalahan dan downtime di sini, tentu saja, sangat mengesankan.
Hasilnya, kami mengidentifikasi beberapa bidang kerja sama:
- tahap pertama adalah pemantauan payung untuk meningkatkan kecepatan penyelesaian insiden
- tahap kedua adalah otomatisasi proses untuk mengurangi risiko dan mengurangi biaya penskalaan departemen TI.
Beberapa “titik putih” dapat dicat dengan warna peringatan yang cerah hanya dengan memproses informasi dari beberapa sistem pemantauan, karena tidak mungkin untuk mengambil metrik secara langsung; data dari sistem pemantauan yang berbeda juga perlu dipusatkan ke dalam “satu layar” secara berurutan. untuk memahami gambaran keseluruhan tentang apa yang terjadi. “Payung” cocok untuk tugas ini dan kami memenuhi persyaratan tersebut saat itu.
Hal yang sangat penting menurut kami dalam hubungan dengan klien adalah kejujuran. Setelah percakapan pertama dan penghitungan biaya lisensi, dikatakan bahwa karena biayanya sangat rendah, mungkin ada baiknya segera membeli lisensi (dibandingkan dengan Dynatrace Klyuch-Astrom dari artikel di atas tentang bank hijau, kami biaya lisensinya bukan sepertiga miliar, tetapi 12 ribu rubel per bulan untuk 1 gigabyte, untuk Sber biayanya beberapa kali lebih murah). Namun kami segera memberi tahu mereka apa yang kami miliki dan apa yang tidak kami miliki. Mungkin perwakilan penjualan dari integrator besar dapat mengatakan “ya, kami dapat melakukan segalanya, tentu saja membeli lisensi kami,” namun kami memutuskan untuk meletakkan semua kartu kami di atas meja. Pada saat peluncuran, kotak kami belum memiliki integrasi dengan Prometheus, dan versi baru dengan subsistem otomasi akan segera dirilis, namun kami belum mengirimkannya ke pelanggan.
Proyek percontohan dimulai, batas-batasnya ditentukan dan kami diberi waktu 2 bulan. Tugas utamanya adalah:
- menyiapkan versi baru platform dan menerapkannya di infrastruktur bank
- menghubungkan 2 sistem pemantauan (Zabbix dan Prometheus);
- mengirim pemberitahuan kepada mereka yang bertanggung jawab di Slack dan melalui SMS;
- menjalankan skrip penyembuhan otomatis.
Bulan pertama proyek percontohan dihabiskan untuk mempersiapkan versi baru platform dalam mode super cepat untuk kebutuhan proyek percontohan. Versi baru segera menyertakan integrasi dengan Prometheus dan penyembuhan otomatis. Berkat tim pengembangan kami, mereka tidak tidur selama beberapa malam, namun melepaskan apa yang mereka janjikan tanpa melewatkan tenggat waktu untuk komitmen lain yang telah dibuat sebelumnya.
Saat kami menyiapkan uji coba, kami menemui masalah baru yang dapat menutup proyek lebih cepat dari jadwal: untuk mengirim peringatan ke pesan instan dan melalui SMS, kami memerlukan koneksi masuk dan keluar ke server Microsoft Azure (saat itu kami menggunakan platform ini untuk mengirim peringatan ke Slack) dan layanan pengiriman SMS eksternal. Namun dalam proyek ini, keselamatan menjadi fokus utama. Sesuai dengan kebijakan bank, “lubang” tersebut tidak dapat dibuka dalam keadaan apapun. Semuanya harus bekerja dari loop tertutup. Kami ditawari untuk menggunakan API layanan internal kami sendiri yang mengirimkan peringatan ke Slack dan melalui SMS, tetapi kami tidak memiliki kesempatan untuk menghubungkan layanan tersebut secara langsung.
Debat malam dengan tim pengembangan berakhir dengan pencarian solusi yang berhasil. Setelah mengobrak-abrik backlog, kami menemukan satu tugas yang tidak pernah cukup waktu dan prioritasnya - membuat sistem plug-in sehingga tim implementasi atau klien dapat menulis add-on sendiri, sehingga memperluas kemampuan platform.
Namun kami memiliki waktu satu bulan lagi, di mana kami harus menginstal semuanya, mengonfigurasi, dan menerapkan otomatisasi.
Menurut Sergei, kepala arsitek kami, dibutuhkan setidaknya satu bulan untuk mengimplementasikan sistem plug-in.
Kami tidak punya waktu...
Hanya ada satu solusi - pergi ke klien dan ceritakan semuanya apa adanya. Diskusikan pergeseran tenggat waktu bersama-sama. Dan itu berhasil. Kami diberi tambahan waktu 2 minggu. Mereka juga memiliki tenggat waktu dan kewajiban internal mereka sendiri untuk menunjukkan hasil, namun mereka memiliki 2 minggu cadangan. Pada akhirnya, kami mempertaruhkan segalanya. Tidak mungkin untuk mengacau. Kejujuran dan pendekatan kemitraan kembali membuahkan hasil.
Sebagai hasil dari uji coba ini, diperoleh beberapa hasil dan kesimpulan teknis penting:
Kami menguji fungsionalitas baru untuk memproses peringatan
Sistem yang diterapkan mulai menerima peringatan dari Prometheus dengan benar dan mengelompokkannya. Peringatan tentang masalah dari klien Prometheus dikirimkan setiap 30 detik (pengelompokan berdasarkan waktu tidak diaktifkan), dan kami bertanya-tanya apakah mungkin untuk mengelompokkannya dalam “payung” itu sendiri. Ternyata itu mungkin - pengaturan pemrosesan peringatan di platform diimplementasikan oleh skrip. Hal ini memungkinkan penerapan hampir semua logika untuk memprosesnya. Kami telah menerapkan logika standar di platform dalam bentuk templat - jika Anda tidak ingin membuat sesuatu sendiri, Anda dapat menggunakan yang sudah jadi.
Antarmuka “pemicu sintetis”. Menyiapkan pemrosesan peringatan dari sistem pemantauan yang terhubung
Membangun keadaan “kesehatan” sistem
Berdasarkan peringatan, peristiwa pemantauan dibuat yang memengaruhi kesehatan unit konfigurasi (CU). Kami menerapkan model layanan sumber daya (RSM), yang dapat menggunakan CMDB internal atau menghubungkan CMDB eksternal - selama proyek percontohan, klien tidak menghubungkan CMDB-nya sendiri.
Antarmuka untuk bekerja dengan model layanan sumber daya. Percontohan RSM.
Faktanya, klien akhirnya memiliki satu layar pemantauan, di mana peristiwa dari sistem yang berbeda dapat dilihat. Saat ini, dua sistem terhubung ke "payung" - Zabbix dan Prometheus, dan sistem pemantauan internal dari platform itu sendiri.
Antarmuka analitik. Layar pemantauan tunggal.
Meluncurkan otomatisasi proses
Peristiwa pemantauan memicu peluncuran tindakan yang telah dikonfigurasi sebelumnya - mengirim peringatan, menjalankan skrip, mendaftarkan/memperkaya insiden - yang terakhir tidak dicoba dengan klien khusus ini, karena dalam proyek percontohan tidak ada integrasi dengan service desk.
Antarmuka pengaturan tindakan. Kirim peringatan ke Slack dan reboot server.
Fungsionalitas produk yang diperluas
Saat mendiskusikan skrip otomasi, klien meminta dukungan bash dan antarmuka di mana skrip ini dapat dikonfigurasi dengan mudah. Versi baru telah melakukan lebih banyak hal (kemampuan untuk menulis konstruksi logis lengkap di Lua dengan dukungan untuk cURL, SSH dan SNMP) dan mengimplementasikan fungsionalitas yang memungkinkan Anda untuk mengelola siklus hidup skrip (membuat, mengedit, kontrol versi , hapus dan arsipkan).
Antarmuka untuk bekerja dengan skrip penyembuhan otomatis. Skrip reboot server melalui SSH.
Temuan Kunci
Selama uji coba, cerita pengguna juga dibuat untuk meningkatkan fungsionalitas saat ini dan meningkatkan nilai bagi klien, berikut beberapa di antaranya:
- menerapkan kemampuan untuk meneruskan variabel langsung dari peringatan ke skrip penyembuhan otomatis;
- tambahkan otorisasi ke platform melalui Direktori Aktif.
Dan kami menerima lebih banyak tantangan global - untuk “membangun” produk dengan kemampuan lain:
- konstruksi otomatis model layanan sumber daya berdasarkan ML, bukan aturan dan agen (mungkin tantangan utama saat ini);
- dukungan untuk bahasa skrip dan logika tambahan (dan ini adalah JavaScript).
Menurut pendapat saya, hal yang paling pentingApa yang ditunjukkan oleh uji coba ini adalah dua hal:
- Kemitraan dengan klien adalah kunci efektivitas, ketika komunikasi efektif dibangun atas dasar kejujuran dan keterbukaan, dan klien menjadi bagian dari tim yang mencapai hasil signifikan dalam waktu singkat.
- Dalam situasi apa pun tidak perlu untuk "menyesuaikan" dan membangun "kruk" - hanya solusi sistem. Lebih baik meluangkan lebih banyak waktu, tetapi membuat solusi sistem yang akan digunakan oleh klien lain. Omong-omong, inilah yang terjadi, sistem plugin dan penghapusan ketergantungan pada Azure memberikan nilai tambah bagi klien lain (halo, Undang-undang Federal 152).
Sumber: www.habr.com