Charity Majors, CTO & Co-Founder di Honeycomb – Seri Wawancara

Charity adalah seorang insinyur operasional dan pendiri startup yang tidak sengaja di Honeycomb. Sebelum ini, dia bekerja di Parse, Facebook (META ), dan Linden Lab pada infrastruktur dan alat pengembang, dan selalu tampaknya berakhir dengan menjalankan database. Dia adalah co-penulis O’Reilly’s Database Reliability Engineering, dan menyukai kebebasan berbicara, perangkat lunak bebas, dan scotch malt tunggal.

Anda adalah Manajer Teknik Produksi di Facebook (sekarang Meta) selama lebih dari 2 tahun, apa saja highlight Anda dari periode ini dan apa saja kesan utama Anda dari pengalaman ini?

Saya bekerja pada Parse, yang merupakan backend untuk aplikasi mobile, semacam Heroku untuk mobile. Saya tidak pernah tertarik bekerja di perusahaan besar, tetapi kami diakuisisi oleh Facebook. Salah satu kesan utama saya adalah bahwa akuisisi sangat, sangat sulit, bahkan dalam keadaan terbaik. Saya selalu memberikan saran kepada pendiri lain bahwa jika Anda akan diakuisisi, pastikan Anda memiliki sponsor eksekutif, dan pikirkan dengan serius tentang apakah Anda memiliki keselarasan strategis. Facebook mengakuisisi Instagram tidak lama sebelum mengakuisisi Parse, dan akuisisi Instagram hampir tidak berjalan lancar, tetapi akhirnya sangat sukses karena mereka memiliki keselarasan strategis dan sponsor yang kuat.

Saya tidak memiliki waktu yang mudah di Facebook, tetapi saya sangat berterima kasih atas waktu yang saya habiskan di sana; saya tidak tahu apakah saya bisa memulai perusahaan tanpa pelajaran yang saya pelajari tentang struktur organisasi, manajemen, strategi, dll. Ini juga memberi saya reputasi yang membuat saya menarik bagi VC, tidak satu pun dari mereka yang memberi saya perhatian sebelum itu. Saya sedikit kesal tentang ini, tetapi saya akan tetap menerimanya.

Apakah Anda bisa membagikan kisah di balik peluncuran Honeycomb?

Tentu. Dari perspektif arsitektur, Parse sudah mendahului zamannya — kami menggunakan microservices sebelum ada microservices, kami memiliki lapisan data yang sangat terbagi, dan sebagai platform yang melayani lebih dari satu juta aplikasi mobile, kami memiliki banyak masalah multi-tenancy yang sangat rumit. Pelanggan kami adalah pengembang, dan mereka terus-menerus menulis dan mengunggah potongan kode dan kueri baru yang, katakanlah, “beragam kualitas” — dan kami hanya harus menerima semuanya dan membuatnya berfungsi, entah bagaimana.

Kami berada di garis depan perubahan yang telah menjadi mainstream sekarang. Dulu, sebagian besar arsitektur sangat sederhana, dan mereka akan gagal berulang kali dengan cara yang dapat diprediksi. Anda biasanya memiliki lapisan web, aplikasi, dan database, dan sebagian besar kompleksitas terikat pada kode aplikasi. Jadi Anda akan menulis pemeriksaan pemantauan untuk mencari kegagalan tersebut, dan membangun dasbor statis untuk data metrik dan pemantauan.

Industri ini telah mengalami ledakan kompleksitas arsitektur selama 10 tahun terakhir. Kami meledakkan monolit, sehingga sekarang Anda memiliki beberapa layanan hingga ribuan mikro layanan aplikasi. Persistensi poliglot adalah norma; bukan “database” lagi, tetapi normal memiliki banyak jenis penyimpanan yang berbeda serta sharding horizontal, lapisan caching, db-per-mikro layanan, antrian, dan lain-lain. Di atas itu, Anda memiliki kontainer yang dihosting di sisi server, layanan dan platform pihak ketiga, kode serverless, penyimpanan blok, dan lain-lain.

Bagian yang sulit dulu adalah debugging kode; sekarang, bagian yang sulit adalah menemukan di mana dalam sistem kode yang perlu Anda debug. Bukan gagal berulang kali dengan cara yang dapat diprediksi, tetapi lebih mungkin bahwa setiap kali Anda dipanggil, itu tentang sesuatu yang belum pernah Anda lihat sebelumnya dan mungkin tidak pernah Anda lihat lagi.

Debugging masalah ini dari awal sangat sulit. Dengan log dan metrik, Anda hampir harus tahu apa yang Anda cari sebelum Anda dapat menemukannya. Tetapi kami mulai memberi makan beberapa set data ke alat Facebook yang disebut Scuba, yang memungkinkan kami memotong dan memotong pada dimensi arbitrer dan data dengan kardinalitas tinggi secara real-time, dan waktu yang dibutuhkan untuk mengidentifikasi dan memecahkan masalah ini dari awal turun seperti batu, seperti dari jam ke… menit? detik? Ini tidak lagi menjadi masalah teknik, tetapi masalah dukungan. Anda hanya bisa mengikuti jejak roti ke jawaban setiap saat, klik-klik-klik.

Ini sangat menakjubkan. Sumber ketidakpastian dan kesulitan yang besar serta pelanggan yang tidak bahagia dan panggilan 2 pagi ini… hanya hilang. Ini tidak sampai Christine dan saya meninggalkan Facebook bahwa kami menyadari betapa besar perubahan ini telah mengubah cara kami berinteraksi dengan perangkat lunak. Ide kembali ke hari-hari lama pemantauan dan dasbor adalah tidak terpikirkan.

Tetapi pada saat itu, kami secara jujur berpikir bahwa ini akan menjadi solusi niche — bahwa ini memecahkan masalah yang mungkin dimiliki platform multitenant besar lainnya. Ini tidak sampai kami telah membangun selama hampir setahun bahwa kami mulai menyadari bahwa, wow, ini sebenarnya menjadi masalah bagi semua orang.

Bagi pembaca yang tidak familiar, apa spesifiknya platform observabilitas dan bagaimana itu berbeda dari pemantauan tradisional dan metrik?

Pemantauan tradisional terkenal memiliki tiga pilar: metrik, log, dan jejak. Anda biasanya perlu membeli banyak alat untuk memenuhi kebutuhan Anda: logging, tracing, APM, RUM, dashboarding, visualisasi, dll. Masing-masing ini dioptimalkan untuk kasus penggunaan yang berbeda dalam format yang berbeda. Sebagai insinyur, Anda duduk di tengah-tengah alat-alat ini, mencoba membuat sense dari semuanya. Anda memindai dasbor mencari pola visual, Anda menyalin-tempel ID dari log ke jejak dan kembali. Ini sangat reaktif dan sepotong-sepotong, dan biasanya Anda merujuk pada alat-alat ini ketika Anda memiliki masalah — mereka dirancang untuk membantu Anda mengoperasikan kode dan menemukan bug dan kesalahan.

Observabilitas modern memiliki satu sumber kebenaran; acara log terstruktur yang sewenang-wenang. Dari acara-acara ini, Anda dapat menghasilkan metrik, dasbor, dan log Anda. Anda dapat memvisualisasikan mereka sepanjang waktu sebagai jejak, Anda dapat memotong dan memotong, Anda dapat memperbesar ke permintaan individu dan keluar ke tampilan panjang. Karena semuanya terhubung, Anda tidak perlu melompat dari alat ke alat, menebak atau mengandalkan intuisi. Observabilitas modern tidak hanya tentang bagaimana Anda mengoperasikan sistem Anda, tetapi tentang bagaimana Anda mengembangkan kode Anda. Ini adalah substrat yang memungkinkan Anda menghubungkan loop umpan balik yang kuat dan ketat yang membantu Anda mengirimkan banyak nilai kepada pengguna dengan cepat, dengan keyakinan, dan menemukan masalah sebelum pengguna Anda melakukannya.

Anda dikenal karena percaya bahwa observabilitas menawarkan satu sumber kebenaran dalam lingkungan teknik. Bagaimana AI terintegrasi ke dalam visi ini, dan apa saja manfaat dan tantangannya dalam konteks ini?

Observabilitas seperti memakai kacamata sebelum Anda meluncur ke jalan raya. Pengembangan yang didorong oleh tes (TDD) merevolusi perangkat lunak pada awal 2000-an, tetapi TDD telah kehilangan efikasi seiring dengan kompleksitas yang semakin banyak terletak pada sistem kita bukan hanya perangkat lunak. Semakin banyak, jika Anda ingin mendapatkan manfaat yang terkait dengan TDD, Anda sebenarnya perlu menginstrumentasi kode dan melakukan sesuatu yang mirip dengan observabilitas yang didorong oleh pengembangan, atau ODD, di mana Anda menginstrumentasi saat Anda pergi, mengirimkan dengan cepat, lalu melihat kode Anda di produksi melalui lensa instrumentasi yang baru saja Anda tulis dan bertanya pada diri sendiri: “apakah itu melakukan apa yang saya harapkan, dan apakah ada yang lain yang terlihat… aneh?”

Tes saja tidak cukup untuk mengkonfirmasi bahwa kode Anda melakukan apa yang seharusnya. Anda tidak tahu sampai Anda telah menontonnya di produksi, dengan pengguna nyata pada infrastruktur nyata.

Jenis pengembangan ini — yang termasuk produksi dalam loop umpan balik yang cepat — sebenarnya lebih cepat, lebih mudah, dan lebih sederhana daripada mengandalkan tes dan siklus deploy yang lebih lambat. Setelah pengembang mencoba bekerja dengan cara ini, mereka terkenal tidak mau kembali ke cara lama yang lambat.

Apa yang membuat saya bersemangat tentang AI adalah bahwa ketika Anda mengembangkan dengan LLM, Anda harus mengembangkan di produksi. Satu-satunya cara Anda dapat menghasilkan set tes adalah dengan memvalidasi kode Anda di produksi dan bekerja mundur. Saya pikir menulis perangkat lunak yang didukung oleh LLM akan menjadi keterampilan yang sama umumnya dengan menulis perangkat lunak yang didukung oleh MySQL atau Postgres dalam beberapa tahun, dan harapan saya adalah bahwa ini akan menarik insinyur dengan cepat ke cara hidup yang lebih baik.

Anda telah mengekspresikan kekhawatiran tentang utang teknis yang meningkat karena revolusi AI. Apakah Anda bisa menjelaskan jenis utang teknis yang dapat diperkenalkan AI dan bagaimana Honeycomb membantu dalam mengelola atau memitigasi utang-utang ini?

Saya khawatir tentang utang teknis dan, mungkin lebih penting, utang organisasi. Salah satu jenis utang teknis terburuk adalah ketika Anda memiliki perangkat lunak yang tidak dipahami oleh siapa pun. Yang berarti bahwa setiap kali Anda perlu memperluas atau mengubah kode itu, atau memecahkan atau memperbaikinya, seseorang harus melakukan pekerjaan yang sulit untuk mempelajari itu.

Dan jika Anda mengirimkan kode ke produksi yang tidak dipahami oleh siapa pun, ada kemungkinan besar bahwa itu tidak ditulis untuk dipahami. Kode yang baik ditulis untuk mudah dibaca dan dipahami dan diperluas. Ini menggunakan konvensi dan pola, menggunakan penamaan yang konsisten dan modularisasi, ini menyeimbangkan DRY dan pertimbangan lain. Kualitas kode tidak dapat dipisahkan dari seberapa mudah orang dapat berinteraksi dengannya. Jika kita hanya melemparkan kode ke produksi karena itu dikompilasi atau lulus tes, kita menciptakan es batu masalah teknis di masa depan untuk diri kita sendiri.

Jika Anda telah memutuskan untuk mengirimkan kode yang tidak dipahami oleh siapa pun, Honeycomb tidak dapat membantu dengan itu. Tetapi jika Anda peduli dengan mengirimkan perangkat lunak yang bersih dan dapat diiterasi, instrumentasi dan observabilitas sangat penting untuk upaya itu. Instrumentasi seperti dokumentasi plus pelaporan status waktu nyata. Instrumentasi adalah satu-satunya cara Anda dapat mengkonfirmasi bahwa perangkat lunak Anda melakukan apa yang Anda harapkan, dan berperilaku seperti yang pengguna Anda harapkan.

Bagaimana Honeycomb menggunakan AI untuk meningkatkan efisiensi dan efektivitas tim teknik?

Insinyur kami menggunakan AI secara luas secara internal, terutama CoPilot. Insinyur junior kami melaporkan menggunakan ChatGPT setiap hari untuk menjawab pertanyaan dan membantu mereka memahami perangkat lunak yang mereka bangun. Insinyur senior kami mengatakan itu sangat baik untuk menghasilkan perangkat lunak yang akan sangat membosankan atau menjengkelkan untuk ditulis, seperti ketika Anda memiliki file YAML besar untuk diisi. Ini juga berguna untuk menghasilkan potongan kode dalam bahasa yang tidak biasa Anda gunakan, atau dari dokumentasi API. Seperti, Anda dapat menghasilkan contoh yang sangat baik dan dapat digunakan dari sesuatu menggunakan SDK dan API AWS, karena itu dilatih pada repositori yang memiliki penggunaan nyata dari kode itu.

Namun, setiap kali Anda membiarkan AI menghasilkan kode Anda, Anda harus melangkah melalui itu baris demi baris untuk memastikan itu melakukan hal yang benar, karena itu pasti akan menghasilkan sampah pada saat-saat tertentu.

Apakah Anda bisa memberikan contoh tentang bagaimana fitur yang didukung AI seperti asisten kueri atau integrasi Slack meningkatkan kolaborasi tim?

Ya, tentu. Asisten kueri kami adalah contoh yang sangat baik. Menggunakan pembangun kueri sangat rumit dan sulit, bahkan bagi pengguna yang kuat. Jika Anda memiliki ratusan atau ribuan dimensi dalam telemetri Anda, Anda tidak selalu dapat mengingat apa yang paling berharga disebut. Dan bahkan pengguna yang kuat lupa detail tentang bagaimana menghasilkan jenis grafik tertentu.

Jadi asisten kueri kami memungkinkan Anda untuk bertanya menggunakan bahasa alami. Seperti, “apa endpoint terlambat?”, atau “apa yang terjadi setelah deploy terakhir saya?” dan itu menghasilkan kueri dan menjatuhkan Anda ke dalamnya. Sebagian besar orang menemukan bahwa menyusun kueri baru dari awal sangat sulit dan mudah untuk menyesuaikan yang sudah ada, jadi itu memberi Anda keunggulan.

Honeycomb menjanjikan resolusi insiden yang lebih cepat. Apakah Anda bisa menjelaskan bagaimana integrasi log, metrik, dan jejak ke dalam tipe data yang disatukan membantu dalam pemecahan masalah dan resolusi masalah yang lebih cepat?

Semuanya terhubung. Anda tidak perlu menebak. Sebagai gantinya, daripada memandang bahwa dasbor ini terlihat seperti dasbor itu, atau menebak bahwa lonjakan ini dalam metrik Anda harus sama dengan lonjakan ini dalam log Anda berdasarkan timestamp….sebagai gantinya, data semua terhubung. Anda tidak perlu menebak, Anda hanya bisa bertanya.

Data menjadi berharga dengan konteks. Generasi alat sebelumnya bekerja dengan menghilangkan semua konteks pada waktu penulisan; setelah Anda telah membuang konteks, Anda tidak pernah bisa mendapatkannya kembali.

Juga: dengan log dan metrik, Anda harus tahu apa yang Anda cari sebelum Anda dapat menemukannya. Ini tidak benar untuk observabilitas modern. Anda tidak perlu tahu apa-apa, atau mencari apa-apa.

Ketika Anda menyimpan data kontekstual yang kaya, Anda dapat melakukan hal-hal dengannya yang terasa seperti sihir. Kami memiliki alat yang disebut BubbleUp, di mana Anda dapat menggambar gelembung di sekitar apa pun yang Anda pikir aneh atau mungkin menarik, dan kami menghitung semua dimensi di dalam gelembung vs di luar gelembung, baseline, dan sortir dan bedakan. Jadi Anda seperti “gelembung ini aneh” dan kami segera memberitahu Anda, “itu berbeda dalam xyz cara”. Jadi banyak debugging turun ke “ini hal yang saya pedulikan, tetapi mengapa saya peduli tentang itu?” Ketika Anda dapat segera mengidentifikasi bahwa itu berbeda karena permintaan ini berasal dari perangkat Android, dengan ID build ini, menggunakan paket bahasa ini, di wilayah ini, dengan ID aplikasi ini, dengan payload besar… sekarang Anda mungkin sudah tahu persis apa yang salah dan mengapa.

Ini tidak hanya tentang data yang disatukan, tetapi juga tentang bagaimana kita dengan mudah menangani data dengan kardinalitas tinggi, seperti ID unik, ID keranjang belanja, ID aplikasi, nama depan/belakang, dll. Generasi alat sebelumnya tidak dapat menangani data kaya seperti itu, yang agak tidak percaya ketika Anda memikirkan tentang itu, karena data kaya dan dengan kardinalitas tinggi adalah data yang paling berharga dan mengidentifikasi semua.

Bagaimana meningkatkan observabilitas diterjemahkan ke dalam hasil bisnis yang lebih baik?

Ini adalah salah satu pergeseran besar lainnya dari generasi sebelumnya ke generasi observabilitas baru. Di masa lalu, sistem, aplikasi, dan data bisnis semua terisolasi dari satu sama lain ke dalam alat yang berbeda. Ini tidak masuk akal — setiap pertanyaan menarik yang Anda ingin tanyakan tentang sistem modern memiliki elemen dari ketiganya.

Observabilitas tidak hanya tentang bug, atau downtime, atau gangguan. Ini tentang memastikan bahwa kita bekerja pada hal yang benar, bahwa pengguna kita memiliki pengalaman yang hebat, bahwa kita mencapai hasil bisnis yang kita targetkan. Ini tentang membangun nilai, bukan hanya mengoperasikan. Jika Anda tidak bisa melihat ke mana Anda akan pergi, Anda tidak bisa bergerak dengan cepat dan Anda tidak bisa mengoreksi jalur dengan cepat. Semakin banyak visibilitas yang Anda miliki ke dalam apa yang pengguna Anda lakukan dengan kode Anda, semakin baik dan kuat insinyur yang Anda bisa menjadi.

Di mana Anda melihat masa depan observabilitas menuju, terutama mengenai perkembangan AI?

Observabilitas semakin tentang memungkinkan tim untuk menghubungkan loop umpan balik yang ketat dan cepat, sehingga mereka dapat mengembangkan dengan cepat, dengan keyakinan, di produksi, dan membuang lebih sedikit waktu dan energi.

Ini tentang menghubungkan titik-titik antara hasil bisnis dan metode teknis.

Dan ini tentang memastikan bahwa kita memahami perangkat lunak yang kita keluarkan ke dunia. Ketika perangkat lunak dan sistem menjadi semakin kompleks, dan terutama ketika AI semakin masuk ke dalam campuran, ini lebih penting dari sebelumnya bahwa kita memegang diri kita sendiri untuk standar manusia yang dapat dipahami dan dikelola.

Dari perspektif observabilitas, kita akan melihat tingkat kesophistikasian yang meningkat dalam pipa data — menggunakan pembelajaran mesin dan teknik sampling yang canggih untuk menyeimbangkan nilai vs biaya, untuk menjaga sebanyak mungkin detail tentang peristiwa outlier dan peristiwa penting dan menyimpan ringkasan dari sisanya dengan biaya yang serendah mungkin.

Penyedia AI membuat klaim yang terlalu panas tentang bagaimana mereka dapat memahami perangkat lunak Anda lebih baik dari Anda, atau bagaimana mereka dapat memproses data dan memberi tahu manusia apa tindakan yang harus diambil. Dari semua yang saya lihat, ini adalah mimpi yang mahal. Positif palsu sangat mahal. Tidak ada pengganti untuk memahami sistem dan data Anda. AI dapat membantu insinyur Anda dengan ini! Tetapi itu tidak dapat menggantikan insinyur Anda.

Terima kasih atas wawancara yang hebat, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Honeycomb.