Tautan observability yang tidak terlalu rahasia ke pendapatan

Tautan observability yang tidak terlalu rahasia ke pendapatan

keyboard dolar

Di banyak perusahaan, observabilitas atau pemantauan adalah kata-kata yang hanya dipahami oleh kelompok teknis. Mungkin tim hukum terlibat karena ada SLA yang tidak boleh dilanggar oleh produk, atau akan merugikan perusahaan dalam bentuk penalti. Ini adalah cara yang salah untuk melihat observabilitas — ini bukan sekadar alat yang memverifikasi kinerja aplikasi Anda dengan benar dan memungkinkan Anda menghindari penalti. Alih-alih, anggap observabilitas sebagai lensa pembesar yang membantu semua tim di perusahaan Anda memahami cara meningkatkan pendapatan, dengan memahami kompleksitas produk Anda.

Ada beberapa cara berbeda untuk memikirkan observabilitas yang tepat: Ini mengukur hal-hal yang sebelumnya tidak dapat diukur. Jika sesuatu dapat diukur, itu dapat ditingkatkan. Kedua, ini adalah cara untuk mengukur keseluruhan sistem yang kompleks — keduanya, bagian yang secara tradisional dipikirkan oleh tim teknologi (“kode mereka”), dan dependensi pihak ketiga yang tidak dipikirkan oleh siapa pun sampai ada keluhan pelanggan.

Faktanya, banyak SLA memiliki klausa seperti “mengecualikan peristiwa di luar kendali perusahaan”. Ini bagus ketika aplikasi Anda tidak aktif dan Anda tidak perlu membayar denda SLA — tetapi bukankah dampak reputasi atau hilangnya pendapatan dari pengguna yang tidak dapat terhubung ke situs selama waktu ini jauh lebih berharga? ?

Faktanya, alih-alih menggunakan observabilitas sebagai penopang untuk memahami kegagalan, mengapa tidak menggunakannya sebagai alat untuk perbaikan? Apakah Anda berpikir tentang berapa banyak pendapatan yang lebih tinggi jika kinerja situs Anda meningkat beberapa milidetik?

Mendapatkan gambaran yang lebih lengkap

Tujuan akhir harus dapat diamati dari semua aspek sistem – baik bagian yang berada di bawah kendali organisasi, dan yang berada di luarnya. Ini sangat penting karena sistem menjadi lebih kompleks dan rumit.

Alat pemantauan konvensional hanya mendeteksi gambaran masalah dan mengapa masalah itu muncul. Alat visibilitas seperti analisis statis, Pemantauan Kinerja Aplikasi (APM) dan Pemantauan Kinerja Jaringan (NPM) tidak menunjukkan bagaimana kode dan komponen lain beroperasi dan berinteraksi di dunia nyata. Karena mereka tidak memperhitungkan keseluruhan sistem, alat ini sering melewatkan masalah dunia nyata.

Saat ini, dengan wadah, layanan mikro, dan kerangka kerja multi-cloud yang muncul sebagai normal baru — dan API mengikat bersama sebanyak beberapa lusin aplikasi — tidak mungkin lagi sekadar memeriksa server aplikasi web, klien aplikasi, cache, atau database untuk mendiagnosis suatu masalah. Aplikasi web menggabungkan kode dari banyak sumber, dan titik koneksi dengan berbagai vendor dan mitra bisnis — untuk fungsi penting seperti pengiriman konten, fungsi keranjang belanja, dan pembayaran web — dapat melibatkan banyak aplikasi berbeda.

Masalah kinerja menyebabkan konsekuensi dunia nyata. Bahkan jika 19 komponen bekerja dengan sempurna tetapi satu tertinggal atau gagal, hasilnya bisa menjadi lambat memuat halaman web atau pembayaran yang tidak dapat diproses. Saat ini, konsumen mengharapkan tugas berlangsung dengan cepat dan efisien. Sistem harus tangguh: tersedia, andal, berkinerja. Untuk tim TI yang menangani masalah ketahanan, sangat penting untuk dapat mengidentifikasi asal-usulnya. Apakah itu terhubung ke kegagalan resolusi DNS, atau masalah pengkodean? Apakah ini disebabkan oleh masalah penyedia backbone atau bug di API?

Untuk sistem yang kompleks, perusahaan harus menggunakan Internet Performance Monitoring (IPM) untuk memberikan pandangan holistik dari keseluruhan sistem dan ketergantungannya. Ketika diterapkan dengan benar, IPM dapat memberikan tampilan tingkat tinggi dari perspektif pengguna, serta detail terperinci tentang kinerja setiap ketergantungan dan titik akhir, bahkan yang tidak Anda kendalikan. Untuk aplikasi atau jaringan yang berada di bawah kendali perusahaan, IPM dapat dengan mudah dilengkapi dengan alat APM atau NPM.

Bergerak melampaui diagnostik dasar

Sama seperti lebih banyak piksel menghasilkan gambar yang lebih baik, lebih banyak data meningkatkan kemampuan untuk mendiagnosis masalah. Misalnya, memahami bahwa API berjalan lambat hanyalah titik awal. Sebagian besar organisasi tidak memiliki metrik yang berhenti pada kinerja titik akhir API. Mereka memiliki metrik tingkat bisnis, seperti ketersediaan, atau kinerja perjalanan pengguna, atau pendapatan. Mengetahui bahwa sepotong kode membutuhkan waktu 15 milidetik untuk dieksekusi adalah berguna – tetapi hanya jika informasi itu dapat dijalin bersama untuk menceritakan keseluruhan cerita tentang kinerja sistem dan dipetakan kembali ke metrik tingkat bisnis tersebut.

Pendekatan ini, terutama bila dikombinasikan dengan pelatihan dan akuntabilitas, menetapkan dasar untuk kerangka kerja praktik terbaik. Pada akhirnya, pengembang, insinyur, dan spesialis operasi memiliki alat yang mereka butuhkan untuk unggul – dan sebagai hasilnya, pelanggan akan menikmati pengalaman digital yang lebih baik, dengan korelasi langsung dengan pendapatan.

Jika diterapkan dengan benar, strategi pemantauan atau observabilitas perusahaan terjalin di seluruh siklus hidup pengembangan perangkat lunak mereka. Ini juga mencakup tim teknis dan non-teknis. Ketika diimplementasikan dengan benar, itu adalah kerangka kerja yang memastikan bahwa pengembang aplikasi dan operator aplikasi selaras. Ini juga memberikan wawasan kepada CEO atau CRO tentang hubungan antara ketahanan aplikasi dan keuntungan.

Tanyakan kepada tim teknis Anda apa tujuan kinerja aplikasi mereka dan bagaimana mereka diukur. Mengetahui tujuan ini dan terus bekerja untuk meningkatkan baseline akan membuat tim Anda lebih kohesif dan aplikasi Anda lebih baik. Memahami dampak aplikasi Anda pada pengalaman pelanggan membuat perusahaan Anda lebih baik. Dan sebagai efek samping yang bagus, itu membuat CEO senang.

Kredit gambar: Gunnar Pippel/Shutterstock

Sergey Katsev adalah Wakil Presiden Teknik, Catchpoint.

Author: Kenneth Henderson