Hai, nama saya Vera Sivakova. Saya bekerja dengan mitra utama Yandex.Kassi - Saya menghubungkan toko dan layanan besar, meluncurkan proyek, dan melakukan perjalanan ke berbagai pertemuan di seluruh dunia. Secara umum, saya mengikuti bahwa semuanya baik-baik saja.
Setiap karyawan Yandex.Money dapat mengubah pekerjaan mereka setahun sekali - pilih departemen dan bekerja di sana selama beberapa hari. Karena itu, sebulan yang lalu, saya duduk di Sapsan dan tiba di St. Petersburg. Departemen pemantauan bekerja di sana, yang juga memantau bahwa 90.000 situs yang terhubung dengan kantor Kasir berjalan baik, dan kami memutuskan untuk bergabung.
Bagaimana tidak menjadi gila? Tidak persis sama (sumber: reddit.com)
Ini adalah kisah tentang cara kerja pemantauan kami, dan apa yang saya pelajari dalam beberapa hari di departemen lain.
Setiap detik, sekitar 600 transaksi melalui layanan dan semua ini perlu dipantau secara real time - tetapi pada waktu yang tepat apakah ini waktunya untuk membunyikan alarm jika terjadi sesuatu? Kita perlu melihat secara sistematis segala hal.
Merupakan praktik yang baik untuk menganalisis sistem dari sudut pandang teknis dan tidak melupakan metrik bisnis - jumlah pembayaran, omset, dan parameter lainnya.
Dalam sistem kecil, pandangan sekilas admin utama (paling sering satu-satunya) sudah cukup. Tetapi ketika ada banyak proses, karyawan tidak dapat memantau semuanya secara manual, sehingga otomatisasi maksimum akan menjadi strategi terbaik. Tidak ada yang akan berhasil tanpa sepengetahuan ahli dan upaya tim, karena pemantauan adalah perbaikan terus-menerus, analisis, dan kemampuan untuk memilih metrik dan pemicu yang kompeten. Mereka akan bekerja jika terjadi penyimpangan dari kondisi yang diberikan dan melaporkan anomali.
Kami membedakan tiga tingkat pemantauan, yang masing-masing memiliki indikator penting sendiri - tingkat sistem, tingkat logika bisnis, dan tingkat rekanan.
Tingkat sistem
Yang paling penting di sini adalah pemantauan infrastruktur sepanjang waktu. Dari alat yang kami gunakan Zabbix untuk mengumpulkan data secara real time - ia memberi tahu tentang operasi server dan pusat data, kualitas jaringan, ketersediaan komponen dan sumber data.
Memantau infrastruktur TI adalah pekerjaan yang sangat bertanggung jawab, karena kegagalan pada level ini penuh dengan ketidakmampuan sistem dan tindakan putus asa. Oleh karena itu, penting tidak hanya untuk menanggapi masalah "berkedip", tetapi juga untuk menganalisis tren dan data historis - ini akan memungkinkan peringatan tepat waktu dari titik-titik kegagalan potensial dan memprediksi kebutuhan untuk penskalaan. Aturan ini berfungsi untuk semua indikator dan tingkat pemantauan, termasuk bisnis.
Untuk titik kritis, ambang batas pemicu harus dipilih di bawah ini. Misalnya, jika waktu respons dari satu router meningkat, kami mentransfer lalu lintas ke router lain dan menghilangkan penyebabnya pada router pertama. Ini memicu pemicu peringatan, yang memungkinkan Anda untuk menerima pemberitahuan masalah potensial sangat dini, yang memberikan cadangan waktu untuk respons, kemampuan untuk memprediksi perubahan, dan menghindari bencana.
Tingkat logika bisnis
Setiap tim menentukan proses yang perlu dilacak, prioritas dan metrik pribadi mereka. Misalnya, tim Kasir memiliki lusinan proses bisnis, seperti pembayaran dengan setiap metode yang tersedia - kartu, dompet elektronik, melalui bank dan terminal online, perdagangan seluler, register pengiriman, dll. Sebagai alat utama untuk mengumpulkan dan menampilkan data pada karya logika bisnis, kami menggunakan Graphite bersama dengan Grafana.
Pada tingkat ini, penting untuk mematuhi pendekatan sistematis dan mencoba untuk menjauh dari "karya / tidak bekerja" biner dan tidak bekerja.
Misalnya, ada metrik "Jumlah pembayaran kartu yang berhasil". Jika mulai berkedip, itu berarti aliran pekerjaan telah menurun. Dalam hal ini, Anda perlu memahami apa sebenarnya alasannya, dan memperhitungkan semua komponen yang terlibat dalam proses ini. Dalam kasus penurunan jumlah transaksi, Anda dapat segera memikirkan fakta bahwa ada kesulitan di sisi bank yang mengakuisisi. Tetapi grafik menunjukkan bahwa dengan ketersediaan bank, semuanya baik-baik saja. Maka Anda perlu menyelidiki lebih lanjut, dan pada akhirnya ternyata, misalnya, bahwa semua pertanyaan ada di tata letak: untuk beberapa alasan, tombol "Bayar" telah hilang atau telah menjadi tidak aktif.
Level Counterparty
Di sini kita berbicara tentang rekanan tertentu - misalnya, mengakuisisi bank dan pedagang.
Kami telah memilih jadwal dan pemicu terpisah untuk pengakuisisi, ketersediaan yang harus kami lacak sepanjang waktu. Bagi kami, sebagai layanan pembayaran, stabilitas sangat penting, oleh karena itu, dalam hal kegagalan salah satu bank, kami segera mentransfer aliran ke cadangan.
Satu bank gagal, tetapi yang lain otomatis terhubung
Kami belajar untuk mengarahkan alur kerja dengan cukup baik dan tepat waktu jika kesalahan dimulai.
Salah satu bank mencatat peningkatan kesalahan pembayaran
Diterjemahkan - dan semuanya beres. Nilai sumbu Y tidak sepadan
Acquirer dapat gagal karena berbagai alasan di tingkat yang telah dijelaskan - sistem dan logika bisnis. Tidak ada yang kebal dari masalah yang tidak terduga dan tidak dapat menjamin ketersediaan 100%. Anda juga perlu mengingat tentang pekerjaan teknis dan rilis yang direncanakan, ketika Anda perlu memonitor dengan cermat kemajuan hubungan. Masalah redundansi dan pengalihan otomatis sangat penting, karena sederhana berarti menghentikan pembayaran untuk bisnis.
Kami bekerja dengan beberapa bank sekaligus untuk meminimalkan risiko downtime dan mengoptimalkan pembayaran kartu SR. SR (tingkat keberhasilan) atau konversi adalah metrik bisnis yang dihitung sebagai rasio dari jumlah pembayaran yang berhasil terhadap jumlah total transaksi. Perusahaan yang berbeda mengukur konversi dengan caranya sendiri: misalnya, seseorang mulai mengukur dari halaman pembayaran, yang lain setelah mengklik tombol "Bayar". Tetapi secara umum, SR dipengaruhi oleh banyak faktor berbeda - MCC, apakah ada 3D-Secure dalam pembayaran, geografi pembayar, pembayaran berulang atau tidak. SR "Rumah Sakit" tidak mungkin untuk ditentukan dan tidak perlu diketahui - dalam setiap kasus itu akan menjadi nilainya sendiri, yang harus dioptimalkan.
Seluruh variasi kesalahan dapat dibagi menjadi dua kelompok besar.
- Kesalahan yang dapat dicegah - misalnya, pembayaran dari negara ini dilarang. Jika Anda yakin ini bukan serangan penipuan dan Anda memiliki pengguna di seluruh dunia, maka dalam hal ini perlu menghubungkan kemungkinan pembayaran dari kartu dari penerbit mana pun. Omong-omong, ini dapat dilakukan di akun pribadi Yandex Cashier.
- Kesalahan yang tidak dapat dipengaruhi - misalnya, kartu terkunci. Di sini hanya penerbitan ulang atau upaya untuk mengulangi pembayaran dengan kartu lain sebagai bagian dari transaksi baru yang akan membantu.
Banyak yang memilih penyedia pembayaran sesuai tarif. Padahal, kurs bukan satu-satunya nilai yang harus diperhitungkan. Anda juga perlu melihat persentase pembayaran yang berhasil (SR) - karena tidak ada yang memiliki konversi 100% dan nilai ini sangat bervariasi dari bank ke bank. Penting juga untuk mempertimbangkan bagaimana skenario pengguna terlihat secara umum: berapa banyak langkah yang harus Anda lalui sebelum membayar, jika antarmuka jelas, dll.
Bagaimana Konversi Mempengaruhi Keuntungan
Dalam kasus kedua, komisi untuk layanan lebih tinggi, tetapi konversi juga lebih tinggi, karena reservasi dan konfigurasi gateway yang tepat digunakan.
Seperti yang Anda lihat dari contoh, solusi yang lebih baik untuk bisnis adalah dengan mengambil layanan yang lebih baik dan, meskipun faktanya komisi lebih tinggi karena perbedaan dalam kualitas akuisisi, pada akhirnya kami memiliki 3 538 080 - 2 847 000 = 691 080 perbedaan rubel per bulan! Dan ini 8 juta setahun, yang merupakan banyak uang untuk bisnis.
Konversi, pergantian, dan tarif sewenang-wenang, tetapi contoh menunjukkan bahwa hal utama dalam layanan adalah stabilitas dan kualitasnya. Dan ini sudah memerlukan konversi yang meningkat dan, sebagai hasilnya, omset yang lebih besar untuk pedagang.
Bagaimana pedagang terhubung
Seperti yang disebutkan sebelumnya, kami mencoba untuk menutupi semuanya dengan metrik dan pemicu yang secara otomatis mengaktifkan suatu peristiwa. Mari kita lihat bagaimana semuanya terjadi pada contoh pemantauan salah satu pedagang.
Setelah terhubung ke Kasir, pedagang, jika perlu, dimonitor. Kami membuat bagan di Grafana dan mengonfigurasikan metrik yang dengannya peringatan otomatis dipicu jika terjadi penyimpangan dari nilai "normal" yang diberikan.
Kami menggunakan Moira untuk mengirim pemberitahuan ke obrolan grup pemantau, yang akan segera memeriksa detailnya. Pemberitahuan berisi tautan ke jadwal dan detail kejadian.
Benar-benar contoh nyata dari pesan dari bot
Setelah menganalisis grafik, spesialis tim pemantauan paling sering menggunakan Kibana untuk melihat log. Di sini situasinya bisa sederhana, dan kemudian dalam log, jelas, kesalahan akan terlihat atau partisipasi tambahan dari analis akan diperlukan untuk menganalisis penyebab kegagalan.
Di masa mendatang, kami ingin menyiapkan pemberitahuan otomatis pedagang tentang kesalahan di pihak mereka, misalnya, tentang tidak dapat diaksesnya server atau tanggapan non-protokol. Ini akan memungkinkan Anda untuk dengan cepat merespons kegagalan dan memberikan informasi pihak lawan untuk menghilangkan penyebabnya.
Selain sisi teknis, kami juga memantau dengan cermat metrik bisnis seperti omset, pendapatan, dan arus keluar, tetapi ini tampaknya menjadi topik untuk kisah-kisah berikut.
Yang paling penting
"Hari ketidaktaatan" saya (yang kami sebut transisi sementara ke departemen lain) berakhir, dan saya kembali ke Moskow. Selama 2 hari di departemen pemantauan, saya belajar banyak dan menyederhanakan pengetahuan saat ini.
- Tugas pemantauan adalah memberikan informasi yang relevan tentang keadaan sistem di semua tingkatan;
- Pilih metrik dan pemicu yang kompeten - 90% sukses;
- Dalam layanan pembayaran, konversi hits tawaran;
- Anda perlu mengikuti teknik dan mengingat tentang metrik bisnis;
- Kita membutuhkan pandangan sistematis tentang proses dan kemampuan untuk menganalisis hubungan;
Namun - bersyukur. Pemantauan, terima kasih!
Itu saja. Ajukan pertanyaan, berlangganan blog kami dan datang berkunjung.