Membangun sistem yang tangguh: Perjalanan kami menuju observabilitas di Intercom

Di Intercom, kami berfokus pada pengalaman pelanggan di atas segalanya – ketersediaan dan kinerja layanan kami adalah prioritas utama kami. Itu membutuhkan budaya pengamatan yang kuat di seluruh tim dan sistem kami.

Akibatnya, kami banyak berinvestasi dalam keandalan aplikasi kami. Tetapi kegagalan yang tidak terduga tidak dapat dihindari, dan ketika itu terjadi, manusialah yang memperbaikinya.

Kami mengoperasikan sistem sosio-teknis, dan kemampuannya untuk pulih ketika menghadapi kesulitan disebut ketahanan. Salah satu komponen penting dari ketahanan adalah kemampuan untuk diamati, langkah-langkah yang kami ambil untuk memungkinkan manusia “melihat” ke dalam sistem yang mereka jalankan.

Posting ini akan mengeksplorasi jalan untuk membangun budaya observabilitas yang lebih kuat, dan pelajaran yang telah kita pelajari selama ini.

Apa yang kami maksud dengan observabilitas di Intercom?

Di Intercom, kami mengirim untuk belajar. Lingkungan produksi kami adalah tempat kode, infrastruktur, dependensi pihak ketiga, dan pelanggan kami bersatu untuk menciptakan realitas objektif – ini adalah satu-satunya tempat untuk mempelajari dan memvalidasi dampak pekerjaan kami. Kami mendefinisikan observabilitas sebagai proses berkelanjutan dari manusia yang mengajukan pertanyaan tentang produksi, dan mendapatkan jawaban*.

Mari kita uraikan sedikit lagi:

• Proses berkelanjutan: Observabilitas yang berhasil berarti orang-orang mengamati sesering mungkin.
• Pertanyaan tentang produksi: Kami ingin definisi kami luas, umum, dan mewakili cakupan luas alur kerja yang kami layani.
• Jawaban*: Perhatikan tanda bintang. Tidak ada alat yang akan memberi Anda jawaban, hanya menawarkan petunjuk yang dapat Anda ikuti untuk menemukan jawaban yang sebenarnya. Anda harus menggunakan model mental Anda sendiri dan memahami sistem yang Anda jalankan.

Tahap 1: Masalah dan solusi

Berbekal definisi observabilitas kami sendiri, kami menilai praktik yang ada dan merumuskan pernyataan masalah. Sampai saat ini, alat observabilitas kami terutama didasarkan pada metrik. Alur kerja yang khas melibatkan melihat dasbor yang penuh dengan bagan dengan metrik yang diiris dan dipotong dadu oleh berbagai kombinasi atribut. Orang-orang akan mencari korelasi, tetapi sering pergi tanpa memenuhi wawasan.

“Metrik mudah ditambahkan dan dipahami, tetapi tidak memiliki atribut kardinalitas tinggi (misalnya ID Pelanggan), sehingga sulit untuk menyelesaikan penyelidikan”

Metrik mudah ditambahkan dan dipahami, tetapi tidak memiliki atribut kardinalitas tinggi (misalnya ID Pelanggan), sehingga sulit untuk menyelesaikan penyelidikan. Sebelumnya, beberapa juara observabilitas akan melanjutkan alur kerja menggunakan alat sekunder (misalnya log, pengecualian, dll), mencoba mengakses informasi kardinalitas tinggi dan membangun gambaran yang lebih lengkap. Keterampilan itu membutuhkan latihan terus-menerus – permintaan yang tidak realistis untuk sebagian besar insinyur produk yang sibuk mengirimkan produk.

Kami mengidentifikasi kurangnya pengalaman observasi yang terkonsolidasi ini sebagai masalah yang harus dipecahkan. Kami ingin memudahkan siapa saja untuk mengajukan pertanyaan sewenang-wenang tentang produksi dan mendapatkan wawasan tanpa harus menguasai seperangkat alat yang tidak terhubung, tidak diatur, dan mahal. Untuk mengurangi masalah, kami memutuskan untuk menggandakan pelacakan telemetri.

Dasbor operasional tipikal yang kami gunakan sebelum menggandakan jejak

Mengapa jejak?

Alat observabilitas apa pun hanyalah alat dengan manusia di belakangnya – dan manusia membutuhkan visualisasi yang baik. Tidak masalah jenis data apa yang mendukung visualisasi, hanya saja alat ini memungkinkan Anda untuk beralih dengan mulus di antara berbagai visualisasi dan mendapatkan perspektif alternatif tentang masalah tersebut.

Jejak memiliki keunggulan besar dibandingkan data telemetri lainnya – mereka mengkodekan informasi yang cukup tentang transaksi untuk mendukung hampir semua visualisasi. Membangun alur kerja yang dapat diamati di atas jejak memastikan pengalaman terkonsolidasi yang mulus tanpa perlu mengganti data atau alat yang mendasarinya.

Beberapa jenis visualisasi yang dapat didukung oleh jejak

Tahap 2: Menerapkan jejak

Di Intercom kami memulai dari yang kecil, memutuskan seperti apa kesuksesan dan memantau kemajuan di sepanjang jalan. Tujuan utama kami adalah untuk mengonfirmasi bahwa pelacakan akan membuat alur kerja yang dapat diamati lebih efisien. Untuk itu, kami perlu mendapatkan jejak ke tangan para insinyur sesegera mungkin.

“Alih-alih melengkapi aplikasi kami dengan jejak dari awal, kami menggunakan pustaka penelusuran yang ada yang kebetulan sudah ada di dependensi”

Untuk menghemat waktu, kami menggunakan vendor kami yang ada, Honeycomb, untuk bukti konsep kami. Kami telah membangun hubungan yang baik dengan mereka saat menggunakan alat mereka untuk acara terstruktur di masa lalu.

Alih-alih melengkapi aplikasi kami dengan jejak dari awal, kami menggunakan pustaka penelusuran yang ada yang kebetulan sudah ada di dependensi, dan melakukan sedikit penyesuaian untuk mengonversi data jejak ke dalam format asli Honeycomb. Kami memulai dengan pengambilan sampel deterministik sederhana, mempertahankan ~1% dari semua transaksi yang kami proses.

Mengaktifkan rekan satu tim untuk mengadopsi jejak

Menggeser organisasi menuju jejak bukanlah prestasi kecil. Jejak lebih kompleks daripada metrik atau log dan memiliki kurva belajar yang curam. Instrumentasi, saluran data, dan perkakas semuanya penting, tetapi tantangan terbesarnya adalah memungkinkan rekan tim Anda untuk memaksimalkan penggunaan jejak mereka. Dengan bukti konsep kami yang berjalan dalam produksi, kami segera mulai fokus untuk membangun budaya observabilitas.

“Kami tidak hanya fokus pada insinyur – kami berbicara dengan direktur, manajer program teknis, anggota tim keamanan, dan perwakilan dukungan pelanggan untuk menekankan bagaimana pelacakan dapat membantu mereka memecahkan masalah khusus mereka”

Menemukan sekutu adalah kunci sukses. Kami mengumpulkan sekelompok juara yang sudah ahli dalam pengamatan. Mereka membantu mengkonfirmasi asumsi kami dan menyebarkan berita tentang jejak dalam tim mereka. Namun kami tidak hanya berfokus pada insinyur – kami berbicara dengan direktur, manajer program teknis, anggota tim keamanan, dan perwakilan dukungan pelanggan untuk menekankan bagaimana pelacakan dapat membantu mereka memecahkan masalah khusus mereka.

Menyesuaikan pesan kami membantu mengunci dukungan. Memperkenalkan alat baru selalu membawa risiko tertentu – dengan menunjukkan potensi dan membuat orang bersemangat, kami meningkatkan peluang keberhasilan kami.

Tahap 3: Memutuskan vendor yang tepat

Dengan dimulainya program pemberdayaan, kami mulai melihat vendor modern yang berfokus pada penelusuran dan merumuskan serangkaian kriteria untuk menilai kandidat potensial.

Alur kerja : Kami mengidentifikasi alur kerja eksplorasi sebagai yang paling penting – ini akan memungkinkan para insinyur untuk memotong dan memotong data produksi secara sewenang-wenang dan mendapatkan wawasan melalui visualisasi dan atribut kardinalitas tinggi. Sebagian besar dalam mendiagnosis suatu masalah adalah dapat menemukannya, dan itu berarti memahami seperti apa "normal" itu. Kami ingin memudahkan para insinyur untuk mengeksplorasi produksi dengan mengajukan pertanyaan sesering mungkin, tidak hanya ketika masalah muncul.

“Kami ingin kontrol penuh atas cara pengambilan sampel dan penyimpanan data”

Kontrol pengambilan sampel dan retensi : Kami menginginkan kontrol penuh atas cara data akan diambil sampel dan disimpan. Pengambilan sampel deterministik membantu kami untuk bangun dan berjalan dengan cepat, tetapi kami ingin lebih selektif dan mempertahankan lebih banyak jejak "menarik" (misalnya kesalahan, permintaan yang lambat) menggunakan pengambilan sampel dinamis cerdas sambil tetap berada di bawah batas kontrak.

Visualisasi data yang akurat : Kami ingin memastikan bahwa, apa pun teknik pengambilan sampel yang kami gunakan, alat observabilitas menanganinya secara transparan dengan memaparkan angka perkiraan "benar" dalam visualisasi. Setiap vendor menghadapi masalah ini secara berbeda – beberapa mengharuskan pengiriman semua data ke agregator global untuk menyimpulkan metrik untuk indikator utama seperti tingkat kesalahan, volume, dll. Ini bukan pilihan bagi kami mengingat volume besar data yang dihasilkan oleh instrumentasi kami yang kaya.

Harga : Kami menginginkan skema harga yang sederhana dan dapat diprediksi yang berkorelasi dengan nilai yang kami dapatkan dari alat tersebut. Pengisian untuk jumlah data yang disimpan dan diekspos tampak adil.

Metrik keterlibatan : Kami ingin vendor menjadi mitra yang baik dan membantu kami melacak adopsi dan efektivitas alat dengan memaparkan metrik penggunaan utama dan tingkat keterlibatan.

Tidak ada vendor yang sempurna, jadi bersiaplah untuk berkompromi. Pada akhirnya, kami menyimpulkan bahwa Honeycomb tidak hanya bekerja lebih baik untuk alur kerja utama yang telah kami identifikasi, tetapi juga mencentang kotak pada metrik pengambilan sampel, penetapan harga, dan penggunaan – jadi kami menghindari migrasi vendor yang mahal.

Setelah tahun kerja yang penuh tantangan, kami telah menyelesaikan bagian teknis dari program observabilitas. Inilah yang telah kami capai:

• Aplikasi monolit utama kami telah diinstrumentasi secara otomatis dengan jejak kaya atribut berkualitas tinggi.
• Insinyur memiliki satu set kecil metode mudah untuk menambahkan instrumentasi kustom ke kode mereka.
• Kami telah menerapkan Honeycomb Refinery untuk mengambil sampel data secara dinamis dan mempertahankan lebih banyak jejak "menarik". Kami mendorong teknisi untuk mengonfigurasi aturan retensi khusus untuk kontrol yang lebih terperinci. Untuk transaksi yang paling berharga, dan jika memungkinkan secara ekonomi, kami menawarkan retensi 100% untuk memberikan data yang mereka butuhkan kepada orang-orang.

Tahap 4: Meningkatkan adopsi

Setelah berkomitmen pada Honeycomb dan menyelesaikan pekerjaan pada jalur data, kami mengalihkan fokus kami kembali ke pemberdayaan. Untuk membangun budaya observabilitas, Anda harus memudahkan orang untuk bergabung. Berikut adalah beberapa cara kami membantu tim mengadopsi alat observabilitas baru:

Menelusuri di lingkungan pengembangan

Untuk membiasakan engineer dengan instrumentasi penelusuran dan mendorong mereka untuk menambahkannya ke kode mereka, kami menawarkan penelusuran opsional dari lingkungan pengembangan lokal dengan jejak yang diekspos di Honeycomb. Ini membantu orang-orang untuk memvisualisasikan instrumentasi kustom baru dengan cara yang persis sama seperti yang mereka lihat saat kode mencapai produksi.

Log bisa sulit dibaca dan ditafsirkan, sedangkan tampilan jejak jauh lebih terstruktur dan terorganisir

Pintasan kueri Slackbot

Saat produksi bermasalah, hal terakhir yang Anda inginkan adalah harus berebut kueri yang tepat. Kami menambahkan reaksi bot khusus ke pesan "tunjukkan kinerja web" kepada saya. Mengikuti tautan Slackbot membuka kinerja titik akhir web yang dipecah berdasarkan layanan.

Kami merampingkan alur kerja observabilitas kami dengan Slackbot yang menyediakan pintasan ke kueri populer dalam alat observabilitas kami

Tahap 5: Refleksi dan langkah selanjutnya

Mengukur adopsi

Mengukur return-of-investment (ROI) pada alat observabilitas itu menantang. Melacak jumlah pengguna aktif adalah indikator yang baik tentang seberapa sering insinyur terlibat dengan alat ini, dan kami mendapat banyak manfaat dari metrik penggunaan Honeycomb.

Bagan ini menunjukkan peningkatan jumlah pengguna Honeycomb aktif sejak pengaktifan observabilitas dimulai

Kami melangkah lebih jauh dan mengukur kegunaan dari keterlibatan tersebut. Kami mendalilkan bahwa jika wawasan yang diperoleh dari alat observabilitas itu berharga, orang akan membagikannya dengan rekan-rekan mereka. Alur kerja teknik kami sangat bergantung pada masalah Github, jadi kami memutuskan untuk menghitung jumlah masalah atau menarik permintaan tempat Honeycomb disebutkan atau ditautkan (jejak, hasil kueri, dll.) sebagai proxy untuk metrik adopsi. Saat kami menggandakan pemberdayaan menjelang akhir tahun 2021, kami mengamati ledakan jumlah masalah yang menyebutkan Honeycomb, membuktikan bahwa kami berada di jalur yang benar.

Bagan batang yang menunjukkan jumlah masalah GitHub di mana Honeycomb disebutkan dalam judul atau deskripsi

Alur kerja yang tidak terduga

Membangun fondasi observabilitas yang kuat memungkinkan alur kerja yang tidak dapat kami bayangkan sebelumnya. Berikut adalah beberapa favorit kami:

Menginformasikan program biaya : Karena kami melacak semua lalu lintas dan memiliki rentang untuk kueri SQL, permintaan Elasticsearch, dll., kami dapat menyelidiki lonjakan penggunaan bagian bersama yang terpisah dari infrastruktur kami (misalnya klaster basis data) dan mengaitkannya ke satu pelanggan. Dengan mencocokkan data ini dengan biaya masing-masing komponen infrastruktur, kami dapat memberikan perkiraan harga pada setiap transaksi yang kami layani. Observabilitas secara tak terduga telah menjadi komponen integral dari program biaya infrastruktur kami.

Meningkatkan audit keamanan : Mampu mempertahankan 100% dari transaksi yang dipilih memungkinkan kami untuk mempertahankan semua interaksi dengan konsol data produksi kami, membantu keamanan untuk membangun visibilitas yang lebih baik atas akses ke data pelanggan kami.

Apa berikutnya?

Membangun budaya observabilitas akan terus menjadi bagian dari program teknis kami: kami akan fokus pada peningkatan materi orientasi kami, menjalin observabilitas lebih lanjut melalui penelusuran ke dalam operasi R&D kami, dan menjelajahi instrumentasi front-end.

Tertarik untuk bergabung dengan tim kami? Lihat peran rekayasa terbuka kami di sini.