Bu bahar kendimizi çok neşeli koşullarda bulduk. Pandemi nedeniyle yaz konferanslarımızın online ortama taşınması gerektiği ortaya çıktı. Bunları online olarak verimli bir şekilde yürütebilmek için hazır yazılım çözümleri bize uygun değildi, kendi çözümümüzü yazmamız gerekiyordu. Ve bunu yapmak için üç ayımız vardı.
Heyecan verici bir üç ay olduğu açık. Ancak dışarıdan bakıldığında şu tamamen açık değil: Çevrimiçi konferans platformu nedir? Hangi parçalardan oluşur? Bu nedenle yazın son DevOops konferansında bu görevden sorumlu olanlara şunu sordum:
- Nikolay Molchanov - JUG Ru Group'un teknik direktörü;
- Vladimir Krasilshchik, arka uçta çalışan pragmatik bir Java programcısıdır (raporlarını Java konferanslarımızda da görebilirsiniz);
- Artyom Nikonov tüm video yayınlarımızdan sorumludur.
Bu arada, sonbahar-kış konferanslarında aynı platformun geliştirilmiş bir versiyonunu kullanacağız - pek çok Habra okuyucusu hâlâ bu platformun kullanıcısı olacak.
Genel resim
— Takımın bileşimi nasıldı?
Nikolay Molchanov: Bir analistimiz, bir tasarımcımız, bir test uzmanımız, üç ön uçumuz ve bir arka uçumuz var. Ve elbette T şeklinde bir uzman!
— Genel olarak süreç nasıldı?
Nikolai: Mart ortasına kadar çevrimiçi için hazır hiçbir şeyimiz yoktu. Ve 15 Mart'ta tüm çevrimiçi döngü dönmeye başladı. Birkaç depo kurduk, planladık, temel mimariyi tartıştık ve her şeyi üç ay içinde yaptık.
Bu elbette planlama, mimari, özellik seçimi, bu özelliklere oy verme, bu özelliklere yönelik politika, bunların tasarımı, geliştirilmesi ve test edilmesi gibi klasik aşamalardan geçti. Sonuç olarak 6 Haziran'da her şeyi üretime sunduk. . Her şey için 90 gün vardı.
— Taahhüt ettiğimiz şeyi başarabildik mi?
Nikolai: Artık DevOops konferansına çevrimiçi olarak katıldığımıza göre, bu işe yaradığı anlamına geliyor. Ben şahsen asıl şeye kendimi adadım: Müşterilere çevrimiçi konferans yapabilecekleri bir araç getireceğim.
Zorluk şuydu: bize konferanslarımızı bilet sahiplerine yayınlayabileceğimiz bir araç verin.
Tüm planlama birkaç aşamaya bölündü ve tüm özellikler (yaklaşık 30 küresel) 4 kategoriye ayrıldı:
- bunu kesinlikle yapacağız (onlarsız yaşayamayız),
- ikinci olarak yapacağımız şey,
- bunu asla yapmayacağız,
- ve bunu asla yapmayacağız.
İlk iki kategorideki tüm özellikleri yaptık.
— Toplamda 600 JIRA sayısının oluşturulduğunu biliyorum. Üç ayda 13 mikro hizmet oluşturdunuz ve bunların yalnızca Java ile yazılmadığını düşünüyorum. Farklı teknolojiler kullandınız, üç erişilebilirlik bölgesinde iki Kubernetes kümeniz ve Amazon'da 5 RTMP akışınız var.
Şimdi sistemin her bir bileşenine ayrı ayrı bakalım.
Yayın Akışı
— Zaten bir video görüntümüzün olduğu ve bazı hizmetlere iletildiği zaman ile başlayalım. Artyom, bize bu akışın nasıl gerçekleştiğini anlatır mısın?
Artyom Nikonov: Genel şemamız şuna benzer: kameradan görüntü -> kontrol odamız -> yerel RTMP sunucusu -> Amazon -> video oynatıcı. Daha fazla detay Haziran ayında Habré'de.
Genel olarak bunu yapmanın iki küresel yolu vardır: donanım üzerinden veya yazılım çözümlerine dayalı. Yazılım yolunu seçtik çünkü uzak hoparlörler söz konusu olduğunda daha kolay. Başka bir ülkedeki konuşmacıya donanım getirmek her zaman mümkün olmuyor ancak yazılımı konuşmacıya ulaştırmak daha kolay ve güvenilir görünüyor.
Donanım açısından bakıldığında, stüdyolarımızda belirli sayıda kameramız (stüdyolarımızda ve uzak hoparlörlerde), stüdyoda belirli sayıda uzaktan kumandamız var ve bunların bazen yayın sırasında masanın altında onarılması gerekiyor.
Bu cihazlardan gelen sinyaller, yakalama kartları, giriş/çıkış kartları ve ses kartlarıyla bilgisayarlara girer. Burada sinyaller karıştırılır ve düzenler halinde birleştirilir:
4 hoparlör için düzen örneği
4 hoparlör için düzen örneği
Ayrıca üç bilgisayar yardımıyla sürekli yayın sağlanmaktadır: bir ana makine ve bir çift çalışan makine vardır. İlk bilgisayar ilk raporu, ikinci - arayı, ilk - bir sonraki raporu, ikinci - bir sonraki arayı vb. Ve ana makine birinciyi ikinciyle karıştırıyor.
Bu bir tür üçgen oluşturur ve bu düğümlerden herhangi biri arızalanırsa, hızlı bir şekilde ve kalite kaybı olmadan müşterilere içerik sunmaya devam edebiliriz. Böyle bir durumumuz vardı. Konferansların ilk haftasında bir makineyi tamir ettik, açıp kapattık. İnsanlar dayanıklılığımızdan memnun görünüyor.
Daha sonra bilgisayarlardan gelen akışlar, iki görevi olan yerel bir sunucuya gider: RTMP akışlarını yönlendirmek ve yedeklemeleri kaydetmek. Yani birden fazla kayıt noktamız var. Video akışları daha sonra sistemimizin Amazon SaaS hizmetleri üzerine kurulu kısmına gönderilir. Kullanırız ,S3,CloudFront.
Nikolai: Video izleyiciye ulaşmadan önce orada ne oluyor? Bir şekilde kesmelisin, değil mi?
Artyom: Videoyu kendi tarafımıza sıkıştırıp MediaLive'a gönderiyoruz. Orada kod dönüştürücüleri başlatıyoruz. Videoları gerçek zamanlı olarak çeşitli çözünürlüklere dönüştürüyorlar, böylece insanlar bunları telefonlarında, ülkedeki zayıf İnternet üzerinden vb. izleyebiliyorlar. Daha sonra bu dereler kesilir. protokolün işleyişi bu şekilde . Bu parçalara işaret eden işaretçileri içeren bir çalma listesini ön uca göndeririz.
— 1080p çözünürlük mü kullanıyoruz?
Artyom: Videomuzun genişliği 1080p - 1920 piksel ile aynı, yüksekliği biraz daha az, resim daha uzun - bunun nedenleri var.
oyuncu
— Artyom, videonun akışlara nasıl girdiğini, farklı ekran çözünürlükleri için farklı oynatma listelerine nasıl dağıtıldığını, parçalara nasıl bölündüğünü ve oynatıcıya nasıl girdiğini anlattı. Kolya, şimdi söyle bana bu nasıl bir oyuncu, akışı nasıl tüketiyor, neden HLS?
Nikolai: Tüm konferans izleyicilerinin izleyebileceği bir oynatıcımız var.
Aslında bu, kütüphanenin etrafındaki bir sarmalayıcıdır , üzerinde başka birçok oyuncunun yazılı olduğu. Ancak çok özel bir işlevselliğe ihtiyacımız vardı: geri sarmak ve kişinin bulunduğu yeri, o anda hangi raporu izlediğini işaretlemek. Ayrıca kendi düzenlerimize, her türlü logoya ve içimizde yerleşik olan diğer her şeye ihtiyacımız vardı. Bu nedenle kendi kütüphanemizi (HLS üzerine sarmalayıcı) yazmaya ve siteye yerleştirmeye karar verdik.
Bu kök işlevidir, dolayısıyla neredeyse ilk kez uygulanmıştır. Ve sonra her şey onun etrafında büyüdü.
Aslında, yetkilendirme yoluyla, oyuncu arka uçtan zaman ve kaliteyle ilişkili parçalara bağlantılar içeren bir çalma listesi alır, gerekli olanları indirir ve bunları kullanıcıya göstererek yol boyunca bir miktar "sihir" gerçekleştirir.
Zaman çizelgesi örneği
— Tüm raporların zaman çizelgesini görüntülemek için oynatıcının içine bir düğme yerleştirilmiştir...
Nikolai: Evet, kullanıcı navigasyonu sorununu hemen çözdük. Nisan ortasında konferanslarımızın her birini ayrı bir sitede yayınlamamaya, hepsini tek bir sitede birleştirmeye karar verdik. Böylece Tam Geçiş bileti kullanıcıları farklı konferanslar arasında serbestçe geçiş yapabilir: hem canlı yayınlar hem de geçmiş konferansların kayıtları.
Kullanıcıların mevcut akışta gezinmesini ve parçalar arasında geçiş yapmasını kolaylaştırmak için bir "Tüm yayın" düğmesi ve parçalar ile raporlar arasında geçiş yapmak için yatay rapor kartları oluşturmaya karar verdik. Klavye kontrolü bulunmaktadır.
— Bununla ilgili herhangi bir teknik zorluk var mıydı?
Nikolai: Farklı raporların başlangıç noktalarının işaretlendiği bir kaydırma çubuğu vardı.
— Sonuç olarak, YouTube benzer bir şey yapmadan önce bu işaretleri kaydırma çubuğuna siz mi uyguladınız?
Artyom: O zamanlar beta sürümündeydi. Bu oldukça karmaşık bir özellik gibi görünüyor çünkü geçtiğimiz yıl bunu kullanıcılarla kısmen test ediyorlardı. Ve artık satışa ulaştı.
Nikolai: Ama aslında daha hızlı satılmasını sağladık. Dürüst olmak gerekirse, bu basit özelliğin arkasında oynatıcının içinde çok büyük miktarda arka uç, ön uç, hesaplamalar ve matematik var.
Başlangıç aşaması
— Gösterdiğimiz bu içeriğin (konuşma kartı, konuşmacılar, web sitesi, program) ön uca nasıl ulaştığını bulalım mı?
Vladimir Krasilshchik: Birkaç dahili BT sistemimiz var. Tüm raporların ve tüm konuşmacıların girildiği bir sistem bulunmaktadır. Bir konuşmacının konferansa katılmasının bir süreci vardır. Konuşmacı bir başvuru gönderir, sistem onu yakalar ve ardından raporun oluşturulduğu belirli bir boru hattı vardır.
Konuşmacı boru hattını böyle görüyor
Bu sistem bizim içsel gelişimimizdir.
Daha sonra, bireysel raporlardan bir program oluşturmanız gerekir. Bildiğiniz gibi bu NP-zor bir problem ama bir şekilde çözüyoruz. Bunu yapmak için, bir program oluşturan ve bunu üçüncü taraf bulut hizmeti Contentful'a yükleyen başka bir bileşen başlatıyoruz. Orada her şey, konferans günlerinin, günlerde zaman dilimlerinin, dilimlerde ise raporların, araların ya da sponsorluk faaliyetlerinin olduğu bir tablo gibi görünüyor. Yani gördüğümüz içerik üçüncü taraf bir hizmette bulunuyor. Ve görev onu siteye iletmektir.
Görünüşe göre site sadece oynatıcılı bir sayfa ve burada karmaşık bir şey yok. Ama öyle değil. Bu sayfanın arkasındaki arka uç Contentful'a gider, oradan zamanlamayı alır, bazı nesneler üretir ve bunu ön uca gönderir. Platformumuzun her müşterisinin yaptığı bir websocket bağlantısını kullanarak, ona arka uçtan ön uca kadar bir program güncellemesi gönderiyoruz.
Gerçek durum: Konuşmacı konferans sırasında iş değiştirdi. İşveren şirket rozetini değiştirmemiz gerekiyor. Bu arka uçtan nasıl oluyor? Websocket aracılığıyla tüm istemcilere bir güncelleme gönderilir ve ardından ön uç zaman çizelgesini yeniden çizer. Bütün bunlar sorunsuz bir şekilde gerçekleşir. Bulut hizmeti ve birkaç bileşenimizin birleşimi bize tüm bu içeriği oluşturma ve öne çıkarma fırsatı veriyor.
Nikolai: Sitemizin klasik bir SPA uygulaması olmadığını burada belirtmekte fayda var. Bu hem düzen tabanlı, oluşturulmuş bir web sitesi hem de bir SPA'dır. Google aslında bu siteyi oluşturulmuş HTML olarak görüyor. Bu, SEO ve kullanıcıya içerik sunmak açısından iyidir. Sayfayı görmeden önce 1,5 megabaytlık JavaScript'in yüklenmesini beklemiyor, halihazırda oluşturulmuş sayfayı hemen görüyor ve raporu her değiştirdiğinizde bunu hissediyorsunuz. İçerik zaten hazır olduğundan ve doğru yerde yayınlandığından her şey yarım saniyede gerçekleşir.
— Teknolojileri listeleyerek yukarıdakilerin hepsinin altına bir çizgi çizelim. Tyoma, 5 Amazon yayınımız olduğunu ve orada video ve ses ulaştırdığımızı söyledi. Orada bash betiklerimiz var, bunları başlatmak ve yapılandırmak için kullanıyoruz ...
Artyom: Bu AWS API aracılığıyla oluyor, orada daha birçok teknik yan hizmet var. Sorumluluklarımızı, teslimatı gerçekleştirebileceğim şekilde paylaştırdık. ve ön uç ve arka uç geliştiriciler bunu oradan alıyor. İçeriğin düzenini basitleştirmek için daha sonra 4K vb. olarak oluşturduğumuz bir dizi kendi bağlamamız var. Son teslim tarihleri çok kısıtlı olduğundan bunu neredeyse tamamen AWS'de yaptık.
— Daha sonra tüm bunlar arka uç sistemini kullanarak oynatıcıya gider. Player'ımızda TypeScript, React, Next.JS var. Arka uçta ise C#, Java, Spring Boot ve Node.js'de çeşitli hizmetlerimiz var. Bunların tümü Yandex.Cloud altyapısını kullanan Kubernetes kullanılarak dağıtılır.
Ayrıca platformu tanımam gerektiğinde bunun kolay olduğunu da belirtmek isterim: tüm depolar GitLab'da, her şey iyi adlandırılmış, testler yazılıyor, belgeler var. Yani acil durum modunda bile bu tür şeylerle ilgilendiler.
İş Kısıtlamaları ve Analitik
— İş gereksinimlerine göre 10 kullanıcıyı hedefledik. Sahip olduğumuz iş kısıtlamaları hakkında konuşmanın zamanı geldi. Yüksek bir iş yükü sağlamamız, kişisel verilerin korunması kanununa uygunluğu sağlamamız gerekiyordu. Ve başka?
Nikolai: Başlangıçta video gereksinimlerinden başladık. En önemli şey, müşteriye hızlı teslimat için dünya çapında dağıtılmış video depolamadır. Diğerleri, 1080p çözünürlüğün yanı sıra geri sarmayı da içerir; çoğu kişi bunu canlı modda uygulamaz. Daha sonra 2x hızı etkinleştirme özelliğini ekledik, bunun yardımıyla canlı yayına "yetişebilir" ve konferansı gerçek zamanlı olarak izlemeye devam edebilirsiniz. Ve bu arada zaman çizelgesi işaretleme işlevi de ortaya çıktı. Ayrıca hataya dayanıklı olmamız ve 10 bağlantının yüküne dayanmamız gerekiyordu. Arka uç açısından bakıldığında bu, her sayfa yenileme için yaklaşık 000 bağlantının 10 istekle çarpımıdır. Ve bu zaten 000 RPS/sn. Birazcık.
— Ortakların çevrimiçi stantlarıyla “sanal sergi” için başka gereksinimler var mıydı?
Nikolai: Evet, bunun oldukça hızlı ve evrensel olarak yapılması gerekiyordu. Her konferans için 10'a kadar ortak şirketimiz vardı ve hepsinin bir veya iki hafta içinde tamamlanması gerekiyordu. Ancak içerikleri format olarak biraz farklıdır. Ancak bu sayfaları anında bir araya getiren ve neredeyse hiçbir geliştirme katılımı gerektirmeyen belirli bir şablon motoru yapıldı.
— Aynı zamanda gerçek zamanlı görüntüleme ve istatistiklerin analitiğine yönelik gereksinimler de vardı. Bunun için Prometheus'u kullandığımızı biliyorum ama bize daha ayrıntılı olarak anlatın: analitik için hangi gereksinimleri karşılıyoruz ve bu nasıl uygulanıyor?
Nikolai: Başlangıçta, A/B testi için bilgi toplamak ve gelecekte müşteriye en iyi içeriği nasıl doğru bir şekilde sunacağımızı anlamak amacıyla bilgi toplamak için pazarlama gereksinimlerimiz var. İş ortağı etkinliklerine ve gördüğünüz analizlere (ziyaret sayacı) ilişkin bazı analizlere yönelik gereksinimler de vardır. Tüm bilgiler gerçek zamanlı olarak toplanır.
Bu bilgiyi toplu halde konuşmacılara bile sağlayabiliriz: belirli bir anda sizi kaç kişinin izlediği. Aynı zamanda 152 sayılı Federal Yasaya uymak amacıyla kişisel hesabınız ve kişisel verileriniz hiçbir şekilde izlenmez.
Platformda, raporlara katılım grafikleri oluşturmak amacıyla kullanıcı etkinliğini gerçek zamanlı olarak (raporun hangi saniyesini kim izledi) ölçmek için pazarlama araçları ve ölçümlerimiz zaten mevcut. Bu verilere dayanarak bundan sonraki konferansların daha iyi olmasını sağlayacak araştırmalar yapılıyor.
Sahtekar
— Dolandırıcılığa karşı mekanizmalarımız var mı?
Nikolai: İş açısından bakıldığında zaman diliminin kısıtlı olması nedeniyle, görev başlangıçta gereksiz bağlantıları hemen engelleyecek şekilde ayarlanmamıştı. İki kullanıcı aynı hesapla oturum açtıysa içeriği görüntüleyebilirler. Ancak bir hesaptan kaç tane eşzamanlı görüntü olduğunu biliyoruz. Ayrıca, özellikle kötü niyetli olan birkaç ihlalciyi de yasakladık.
Vladimir: Neyse ki, yasaklanan kullanıcılardan biri bunun neden olduğunu anladı. Geldi, özür diledi ve bilet alacağına söz verdi.
— Tüm bunların gerçekleşebilmesi için tüm kullanıcıları girişten çıkışa kadar tamamen takip etmeli, ne yaptıklarını her zaman bilmelisiniz. Bu sistem nasıl çalışıyor?
Vladimir: Daha sonra raporun başarısı için analiz ettiğimiz veya ortaklarımıza sunabileceğimiz analitik ve istatistiklerden bahsetmek istiyorum. Tüm istemciler bir websocket bağlantısı aracılığıyla belirli bir arka uç kümesine bağlanır. Orada duruyor . Her müşteri her zaman diliminde ne yaptığını ve hangi parçayı izlediğini gönderir. Daha sonra bu bilgiler hızlı Hazelcast işleri kullanılarak toplanıyor ve bu parçaları izleyen herkese geri gönderiliyor. Köşede şu anda kaç kişinin bizimle birlikte olduğunu görüyoruz.
Aynı bilgiler depolanır ve daha ilginç bir grafik oluşturma fırsatına sahip olduğumuz veri gölümüze gidiyor. Şu soru ortaya çıkıyor: Bu raporu kaç benzersiz kullanıcı görüntüledi? Biz gitmek , bu raporun kimliğiyle gelen tüm kişilerin ping'leri var. Benzersiz olanları topladık, bir araya getirdik ve artık anlayabiliyoruz.
Nikolai: Ancak aynı zamanda Prometheus'tan gerçek zamanlı veriler de alıyoruz. Tüm Kubernetes hizmetlerine ve Kubernetes'in kendisine karşı ayarlanmıştır. Kesinlikle her şeyi topluyor ve Grafana ile gerçek zamanlı olarak her türlü grafiği oluşturabiliyoruz.
Vladimir: Bir yandan bunu daha ileri OLAP işlemleri için indiriyoruz. Ve OLTP için uygulama her şeyi Prometheus, Grafana'ya indirir ve hatta grafikler birleşir!
- Grafiklerin yakınlaştığı durum budur.
Dinamik Değişiklikler
— Dinamik değişikliklerin nasıl hayata geçirildiğini bize anlatın: Rapor başlamadan 6 dakika önce iptal edildiyse eylem zinciri nedir? Hangi boru hattı çalışıyor?
Vladimir: Boru hattı çok şartlı. Birkaç olasılık var. Birincisi, program oluşturma programının işe yaraması ve programı değiştirmesidir. Değiştirilen program Contentful'a yüklenir. Bundan sonra arka uç, Contentful'da bu konferans için değişiklikler olduğunu anlar, onu alır ve yeniden oluşturur. Her şey websocket aracılığıyla toplanır ve gönderilir.
İkinci olasılık, her şeyin baş döndürücü bir hızda gerçekleşmesi: Editör, Contentful'daki bilgileri (Telegram'a bağlantı, konuşmacının sunumu vb.) manuel olarak değiştirir ve ilk seferkiyle aynı mantık çalışır.
Nikolai: Her şey sayfayı yenilemeden gerçekleşir. Müşteri için tüm değişiklikler kesinlikle sorunsuz bir şekilde gerçekleşir. Aynı şey raporları değiştirmek için de geçerli. Zamanı geldiğinde rapor ve arayüz değişir.
Vladimir: Ayrıca zaman çizelgesinde raporların başlatılması için zaman kesintileri vardır. Başlangıçta hiçbir şey yoktur. Ve farenizi kırmızı şeridin üzerine getirirseniz, bir noktada yayın yönetmeni sayesinde kesintiler görünecektir. Yönetmen yayının doğru başlangıcını ayarlar, arka uç bu değişikliği alır, tüm parçanın sunumlarının başlangıç ve bitiş zamanlarını konferans programına göre hesaplar, müşterilerimize gönderir ve oyuncu kesintileri çeker. Artık kullanıcı raporun başına ve sonuna kolayca gidebilir. Bu, sıkı bir iş gereğiydi, çok kullanışlı ve kullanışlıydı. Raporun gerçek başlangıç zamanını bulmakla zaman kaybetmezsiniz. Ve bir önizleme yaptığımızda kesinlikle harika olacak.
Dağıtım
— Dağıtım hakkında soru sormak istiyorum. Kolya ve ekibi başlangıçta bizim için her şeyin ortaya çıktığı tüm altyapıyı kurmak için çok zaman harcadılar. Söylesene, bunların hepsi neyden yapılmış?
Nikolai: Teknik açıdan bakıldığında, başlangıçta ürünün herhangi bir satıcıdan olabildiğince soyut olması yönünde bir gereksinimimiz vardı. Özellikle AWS'den veya özellikle Yandex'den veya Azure vb.'den Terraform komut dosyaları oluşturmak için AWS'ye gelin. gerçekten uymadı. Bir ara bir yere taşınmak zorunda kaldık.
İlk üç hafta boyunca sürekli olarak bunu daha iyi yapmanın bir yolunu arıyorduk. Sonuç olarak, Kubernetes'in bu durumda bizim her şeyimiz olduğu sonucuna vardık; çünkü otomatik olarak ölçeklenen hizmetler oluşturmamıza, otomatik kullanıma sunmamıza ve neredeyse tüm hizmetleri kutudan çıkarmamıza olanak tanıyor. Doğal olarak tüm hizmetlerin Kubernetes ve Docker ile çalışacak şekilde eğitilmesi gerekiyordu ve ekibin de öğrenmesi gerekiyordu.
İki kümemiz var. Test ve üretim. Donanım ve ayarlar açısından kesinlikle aynıdırlar. Altyapıyı kod olarak uyguluyoruz. Tüm hizmetler, otomatik bir işlem hattı kullanılarak özellik dallarından, ana dallardan, test dallarından ve GitLab'dan üç ortama otomatik olarak dağıtılır. Bu, maksimum düzeyde GitLab'a, maksimum düzeyde Elastic ve Prometheus'a entegre edilmiştir.
Tüm testler, entegrasyonlar, işlevsel testler, ortam üzerinde entegrasyon testleri çalıştırma ve ayrıca yük testleri ile test etme ile değişiklikleri herhangi bir ortama hızlı bir şekilde (arka uç için 10 dakika içinde, ön uç için 5 dakika içinde) sunma fırsatına sahip oluyoruz. bir test ortamı, üretimde elde etmek istediğimiz şeyin hemen hemen aynısıdır.
Testler hakkında
— Neredeyse her şeyi test ediyorsunuz, her şeyi nasıl yazdığınıza inanmak zor. Bize arka uç testleri hakkında bilgi verebilir misiniz: her şeyin ne kadarı kapsanıyor, hangi testler?
Vladimir: İki tür test yazılmıştır. Bunlardan ilki bileşen testleridir. Tüm yay uygulamasının ve tabanının kaldırma seviyesi testleri . Bu, en üst düzey iş senaryolarının testidir. İşlevleri test etmiyorum. Sadece bazı büyük şeyleri test ediyoruz. Örneğin, doğrudan testte, bir kullanıcıya giriş yapma süreci, kullanıcının gidebileceği yere bilet talebi ve yayını izlemek için erişim talebi taklit edilir. Çok net kullanıcı senaryoları.
Yaklaşık olarak aynı şey, gerçekte çevre üzerinde çalışan entegrasyon testlerinde de uygulanır. Aslında üretimdeki bir sonraki dağıtım başlatıldığında, üretimde de gerçek temel senaryolar çalışıyor. Aynı giriş, bilet isteme, CloudFront'a erişim isteme, akışın izinlerimle gerçekten bağlanıp bağlanmadığını kontrol etme, yönetmenin arayüzünü kontrol etme.
Şu anda gemide yaklaşık 70 bileşen testim ve yaklaşık 40 entegrasyon testim var. Kapsama oranı %95'e çok yakındır. Bu, bileşen olanlar için, entegrasyon olanlar için daha az, çok fazla ihtiyaç yok. Projenin her türlü kod üretimini içerdiğini düşünürsek bu çok iyi bir gösterge. Üç ayda yaptıklarımızı yapmanın başka yolu yoktu. Çünkü manuel olarak test edersek, testçimize özellikler verirsek ve o hataları bulur ve düzeltmeler için bize geri gönderirse, o zaman koddaki hata ayıklamaya yönelik bu gidiş-dönüş yolculuğu çok uzun olur ve herhangi bir son teslim tarihini karşılayamayız.
Nikolai: Geleneksel olarak, bazı işlevleri değiştirirken tüm platformda bir gerileme gerçekleştirmek için, iki gün boyunca oturup her yeri dürtmeniz gerekir.
Vladimir: Dolayısıyla bir özelliği tahmin ederken iki basit kalem ve 4 websoket için 1 güne ihtiyacım var diyorum, Kolya buna izin veriyor, bu büyük bir başarı. Zaten bu 4 günün 2 tür test içerdiğine alışkın ve o zaman büyük olasılıkla işe yarayacak.
Nikolai: Ayrıca yazılmış 140 testim var: bileşen + işlevsel, bunlar aynı şeyi yapıyor. Aynı senaryoların tümü üretimde, testte ve üretimde test edilir. Ayrıca yakın zamanda işlevsel temel kullanıcı arayüzü testlerini de ekledik. Bu şekilde bozulabilecek en temel işlevleri ele alıyoruz.
Vladimir: Elbette yük testlerinden bahsetmeye değer. Her şeyin nasıl olduğunu, Rabbit'te neler olduğunu, JVM'lerde neler olduğunu, gerçekte ne kadar belleğe ihtiyaç duyulduğunu anlamak için platformu gerçeğe yakın bir yük altında test etmek gerekiyordu.
— Yayın tarafında herhangi bir şeyi test edip etmediğimizden emin değilim ama buluşmalar yaptığımızda kod dönüştürücülerde sorunlar yaşandığını hatırlıyorum. Akışları test ettik mi?
Artyom: Tekrarlanarak test edildi. Buluşmalar düzenlemek. Buluşmaların düzenlenmesi sürecinde yaklaşık 2300 JIRA bileti vardı. Bunlar insanların buluşmak için yaptığı genel şeyler. Kirill Tolkachev'in yönettiği platformun bazı kısımlarını buluşmalar için ayrı bir sayfaya taşıdık ().
Dürüst olmak gerekirse büyük bir sorun yoktu. Kelimenin tam anlamıyla birkaç kez CloudFront'ta önbelleğe alma hataları yakaladık, bunu oldukça hızlı bir şekilde çözdük - yalnızca politikaları yeniden yapılandırdık. Sitedeki akış sistemlerinde insanlarda önemli ölçüde daha fazla hata vardı.
Konferanslar sırasında daha fazla ekipman ve hizmeti kapsayabilmek için birkaç ihracatçı daha yazmak zorunda kaldım. Bazı yerlerde sırf ölçü olsun diye kendi bisikletimi yapmak zorunda kaldım. AV (ses-video) donanımı dünyası pek de pembe değil - etkileyemeyeceğiniz bir tür "API" ekipmanınız var. Ve ihtiyacınız olan bilgiyi alabileceğiniz bir gerçek olmaktan çok uzak. Donanım satıcıları gerçekten yavaştır ve onlardan istediğinizi almanız neredeyse imkansızdır. Toplamda 100'den fazla donanım var, ihtiyacınız olanı geri vermiyorlar ve en azından bir şekilde sistemde hata ayıklayabileceğiniz garip ve gereksiz ihracatçılar yazıyorsunuz.
Оборудование
— Konferanslar başlamadan önce kısmen ek ekipman satın aldığımızı hatırlıyorum.
Artyom: Bilgisayarlar, dizüstü bilgisayarlar ve pil paketleri satın aldık. Şu anda 40 dakika elektriksiz yaşayabiliriz. Haziran ayında St. Petersburg'da şiddetli fırtınalar vardı - bu yüzden böyle bir elektrik kesintisi yaşadık. Aynı zamanda birçok sağlayıcı farklı noktalardan optik bağlantılarla bize geliyor. Bu aslında 40 dakikalık bir inşaat kesintisi anlamına geliyor ve bu süre zarfında ışıkların açık, sesin, kameraların vb. çalışır durumda olacağı anlamına geliyor.
— İnternetle benzer bir hikayemiz var. Stüdyolarımızın bulunduğu ofiste katlar arasına şiddetli bir ağ çektik.
Artyom: Katlar arasında 20 Gbit fiberimiz var. Katların ilerisinde, bir yerlerde optik var, bir yerlerde optik yok, ancak yine de gigabit kanallardan daha az kanal var - konferansın parçaları arasında üzerlerinde video yayınlıyoruz. Genel olarak kendi altyapınız üzerinde çalışmak çok uygundur, bunu sitelerdeki çevrimdışı konferanslarda nadiren yapabilirsiniz.
— JUG Ru Group'ta çalışmadan önce, Grafana'da oluşturduğunuz tüm ölçümleri gösteren büyük bir monitörün bulunduğu çevrimdışı konferanslarda donanım odalarının bir gecede nasıl kurulduğunu gördüm. Artık, konferans sırasında bazı hataları düzelten ve özellikler geliştiren geliştirme ekibinin bulunduğu bir genel merkez odası da var. Aynı zamanda geniş ekranda görüntülenen bir izleme sistemi bulunmaktadır. Artyom, Kolya ve diğerleri oturup her şeyin yolunda gitmediğinden ve güzel çalıştığından emin oluyorlar.
Meraklar ve sorunlar
— Amazon ile yayın yaptığımız, internette bir oynatıcının olduğu, her şeyin farklı programlama dillerinde yazıldığı, hata toleransı ve diğer iş gereksinimlerinin sağlandığı, tüzel kişiler için desteklenen kişisel bir hesap da dahil olmak üzere iyi konuştunuz ve bireyler ve OAuth 2.0 kullanan biriyle entegre olabiliyoruz, dolandırıcılığa karşı koruma var, kullanıcı engelleme var. Değişiklikleri dinamik bir şekilde gerçekleştirebiliyoruz çünkü bunu iyi yaptık ve hepsi test edildi.
Bir şeyin başlatılmasında ne gibi tuhaflıkların bulunduğunu bilmek ilgimi çekiyor. Bir arka uç, ön uç geliştirirken, çılgınca bir şeyin ortaya çıktığı ve bununla ne yapacağınızı anlamadığınız garip durumlar oldu mu?
Vladimir: Bana öyle geliyor ki bu sadece son üç aydır oluyor. Her gün. Gördüğünüz gibi tüm saçlarım çekildi.
Vladimir Krasilshchik 3 ay sonra bir tür oyun ortaya çıktığında ve kimse onunla ne yapacağını anlamadığında
Her gün böyle bir şey oluyordu, öyle bir an oluyordu ki, onu alıp saçınızı yoluyordunuz ya da başka kimsenin olmadığını ve bunu yalnızca sizin yapabileceğinizi anlıyordunuz. İlk büyük etkinliğimiz TechTrain'di. 6 Haziran sabah saat 2'de biz henüz üretim ortamını kullanıma sunmamıştık, Kolya bunu piyasaya sürüyordu. Ve kişisel hesap, OAuth2.0'ı kullanan bir yetkilendirme sunucusu olarak çalışmadı. Platformu ona bağlamak için onu bir OAuth2.0 sağlayıcısına dönüştürdük. Muhtemelen 18 saattir aralıksız çalışıyordum, bilgisayara baktım ve hiçbir şey görmedim, neden çalışmadığını anlamadım ve Kolya koduma uzaktan baktı, Spring konfigürasyonunda bir hata aradı. , buldum ve LC çalıştı ve üretimde de.
Nikolai: Ve TechTrain'den bir saat önce yayın gerçekleşti.
Birçok yıldız burada hizalanmıştı. Son derece şanslıydık çünkü süper bir ekibimiz vardı ve herkes bunu çevrimiçi yapma fikrinden ilham almıştı. Tüm bu üç ay boyunca bizi "YouTube'u yarattığımız" gerçeği yönlendirdi. Saçımı yolmaya izin vermedim ama herkese her şeyin yoluna gireceğini söyledim çünkü aslında her şey uzun zaman önce hesaplanmıştı.
Performans hakkında
— Sitede tek bir yolda kaç kişinin bulunduğunu bana söyleyebilir misiniz? Herhangi bir performans sorunu var mıydı?
Nikolai: Daha önce de söylediğimiz gibi herhangi bir performans sorunu yaşanmadı. Bir rapora katılan maksimum kişi sayısı 1300 kişiydi, bu Heisenbug'da.
— Yerel görüntülemede herhangi bir sorun var mıydı? Ve her şeyin nasıl çalıştığına dair diyagramlarla teknik bir açıklamaya sahip olmak mümkün mü?
Nikolai: Bu konuyla ilgili daha sonra bir makale hazırlayacağız.
Hatta akışlardaki hataları yerel olarak ayıklayabilirsiniz. Konferanslar başladıktan sonra her şey daha da kolaylaştı çünkü her zaman izleyebileceğimiz üretim akışları ortaya çıktı.
Vladimir: Anladığım kadarıyla, ön uç geliştiriciler yerel olarak taklitlerle çalışıyordu ve ardından ön taraftaki geliştiricilere dağıtım süresi de kısa olduğundan (5 dakika), sertifikalarla ilgili neler olup bittiğini kontrol etmede herhangi bir sorun olmuyor.
— Her şey yerel olarak bile test edildi ve hata ayıklandı. Bu, tüm teknik özellikleriyle bir makale yazacağımız, size göstereceğimiz, her şeyi diyagramlarla, nasıl olduğunu anlatacağımız anlamına geliyor.
Vladimir: Alıp tekrarlayabilirsiniz.
- 3 ay içinde.
sonuç
— Küçük bir ekip tarafından üç ayda yapıldığını düşünürsek her şey bir arada anlatıldığında kulağa hoş geliyor.
Nikolai: Büyük bir takım bunu yapmaz. Ancak birbirleriyle oldukça yakın ve iyi iletişim kurabilen ve anlaşmaya varabilen küçük bir grup insan bunu başarabilir. Hiçbir çelişkileri yok, mimari iki günde icat edildi, sonuçlandırıldı ve aslında değişmedi. Özellik isteklerinin ve değişikliklerin yığılması açısından gelen iş gereksinimlerinin çok katı bir şekilde kolaylaştırılması söz konusudur.
— Yaz konferansları gerçekleştiğinde, daha sonraki görevler listenizde neler vardı?
Nikolai: Örneğin krediler. Video üzerinde sürünen çizgiler, gösterilen içeriğe bağlı olarak videonun bazı yerlerinde açılır pencereler. Örneğin, konuşmacı dinleyicilere bir soru sormak istiyor ve ekranda konuşmacının kendisine verilen oylama sonuçlarına göre geriye giden bir oylama beliriyor. Sunum sırasında raporun beğenileri, kalpleri, derecelendirmeleri şeklinde bir tür sosyal aktivite, böylece daha sonra geri bildirim formlarıyla dikkatiniz dağılmadan geri bildirimi doğru zamanda doldurabilirsiniz. Başlangıçta bu şekilde.
Ayrıca yayın ve konferans dışında tüm platforma konferans sonrası bir durum da ekleniyor. Bunlar çalma listeleridir (kullanıcılar tarafından derlenenler dahil), muhtemelen diğer geçmiş konferanslardan gelen, entegre edilmiş, etiketlenmiş, kullanıcı tarafından erişilebilir ve ayrıca web sitemizde görüntülenebilen içeriklerdir ().
— Arkadaşlar, cevaplarınız için çok teşekkür ederim!
Okurlarımız arasında yaz konferanslarımıza katılanlar varsa lütfen oyuncu ve yayın hakkındaki izlenimlerinizi paylaşın. Uygun olan neydi, sizi rahatsız eden neydi, gelecekte ne görmek istersiniz?
Platformla ilgileniyorsanız ve onu “savaşta” görmek istiyorsanız, onu tekrar kullanıyoruz. . Bunların çok çeşitli çeşitleri var, dolayısıyla sizin için doğru olanın mutlaka bir tane olduğu kesindir.
Kaynak: habr.com