Pengujian A / B adalah cara yang ampuh untuk menguji antarmuka sebelum dipublikasikan ke seluruh audiens. Saya memutuskan untuk memberi tahu alat apa ini, fitur pencatatan apa yang dimilikinya, bagaimana metrik dikompilasi, dan apa inti dari eksperimen di frontend. Mari kita bicara tentang perangkat dan layanan mereka untuk menyelesaikan tugas analitis harian. Kami akan membahas beberapa jalur pengembangan untuk pengembang yang tampaknya sudah dapat melakukan segalanya, tetapi menginginkan lebih.
- Nama saya Lesha, saya bekerja di Pencarian dan mengembangkan hasil pencarian produk Yandex yang paling penting, mungkin.
Anda semua, dengan satu atau lain cara, pernah menggunakan pencarian apa pun. Beberapa istilah. Masalahnya terdiri dari berbagai blok. Ada dokumen organik sederhana yang kami kumpulkan dari seluruh Internet dan entah bagaimana tahu caranya menyajikan, dan ada blok khusus yang kami tampilkan sebagai markup khusus. Kami tahu banyak data tentang isinya. Blok-blok ini disebut penyihir. Terminologi spesifik diadopsi oleh Yandex dan tidak hanya.
Hari ini saya ingin memberi tahu Anda bagaimana kami melakukan eksperimen, nuansa apa, peralatan, dan penemuan menakjubkan apa yang ada di zashnik kami dalam bidang aktivitas kami ini.
Untuk apa pengujian A / B?
Di mana untuk memulai? Mengapa Yandex membutuhkan eksperimen A / B?
Saya ingin memulai dengan liriknya. Belum lama berselang, bersama putri saya, saya menonton satu film pendek ilmiah “4,5 miliar tahun dalam 40 menit. Sejarah Bumi. " Sering ada eksperimen A / B. Termasuk ini. Saya mencoba membuat salah satu yang paling menarik dan menyenangkan di slide ini. Inilah saat evolusi memiliki beberapa cabang. Misalnya, ada dua keluarga: marsupial dan plasenta. Dan seperti yang kita lihat sekarang, entah bagaimana plasenta menang. Inilah sebabnya mereka menang.
Ini sudah dipikirkan oleh otak manusia. Dalam perkembangan pranatal dan lebih lanjut dari marsupial, kotak tengkorak mengeras dengan cepat dan mencegah perkembangan otak. Dan di dalam plasenta, semuanya berkembang, semuanya lunak sampai otak terlipat dengan alur, permukaannya tumbuh, membuat neokorteks curam. Akibatnya, plasenta akan menang dalam evolusi. Apa gunanya Alam memiliki evolusi, dan kekuatan penggeraknya adalah mutasi dan seleksi alam, seperti yang mungkin Anda ketahui.
Perusahaan memiliki analogi eksperimen A / B alam: setiap bisnis ingin mengembangkan secara stabil dan menginvestasikan upaya-upaya tertentu, menggunakan eksperimen A / B sebagai cara untuk bermutasi, mengubah sesuatu. Perusahaan menggunakan semua kekuatan matematis analitik untuk memilih eksperimen ini.
Eksperimen A / B dan seluruh evolusi ditujukan untuk mencapai tujuan, mampu mengamati diri sendiri dari luar, membandingkannya dengan pesaing, dan mencari hipotesis baru. Untuk pengembang pada umumnya, terutama untuk vendor front-end, penting untuk menguji fitur baru pada sebagian kecil dari produksi.
Sebuah cerita pendek terlihat seperti ini. Kita dapat mengatakan bahwa 2010, ketika manajer produk kami melakukan percobaan A / B pertama, adalah periode pasca-setelah Big Bang. Gugus bintang tertentu baru saja mulai muncul, pemahaman tentang bagaimana melakukan percobaan A / B, apa yang harus dilihat, cara mencatat. Benjolan pertama, kesalahan pertama, diakumulasikan.
Selama periode ini dari 2010 hingga 2019, kami mencapai hasil yang signifikan. Saat ini, semua istilah tentang log, percobaan, metrik, tujuan, pencapaian, dan sebagainya sudah menjadi dasar bagi kami, khususnya bagi pendatang baru untuk pengembang baru. Ini adalah bahasa gaul kami, mentalitas Yandex internal kami.
Pencarian Besar
Kami beralih langsung ke daging, tentang Pencarian hebat. Pencarian Besar dalam strukturnya terlihat seperti ini.
Kami memiliki browser, penyeimbang, banyak pusat data, dan infrastruktur yang sangat kaya di bawah tenda. Diagram menunjukkan bahwa perangkat ini kompleks, ada banyak komponen. Dan yang paling mengejutkan, semua komponen ini mampu melakukan percobaan A / B dan, tentu saja, menulis dan menganalisis log.
Log
Log ditulis oleh banyak komponen. Tentu saja, lebih menarik bagi kita untuk berbicara dalam konteks frontend. Frontend mencatat dua irisan besar yang signifikan. Ini murni log teknis yang terkait dengan pengukuran langsung beberapa waktu, kinerja pada perangkat klien. Pengukuran pengguna nyata, metrik RUM. Berikut adalah waktu sebelum byte pertama, sebelum rendering pertama, sebelum memuat semua konten DOM dan sebelum interaktivitas.
Bersamaan dengan ini, ada log yang ditulis oleh server dan pengaturan huruf klien. Ini adalah log grosir. Dalam realitas kita, bahkan di sini ada istilah "baobab". Mengapa baobab? Karena pohon: pohon komponen, pohon fitur, di mana salah satu log utama adalah log tayangan, klik, dan peristiwa teknis lainnya yang kami daftarkan untuk analisis selanjutnya.
Slide ini menunjukkan alat untuk menyimpan log di dalam Yandex dan untuk komputasi terdistribusi. Kami memilikinya bernama
Yandex Tables, YT . Segala sesuatu yang dikembangkan di Yandex memiliki huruf Y. Saya mencoba mengingat analog dari alat ini di dunia luar. Menurut pendapat saya, Facebook memiliki alat MapReduce yang disebut Hadoop. Ini memungkinkan Anda untuk menerapkan penyimpanan dan perhitungan.
Slide menunjukkan statistik untuk 8 Agustus tahun ini. Salah satu log pencarian paling berharga, sesi pengguna, adalah 54 terabyte per hari dalam bentuknya. Ini adalah sejumlah besar informasi yang tidak dapat disekop dalam bentuk mentahnya. Karena itu, seseorang harus dapat membangun beberapa cerita tingkat tinggi.
Untuk bekerja dengan log, khususnya, semua pengembang kami yang sangat berpengalaman harus menguasai semacam alat analitik.
Di dalam Yandex, ada alat
YQL . Ini adalah bahasa query dan perhitungan seperti SQL di atas log kami, yang memungkinkan Anda membangun semua jenis lingkungan, melakukan hanya analisis tingkat rendah, melihat langsung pada angka tertentu, persentase rata-rata, dan membuat laporan. Alat ini cukup kuat, memiliki API bercabang besar dan banyak fitur. Banyak proses infrastruktur dibangun atas dasar itu.
Selain itu, di antara pengembang front-end kami dan, khususnya, analis, alat Jupyter sangat diminati dan populer. Sudah dimungkinkan dengan kekuatan alat Numpy dan lainnya yang diketahui oleh Anda, misalnya Pandas, untuk melakukan beberapa jenis transformasi dan analisis tingkat tinggi atas log kami.
Kami sangat menghargai log, secara harfiah memperjuangkan setiap entri. Untuk melakukan ini, dalam repositori proyek pencarian kami, ada tes dalam kode front-end yang memungkinkan kami untuk memverifikasi bahwa semua peristiwa dicatat dengan benar. Kami menulis tes untuk setiap fitur kami, kami dapat memeriksa skrip tertentu, mengklik tautan tertentu, tombol, menggulir galeri tertentu di antarmuka kami dan melihat jumlah log yang dicatat persis dengan nilai yang kami harapkan, yang kami rekam, yang kami buat beberapa standar. Dan kemudian kita akan masuk ke nilai referensi ini.
Kami juga sangat memperhatikan kinerja antarmuka kami. Dalam permintaan kumpulan apa pun dengan fungsionalitas baru atau refactoring fungsionalitas yang ada, kami sangat memperhatikan waktu, volume, jumlah panggilan fungsi tertentu. Pada slide adalah salah satu laporan permintaan kumpulan yang benar-benar acak. Kami memiliki dua tahap pencarian, satu adalah tipe ajax: pertama kita memuat header pada halaman dengan panah pencarian, dan ketika semua sumber pencarian bekerja, kita masih bisa mengukur waktu templat dan semua kinerja ketika merender bagian utama dari output.
Bagi kami, seperti, tentu saja, dan untuk subjek lain dalam TI, kesalahan dalam produksi dan dalam lingkungan khusus sangat penting. Kami memiliki alat yang disebut penguat kesalahan, yang memungkinkan Anda untuk melihat kesalahan nyata dalam produksi secara real time dengan kerangka waktu yang cukup baik. Di bawah tenda, alat ini menggunakan database ClickHouse, di mana permintaan diproses cukup cepat, dan database itu sendiri dirancang untuk pekerjaan analitis. Sebagian besar interaksi diimplementasikan secara khusus dengan ClickHouse.
Kami berbicara tentang kayu, tentang varietas mereka. Ada banyak dari mereka. Untuk memindahkan eksperimen dan menganalisis sesuatu, untuk membuat keputusan tentang sesuatu, kami memiliki sejumlah besar metrik. Ini adalah beberapa konvolusi atas volume besar data mentah.
Metrik
Yandex sekarang memiliki sekitar 8,6 ribu berbagai metrik yang didasarkan pada log mentah yang sama - dan yang lebih tinggi, seperti sesi pencarian dan pengguna. Mereka sangat beragam, dan seringkali berorientasi pada fitur. Artinya, ini adalah metrik khusus untuk penyihir tertentu, blok tertentu, sepotong permintaan, jenis dokumen yang kami tampilkan.
Dalam skenario pengujian kami, dimungkinkan untuk memeriksa nilai metrik di antarmuka kami sendiri. Saat kami kehilangan skenario tertentu, kami dapat melihat hasil perhitungan log dan sumber nilai metrik tertentu.
Peran penting dimainkan oleh metrik kecepatan. Semuanya cukup sederhana. Ini biasanya semacam persentil, atau nilai rata-rata dan penyimpangan dan signifikansi statistiknya.
Ada banyak dari mereka, mereka memperhitungkan waktu standardisasi dan waktu pengiriman konten ke perangkat pengguna.
Kinerja klien langsung juga diperhitungkan: waktu render, waktu interaktivitas, dan lainnya.
Eksperimennya
Jadi bagaimana kita melakukan eksperimen? Misalnya, ada dua pengguna yang tiba-tiba memutuskan untuk menggunakan pencarian Yandex. Kami sepakat satu sama lain - kami pergi hari ini, misalnya, ke Starbucks, dan mencari dia menggunakan pencarian kami. Permintaan mereka, jatuh ke infrastruktur sumber pencarian kami, ditandai dengan spidol tertentu. Dengan spidol, pengguna ini masuk ke berbagai keranjang percobaan. Setiap keranjang berisi serangkaian bendera tertentu yang mengaktifkan eksperimen di setiap sumber pencarian. Misalnya, kedua pengguna ini pergi ke hasil pencarian dan menggunakan petunjuk pencarian. Pengenalan pertama "Starbucks", melihat beberapa petunjuk kata demi kata dalam bentuk kata-kata. Ketika dia berakhir dengan pencarian, dia melihat blok tentang organisasi ini, mengatakan - ya, saya menemukannya, saya pergi ke sana. Dan pengguna kedua menemukan petunjuk navigasi yang sudah ada di antarmuka petunjuk pencarian, dengan cepat beralih ke organisasi dan menerima respons lebih cepat.
Untuk semua variasi perubahan ini, perbedaan dalam antarmuka, dalam fungsi tertentu, alat BEM bertanggung jawab. Ini bukan hanya kerangka kerja, tetapi seluruh metodologi untuk deklarasi komponen visual, modifikasi mereka. Bahkan di sini di latar belakang adalah kromosom DNA yang tampaknya bermutasi melalui bem. Sebenarnya, bem adalah Yandex DNA, DNA percobaan di ujung depan.
Ada beberapa implementasi dalam metodologi. Salah satunya adalah pada tumpukan i-bem yang sudah mapan, yang berada di suatu tempat di bawah kap yang terhubung ke jQuery. Ini sudah merupakan teknologi yang cukup matang. Pada tumpukan seperti itu, kita dapat memecahkan banyak masalah. Hari ini, teknologi bem-react, yang sudah diimplementasikan pada kerangka Bereaksi dan bahasa TypeScript, mendapatkan dorongan dan pengembangan besar. Semua alat ini memungkinkan Anda membuat eksperimen dan mengabarkan ide utama - kemampuan untuk mendeklarasikan komponen visual dan modifikasinya. Kami memiliki keseluruhan level terpisah dalam repositori dengan deklarasi dari eksperimen tersebut. Tetapi sekitar tahun 2015, mereka menyadari bahwa secara ekonomis tidak menguntungkan untuk menyebarkan bendera eksperimental kami di seluruh kode front-end. Faktanya adalah bahwa unit percobaan mencapai produksi nyata, dan segala sesuatu yang tidak digunakan sangat sulit untuk dipotong dari kode nanti. Karena itu, kami mengusir mereka ke tingkat definisi yang terpisah. Dan di sini sekali lagi berkat metodologi-bem, yang memberi kami kesempatan untuk menggunakan level redefinisi. Kami menyatakan eksperimen kami pada mereka.
Ini adalah salah satu laporan percobaan. Dua kolom: kontrol dan percobaan. Sebelum Anda bahkan tidak semua yang ada di laporan. Kenapa dia begitu lama? Pertama-tama, Anda melihat berapa metrik yang kami miliki - 8,6 ribu.
Namun peran utama sebenarnya hanya dimainkan oleh metrik yang berbeda. Dan kami dapat melakukan percobaan pada saat yang bersamaan, yaitu, pada satu pengguna kami dapat secara bersamaan memiliki sekitar 20 percobaan. Mereka tidak saling bertentangan dengan cara apa pun, dan dalam semua percobaan kami hanya metrik produk murni yang ternoda, tanpa memengaruhi satu sama lain. Sekarang ada sekitar 800 percobaan dalam produksi: tidak hanya mesin pencari, tetapi juga dari begitu banyak layanan. Alat itu disebut AB, yang tidak mengejutkan. Layanan memulai eksperimen di dalamnya, mendeklarasikan sampel tertentu, dan kemudian melihat perbedaan antara metrik, yang setelah beberapa periode mulai berbeda dalam eksperimen dan kontrol.
Peran Pengembang Terkait
Sebagai konsekuensi dari keanekaragaman ini dalam pekerjaan pengembang front-end, bahkan ada peran di antara mereka. Ada pakar percobaan, dan untuk ini kami secara resmi memberikan prestasi dalam kerangka jaringan internal Yandex, orang benar-benar lulus ujian. Mereka menganalisis eksperimen, memvalidasi hasil mereka tentang para ahli dan mendapatkan paspor yang mengatakan: "Saya seorang analis, saya bisa menganalisis eksperimen." Dan secara umum, semua pekerjaan dengan eksperimen, dengan metrik kami, difokuskan terutama pada peningkatan produk itu sendiri. Saya adalah salah satu perwakilan, saya sangat termotivasi untuk mengembangkan produk, dan bukan hanya kode dan bukan teknologinya. Dan itu benar-benar membuat saya bersemangat ketika saya datang ke sebuah tim dan membuat suatu produk.
Apa intinya? Kami memiliki sejumlah besar log yang ditulis setiap hari untuk sistem penyimpanan kami. Ada banyak metrik yang kami hitung, kami melakukan eksperimen padanya. Infrastruktur sangat besar. Alat modern teratas yang memungkinkan Anda untuk mengimplementasikan sejumlah besar alat adalah paket bem-react. Kami menaruh perhatian besar pada indikator kecepatan dan kualitas, stabilitas produk. Dan secara umum, kami semakin banyak berkembang di pengembang kami peran baru yang terkait dengan spesialisasi utama - frontend. Saya memiliki semuanya. Terima kasih atas perhatian anda