Observabilitas sering kali lebih penting daripada pengujian
Dalam kebanyakan kasus, observabilitas yang baik lebih penting daripada pengujian yang baik. Seperti kita ketahui
Tidak ada sistem yang kebal terhadap kegagalan, jadi kita harus siap untuk pulih dari kegagalan
Mampu pulih dari kegagalan dengan cepat, itu merupakan dampak dari observabilitas yang baik. Dalam hal ini, saya akan sedikit menyebutkan 3 fase kegagalan:
- Peringatan di picu, itu bisa berasal dari sistem atau pengguna, jika itu berasal dari pengguna, itu pertanda kita perlu memperbarui aturan peringatan kita.
- Penelitian masalah, ini adalah fase di mana kita mencoba mencari tahu apa yang salah dengan sistem.
- Perbaikan, ini adalah fase di mana kita menjalankan tugas untuk membawa kita ke keadaan sehat.
Dari gambar diatas, kita bisa lihat bahwa memiliki observabilitas yang baik akan membantu mengurangi waktu sistem untuk pulih (Mean Time to Recover). Memberi kita peluang untuk kita untuk dapat membuat perubahan lebih cepat, dikarenakan kemampuan kita untuk pulih dari permasalahan sudah cukup baik, yang membuat ongkos kesalahan (error cost) yang kita gunakan lebih sedikit.
Tentu saja, itu semua bergantung pada anggaran kesalahan (error budget) yang kita anggarkan terhadap sistem yang kita operasikan. Dan ketika kita mengupas lebih dalam mengenai perubahan yang cepat, itu akan membawa kita untuk belajar bagaimana gagal dengan anggun.
Dan memiliki pengujian yang baik akan mencegah frekuensi kegagalan dari waktu ke waktu. Dalam hal itu, keduanya observabilitas dan pengujian dalam suatu sistem itu penting.
Jadi, seperti apa observabilitas yang baik?
Tidak akan ada jawaban tunggal untuk ini, semuanya tergantung pada sistem yang anda gunakan. Tetapi dalam kasus ini, saya ingin berbagi pola umum konsumsi informasi yang membantu kita mengamati sistem kita.
Metrics
Metrics adalah ukuran penilaian kuantitatif yang biasa digunakan untuk menilai, membandingkan, dan melacak kinerja suatu sistem. Ini memungkinkan kita untuk melakukan eksplorasi secara langsung keseluruhan dari sebuah sistem.
Ini memberi Anda cara untuk melihat garis besar dari sebuah sistem, seperti:
- berapa rata-rata penggunaan memori di semua pusat data (datacenter)
- atau berapa tingkat kesalahan (error rate) di beberapa aplikasi.
Dimana pula terdapat metodologi yang populer digunakan dalam pengukuran sebuah metrics dari sebuah sistem yaitu RED Methods yang di adopsi dari buku Google SRE, dalam topik The Golden Four Signal
Logging
Logging adalah proses merekam peristiwa yang terjadi pada suatu sistem. Biasanya menggambarkan apa yang dilakukan sistem pada waktu dan konteks tertentu. Ini memungkinkan kita untuk mendapatkan pengetahuan yang lebih dalam tentang apa yang terjadi pada suatu sistem.
Tangkapan layar di atas menunjukkan daftar peristiwa dan konteks terhadap sebuah aplikasi.
Tracing
Tracing adalah serangkaian log yang terhubung dalam satu transaksi. Ini memberikan nilai yang sangat mirip dengan menambahkan konteks identitas transaksi (transaction id) pada log peristiwa. Biasanya sangat membantu untuk menganalisa sistem yang terdistribusi, dan memiliki banyak server.
Traces disamping mempresentasikan sebuah transaksi, dan span akan mewakili setiap pos (checkpoint) yang di lewati oleh transaksi.
Sebagai contoh, load balancer (span1) mengirim permintaan ke aplikasi (span2), kemudian aplikasi membaca database (span3).
Lalu, apa manfaat dari informasi ini?
Visualisasi
Visualisasi adalah satu hal berharga yang dapat Anda lakukan dengan data yang Anda miliki. Dengan mengelompokkan informasi berdasarkan apa yang penting bagi organisasi Anda, itu akan sangat membantu untuk memahami kesehatan sistem, membuat keputusan teknis / bisnis, menemukan anomali, dan hal-hal lain.
Alerting
Untuk menjaga sistem Anda seperti yang Anda harapkan. Menyiapkan notifikasi (alert) otomatis pada kondisi tertentu pada sistem Anda, berdasarkan metrics atau log. Hal ini sangat penting untuk menjaga kesehatan sistem anda agar bisa diandalkan.
Masalah paling umum tentang alerting dari pengalaman saya adalah, ketika kita memiliki terlalu banyak peringatan yang tidak dapat ditindaklanjuti, dan berujung diabaikan karena itu menjadi normal. Hal ini terjadi dikarenakan konfigurasi dari sebuah notifikasi (alert) perlu di perbaharui.
Maka dari itu untuk menghindari kondisi tersebut, hal utama yang perlu kita pahami sebelum dapat mengatur sebuah peringatan (alerting) adalah memahami kondisi normal pada sistem secara kuantitatif.
Dari situ, kita dapat mengklasifikasikan peringatan pada tingkat keparahannya, seperti:
- Notice: pemberitahuan di mana Anda mungkin tertarik untuk mendapatkan informasinya secara langsung
- Warning: gejala sistem yang akan bermasalah, atau terjadi sebuah masalah tetapi belum terlalu krusial. Warning bermanfaat untuk memberi anda ruang untuk melakukan sesuatu sebelum sesuatu yang benar-benar buruk terjadi.
- Critical: terjadi kesalahan yang cukup krusial, dan diperlukan sebuah tindakan langsung untuk memulihkannya.
Dan memiliki aturan seperti berikut:
- Sebagai peringatan, beri tahu saya hanya selama periode waktu tertentu, misalnya (08: 00–20: 00), karena pentingnya peringatan mungkin tidak layak membangunkan Anda di malam hari.
- Dan kritis hanyalah sesuatu yang akan membangunkan Anda pada pukul 04:00 pagi.
Dan seiring waktu pada setiap peringatan (alert), kita harus melakukan evaluasi kecil seperti:
- Apakah ini notifikasi tersebut bermanfaat?
- Apakah aturan notifikasi sudah sesuai yang di harapkan?
Pertanyaan-pertanyaan itu akan membantu Anda menyesuaikan aturan peringatan (alert) ke arah yang lebih akurat, dan tidak menyebabkan terlalu banyak atau terlalu sedikit.
Debugging
Debugging merupakan proses pencarian sumber masalah pada sistem. Dalam proses ini, kita akan dihadapkan dengan pertanyaan-pertanyaan yang menuntun kita pada jawaban, apa penyebab masalah pada sistem? Dan metrics, logging & tracing akan sangat berperan penting untuk menjawab pertanyaan tersebut.
Seringkali kali kita tidak menyadari seberapa pentingnya kemampuan untuk men-debug sistem yang kita operasikan di production. Sedangkan, apa yang terjadi di production merupakan satu-satunya hal mendefinisikan performa dari sistem kita.
Dibawah ini merupakan video menarik yang dapat memberi pandangan tentang debugging ketika situasi sedang genting
Kesimpulan
Beberapa hal yang dibahas diatas, bukan merupakan suatu keharusan yang dimiliki untuk mencapai observabilitas yang baik. Ben Sigelman, memberikan sudut pandang yang menarik mengenai pendekatan yang bisa kita lakukan untuk mencapai observabilitas sistem yang baik pada video Three Pillars, Zero Answers: We Need to Rethink Observability
Sebagai kesimpulan, observabilitas yang baik akan diperoleh dari waktu ke waktu dengan belajar pada setiap kegagalan sistem. Itu seharusnya memberi kita arah perbaikan yang tepat menuju sistem yang lebih tangguh.