Musim semi ini kami mendapati diri kami dalam kondisi yang sangat ceria. Karena pandemi ini, menjadi jelas bahwa konferensi musim panas kami perlu dipindahkan secara online. Dan untuk melaksanakannya secara online secara efisien, solusi perangkat lunak yang sudah jadi tidak cocok untuk kami; kami perlu menulis sendiri. Dan kami punya waktu tiga bulan untuk melakukan ini.
Jelas sekali bahwa ini merupakan tiga bulan yang menyenangkan. Namun dari luar tidak sepenuhnya jelas: apa itu platform konferensi online? Terdiri dari bagian apa? Oleh karena itu, pada konferensi DevOops musim panas yang lalu, saya bertanya kepada mereka yang bertanggung jawab atas tugas ini:
- Nikolay Molchanov - direktur teknis JUG Ru Group;
- Vladimir Krasilshchik adalah seorang programmer Java pragmatis yang bekerja di backend (Anda juga dapat melihat laporannya di konferensi Java kami);
- Artyom Nikonov bertanggung jawab atas semua streaming video kami.
Omong-omong, pada konferensi musim gugur-musim dingin kami akan menggunakan versi perbaikan dari platform yang sama - sehingga banyak pembaca habra yang masih menjadi penggunanya.
Gambar besar
— Bagaimana komposisi tim?
Nikolay Molchanov: Kami memiliki seorang analis, seorang desainer, seorang penguji, tiga front-end, dan back-end. Dan, tentu saja, spesialis berbentuk T!
— Secara umum seperti apa prosesnya?
Nikolai: Hingga pertengahan Maret, kami sama sekali belum siap untuk online. Dan pada tanggal 15 Maret, seluruh carousel online mulai berputar. Kami menyiapkan beberapa repositori, merencanakan, mendiskusikan arsitektur dasar dan melakukan semuanya dalam tiga bulan.
Hal ini tentu saja melalui tahapan klasik perencanaan, arsitektur, pemilihan fitur, pemungutan suara untuk fitur-fitur tersebut, kebijakan untuk fitur-fitur tersebut, desain, pengembangan, dan pengujian. Hasilnya, pada tanggal 6 Juni, kami meluncurkan semuanya ke produksi. . Ada 90 hari untuk semuanya.
— Apakah kita berhasil mencapai komitmen kita?
Nikolai: Karena kami sekarang berpartisipasi dalam konferensi DevOops online, itu berarti berhasil. Saya pribadi berkomitmen pada hal utama: Saya akan memberikan kepada pelanggan alat yang dapat digunakan untuk melakukan konferensi online.
Tantangannya adalah ini: memberi kami alat yang dapat digunakan untuk menyiarkan konferensi kami kepada pemegang tiket.
Semua perencanaan dibagi menjadi beberapa tahap, dan semua fitur (sekitar 30 global) dibagi menjadi 4 kategori:
- yang pasti akan kita lakukan (kita tidak bisa hidup tanpanya),
- yang akan kita lakukan kedua,
- yang tidak akan pernah kita lakukan,
- dan hal yang tidak akan pernah kami lakukan.
Kami membuat semua fitur dari dua kategori pertama.
— Saya tahu bahwa total 600 terbitan JIRA telah dibuat. Dalam tiga bulan, Anda membuat 13 layanan mikro, dan saya menduga layanan tersebut tidak hanya ditulis di Java. Anda menggunakan teknologi yang berbeda, Anda memiliki dua klaster Kubernetes di tiga zona ketersediaan dan 5 aliran RTMP di Amazon.
Sekarang mari kita lihat setiap komponen sistem secara terpisah.
Mengalir
— Mari kita mulai ketika kita sudah memiliki gambar video, dan gambar tersebut dikirimkan ke beberapa layanan. Artyom, beri tahu kami bagaimana streaming ini terjadi?
Artyom Nikonov: Skema umum kami terlihat seperti ini: gambar dari kamera -> ruang kendali kami -> server RTMP lokal -> Amazon -> pemutar video. Keterangan lebih lanjut di Habré pada bulan Juni.
Secara umum, ada dua cara global untuk melakukan hal ini: baik melalui perangkat keras atau berdasarkan solusi perangkat lunak. Kami memilih jalur perangkat lunak karena lebih mudah dalam kasus speaker jarak jauh. Tidak selalu mungkin untuk membawa perangkat keras ke pembicara di negara lain, namun mengirimkan perangkat lunak ke pembicara tampaknya lebih mudah dan lebih dapat diandalkan.
Dari sudut pandang perangkat keras, kami memiliki sejumlah kamera (di studio kami dan di speaker jarak jauh), sejumlah remote control di studio, yang terkadang harus diperbaiki tepat di bawah meja selama siaran.
Sinyal dari perangkat ini memasuki komputer dengan kartu penangkap, kartu input/output, dan kartu suara. Di sana sinyal dicampur dan dirangkai menjadi tata letak:
Contoh layout untuk 4 speaker
Contoh layout untuk 4 speaker
Selanjutnya, penyiaran berkelanjutan disediakan dengan bantuan tiga komputer: ada satu mesin utama dan sepasang mesin yang berfungsi secara bergantian. Komputer pertama mengumpulkan laporan pertama, komputer kedua mengumpulkan laporan istirahat, komputer pertama mengumpulkan laporan berikutnya, komputer kedua mengumpulkan laporan istirahat berikutnya, dan seterusnya. Dan mesin utama mencampurkan yang pertama dengan yang kedua.
Ini menciptakan semacam segitiga, dan jika salah satu dari node ini gagal, kami dapat dengan cepat dan tanpa kehilangan kualitas terus mengirimkan konten ke klien. Kami mengalami situasi seperti itu. Selama minggu pertama konferensi, kami memperbaiki satu mesin, menyalakan/mematikannya. Masyarakat tampaknya senang dengan ketahanan kami.
Selanjutnya, aliran dari komputer menuju ke server lokal, yang memiliki dua tugas: merutekan aliran RTMP dan mencatat cadangan. Jadi kami memiliki beberapa titik perekaman. Aliran video kemudian dikirim ke bagian sistem kami yang dibangun di layanan Amazon SaaS. Kita gunakan ,S3,CloudFront.
Nikolai: Apa yang terjadi sebelum video tersebut sampai ke penonton? Anda harus memotongnya, bukan?
Artyom: Kami mengompres video dari pihak kami dan mengirimkannya ke MediAlive. Kami meluncurkan transcoder di sana. Mereka mentranskode video secara real-time menjadi beberapa resolusi sehingga orang dapat menontonnya di ponsel, melalui internet yang buruk di negara tersebut, dan sebagainya. Kemudian aliran-aliran ini dipotong , beginilah cara kerja protokolnya . Kami mengirimkan daftar putar ke frontend yang berisi petunjuk ke bagian ini.
— Apakah kita menggunakan resolusi 1080p?
Artyom: Lebar video kami sama dengan 1080p - 1920 piksel, dan tingginya sedikit lebih kecil, gambarnya lebih memanjang - ada alasannya.
Pemain
— Artyom menjelaskan bagaimana video tersebut masuk ke streaming, bagaimana video tersebut didistribusikan ke dalam daftar putar yang berbeda untuk resolusi layar yang berbeda, dipotong-potong dan masuk ke pemutar. Kolya, sekarang beri tahu saya pemain macam apa ini, bagaimana cara mengonsumsi streaming, mengapa HLS?
Nikolai: Kami memiliki pemain yang dapat ditonton oleh semua pemirsa konferensi.
Pada dasarnya, ini adalah pembungkus perpustakaan , di mana banyak pemain lain ditulis. Namun kami memerlukan fungsi yang sangat spesifik: memutar ulang dan menandai tempat orang tersebut berada, laporan apa yang sedang dia tonton. Kami juga membutuhkan tata letak kami sendiri, segala jenis logo, dan segala sesuatu yang ada di dalam kami. Oleh karena itu, kami memutuskan untuk menulis perpustakaan kami sendiri (pembungkus HLS) dan menyematkannya di situs.
Ini adalah fungsi root, jadi ini diimplementasikan hampir pertama kali. Dan kemudian segala sesuatu tumbuh di sekitarnya.
Faktanya, melalui otorisasi, pemain menerima daftar putar dari backend dengan tautan ke bagian-bagian yang berkorelasi dengan waktu dan kualitas, mengunduh yang diperlukan dan menunjukkannya kepada pengguna, melakukan semacam “keajaiban” di sepanjang jalan.
Contoh garis waktu
— Sebuah tombol terpasang langsung di pemutar untuk menampilkan garis waktu semua laporan...
Nikolai: Ya, kami segera menyelesaikan masalah navigasi pengguna. Pada pertengahan April kami memutuskan bahwa kami tidak akan menyiarkan setiap konferensi kami di situs web terpisah, namun akan menggabungkan semuanya dalam satu situs. Sehingga pengguna tiket Full Pass dapat dengan leluasa beralih antar konferensi yang berbeda: baik siaran langsung maupun rekaman konferensi sebelumnya.
Dan untuk memudahkan pengguna menavigasi aliran saat ini dan beralih antar trek, kami memutuskan untuk membuat tombol “Seluruh siaran” dan kartu laporan horizontal untuk beralih antara trek dan laporan. Ada kontrol keyboard.
— Apakah ada kesulitan teknis dalam hal ini?
Nikolai: Mereka memiliki bilah gulir yang menandai titik awal berbagai laporan.
— Pada akhirnya, apakah Anda menerapkan tanda ini pada bilah gulir sebelum YouTube melakukan hal serupa?
Artyom: Mereka memilikinya dalam versi beta saat itu. Sepertinya ini adalah fitur yang cukup kompleks karena mereka telah mengujinya sebagian dengan pengguna selama setahun terakhir. Dan sekarang sudah mencapai penjualan.
Nikolai: Tapi sebenarnya kami menjualnya lebih cepat. Sejujurnya, di balik fitur sederhana ini terdapat banyak sekali backend, frontend, perhitungan, dan matematika di dalam pemutar.
Paling depan
— Mari kita cari tahu bagaimana konten yang kami tampilkan (kartu ucapan, pembicara, situs web, jadwal) sampai ke bagian depan?
Vladimir Krasilshchik: Kami memiliki beberapa sistem TI internal. Ada sistem yang memasukkan semua laporan dan semua pembicara. Ada proses dimana seorang pembicara mengambil bagian dalam sebuah konferensi. Pembicara mengajukan permohonan, sistem menangkapnya, lalu ada saluran tertentu yang menjadi dasar pembuatan laporan.
Beginilah cara pembicara melihat saluran pipa
Sistem ini adalah pengembangan internal kami.
Selanjutnya, Anda perlu membuat jadwal dari masing-masing laporan. Seperti yang Anda ketahui, ini adalah masalah NP-hard, tapi entah bagaimana kami menyelesaikannya. Untuk melakukan ini, kami meluncurkan komponen lain yang menghasilkan jadwal dan mengunggahnya ke layanan cloud pihak ketiga Contentful. Di sana semuanya tampak seperti tabel yang didalamnya terdapat hari-hari konferensi, pada hari-hari tersebut terdapat slot waktu, dan pada slot tersebut terdapat laporan, istirahat atau kegiatan sponsorship. Jadi konten yang kami lihat terletak di layanan pihak ketiga. Dan tugasnya adalah menyampaikannya ke situs.
Tampaknya situs tersebut hanyalah halaman dengan pemain, dan tidak ada yang rumit di sini. Tapi ternyata tidak. Backend di belakang halaman ini menuju ke Contentful, mengambil jadwal dari sana, membuat beberapa objek dan mengirimkannya ke frontend. Menggunakan koneksi websocket, yang dibuat oleh setiap klien platform kami, kami mengiriminya pembaruan jadwal dari backend ke frontend.
Kasus nyata: pembicara berganti pekerjaan tepat selama konferensi. Kita perlu mengganti lencana perusahaan tempat dia bekerja. Bagaimana hal ini bisa terjadi dari backend? Pembaruan dikirim ke semua klien melalui websocket, dan kemudian frontend sendiri menggambar ulang timeline. Semua ini terjadi dengan mulus. Kombinasi layanan cloud dan beberapa komponen kami memberi kami peluang untuk menghasilkan semua konten ini dan menyajikannya ke depan.
Nikolai: Penting untuk diklarifikasi di sini bahwa situs kami bukanlah aplikasi SPA klasik. Ini adalah situs web yang dirender berbasis tata letak dan SPA. Google sebenarnya melihat situs ini sebagai HTML yang dirender. Ini bagus untuk SEO dan untuk mengirimkan konten kepada pengguna. Ia tidak menunggu 1,5 megabyte JavaScript dimuat sebelum melihat halamannya, ia langsung melihat halaman yang sudah dirender, dan Anda merasakannya setiap kali Anda mengganti laporan. Semuanya terjadi dalam setengah detik, karena kontennya sudah siap dan diposting di tempat yang tepat.
— Mari kita menarik garis di bawah semua hal di atas dengan membuat daftar teknologinya. Tyoma mengatakan kami memiliki 5 aliran Amazon dan kami mengirimkan video dan suara ke sana. Kami memiliki skrip bash di sana, kami menggunakannya untuk meluncurkan dan mengkonfigurasi...
Artyom: Ini terjadi melalui API AWS, masih banyak lagi layanan sampingan teknis di sana. Kami membagi tanggung jawab kami sehingga saya dapat memenuhinya , dan pengembang front-end dan back-end mengambilnya dari sana. Kami memiliki sejumlah ikatan kami sendiri untuk menyederhanakan tata letak konten, yang kemudian kami buat dalam 4K, dll. Karena tenggat waktunya sangat ketat, kami melakukannya hampir seluruhnya di AWS.
— Lalu semua ini masuk ke pemutar menggunakan sistem backend. Kami memiliki TypeScript, React, Next.JS di pemutar kami. Dan di backend kami memiliki beberapa layanan di C#, Java, Spring Boot dan Node.js. Ini semua disebarkan menggunakan Kubernetes menggunakan infrastruktur Yandex.Cloud.
Saya juga ingin mencatat bahwa ketika saya perlu mengenal platform ini, ternyata mudah: semua repositori ada di GitLab, semuanya diberi nama dengan baik, tes telah ditulis, ada dokumentasi. Artinya, bahkan dalam mode darurat, mereka mengurus hal-hal seperti itu.
Kendala Bisnis dan Analisis
— Kami menargetkan 10 pengguna berdasarkan kebutuhan bisnis. Saatnya membicarakan keterbatasan bisnis yang kita alami. Kami harus memastikan beban kerja yang tinggi, memastikan kepatuhan terhadap undang-undang tentang pelestarian data pribadi. Lalu apa lagi?
Nikolai: Awalnya kami mulai dari persyaratan video. Yang paling penting adalah penyimpanan video terdistribusi di seluruh dunia untuk pengiriman cepat ke klien. Lainnya menyertakan resolusi 1080p, serta mundur, yang banyak lainnya tidak diterapkan dalam mode langsung. Kemudian kami menambahkan kemampuan untuk mengaktifkan kecepatan 2x, dengan bantuannya Anda dapat "mengikuti" siaran langsung dan terus menonton konferensi secara real time. Dan seiring berjalannya waktu, fungsi penandaan garis waktu muncul. Selain itu, kami harus toleran terhadap kesalahan dan menahan beban 10 koneksi. Dari sudut pandang backend, ini adalah sekitar 000 koneksi dikalikan dengan 10 permintaan untuk setiap penyegaran halaman. Dan ini sudah 000 RPS/detik. Cukup banyak.
— Apakah ada persyaratan lain untuk “pameran virtual” dengan stan online mitra?
Nikolai: Ya, hal ini harus dilakukan dengan cepat dan universal. Kami memiliki hingga 10 perusahaan mitra untuk setiap konferensi, dan semuanya harus diselesaikan dalam satu atau dua minggu. Namun, kontennya sedikit berbeda dalam format. Namun mesin templat tertentu dibuat untuk merakit halaman-halaman ini dengan cepat, tanpa partisipasi pengembangan lebih lanjut.
— Ada juga persyaratan untuk analisis tampilan dan statistik waktu nyata. Saya tahu kami menggunakan Prometheus untuk ini, tetapi beri tahu kami lebih detail: persyaratan apa yang kami penuhi untuk analitik, dan bagaimana penerapannya?
Nikolai: Awalnya, kami memiliki persyaratan pemasaran untuk mengumpulkan pengujian A/B dan mengumpulkan informasi guna memahami cara memberikan konten terbaik dengan benar kepada klien di masa depan. Ada juga persyaratan untuk beberapa analitik pada aktivitas mitra dan analitik yang Anda lihat (konter kunjungan). Semua informasi dikumpulkan secara real time.
Kami dapat memberikan informasi ini dalam bentuk agregat bahkan kepada pembicara: berapa banyak orang yang menonton Anda pada waktu tertentu. Pada saat yang sama, untuk mematuhi Undang-undang Federal 152, akun pribadi dan data pribadi Anda tidak dilacak dengan cara apa pun.
Platform ini sudah memiliki alat pemasaran dan metrik kami untuk mengukur aktivitas pengguna secara real time (siapa yang menonton laporan pada detik berapa) untuk membuat grafik kehadiran pada laporan. Berdasarkan data ini, penelitian sedang dilakukan yang akan membuat konferensi berikutnya menjadi lebih baik.
Tipuan
— Apakah kita mempunyai mekanisme anti-penipuan?
Nikolai: Karena kerangka waktu yang ketat dari sudut pandang bisnis, tugas awalnya tidak ditetapkan untuk segera memblokir koneksi yang tidak perlu. Jika dua pengguna masuk dengan akun yang sama, mereka dapat melihat konten. Namun kami tahu berapa banyak penayangan simultan dari satu akun. Dan kami melarang beberapa pelanggar yang sangat jahat.
Vladimir: Untungnya, salah satu pengguna yang diblokir memahami mengapa hal ini terjadi. Dia datang, meminta maaf dan berjanji akan membeli tiket.
— Agar semua ini terjadi, Anda harus benar-benar melacak semua pengguna dari pintu masuk hingga keluar, selalu mengetahui apa yang mereka lakukan. Bagaimana cara kerja sistem ini?
Vladimir: Saya ingin berbicara tentang analitik dan statistik, yang kemudian kami analisis untuk keberhasilan laporan atau kemudian dapat diberikan kepada mitra. Semua klien terhubung melalui koneksi websocket ke cluster backend tertentu. Itu berdiri di sana . Setiap klien pada setiap periode waktu mengirimkan apa yang dia lakukan dan lagu apa yang dia tonton. Kemudian informasi ini dikumpulkan menggunakan pekerjaan Hazelcast yang cepat dan dikirim kembali ke semua orang yang menonton trek ini. Kami melihat di sudut berapa banyak orang yang sekarang bersama kami.
Informasi yang sama disimpan di dan pergi ke data lake kami, dari sana kami memiliki kesempatan untuk membuat grafik yang lebih menarik. Timbul pertanyaan: berapa banyak pengguna unik yang melihat laporan ini? Kita pergi ke , ada ping dari semua orang yang datang dengan id laporan ini. Kami mengumpulkan, mengumpulkan yang unik, dan sekarang kami dapat memahaminya.
Nikolai: Namun pada saat yang sama, kami juga menerima data real-time dari Prometheus. Ini diatur terhadap semua layanan Kubernetes, terhadap Kubernetes itu sendiri. Ia mengumpulkan segalanya, dan dengan Grafana kita dapat membuat grafik apa pun secara real time.
Vladimir: Di satu sisi, kami mengunduh ini untuk pemrosesan OLAP lebih lanjut. Dan untuk OLTP, aplikasi mengunduh semuanya ke Prometheus, Grafana, dan grafiknya bahkan menyatu!
- Ini adalah kasus ketika grafiknya konvergen.
Perubahan Dinamis
— Beri tahu kami bagaimana perubahan dinamis diterapkan: jika laporan dibatalkan 6 menit sebelum dimulai, apa rangkaian tindakannya? Saluran pipa mana yang berfungsi?
Vladimir: Pipa ini sangat kondisional. Ada beberapa kemungkinan. Yang pertama adalah program pembuatan jadwal berhasil dan mengubah jadwal. Jadwal yang diubah diunggah ke Contentful. Setelah itu backend memahami bahwa ada perubahan untuk konferensi ini di Contentful, mengambilnya dan membangunnya kembali. Semuanya dikumpulkan dan dikirim melalui websocket.
Kemungkinan kedua, ketika semuanya terjadi dengan sangat cepat: editor secara manual mengubah informasi di Contentful (tautan ke Telegram, presentasi pembicara, dll.) dan logika yang sama berfungsi seperti yang pertama kali.
Nikolai: Semuanya terjadi tanpa menyegarkan halaman. Semua perubahan terjadi dengan mulus bagi klien. Hal yang sama berlaku untuk berpindah laporan. Ketika saatnya tiba, laporan dan antarmuka berubah.
Vladimir: Selain itu, ada batas waktu untuk memulai laporan di timeline. Pada awalnya tidak ada apa-apa. Dan jika Anda mengarahkan mouse ke garis merah, maka pada titik tertentu, berkat direktur siaran, potongan akan muncul. Sutradara menetapkan awal siaran yang benar, backend mengambil perubahan ini, menghitung waktu mulai dan berakhirnya presentasi seluruh lagu sesuai dengan jadwal konferensi, mengirimkannya ke klien kami, dan pemain mengambil cutoff. Sekarang pengguna dapat dengan mudah menavigasi ke awal dan akhir laporan. Itu adalah persyaratan bisnis yang ketat, sangat nyaman dan berguna. Anda tidak membuang waktu untuk mencari waktu mulai laporan yang sebenarnya. Dan saat kami melakukan pratinjau, itu akan sangat luar biasa.
Penyebaran
— Saya ingin bertanya tentang penempatan. Kolya dan tim menghabiskan banyak waktu di awal untuk menyiapkan seluruh infrastruktur tempat segala sesuatunya dilakukan untuk kami. Katakan padaku, terbuat dari apa semua itu?
Nikolai: Dari sudut pandang teknis, awalnya kami memiliki persyaratan agar produk tersebut abstrak mungkin dari vendor mana pun. Datanglah ke AWS untuk membuat skrip Terraform khusus dari AWS, atau khusus dari Yandex, atau dari Azure, dll. tidak terlalu cocok. Kami harus pindah ke suatu tempat pada suatu saat.
Selama tiga minggu pertama kami terus mencari cara untuk melakukan hal ini dengan lebih baik. Hasilnya, kami sampai pada kesimpulan bahwa Kubernetes dalam hal ini adalah segalanya bagi kami, karena memungkinkan kami membuat layanan penskalaan otomatis, peluncuran otomatis, dan menyiapkan hampir semua layanan secara langsung. Tentu saja, semua layanan harus dilatih untuk bekerja dengan Kubernetes, Docker, dan tim juga harus belajar.
Kami memiliki dua cluster. Uji dan produksi. Mereka benar-benar identik dalam hal perangkat keras dan pengaturan. Kami menerapkan infrastruktur sebagai kode. Semua layanan secara otomatis diluncurkan ke dalam tiga lingkungan dari cabang fitur, cabang master, cabang pengujian, dan GitLab menggunakan jalur pipa otomatis. Ini terintegrasi secara maksimal ke dalam GitLab, terintegrasi secara maksimal dengan Elastic, Prometheus.
Kami mendapat kesempatan dengan cepat (untuk backend dalam 10 menit, untuk frontend dalam 5 menit) meluncurkan perubahan pada lingkungan apa pun dengan semua pengujian, integrasi, menjalankan pengujian fungsional, pengujian integrasi pada lingkungan, dan juga pengujian dengan pengujian beban pada lingkungan pengujian kira-kira sama dengan yang ingin kita dapatkan dalam produksi.
Tentang tes
— Anda menguji hampir semuanya, sulit mempercayai cara Anda menulis semuanya. Bisakah Anda memberi tahu kami tentang pengujian backend: seberapa banyak semuanya tercakup, pengujian apa?
Vladimir: Dua jenis tes telah ditulis. Yang pertama adalah tes komponen. Uji tingkat angkat seluruh aplikasi pegas dan dudukannya . Ini adalah ujian skenario bisnis tingkat tertinggi. Saya tidak menguji fungsi. Kami hanya menguji beberapa hal besar. Misalnya, saat pengujian, proses masuk ke pengguna ditiru, permintaan pengguna untuk tiket ke tempat yang bisa dia tuju, dan permintaan akses untuk menonton streaming. Skenario pengguna yang sangat jelas.
Kira-kira hal yang sama diterapkan dalam apa yang disebut pengujian integrasi, yang sebenarnya dijalankan di lingkungan. Faktanya, ketika penerapan produksi berikutnya diluncurkan, skenario dasar sebenarnya juga berjalan dalam produksi. Login yang sama, meminta tiket, meminta akses ke CloudFront, memeriksa apakah streaming benar-benar terhubung dengan izin saya, memeriksa antarmuka direktur.
Saat ini saya memiliki sekitar 70 pengujian komponen dan sekitar 40 pengujian integrasi. Cakupannya sangat mendekati 95%. Ini untuk komponen, lebih sedikit untuk integrasi, tidak banyak yang dibutuhkan. Mengingat proyek ini melibatkan semua jenis pembuatan kode, ini merupakan indikator yang sangat bagus. Tidak ada cara lain untuk melakukan apa yang kami lakukan dalam tiga bulan. Karena jika kami menguji secara manual, memberikan fitur kepada penguji kami, dan dia akan menemukan bug dan mengembalikannya kepada kami untuk diperbaiki, maka perjalanan bolak-balik untuk men-debug kode ini akan sangat lama, dan kami tidak akan memenuhi tenggat waktu apa pun.
Nikolai: Secara konvensional, untuk melakukan regresi pada seluruh platform ketika mengubah beberapa fungsi, Anda perlu duduk dan menyodok ke mana saja selama dua hari.
Vladimir: Oleh karena itu, sukses besar ketika saya memperkirakan suatu fitur, saya mengatakan bahwa saya memerlukan 4 hari untuk dua pena sederhana dan 1 soket web, Kolya mengizinkannya. Dia sudah terbiasa dengan kenyataan bahwa 4 hari ini mencakup 2 jenis tes, dan kemungkinan besar, itu akan berhasil.
Nikolai: Saya juga memiliki 140 tes tertulis: komponen + fungsional, yang melakukan hal yang sama. Semua skenario yang sama diuji dalam produksi, pengujian, dan produksi. Kami juga baru-baru ini menambahkan pengujian UI dasar fungsional. Dengan cara ini kami membahas fungsi paling dasar yang mungkin berantakan.
Vladimir: Tentu saja, ada baiknya membicarakan tes beban. Penting untuk menguji platform di bawah beban yang mendekati beban asli untuk memahami bagaimana semuanya, apa yang terjadi dengan Rabbit, apa yang terjadi dengan JVM, berapa banyak memori yang sebenarnya dibutuhkan.
— Saya tidak tahu pasti apakah kami sedang menguji sesuatu di sisi streaming, tapi saya ingat ada masalah dengan transcoder saat kami melakukan pertemuan. Sudahkah kita menguji alirannya?
Artyom: Diuji secara berulang. Menyelenggarakan pertemuan. Dalam proses penyelenggaraan meetup, terdapat kurang lebih 2300 tiket JIRA. Ini hanyalah hal umum yang dilakukan orang untuk mengadakan pertemuan. Kami mengambil bagian dari platform ke halaman terpisah untuk pertemuan, yang dijalankan oleh Kirill Tolkachev ().
Sejujurnya, tidak ada masalah besar. Secara harfiah beberapa kali kami menemukan bug caching di CloudFront, kami menyelesaikannya dengan cukup cepat - kami cukup mengkonfigurasi ulang kebijakannya. Ada lebih banyak bug secara signifikan pada manusia, dalam sistem streaming di situs.
Selama konferensi, saya harus menulis beberapa eksportir lagi untuk mencakup lebih banyak peralatan dan layanan. Di beberapa tempat saya harus membuat sepeda sendiri hanya demi metrik. Dunia perangkat keras AV (audio-video) tidak terlalu bagus - Anda memiliki semacam "API" peralatan yang tidak dapat Anda pengaruhi. Dan itu jauh dari fakta bahwa Anda akan bisa mendapatkan informasi yang Anda butuhkan. Vendor perangkat keras sangat lambat, dan hampir mustahil mendapatkan apa yang Anda inginkan dari mereka. Totalnya ada lebih dari 100 perangkat keras, mereka tidak memberikan apa yang Anda butuhkan, dan Anda menulis eksportir yang aneh dan berlebihan, berkat itu Anda setidaknya dapat men-debug sistem.
Оборудование
— Saya ingat bagaimana sebelum konferensi dimulai, kami membeli sebagian peralatan tambahan.
Artyom: Kami membeli komputer, laptop, dan baterai. Saat ini kita bisa hidup tanpa listrik selama 40 menit. Pada bulan Juni terjadi badai petir hebat di St. Petersburg - jadi kami mengalami pemadaman listrik. Pada saat yang sama, beberapa penyedia datang kepada kami dengan tautan optik dari berbagai titik. Ini sebenarnya adalah waktu henti bangunan selama 40 menit, yang selama itu lampu, suara, kamera, dll. akan menyala.
— Kami memiliki cerita serupa dengan Internet. Di kantor tempat studio kami berada, kami menarik jaring yang kuat di antara lantai.
Artyom: Kami memiliki 20 Gbit serat antar lantai. Lebih jauh di sepanjang lantai, di suatu tempat ada optik, di suatu tempat tidak ada optik, tetapi masih ada saluran yang lebih sedikit daripada saluran gigabit - kami menjalankan video di antara trek konferensi. Secara umum, bekerja pada infrastruktur Anda sendiri sangat nyaman, Anda jarang dapat melakukan ini pada konferensi offline di situs.
— Sebelum saya bekerja di JUG Ru Group, saya melihat bagaimana ruang perangkat keras di konferensi offline diatur dalam semalam, di mana terdapat monitor besar dengan semua metrik yang Anda buat di Grafana. Sekarang ada juga ruang kantor pusat tempat tim pengembangan duduk, yang selama konferensi memperbaiki beberapa bug dan mengembangkan fitur. Pada saat yang sama, terdapat sistem pemantauan yang ditampilkan pada layar besar. Artyom, Kolya, dan yang lainnya duduk dan memastikan semuanya tidak jatuh dan berfungsi dengan baik.
Keingintahuan dan masalah
— Anda berbicara dengan baik tentang fakta bahwa kami memiliki streaming dengan Amazon, ada pemain dengan web, semuanya ditulis dalam bahasa pemrograman yang berbeda, toleransi kesalahan dan persyaratan bisnis lainnya disediakan, termasuk akun pribadi yang didukung untuk badan hukum dan individu, dan kita bisa berintegrasi dengan seseorang menggunakan OAuth 2.0, ada anti penipuan, pemblokiran pengguna. Kami dapat meluncurkan perubahan secara dinamis karena kami melakukannya dengan baik, dan semuanya telah diuji.
Saya tertarik untuk mengetahui keanehan apa saja yang terlibat dalam memulai sesuatu. Pernahkah ada situasi aneh ketika Anda sedang mengembangkan backend, frontend, sesuatu yang gila terjadi dan Anda tidak mengerti apa yang harus dilakukan dengannya?
Vladimir: Menurut saya, hal ini baru terjadi tiga bulan terakhir. Setiap hari. Seperti yang Anda lihat, semua rambut saya telah dicabut.
Vladimir Krasilshchik setelah 3 bulan, ketika semacam permainan muncul dan tidak ada yang mengerti apa yang harus dilakukan dengannya
Setiap hari ada hal seperti ini, ketika ada saat ketika Anda mengambil dan mencabut rambut Anda, atau menyadari bahwa tidak ada orang lain, dan hanya Anda yang bisa melakukannya. Acara besar pertama kami adalah TechTrain. Pada tanggal 6 Juni jam 2 pagi kami belum meluncurkan lingkungan produksi, Kolya sedang meluncurkannya. Dan akun pribadi tidak berfungsi sebagai server otorisasi menggunakan OAuth2.0. Kami mengubahnya menjadi penyedia OAuth2.0 untuk menghubungkan platform ke sana. Saya telah bekerja mungkin selama 18 jam berturut-turut, saya melihat komputer dan tidak melihat apa pun, saya tidak mengerti mengapa komputer tidak berfungsi, dan Kolya melihat kode saya dari jarak jauh, mencari bug di konfigurasi Spring , menemukannya, dan LC berfungsi, dan dalam produksi juga.
Nikolai: Dan satu jam sebelum TechTrain dirilis.
Banyak bintang berjajar di sini. Kami sangat beruntung karena kami memiliki tim yang super, dan semua orang terinspirasi oleh ide untuk melakukannya secara online. Selama tiga bulan ini kami didorong oleh fakta bahwa kami “membuat YouTube.” Saya tidak membiarkan diri saya mencabuti rambut saya, tetapi saya mengatakan kepada semua orang bahwa semuanya akan berhasil, karena sebenarnya semuanya sudah diperhitungkan sejak lama.
Tentang kinerja
— Bisakah Anda memberi tahu saya berapa banyak orang yang berada di situs dalam satu jalur? Apakah ada masalah kinerja?
Nikolai: Tidak ada masalah kinerja, seperti yang telah kami katakan. Maksimal orang yang menghadiri satu laporan adalah 1300 orang, ini di Heisenbug.
— Apakah ada masalah dengan penayangan lokal? Dan apakah mungkin untuk mendapatkan deskripsi teknis dengan diagram cara kerjanya?
Nikolai: Kami akan membuat artikel tentang ini nanti.
Anda bahkan dapat men-debug streaming secara lokal. Begitu konferensi dimulai, segalanya menjadi lebih mudah, karena muncul aliran produksi yang dapat kita tonton sepanjang waktu.
Vladimir: Sejauh yang saya pahami, pengembang front-end bekerja secara lokal dengan tiruan, dan kemudian, karena waktu untuk meluncurkan ke pengembang di depan juga singkat (5 menit), tidak ada masalah dalam memeriksa apa yang terjadi dengan sertifikat.
— Semuanya diuji dan di-debug, bahkan secara lokal. Ini berarti kami akan menulis artikel dengan semua fitur teknis, menunjukkan kepada Anda, memberi tahu Anda semuanya dengan diagram, bagaimana keadaannya.
Vladimir: Anda dapat mengambilnya dan mengulanginya.
- Dalam 3 bulan.
Total
— Segala sesuatu yang dijelaskan bersama-sama terdengar keren, mengingat hal itu dilakukan oleh tim kecil dalam waktu tiga bulan.
Nikolai: Sebuah tim besar tidak akan melakukan ini. Namun sekelompok kecil orang yang berkomunikasi dengan cukup erat dan baik satu sama lain serta dapat mencapai kesepakatan dapat melakukan hal tersebut. Tidak ada kontradiksi di dalamnya, arsitekturnya ditemukan dalam dua hari, diselesaikan dan tidak benar-benar berubah. Ada fasilitasi yang sangat ketat terhadap kebutuhan bisnis yang masuk dalam hal menumpuk permintaan fitur dan perubahan.
— Apa daftar tugas selanjutnya yang Anda perlukan ketika konferensi musim panas sudah dilaksanakan?
Nikolai: Misalnya kredit. Garis merayap pada video, pop-up di beberapa tempat dalam video tergantung konten yang ditampilkan. Misalnya, pembicara ingin mengajukan pertanyaan kepada audiens, dan muncul suara di layar, yang kembali ke belakang berdasarkan hasil voting kepada pembicara itu sendiri. Semacam aktivitas sosial berupa like, heart, rating terhadap laporan pada saat presentasi itu sendiri, sehingga Anda dapat mengisi feedback di saat yang tepat tanpa nantinya terganggu oleh formulir feedback. Awalnya seperti ini.
Dan juga menambah seluruh platform, kecuali streaming dan konferensi, juga keadaan pasca-konferensi. Ini adalah daftar putar (termasuk yang disusun oleh pengguna), mungkin konten dari konferensi sebelumnya, terintegrasi, diberi label, dapat diakses oleh pengguna, dan juga tersedia untuk dilihat di situs web kami ().
— Teman-teman, terima kasih banyak atas jawaban Anda!
Jika di antara pembaca ada yang menghadiri konferensi musim panas kami, silakan bagikan kesan Anda tentang pemutar dan siarannya. Apa yang nyaman, apa yang membuat Anda kesal, apa yang ingin Anda lihat di masa depan?
Jika Anda tertarik dengan platform ini dan ingin melihatnya “dalam pertempuran”, kami akan menggunakannya lagi di platform kami . Ada banyak sekali jenisnya, jadi hampir pasti ada satu yang tepat untuk Anda.
Sumber: www.habr.com