Mengungkap Hal Tidak Diketahui yang Masih Tidak Diketahui

Meta memiliki ekosistem produk yang digunakan oleh miliaran pengguna setiap hari, baik untuk hubungan sosial maupun interaksi bisnis. Miliaran pengguna ini juga meminta kami untuk terus-menerus dan—dengan laju yang dipercepat—memberikan fungsi dan peningkatan baru pada produk kami. Karena basis pengguna yang besar, kami mengirimkan ribuan perubahan kode setiap hari untuk memenuhi harapan tersebut.

Merilis peningkatan produk dalam jumlah besar secara terus-menerus menciptakan potensi regresi kesehatan aplikasi yang dapat menyebabkan penurunan pengalaman pengguna. Di Meta, kami memiliki lapisan fitur pencegahan yang canggih untuk mencegah pelepasan perubahan produk yang salah. Fitur pencegahan ini memantau berbagai sinyal produk dan mendeteksi regresi sebelum rilis aplikasi. Tiga area yang termasuk dalam sinyal ini adalah performa/kinerja, reliabilitas (fungsi dan sistemik), serta efisiensi. Ini secara kolektif disebut sebagai "PRE" dari produk. Pencegahan dimulai dengan berbagai pengamatan dan jejak analitik yang dikumpulkan saat developer membuat kode. Selain itu, fitur observasi dan pemantauan mengumpulkan data dari penggunaan internal produk di lingkungan praproduksi. Fitur jaminan kualitas manual dan otomatis menguji produk di lingkungan praproduksi tersebut.

Sementara mekanisme ini ada untuk menilai kualitas perubahan kode sebelum mereka sampai di produksi–dan karenanya terhindar dari berdampak pada pengguna–ada kemungkinan bahwa perubahan yang berdampak pada pengguna berhasil masuk ke proses produksi sehingga perlu dikerjakan ulang dan diterapkan sekali lagi. Untuk mengurangi kemungkinan masalah yang memengaruhi populasi besar, kami menggunakan berbagai mekanisme untuk merilis perubahan secara bertahap ke publik.

Saat ada penyimpangan dari fungsi yang diharapkan pengguna, kami mendefinisikannya sebagai regresi. Kami menggunakan kata "sinyal" untuk menunjukkan bahwa pengguna memberi tahu kami bahwa ada sesuatu yang tidak sesuai harapan mereka. Kami mengumpulkan sinyal regresi sesegera mungkin secara sistematis melalui insight data dan kode yang diinstrumentasi, lalu bekerja untuk mengurangi dampak pengguna dengan menerapkan perbaikan. Dalam kasus tersebut, ketika kami tidak mendapatkan sinyal yang kuat dari fitur kami, kami mengandalkan laporan pengguna sebagai sinyal bahwa regresi telah terjadi. Laporan ini datang melalui berbagai mekanisme, seperti pengguna menggoyangkan ponsel mereka untuk melaporkan masalah dalam konteks ketika pengguna sedang membuka aplikasi saat masalah terjadi.

Untuk memastikan bahwa kami memenuhi kebutuhan pelanggan kami dan melakukannya secepat mungkin–terkadang di hari yang sama–Meta telah banyak berinvestasi dalam sejumlah program dan sistem keandalan untuk memungkinkan daya tanggap yang signifikan dalam skala besar.

Sinyal dapat berasal dari pengguna publik kami (individu, perusahaan, grup, dll.) atau dari pengguna internal. Kami dengan hati-hati memeriksa sinyal dari pengguna internal untuk membantu mencegah terjadinya perubahan yang tidak diinginkan dalam produksi. Perhatikan bahwa sinyalnya agregat. Contoh: sinyal menyertakan jumlah bug per juta pengguna. Sinyal juga dapat berasal dari fitur dan skenario pengujian otomatis, fitur pengembangan (kami memperingatkan developer tentang perubahan yang dapat menyebabkan masalah runtime), pencatatan sistem, dan banyak sumber lainnya. Kami juga memiliki fitur yang memperkuat sinyal ini agar cepat dalam menentukan penyebab dan perbaikan yang tepat.

Setelah regresi teridentifikasi, kami melanjutkan agar cepat menemukan teknisi yang relevan untuk menerapkan perbaikan dan merilisnya. Bergantung pada kerumitan regresi, kami menggunakan sejumlah metode untuk menentukan teknisi yang tepat, termasuk memanfaatkan kecerdasan Meta dalam pembelajaran mesin. Karena cara kerja pembelajaran mesin, ini adalah proses yang berkelanjutan karena kami merilis fitur baru dan melatih ulang model kami untuk mengikuti perubahan konstan.

Dan ya, ada tujuan akhirnya: Kami berkembang dari mendeteksi regresi, hingga menguranginya, hingga mencegahnya dan menahannya secara berkelanjutan. Dalam prosesnya, kami memaksimalkan daya tanggap, laba atas investasi, dan efisiensi.

Di bagian selanjutnya, kami akan membahas secara lebih mendetail tentang cara kami menetapkan dengan pasti bahwa regresi telah terjadi, dan dengan pengetahuan tersebut, cara kami menanggapinya.

Menerjemahkan Hal Tidak Diketahui Menjadi Diketahui & Mengukurnya

Saat kami berbicara tentang hal yang tidak diketahui, kami mengacu pada bug yang sedang dialami oleh pengguna atau sistem. Pertama-tama, kami mungkin mengetahui tentang kemungkinan bug dari sejumlah sumber yang berbeda.

• Pengujian sintetik atas berfungsinya aplikasi kami dan produk spesifik dalam aplikasi tersebut.
• Pengguna internal yang menguji untuk menemukan bug. Ini dapat mencakup tim pengujian khusus kami, atau basis pengguna yang lebih luas di dalam Meta.
• Pengguna eksternal yang mengalami masalah menggunakan dialog laporkan masalah di aplikasi kami.

Bug ini tidak diketahui sampai benar-benar ditandai sebagai insiden yang dialami oleh pengguna. Ketika jumlah laporan bug tersebut mencapai ambang tertentu, kami menganggapnya benar-benar positif, mewakili peristiwa regresi: perubahan kode telah membuat bug baru dan kami harus melanjutkan dengan cepat untuk memitigasinya. Ada dua jenis laporan utama:

• “Hal tidak diketahui yang diketahui”—saat kode yang diinstrumentasi mendeteksi dan melaporkan regresi; dan kami memiliki sejumlah fitur yang membantu menghasilkan sinyal ini
• “Hal tak diketahui yang tidak diketahui”—saat regresi tidak tertangkap secara internal dan kami mengandalkan pengguna untuk benar-benar melaporkan regresi tersebut

Selain itu, regresi dibagi menjadi beberapa kategori, seperti apakah mereka mewakili bug kode, sesuatu yang lebih mirip spam, atau pelanggaran kebijakan konten lainnya. Fokus kami adalah pada area pertama, tempat kami ingin mengatasi masalah pengalaman pengguna terkait kode. Bagaimana cara Anda melakukannya dengan para pengguna yang melaporkan ribuan masalah?

Memproduksi Sinyal dan Insight

Untuk mengelola volume laporan yang besar, kami membuat sinyal khusus yang menandai masalah bagi kami. Jenis sinyal pertama adalah jika ambang batas diatur dengan benar, akan memberitahukan bahwa memang telah terjadi insiden atau regresi. Perhatikan bahwa beberapa peristiwa mungkin terjadi, tergantung pada jenis regresi. Contoh: regresi mungkin memengaruhi banyak produk karena basis kode umum. Kami mencari kesamaan tersebut dan mengatasinya sebagai insiden tunggal untuk menyelaraskan sumber daya secara optimal. Grafik di bawah ini adalah contoh cara secara visual melihat penyimpangan dari garis tren yang menunjukkan regresi.

Kami kemudian mengumpulkan sinyal tambahan, beberapa di antaranya menunjukkan jenis regresi yang mungkin kami hadapi. Sinyal ini memberikan insight tentang gejala yang terkait dengan regresi, dan dihasilkan oleh algoritma pembelajaran mesin yang diatur untuk produk Meta tertentu. Algoritme menganalisis laporan pengguna untuk menentukan penyebab regresi dan karenanya, tim teknik mana yang paling baik mengatasinya dengan menerapkan perbaikan kode atau tindakan lain.

Banyak sinyal lain juga dihasilkan berdasarkan data catatan yang telah dikumpulkan. Catatan diagnostik ini dapat berupa catatan sisi klien atau sisi server yang—dengan persetujuan pengguna—dikumpulkan untuk membantu menentukan penyebabnya. Aplikasi menyertakan alur persetujuan yang sesuai untuk menentukan apakah jenis data ini dapat dikumpulkan berdasarkan izin pengguna. Kami juga mempertimbangkan usia data ini untuk mematuhi peraturan yang berlaku.

Kombinasi sinyal memungkinkan kami memahami regresi dan menugaskannya ke tim produk yang tepat untuk memitigasi masalah dengan cepat dan memulihkan pengalaman pengguna seperti yang mereka harapkan.

Insight juga diperoleh dari temuan secara agregat. Kami melihat data untuk menemukan akar penyebab umum dan menentukan apakah perubahan perlu dilakukan untuk mencegah regresi berulang. Melakukannya adalah aspek penting dari memiliki pendekatan yang kokoh untuk mengatasi masalah pengalaman pengguna karena membantu kami meminimalkan permukaan regresi dari waktu ke waktu.

Aplikasi seluler kami tidak hanya menyertakan jalur navigasi yang memungkinkan pengguna melaporkan masalah, tetapi juga menyediakan kemampuan untuk menunjukkan masalah dengan menggoyangkan perangkat. Dengan begitu, telemetri dalam konteks dapat dikumpulkan. Telemetri itu semakin diperkaya melalui sinyal Kotak Hitam yang berasal dari aplikasi. Kotak Hitam itu seperti perekam penerbangan yang secara otomatis menangkap catatan tertentu (sebagaimana disetujui oleh pengguna) tentang apa yang terjadi dengan aplikasi pada saat bug dilaporkan sehingga kami dapat mendiagnosis masalah dengan lebih baik.

Semua telemetri ini digabungkan menjadi set tampilan lini masa untuk membantu tim teknik menentukan penyebab masalah. Karena frekuensi rilis yang cepat dari aplikasi kami, serta perubahan dalam komponen aplikasi sisi server, menentukan masalah akan sulit dilakukan tanpa kemampuan ini. Memiliki telemetri ini dari waktu ke waktu membantu kami mendeteksi pola dalam regresi untuk mencegahnya di masa mendatang.

Menskalakan ke Permukaan Produk yang Lebih Kecil

Karena kami telah meningkatkan kemampuan kami untuk menghasilkan sinyal yang lebih presisi, kami dapat menyerang lebih banyak permukaan regresi, bagian dari yang sebelumnya tidak terdeteksi. Permukaan mewakili penawaran tertentu dalam suatu produk, seperti Kabar Berita atau Reels. Ini merupakan tantangan karena produk tidak hanya memiliki banyak fitur granular, tetapi fitur baru diperkenalkan secara reguler. Oleh karena itu, permukaan regresi tidak hanya besar, tetapi juga bertumbuh dari waktu ke waktu. Oleh karena itu, strategi defensif dan ofensif kami harus terus beradaptasi.

Untuk menskalakan, ada beberapa kondisi yang perlu dipenuhi:

1. Kita harus memiliki cakupan yang tepat dan klasifikasi yang sesuai untuk permukaan produk yang ada
2. Kita harus mengurangi permukaan regresi untuk produk yang sudah ada (baca: pencegahan)
3. Kami harus memperluas jangkauan algoritma kami ke permukaan produk baru

Tanpa memenuhi persyaratan di atas, kami berisiko mengalami sistem membengkak yang tidak dapat dikelola karena ukuran, kerumitan, dan ketidakakuratan. Jadi, upaya kami adalah menjaga keseimbangan tersebut sekaligus menjalankan operasi sehari-hari secara efisien.

Bergerak Melampaui Bug

Saat kami terus mengurangi permukaan regresi (tanpa lengah), kami meningkatkan fokus kami di area penting lainnya: pencegahan dan kegunaan.

Pencegahan berkaitan dengan:

1. Bagaimana cara belajar dari regresi sebelumnya?
2. Pertahanan apa yang harus diterapkan agar regresi ini tidak terjadi lagi?
3. Bagaimana cara memastikan bahwa permukaan regresi terus menurun dari waktu ke waktu?

Seperti yang telah dibahas sebelumnya, kami mengumpulkan data dari regresi sebelumnya untuk mempelajarinya. Pembelajaran tersebut dapat diterjemahkan ke dalam:

1. Menempatkan penanda dalam kode kami untuk memperingatkan kami di masa mendatang, saat masih dalam lingkungan praproduksi, sehingga kami dapat menghentikan perubahan yang tidak diinginkan agar tidak maju ke produksi
2. Meningkatkan cakupan tes di berbagai level untuk mendeteksi regresi tersebut
3. Mengubah produk itu sendiri untuk mengatasi masalah ini

Pencegahan membantu kita untuk terus menggeser regresi lebih jauh ke kiri dalam siklus pengembangan agar terus mengurangi biaya. Ini dilakukan dengan mendapatkan sinyal yang cukup kaya lebih awal dalam proses pengembangan, dimulai dengan penulisan kode dan siklus rilis praproduksi. Hal ini tidak hanya meningkatkan pengalaman pengguna tetapi juga memangkas biaya pengembangan dan membantu kami mengalihkan sumber daya ke pengembangan produk baru.

Peningkatan kemampuan dalam menangani regresi secara lebih efisien memungkinkan kami untuk lebih fokus pada kebingungan pengguna atau masalah kegunaan. Ini adalah masalah nilai yang lebih tinggi karena berfokus pada peningkatan produk dan bukan memperbaikinya. Seiring waktu, proporsi masalah kegunaan terhadap regresi akan meningkat, dan jumlah total masalah kegunaan dan regresi akan menurun.

Pada akhirnya, ini menghasilkan pengalaman pengguna yang terus meningkat seiring dengan dimensi fungsi dan kegunaan.

Artikel ini ditulis berkat kolaborasi dengan Bijan Marjan, Technical Program Manager di Meta.