Musim semi iki kita ketemu ing kahanan sing nyenengake banget. Amarga pandemi, dadi jelas yen konferensi musim panas kudu dipindhah kanthi online. Lan supaya bisa ditindakake kanthi online kanthi efisien, solusi piranti lunak sing wis siap ora cocog kanggo kita; kita kudu nulis dhewe. Lan kita duwe telung sasi kanggo nindakake iki.
Sing jelas wis telung sasi sing nyenengake. Nanging saka njaba ora jelas: apa platform konferensi online? Bagian apa sing kalebu? Mulane, ing pungkasan konferensi DevOops musim panas, aku takon sing tanggung jawab kanggo tugas iki:
- Nikolay Molchanov - direktur teknis JUG Ru Group;
- Vladimir Krasilshchik minangka programmer Java pragmatis sing nggarap backend (sampeyan uga bisa ndeleng laporan ing konferensi Jawa kita);
- Artyom Nikonov tanggung jawab kanggo kabeh streaming video kita.
Miturut cara, ing konferensi Autumn-musim dingin kita bakal nggunakake versi apik saka platform padha - supaya akeh maca habra isih bakal kedhaftar.
Sakabèhé gambar
- Apa komposisi tim kasebut?
Nikolay Molchanov: Kita duwe analis, desainer, tester, telung front-end, lan mburi mburi. Lan, mesthi, spesialis T-shaped!
- Apa proses katon ing umum?
Nikolay: Nganti pertengahan Maret, kita ora duwe apa-apa sing siap online. Lan tanggal 15 Maret, kabeh carousel online wiwit muter. Kita nyiyapake sawetara repositori, ngrancang, ngrembug babagan arsitektur dhasar lan nindakake kabeh sajrone telung wulan.
Iki, mesthi, ngliwati tahap perencanaan klasik, arsitektur, pilihan fitur, voting kanggo fitur kasebut, kabijakan kanggo fitur kasebut, desain, pangembangan, tes. Akibaté, ing 6 Juni, kita mbalek kabeh kanggo produksi. . Ana 90 dina kanggo kabeh.
— Apa kita bisa ngrampungake apa sing kita setya?
Nikolay: Amarga saiki kita melu konferensi DevOops online, tegese bisa digunakake. Aku pribadi setya ing bab utama: Aku bakal nggawa pelanggan alat karo kang padha bisa nggawe konferensi online.
Tantangan kasebut yaiku: wenehi alat sing bisa digunakake kanggo nyiarake konferensi menyang sing duwe tiket.
Kabeh perencanaan dipérang dadi sawetara tahapan, lan kabeh fitur (kira-kira 30 global) dipérang dadi 4 kategori:
- sing mesthi bakal ditindakake (kita ora bisa urip tanpa dheweke),
- kang bakal kita tindakake kapindho,
- sing ora bakal kita lakoni,
- lan sing ora bakal kita lakoni.
Kita nggawe kabeh fitur saka rong kategori pisanan.
- Aku ngerti yen total 600 masalah JIRA digawe. Ing telung sasi, sampeyan nggawe 13 microservices, lan aku curiga sing padha ditulis ora mung ing Jawa. Sampeyan nggunakake teknologi sing beda, sampeyan duwe rong klompok Kubernetes ing telung zona kasedhiyan lan 5 aliran RTMP ing Amazon.
Saiki ayo nimbang saben komponen sistem kasebut kanthi kapisah.
Streaming
— Ayo dadi miwiti karo nalika kita wis duwe gambar video, lan iku ditularaké kanggo sawetara layanan. Artyom, critakna kepiye streaming iki?
Artyom Nikonov: Skema umum kita katon kaya iki: gambar saka kamera -> ruang kontrol kita -> server RTMP lokal -> Amazon -> pamuter video. rincian liyane ing Habré ing wulan Juni.
Umumé, ana rong cara global kanggo nindakake iki: ing hardware utawa adhedhasar solusi piranti lunak. Kita milih rute piranti lunak amarga luwih gampang ing kasus speaker remot. Ora mesthi bisa nggawa hardware menyang speaker ing negara liya, nanging ngirim piranti lunak menyang speaker katon luwih gampang lan dipercaya.
Saka sudut pandang hardware, kita duwe sawetara kamera (ing studio lan speaker remot), sawetara kontrol remot tartamtu ing studio, sing kadhangkala kudu didandani ing sangisore meja sajrone siaran.
Sinyal saka piranti kasebut mlebu ing komputer kanthi kertu panangkepan, kertu input/output, lan kertu swara. Ing kana sinyal dicampur lan dirakit dadi tata letak:
Conto tata letak kanggo 4 speaker
Conto tata letak kanggo 4 speaker
Salajengipun, siaran terus-terusan diwenehake kanthi bantuan telung komputer: ana siji mesin utama lan sepasang sing kerja. Komputer pisanan ngumpulake laporan pisanan, kaloro - break, pisanan - laporan sabanjuré, kaloro - break sabanjuré, lan ing. Lan mesin utama nyampur pisanan karo kaloro.
Iki nggawe jinis segitiga, lan yen ana simpul kasebut gagal, kita bisa kanthi cepet lan tanpa mundhut kualitas terus ngirim konten menyang klien. Kita ngalami kahanan kaya ngono. Sajrone minggu pisanan konferensi, kita ndandani siji mesin, nguripake / mateni. Wong-wong katon seneng karo ketangguhan kita.
Sabanjure, stream saka komputer menyang server lokal, sing duwe rong tugas: rute RTMP stream lan rekaman serep. Dadi, kita duwe sawetara titik rekaman. Aliran video banjur dikirim menyang bagean sistem kita sing dibangun ing layanan Amazon SaaS. Kita nggunakake , S3, CloudFront.
Nikolay: Apa sing kedadeyan sadurunge video kasebut tekan pamirsa? Sampeyan kudu dipotong piye wae, ta?
Artyom: Kita kompres video kasebut lan dikirim menyang MediaLive. Kita miwiti transcoder ing kana. Padha transcode video ing wektu nyata menyang sawetara résolusi supaya wong bisa nonton ing telpon, liwat Internet miskin ing negara, lan ing. Banjur lepen iki dipotong dadi , iki cara kerjane protokol . Kita ngirim dhaptar lagu menyang frontend sing ngemot penunjuk menyang potongan kasebut.
— Apa kita nggunakake resolusi 1080p?
Artyom: Jembaré video kita padha karo 1080p - 1920 piksel, lan dhuwuré rada kurang, gambar luwih elongated - ana alesan kanggo iki.
Pamuter
- Artyom njlèntrèhaké carane video nemu lepen, cara disebarake menyang dhaptar lagu beda kanggo resolusi layar beda, Cut menyang chunks lan nemu menyang pamuter. Kolya, saiki ngomong apa jenis pemain iki, carane nggunakake stream, kok HLS?
Nikolay: Kita duwe pemain sing bisa ditonton kabeh pamirsa konferensi.
Ateges, iki minangka bungkus ing perpustakaan , kang ditulis akeh pemain liyane. Nanging kita butuh fungsi sing spesifik banget: muter maneh lan menehi tandha ing papan ing ngendi wong kasebut, laporan apa sing lagi ditonton. Kita uga butuh tata letak dhewe, kabeh jinis logo lan kabeh sing dibangun karo kita. Mulane, kita mutusake kanggo nulis perpustakaan kita dhewe (bungkus liwat HLS) lan sijine ing situs.
Iki minangka fungsi root, mula diimplementasikake meh pisanan. Banjur kabeh tuwuh ing saubengé.
Nyatane, liwat wewenang, pamuter ditampa saka backend dhaptar lagu kanthi pranala menyang potongan sing ana hubungane karo wektu lan kualitas, ngundhuh sing perlu lan nuduhake menyang pangguna, nindakake sawetara "sihir" ing dalan.
Tuladha timeline
- Tombol dibangun langsung menyang pamuter kanggo nampilake garis wektu kabeh laporan ...
Nikolay: Ya, kita langsung ngrampungake masalah navigasi pangguna. Ing pertengahan April, kita mutusake yen kita ora bakal nyiarake saben konferensi ing situs web sing kapisah, nanging bakal nggabungake kabeh dadi siji. Supaya pangguna tiket Full Pass bisa bebas ngalih ing antarane konferensi sing beda: siaran langsung lan rekaman sing kepungkur.
Lan kanggo nggampangake pangguna kanggo navigasi stream saiki lan ngalih ing antarane trek, kita mutusaké kanggo nggawe tombol "Siaran Kabèh" lan kertu laporan horisontal kanggo ngoper antarane trek lan laporan. Ana kontrol keyboard.
- Apa ana masalah teknis babagan iki?
Nikolay: Dheweke duwe garis gulung ing ngendi titik wiwitan laporan sing beda-beda ditandhani.
— Pungkasane, apa sampeyan ngetrapake tandha-tandha kasebut ing garis gulung sadurunge YouTube nindakake perkara sing padha?
Artyom: Dheweke duwe ing beta banjur. Kayane iki minangka fitur sing cukup rumit amarga wis nyoba sebagian karo pangguna sajrone taun kepungkur. Lan saiki wis tekan sale.
Nikolay: Nanging kita bener entuk kanggo adol luwih cepet. Jujur, konco fitur prasaja iki ana jumlah ageng backend, frontend, petungan lan math nang pamuter.
Frontend
— Ayo ngerteni kepiye konten sing dituduhake (kertu pidato, speaker, situs web, jadwal) nganti tekan ngarep?
Vladimir Krasilshchik: Kita duwe sawetara sistem IT internal. Ana sistem ing ngendi kabeh laporan lan kabeh speaker dilebokake. Ana proses ing ngendi pembicara melu konferensi. Speaker ngirim aplikasi, sistem dijupuk, banjur ana pipeline tartamtu miturut kang laporan digawe.
Iki carane speaker ndeleng pipeline
Sistem iki minangka pangembangan internal kita.
Sabanjure, sampeyan kudu nggawe jadwal saka laporan individu. Sing ngerti, iki masalah NP-hard, nanging kita piye wae ngatasi. Kanggo nindakake iki, kita miwiti komponen liyane sing nggawe jadwal lan upload menyang layanan maya pihak katelu Contentful. Ing kana, kabeh wis katon kaya meja sing ana dina konferensi, ing dina ana slot wektu, lan ing slot ana laporan, istirahat utawa kegiatan sponsor. Dadi konten sing kita deleng ana ing layanan pihak katelu. Lan tugas kanggo ngirim menyang situs.
Iku bakal koyone sing situs mung kaca karo pemain, lan ana apa-apa rumit kene. Kajaba iku ora. Backend ing mburi kaca iki menyang Contentful, entuk jadwal saka kana, ngasilake sawetara obyek lan dikirim menyang frontend. Nggunakake sambungan websocket, sing digawe saben klien ing platform kita, kita ngirim nganyari jadwal saka backend menyang frontend.
Kasus nyata: speaker diganti proyek pas konferensi. Kita kudu ngganti badge perusahaan majikane. Kepiye kedadeyan kasebut saka mburi? Nganyari dikirim menyang kabeh klien liwat websocket, banjur frontend dhewe redraws timeline. Kabeh iki kelakon seamlessly. Kombinasi layanan maya lan sawetara komponen kita menehi kesempatan kanggo ngasilake kabeh konten iki lan nyedhiyakake menyang ngarep.
Nikolay: Penting kanggo njlentrehake ing kene yen situs kita dudu aplikasi SPA klasik. Iki minangka situs web adhedhasar tata letak, lan SPA. Google bener ndeleng situs iki minangka HTML. Iki apik kanggo SEO lan kanggo ngirim konten menyang pangguna. Ora ngenteni 1,5 megabyte JavaScript kanggo mbukak sadurunge ndeleng kaca, langsung ndeleng kaca sing wis digawe, lan sampeyan ngrasakake saben sampeyan ngalih laporan. Kabeh kedadeyan ing setengah detik, amarga konten wis siyap lan dikirim ing papan sing bener.
- Ayo nggawe garis ing kabeh ndhuwur kanthi dhaptar teknologi. Tyoma ujar manawa kita duwe 5 aliran Amazon, lan kita ngirim video lan swara ing kana. Kita duwe skrip bash ing kana, kita digunakake kanggo miwiti lan ngatur ...
Artyom: Iki kedadeyan liwat API AWS, ana akeh layanan sisih teknis liyane. We dibagi tanggung jawab supaya aku ngirim menyang , lan pangembang ngarep lan mburi mburi njupuk saka ing kono. Kita duwe sawetara ikatan dhewe kanggo nyederhanakake tata letak konten, sing banjur digawe ing 4K, lsp. Wiwit deadline banget nyenyet, kita nindakake meh kabeh ing AWS.
- Banjur kabeh iki dadi menyang pamuter nggunakake sistem backend. Kita duwe TypeScript, React, Next.JS ing pamuter kita. Lan ing backend kita duwe sawetara layanan ing C #, Jawa, Spring Boot lan Node.js. Iki kabeh disebarake nggunakake Kubernetes nggunakake infrastruktur Yandex.Cloud.
Aku uga pengin dicathet yen nalika aku kudu kenal karo platform kasebut, ternyata gampang: kabeh repositori ana ing GitLab, kabeh dijenengi kanthi apik, tes ditulis, ana dokumentasi. Yaiku, sanajan ing mode darurat, dheweke ngurus perkara kasebut.
Watesan Bisnis lan Analytics
- Kita target 10 pangguna adhedhasar syarat bisnis. Iku wektu kanggo ngomong babagan watesan bisnis sing kita duwe. Kita kudu njamin beban kerja sing dhuwur, mesthekake tundhuk karo hukum babagan pengawetan data pribadhi. Lan apa maneh?
Nikolay: Kaping pisanan, kita miwiti saka syarat video. Sing paling penting yaiku nyebarake panyimpenan video ing saindenging jagad kanggo pangiriman cepet menyang klien. Liyane kalebu resolusi 1080p, uga mundur, sing akeh liyane ora dileksanakake ing mode langsung. Mengko kita nambahake kemampuan kanggo ngaktifake kacepetan 2x, kanthi bantuan sampeyan bisa "nyekel" kanthi langsung lan terus nonton konferensi ing wektu nyata. Lan ing sadawane dalan, fungsi tandha timeline katon. Kajaba iku, kita kudu toleran kesalahan lan tahan beban 10 sambungan. Saka sudut pandang backend, iki kira-kira 000 sambungan dikalikan karo 10 panjalukan kanggo saben refresh kaca. Lan iki wis 000 RPS / sec. Cukup sethithik.
- Apa ana syarat liyane kanggo "pameran virtual" karo mitra online?
Nikolay: Ya, iki kudu ditindakake kanthi cepet lan universal. Kita duwe nganti 10 perusahaan mitra kanggo saben konferensi, lan kabeh mau kudu rampung sajrone seminggu utawa rong minggu. Nanging, isine rada beda karo format. Nanging mesin cithakan tartamtu digawe sing nglumpukake kaca kasebut kanthi cepet, kanthi meh ora ana partisipasi pangembangan.
- Ana uga syarat kanggo analytics tampilan lan statistik wektu nyata. Aku ngerti yen kita nggunakake Prometheus kanggo iki, nanging marang kita luwih rinci: apa syarat kita ketemu kanggo analytics, lan carane iki dileksanakake?
Nikolay: Kaping pisanan, kita duwe syarat marketing kanggo ngumpulake tes A/B lan ngumpulake informasi supaya bisa ngerti carane ngirim konten sing paling apik kanggo klien ing mangsa ngarep. Ana uga syarat kanggo sawetara analytics babagan aktivitas partner lan analytics sing sampeyan deleng (bukak counter). Kabeh informasi diklumpukake ing wektu nyata.
Kita bisa nyedhiyani informasi iki ing wangun aggregated malah kanggo speaker: carane akeh wong padha nonton sampeyan ing wektu tartamtu. Ing wektu sing padha, kanggo netepi Hukum Federal 152, akun pribadhi lan data pribadhi ora dilacak kanthi cara apa wae.
Platform kasebut wis duwe alat marketing lan metrik kita kanggo ngukur aktivitas pangguna ing wektu nyata (sing nonton apa detik saka laporan kasebut) kanggo nggawe grafik kehadiran ing laporan kasebut. Adhedhasar data kasebut, riset ditindakake kanggo nggawe konferensi sabanjure luwih apik.
Penipuan
— Apa kita duwe mekanisme anti-penipuan?
Nikolay: Amarga pigura wektu sing nyenyet saka sudut pandang bisnis, tugas kasebut ora disetel kanggo langsung mblokir sambungan sing ora perlu. Yen pangguna loro mlebu ing akun sing padha, dheweke bisa ndeleng konten kasebut. Nanging kita ngerti carane akeh tampilan simultaneous saka siji akun. Lan kita nglarang sawetara nerak utamane angkoro.
Vladimir: Kanggo menehi kredit, salah sawijining pangguna sing dilarang ngerti sebabe kedadeyan kasebut. Dheweke teka, njaluk ngapura lan janji arep tuku tiket.
— Kanggo kabeh iki kelakon, sampeyan kudu rampung nglacak kabeh pangguna saka entri kanggo metu, tansah ngerti apa sing lagi dilakoni. Kepiye cara kerja sistem iki?
Vladimir: Aku kaya kanggo pirembagan bab analytics lan statistik, kang banjur kita analisa kanggo sukses laporan utawa banjur bisa nyedhiyani partners. Kabeh klien disambungake liwat sambungan websocket menyang kluster backend tartamtu. Iku ngadeg ana . Saben klien ing saben wektu ngirim apa sing ditindakake lan trek apa sing ditonton. Banjur informasi iki dikumpulake nggunakake proyek Hazelcast sing cepet lan dikirim maneh menyang saben wong sing nonton trek kasebut. We ndeleng ing sudhut carane akeh wong saiki karo kita.
Informasi sing padha disimpen ing lan menyang tlaga data kita, saka ngendi kita duwe kesempatan kanggo mbangun grafik sing luwih menarik. Pitakonan muncul: pira pangguna unik sing ndeleng laporan iki? We menyang , ana ping kabeh wong sing teka dening id laporan iki. We diklumpukake, aggregated unik, lan saiki kita bisa ngerti.
Nikolay: Nanging ing wektu sing padha, kita uga nampa data wektu nyata saka Prometheus. Iki disetel marang kabeh layanan Kubernetes, marang Kubernetes dhewe. Iku ngumpulake pancen kabeh, lan karo Grafana kita bisa nggawe grafik ing wektu nyata.
Vladimir: Ing tangan siji, kita ngundhuh iki kanggo proses OLAP luwih lanjut. Lan kanggo OLTP, aplikasi kasebut ndownload kabeh menyang Prometheus, Grafana lan grafik malah konvergen!
- Iki kasus nalika grafik converge.
Owah-owahan Dinamis
- Marang kita carane owah-owahan dinamis sing mbalek metu: yen laporan iki dibatalake 6 menit sadurunge wiwitan, apa chain saka tumindak? Pipa sing dianggo?
Vladimir: Pipa kasebut banget kondisional. Ana sawetara kemungkinan. Sing pertama yaiku program nggawe jadwal kerja lan ngganti jadwal. Jadwal sing diowahi diunggah menyang Contentful. Sawise backend ngerti yen ana owah-owahan kanggo konferensi iki ing Contentful, njupuk lan mbangun maneh. Kabeh diklumpukake lan dikirim liwat websocket.
Kemungkinan kapindho, nalika kabeh kedadeyan kanthi cepet: editor kanthi manual ngganti informasi ing Contentful (link menyang Telegram, presentasi speaker, lsp) lan logika sing padha bisa digunakake minangka pisanan.
Nikolay: Kabeh kedadeyan tanpa refresh kaca. Kabeh owah-owahan dumadi pancen seamlessly kanggo klien. Semono uga kanggo ngalih laporan. Nalika wektu teka, laporan lan antarmuka ganti.
Vladimir: Uga, ana potongan wektu kanggo wiwitan laporan ing garis wektu. Ing wiwitan ora ana apa-apa. Lan yen sampeyan nglayang mouse ing garis abang, banjur ing sawetara titik, thanks kanggo direktur siaran, cutoffs bakal katon. Direktur nyetel wiwitan siaran sing bener, backend njupuk owah-owahan iki, ngetung wektu wiwitan lan pungkasan kabeh presentations trek miturut jadwal konferensi, dikirim menyang klien kita, lan pamuter ndudohke cutoffs. Saiki pangguna bisa gampang navigasi menyang wiwitan lan pungkasan laporan. Iki minangka syarat bisnis sing ketat, trep lan migunani. Sampeyan ora mbuwang wektu nemokake wektu wiwitan nyata kanggo laporan kasebut. Lan nalika kita nindakake pratinjau, iku bakal apik banget.
Penyebaran
- Aku arep takon babagan penyebaran. Kolya lan tim ngginakaken akeh wektu ing wiwitan kanggo nyiyapake kabeh prasarana kang kabeh unfolds kanggo kita. Marang kula, iku kabeh digawe saka apa?
Nikolay: Saka sudut pandang teknis, mula kita duwe syarat supaya produk kasebut dadi abstrak saka vendor apa wae. Teka AWS kanggo nggawe skrip Terraform khusus saka AWS, utawa khusus saka Yandex, utawa saka Azure, lsp. ora pas tenan. We kudu pindhah nang endi wae ing sawetara titik.
Ing telung minggu pisanan kita terus-terusan golek cara kanggo nindakake iki kanthi luwih apik. Akibaté, kita nyimpulake yen Kubernetes ing kasus iki minangka kabeh, amarga ngidini kita nggawe layanan skala otomatis, rollout otomatis, lan meh kabeh layanan metu saka kothak. Mesthine, kabeh layanan kudu dilatih kanggo nggarap Kubernetes, Docker, lan tim uga kudu sinau.
Kita duwe rong klompok. Test lan produksi. Padha pancen padha ing syarat-syarat hardware lan setelan. Kita ngetrapake infrastruktur minangka kode. Kabeh layanan diluncurake kanthi otomatis dadi telung lingkungan saka cabang fitur, cabang master, cabang uji, lan GitLab nggunakake pipa otomatis. Iki digabungake kanthi maksimal menyang GitLab, digabungake kanthi maksimal karo Elastic, Prometheus.
Kita entuk kesempatan kanthi cepet (kanggo backend sajrone 10 menit, kanggo frontend sajrone 5 menit) ngowahi owah-owahan menyang lingkungan apa wae kanthi kabeh tes, integrasi, tes fungsional, tes integrasi ing lingkungan, lan uga nyoba kanthi tes beban. lingkungan test kira-kira bab sing padha kita arep kanggo njaluk ing produksi.
Babagan tes
- Sampeyan nyoba meh kabeh, angel pracaya carane sampeyan nulis kabeh. Apa sampeyan bisa ngandhani babagan tes backend: pira kabeh wis dijamin, tes apa?
Vladimir: Rong jinis tes wis ditulis. Kaping pisanan yaiku tes komponen. Tes level angkat kabeh aplikasi musim semi lan basis ing . Iki minangka tes skenario bisnis tingkat paling dhuwur. Aku ora nyoba fungsi. Kita mung nyoba sawetara perkara gedhe. Contone, ing tes kasebut, proses mlebu menyang pangguna ditiru, panjaluk pangguna kanggo tiket menyang papan sing bisa dituju, lan panjaluk akses kanggo nonton stream kasebut. Skenario pangguna sing cetha banget.
Kira-kira bab sing padha ditindakake ing tes integrasi sing diarani, sing bener-bener mlaku ing lingkungan. Nyatane, nalika panyebaran sabanjure ing produksi diluncurake, skenario dhasar nyata uga mlaku ing produksi. Login sing padha, njaluk tiket, njaluk akses menyang CloudFront, mriksa manawa stream kasebut bener-bener nyambung karo ijinku, mriksa antarmuka direktur.
Ing wayahe aku duwe bab 70 tes komponen lan bab 40 tes integrasi ing Papan. Jangkoan banget cedhak 95%. Iki kanggo komponen, kurang kanggo integrasi, mung ora perlu. Ngelingi yen proyek kasebut kalebu kabeh jinis generasi kode, iki minangka indikator sing apik banget. Ora ana cara liya kanggo nindakake apa sing ditindakake sajrone telung sasi. Amarga yen kita dites kanthi manual, menehi fitur kanggo tester kita, lan dheweke bakal nemokake kewan omo lan bali menyang kita kanggo mbenakake, banjur trip babak iki kanggo debug kode bakal dawa banget, lan kita ora bakal ketemu tenggat wektu.
Nikolay: Conventionally, kanggo nindakake regresi ing kabeh platform nalika ngganti sawetara fungsi, sampeyan kudu njagong lan poke nang endi wae kanggo rong dina.
Vladimir: Mulane, iku sukses gedhe yen aku ngira fitur, Aku ngomong yen aku kudu 4 dina kanggo loro pena prasaja lan 1 websocket, Kolya ngidini. Dheweke wis biasa karo kasunyatan sing 4 dina iki kalebu 2 jinis tes, banjur, paling kamungkinan, bakal bisa.
Nikolay: Aku uga 140 tes ditulis: komponèn + fungsi, kang nindakake bab sing padha. Kabeh skenario sing padha diuji ing produksi, ing tes, lan ing produksi. Kita uga bubar nambah tes UI dhasar fungsional. Kanthi cara iki kita nutupi fungsi paling dhasar sing bisa rusak.
Vladimir: Mesthine, kudu ngomong babagan tes beban. Sampeyan kudu nyoba platform ing beban sing cedhak karo sing nyata kanggo ngerti kepiye kabeh, apa sing kedadeyan karo Kelinci, apa sing kedadeyan karo JVM, kepiye memori sing dibutuhake.
- Aku ora ngerti manawa kita nyoba apa wae ing sisih stream, nanging aku elinga yen ana masalah karo transcoder nalika kita ketemu. Apa kita wis nyoba stream?
Artyom: Diuji kanthi iteratif. Ngatur pertemuan. Ing proses nganakake temu, kurang luwih 2300 tiket JIRA. Iki mung umum sing ditindakake wong kanggo nggawe rapat. Kita njupuk bagéyan saka platform menyang kaca kapisah kanggo meetups, kang dikelola dening Kirill Tolkachev ().
Kanggo jujur, ora ana masalah gedhe. Secara harfiah kaping pirang-pirang kita nyekel kewan omo ing CloudFront, kita ngrampungake kanthi cepet - kita mung ngatur ulang kabijakan kasebut. Ana luwih akeh kewan omo ing wong, ing sistem streaming ing situs kasebut.
Sajrone konferensi, aku kudu nulis sawetara eksportir liyane kanggo nutupi luwih akeh peralatan lan layanan. Ing sawetara panggonan aku kudu nggawe sepedha dhewe mung kanggo metrik. Ing donya hardware AV (audio-video) ora banget rosy - sampeyan duwe sawetara jinis "API" peralatan sing mung ora bisa pengaruhe. Lan adoh saka kasunyatan manawa sampeyan bakal entuk informasi sing dibutuhake. vendor hardware tenan alon, lan iku meh mokal kanggo njaluk apa sing arep saka wong-wong mau. In total ana luwih saka 100 bêsik hardware, padha ora menehi bali apa sing perlu, lan sampeyan nulis eksportir aneh lan keluwih, thanks kanggo sampeyan bisa ing paling piye wae debug sistem.
Peralatan
- Aku elinga carane sadurunge wiwitan Konferensi kita sebagian dituku peralatan tambahan.
Artyom: Kita tuku komputer, laptop, lan paket baterei. Saiki kita bisa urip tanpa listrik sajrone 40 menit. Ing wulan Juni, ana badai petir ing St. Ing wektu sing padha, sawetara panyedhiya teka menyang kita kanthi pranala optik saka macem-macem titik. Iki pancene 40 menit saka downtime bangunan, sajrone kita bakal duwe lampu, swara, kamera, lan liya-liyane.
— Kita duwe crita sing padha karo Internet. Ing kantor sing ana studio kita, kita nyeret jaring sing sengit ing antarane jubin.
Artyom: Kita duwe 20 Gbit serat ing antarane lantai. Luwih ing jubin, ing endi wae ana optik, ing endi wae ora ana optik, nanging isih ana saluran sing luwih sithik tinimbang gigabit - kita mbukak video ing antarane trek konferensi. Umumé, trep banget kanggo nggarap infrastruktur sampeyan dhewe; sampeyan arang bisa nindakake iki ing konferensi offline ing situs.
- Sadurunge aku makarya ing JUG Ru Group, Aku weruh carane kamar hardware ing Konferensi offline diatur sewengi, ngendi ana monitor gedhe karo kabeh metrik sing mbangun ing Grafana. Saiki ana uga kamar markas ing ngendi tim pangembangan lenggah, sing sajrone konferensi ndandani sawetara kewan omo lan ngembangake fitur. Ing wektu sing padha, ana sistem pemantauan sing ditampilake ing layar gedhe. Artyom, Kolya lan wong lanang liyane njagong lan priksa manawa kabeh ora tiba lan bisa digunakake kanthi apik.
Penasaran lan masalah
— Sampeyan ngandika apik babagan kasunyatan sing kita wis streaming karo Amazon, ana pemain karo web, kabeh ditulis ing basa program beda, toleransi fault lan syarat bisnis liyane kasedhiya, kalebu akun pribadi sing didhukung kanggo entitas legal lan individu, lan kita bisa nggabungake karo wong sing nggunakake OAuth 2.0, ana anti-penipuan, pamblokiran pangguna. Kita bisa nindakake owah-owahan kanthi dinamis amarga kita nindakake kanthi apik, lan kabeh wis diuji.
Aku kasengsem ngerti apa oddities padha melu ing miwiti soko. Apa ana kahanan aneh nalika sampeyan ngembangake backend, frontend, ana sing edan lan sampeyan ora ngerti apa sing kudu ditindakake?
Vladimir: Iku misale jek kanggo kula sing iki mung kedaden kanggo telung sasi pungkasan. Saben dina. Kaya sing sampeyan ngerteni, kabeh rambutku wis dicabut.
Vladimir Krasilshchik sawise 3 sasi, nalika sawetara jinis game metu lan ora ana sing ngerti apa sing kudu dilakoni.
Saben dina ana sing kaya mangkene, nalika sampeyan njupuk lan nyuwek rambute, utawa ngerti yen ora ana wong liya, lan mung sampeyan sing bisa nindakake. Acara gedhe pisanan kita yaiku TechTrain. Tanggal 6 Juni jam 2 esuk kita durung ngluncurake lingkungan produksi, Kolya nggulung. Lan akun pribadhi ora bisa digunakake minangka server wewenang nggunakake OAuth2.0. Kita ngowahi dadi panyedhiya OAuth2.0 kanggo nyambungake platform kasebut. Aku wis kerja suwene 18 jam terus, aku ndeleng komputer lan ora weruh apa-apa, aku ora ngerti kenapa ora bisa digunakake, lan Kolya ndeleng kodeku saka adoh, golek bug ing konfigurasi Spring , ketemu, lan LC makarya, lan ing produksi banget.
Nikolay: Lan jam sadurunge TechTrain release njupuk Panggonan.
Akeh lintang sing didadekake siji ing kene. Kita pancen begja amarga duwe tim super, lan kabeh wong bungah babagan ide kanggo nindakake online. Kabeh telung sasi iki kita didorong dening kasunyatan sing kita "gawe YouTube." Aku ora ngidini aku nyuwek rambutku, nanging ngandhani kabeh wong yen kabeh bakal bisa ditindakake, amarga nyatane, kabeh wis diwilang biyen.
Babagan kinerja
— Bisa ngomong carane akeh wong ing situs ing siji trek? Apa ana masalah kinerja?
Nikolay: Ora ana masalah kinerja, kaya sing wis dakkandhakake. Jumlah maksimum wong sing nekani siji laporan ana 1300 wong, iki ing Heisenbug.
- Apa ana masalah karo tampilan lokal? Lan apa bisa duwe katrangan teknis kanthi diagram babagan cara kerjane?
Nikolay: Kita bakal nggawe artikel babagan iki mengko.
Sampeyan bisa malah debug stream lokal. Sawise konferensi diwiwiti, dadi luwih gampang, amarga aliran produksi katon sing bisa ditonton kabeh.
Vladimir: Nalika aku ngerti, pangembang ngarep-mburi makarya sacara lokal kanthi moyoki, banjur, amarga wektu kanggo muter menyang devs ing ngarep uga cendhak (5 menit), ora ana masalah karo mriksa apa sing kedadeyan karo sertifikat.
- Kabeh wis dites lan debugged, malah lokal. Iki tegese kita bakal nulis artikel kanthi kabeh fitur teknis, nuduhake sampeyan, ngandhani kabeh kanthi diagram, kepiye.
Vladimir: Sampeyan bisa njupuk lan mbaleni.
- Ing 3 sasi.
Asile
— Kabeh sing diterangake bebarengan muni kelangan, considering sing wis rampung dening tim cilik ing telung sasi.
Nikolay: Tim gedhe ora bakal nindakake iki. Nanging saklompok cilik wong sing komunikasi cukup rapet lan apik karo saben liyane lan bisa dadi persetujuan. Dheweke ora duwe kontradiksi, arsitektur diciptakake sajrone rong dina, dirampungake lan durung diganti. Ana fasilitas sing ketat banget kanggo syarat bisnis sing mlebu babagan panjaluk lan owah-owahan fitur.
- Apa sing ana ing dhaptar tugas liyane nalika konferensi musim panas wis ditindakake?
Nikolay: Contone, kridit. Garis creeping ing video, pop-up ing sawetara panggonan ing video gumantung isi sing ditampilake. Contone, penutur pengin takon marang pamirsa, lan swara muncul ing layar, sing bali menyang mburi adhedhasar asil voting menyang pamicara dhewe. Sawetara jinis kegiatan sosial ing wangun seneng, ati, ratings saka laporan sak presentation dhewe, supaya sampeyan bisa ngisi umpan balik ing wayahe tengen tanpa bakal disambi mengko dening wangun saran. Wiwitane kaya iki.
Lan uga nambahake kabeh platform, kajaba streaming lan konferensi, uga negara pasca konferensi. Iki minangka dhaptar lagu (kalebu sing disusun dening pangguna), bisa uga isi saka konferensi liyane sing kepungkur, terintegrasi, diwenehi label, bisa diakses pangguna, lan uga kasedhiya kanggo dideleng ing situs web kita ().
— Wong lanang, matur nuwun banget kanggo jawaban sampeyan!
Yen ing antarane para pamaca ana sing rawuh ing konferensi musim panas, mangga nuduhake kesan sampeyan babagan pamuter lan siaran. Apa sing trep, apa sing nggawe sampeyan jengkel, apa sing pengin sampeyan deleng ing mangsa ngarep?
Yen sampeyan kasengsem ing platform lan pengin ndeleng "ing perang", kita nggunakake maneh ing kita . Ana macem-macem, mula mesthi ana sing cocog kanggo sampeyan.
Source: www.habr.com