今年春天，我們發現自己的處境非常愉快。 由於大流行，我們的夏季會議顯然需要轉移到線上。 為了有效地在線上進行這些工作，現成的軟體解決方案不適合我們；我們需要編寫自己的解決方案。 我們有三個月的時間來做這件事。
顯然這是令人興奮的三個月。 但從外部來看，這並不完全顯而易見：什麼是線上會議平台？ 它由哪些部分組成？ 因此，在最後一次夏季 DevOops 會議上，我問負責這項任務的人：
- Nikolay Molchanov - JUG Ru 集團技術總監；
- Vladimir Krasilshchik 是一位務實的 Java 程式設計師，從事後端工作（您也可以在我們的 Java 會議上看到他的報告）；
- Artyom Nikonov 負責我們所有的視訊串流。
順便說一句，在秋冬會議上，我們將使用同一平台的改進版本 - 所以許多哈布拉讀者仍然是它的用戶。
大局觀
——團隊的組成是怎樣的？
尼古拉·莫爾恰諾夫： 我們有一名分析師、一名設計師、一名測試員、三個前端和一個後端。 當然還有T型專家！
——整個過程是怎樣的？
尼古拉： 直到三月中旬，我們還沒有準備好任何線上內容。 15月XNUMX日，整個線上輪播開始旋轉。 我們建立了多個儲存庫，規劃並討論了基本架構，並在三個月內完成了所有工作。
當然，這經歷了規劃、架構、功能選擇、對這些功能進行投票、這些功能的政策、設計、開發、測試等經典階段。 結果，我們在 6 月 XNUMX 日將所有內容投入生產。 。 所有事情都有 90 天的時間。
— 我們是否成功完成了我們的承諾？
尼古拉： 由於我們現在在線參加 DevOops 會議，這意味著它有效。 我個人致力於主要的事情：我將為客戶提供一個可以召開線上會議的工具。
挑戰在於：給我們一個工具，讓我們可以向持票者廣播我們的會議。
所有規劃分為幾個階段，所有功能（全域約30個）分為4類：
- 我們一定會這樣做（沒有他們我們就活不下去），
- 我們接下來要做的就是
- 我們永遠不會這樣做，
- 我們永遠不會這樣做。
我們製作了前兩類的所有功能。
— 我知道總共創建了 600 個 JIRA 問題。 三個月內，你製作了 13 個微服務，我懷疑它們不僅是用 Java 寫的。 您使用了不同的技術，在三個可用區中擁有兩個 Kubernetes 集群，在 Amazon 中擁有 5 個 RTMP 流。
現在讓我們分別看看系統的每個組件。
串流媒體
— 讓我們從我們已經擁有視訊影像並將其傳輸到某些服務開始。 Artyom，請告訴我們這個串流媒體是如何發生的？
阿爾喬姆·尼科諾夫： 我們的整體方案如下：來自攝影機的影像 -> 我們的控制室 -> 本地 RTMP 伺服器 -> 亞馬遜 -> 視訊播放器。 更多細節 六月的哈布雷。
一般來說，有兩種全局方法可以實現此目的：基於硬體或基於軟體解決方案。 我們選擇軟體路線是因為它對於遠端揚聲器來說更容易。 將硬體帶到另一個國家的揚聲器並不總是可能的，但向揚聲器提供軟體似乎更容易、更可靠。
從硬體的角度來看，我們有一定數量的攝影機（在我們的演播室和遠端揚聲器處），演播室中有一定數量的遙控器，有時必須在廣播期間在桌子底下進行維修。
這些設備的訊號透過擷取卡、輸入/輸出卡和聲卡進入電腦。 在那裡，信號被混合併組裝成佈局：
4 個揚聲器的版面範例
4 個揚聲器的版面範例
進一步地，連續廣播是透過三台電腦實現的：主機一台，工作機兩台。 第一台計算機收集第一個報告，第二台計算機收集休息時間，第一台計算機收集下一個報告，第二台計算機收集下一個休息時間，依此類推。 主機將第一個與第二個混合。
這創建了一種三角形，如果這些節點中的任何一個發生故障，我們可以快速且不損失品質地繼續向客戶提供內容。 我們就遇過這樣的情況。 在會議的第一周，我們修復了一台機器，打開/關閉它。 人們似乎對我們的韌性感到滿意。
接下來，來自電腦的串流傳輸到本機伺服器，該伺服器有兩個任務：路由 RTMP 流和記錄備份。 所以我們有多個記錄點。 然後，視訊串流被傳送到我們基於 Amazon SaaS 服務所建構的系統部分。 我們用 、S3、CloudFront。
尼古拉： 在影片到達觀眾之前會發生什麼？ 你必須以某種方式削減它，對吧？
阿爾喬姆： 我們自行壓縮影片並將其發送到 MediaLive。 我們在那裡推出轉碼器。 他們將視訊即時轉碼成多種分辨率，以便人們可以在手機上、透過國內較差的網路等觀看它們。 然後這些流被切割成 ，這就是協議的工作原理 。 我們向前端發送一個播放列表，其中包含指向這些區塊的指標。
— 我們使用 1080p 解析度嗎？
阿爾喬姆： 我們影片的寬度與 1080p - 1920 像素相同，高度稍小，圖片更拉長 - 這是有原因的。
玩家
— Artyom 描述了影片如何進入串流、如何針對不同的螢幕解析度分配到不同的播放清單、切成區塊並進入播放器。 Kolya，現在告訴我這是什麼類型的播放器，它如何消耗串流，為什麼是 HLS？
尼古拉： 我們有一個所有會議觀眾都可以觀看的播放器。
本質上，這是庫的包裝 ，上面寫著許多其他球員。 但我們需要非常具體的功能：倒帶並標記該人的位置以及他目前正在觀看的報告。 我們還需要自己的佈局、各種徽標以及我們內建的所有其他內容。 因此，我們決定編寫自己的庫（HLS 的包裝器）並將其嵌入到網站中。
這是根功能，因此它幾乎是最先實現的。 然後一切都圍繞著它生長。
事實上，透過授權，播放器從後端接收一個播放列表，其中包含與時間和品質相關的區塊的鏈接，下載必要的區塊並將其顯示給用戶，並在此過程中執行一些「魔術」。
時間軸範例
— 播放器中內建了一個按鈕，用於顯示所有報告的時間軸...
尼古拉： 是的，我們立即解決了用戶導航的問題。 四月中旬，我們決定不再在單獨的網站上廣播每次會議，而是將所有內容合併在一個網站上。 這樣，全通票用戶就可以在不同的會議之間自由切換：既可以直播，也可以錄製過去的會議。
為了讓使用者更容易導航當前串流並在曲目之間切換，我們決定製作一個「整個廣播」按鈕和水平報告卡，用於在曲目和報告之間切換。 有鍵盤控制。
— 這有什麼技術困難嗎？
尼古拉： 他們有一個滾動條，上面標記了不同報告的起點。
— 最後，你們是在 YouTube 做類似的事情之前在滾動條上實現這些標記的嗎？
阿爾喬姆： 當時他們還處於測試階段。 這似乎是一個相當複雜的功能，因為他們在過去的一年裡已經對用戶進行了部分測試。 現在它已經上市了。
尼古拉： 但實際上我們的銷售速度更快。 老實說，在這個簡單的功能背後，播放器內部有大量的後端、前端、計算和數學。
前端
— 讓我們弄清楚我們展示的這些內容（演講卡、演講者、網站、時間表）如何到達前端？
弗拉基米爾·克拉西爾希克： 我們有幾個內部 IT 系統。 有一個系統可以輸入所有報告和所有發言者。 演講者參加會議有過程。 演講者提交申請，系統捕獲該申請，然後根據特定的管道建立報告。
這就是演講者對管道的看法
這個系統是我們內部開發的。
接下來，您需要根據各個報告製定時間表。 如您所知，這是一個 NP 難題，但我們以某種方式解決了它。 為此，我們啟動了另一個元件來產生時間表並將其上傳到第三方雲端服務 Contentful。 在那裡，一切看起來都像一張桌子，其中有會議的日子，日子裡有時段，時段中有報告、休息或贊助活動。 所以我們看到的內容位於第三方服務中。 而任務就是將其傳送到現場。
看起來這個網站只是一個有播放器的頁面，這裡沒有什麼複雜的。 但事實並非如此。 該頁面後面的後端轉到 Contentful，從那裡獲取時間表，產生一些物件並將其發送到前端。 使用我們平台的每個客戶端都會建立的 websocket 連接，我們向他發送從後端到前端的時間表更新。
真實案例：演講者在會議期間就換了工作。 我們需要更換他的雇主公司徽章。 從後端來看，這是如何發生的？ 更新透過 websocket 發送到所有客戶端，然後前端本身重新繪製時間軸。 這一切都發生得天衣無縫。 雲端服務和我們的幾個組件的結合使我們有機會產生所有這些內容並將其提供給前台。
尼古拉： 在此需要澄清的是，我們的網站不是經典的 SPA 應用程式。 這既是一個基於佈局的渲染網站，也是一個 SPA。 Google 實際上將此網站視為呈現的 HTML。 這有利於搜尋引擎優化並向用戶交付內容。 它不會等待 1,5 MB 的 JavaScript 載入才看到頁面，它會立即看到已經渲染的頁面，並且每次切換報表時您都會感覺到。 一切都在半秒鐘內發生，因為內容已經準備好並發佈在正確的位置。
— 讓我們透過列出技術來對上述所有內容劃清界限。 Tyoma 說我們有 5 個亞馬遜串流媒體，我們在那裡提供視訊和聲音。 我們那裡有 bash 腳本，我們用它們來啟動和配置...
阿爾喬姆： 這是透過 AWS API 實現的，那裡還有更多技術方面的服務。 我們劃分了責任，以便我能夠交付 ，前端和後端開發人員從那裡獲取它。 我們有許多自己的綁定來簡化內容的佈局，然後我們將其製作為 4K 等。 由於期限非常緊迫，我們幾乎完全在 AWS 上完成。
— 然後所有這些都進入使用後端系統的播放器中。 我們的播放器有 TypeScript、React、Next.JS。 在後端，我們有多種 C#、Java、Spring Boot 和 Node.js 服務。 這一切都是使用 Yandex.Cloud 基礎架構使用 Kubernetes 進行部署的。
我還想指出的是，當我需要熟悉該平台時，結果很簡單：所有儲存庫都在 GitLab 上，所有內容都命名良好，編寫了測試，有文件。 也就是說，即使在緊急模式下，他們也會處理這些事情。
業務限制和分析
— 我們根據業務需求定位了 10 個使用者。 是時候談談我們的業務限制了。 我們必須確保高工作量，確保遵守有關個人資料保存的法律。 還有什麼？
尼古拉： 最初，我們從視訊需求開始。 最重要的是世界各地的分散式視訊存儲，以便快速交付給客戶。 其他功能包括 1080p 解析度以及倒帶功能，但許多其他功能並未在即時模式下實現。 後來我們增加了啟用2倍速度的功能，在它的幫助下您可以「趕上」直播並繼續即時觀看會議。 在此過程中，時間軸標記功能出現了。 另外，我們必須能夠容錯並承受 10 個連接的負載。 從後端的角度來看，這大約是每次頁面刷新的 000 個連線乘以 10 個請求。 這已經是 000 RPS/秒。 相當有一點。
— 對於合作夥伴線上展位的「虛擬展覽」還有其他要求嗎？
尼古拉： 是的，這必須非常迅速且普遍地完成。 每次會議我們最多有 10 家合作夥伴公司，所有會議都必須在一兩週內完成。 然而，它們的內容在格式上略有不同。 但製作了某種模板引擎來動態組裝這些頁面，幾乎沒有進一步的開發參與。
— 也有即時視圖和統計分析的要求。 我知道我們為此使用 Prometheus，但請更詳細地告訴我們：我們滿足哪些分析要求，以及如何實現？
尼古拉： 最初，我們有收集 A/B 測試和資訊的行銷要求，以便了解未來如何正確地向客戶提供最佳內容。 還需要對合作夥伴活動進行一些分析以及您看到的分析（訪問櫃檯）。 所有資訊都是即時收集的。
我們甚至可以向演講者提供匯總形式的資訊：在某個時間點有多少人在觀看您。 同時，為了遵守聯邦法律 152，我們不會以任何方式追蹤您的個人帳戶和個人資料。
該平台已經擁有行銷工具和我們用於即時測量用戶活動（誰觀看了報告的哪一秒）的指標，以便建立報告的出席率圖表。 基於這些數據，正在進行的研究將使下一次的會議變得更好。
詐欺罪
— 我們有反詐騙機制嗎？
尼古拉： 由於從業務角度來看時間緊迫，該任務最初並未設定為立即阻止不必要的連線。 如果兩個使用者使用相同帳戶登錄，則可以查看內容。 但我們知道一個帳戶有多少同時觀看次數。 我們也禁止了一些特別惡意的違規者。
弗拉基米爾： 值得讚揚的是，其中一名被禁止的用戶明白為什麼會發生這種情況。 他來了，道歉並答應買票。
——要實現這一切，你必須完整追蹤所有用戶從進入到退出的過程，並始終知道他們在做什麼。 這個系統如何運作？
弗拉基米爾： 我想談談分析和統計，然後我們分析報告是否成功，或者可以提供給合作夥伴。 所有客戶端都透過 websocket 連接到特定的後端叢集。 它站在那裡 。 每個客戶在每個時間段發送他正在做什麼以及他正在觀看什麼曲目。 然後，使用快速 Hazelcast 作業聚合這些訊息，並將其發送回觀看這些曲目的每個人。 我們在角落看到現在有多少人和我們在一起。
相同的資訊儲存在 並進入我們的數據湖，我們有機會建立一個更有趣的圖表。 問題來了：有多少獨立用戶查看了這份報告？ 我們去 ，有所有透過此報告的 id 來的人的 ping。 我們收集、匯總了獨特的信息，現在我們可以理解了。
尼古拉： 但同時，我們也接收來自Prometheus的即時數據。 它是針對所有 Kubernetes 服務、針對 Kubernetes 本身而設定的。 它收集了所有信息，透過 Grafana，我們可以即時建立任何圖表。
弗拉基米爾： 一方面，我們下載它以進行進一步的 OLAP 處理。 對於 OLTP，應用程式將整個內容下載到 Prometheus、Grafana，圖表甚至會收斂！
- 這是圖收斂時的情況。
動態變化
— 告訴我們動態變化是如何推出的：如果報告在開始前 6 分鐘被取消，那麼行動鍊是什麼？ 哪個管道有效？
弗拉基米爾： 管道是非常有條件的。 有幾種可能性。 第一個是時間表產生程式起作用並改變了時間表。 修改後的時間表上傳到 Contentful。 之後後端了解到 Contentful 中此會議有更改，將其取得並重建。 一切都透過 websocket 收集和發送。
第二種可能性，當一切都以極快的速度發生時：編輯手動更改 Contentful 中的信息（連結到 Telegram、演講者的簡報等），並且與第一次的邏輯相同。
尼古拉： 一切都在不刷新頁面的情況下發生。 對客戶來說，所有的改變都是無縫發生的。 切換報告也是如此。 當時間到來時，報告和介面會發生變化。
弗拉基米爾： 此外，時間軸中還有開始報告的時間截止點。 一開始什麼都沒有。 如果您將滑鼠懸停在紅色條紋上，那麼在某個時刻，由於廣播導演的幫助，將會出現截止點。 導演設定正確的廣播開始時間，後端接收此更改，根據會議時間表計算整個曲目演示的開始和結束時間，將其發送給我們的客戶，然後播放器繪製截止時間。 現在，用戶可以輕鬆導航到報告的開頭和結尾。 這是一個嚴格的業務要求，非常方便和有用。 您無需浪費時間查找報告的實際開始時間。 當我們進行預覽時，那將是絕對精彩的。
部署
——我想問一下部署的問題。 Kolya 和團隊一開始就花了很多時間來建立整個基礎設施，讓一切都為我們展開。 告訴我，這一切都是用什麼製成的？
尼古拉： 從技術角度來看，我們最初要求產品盡可能從任何供應商中抽象化。 來到 AWS 專門從 AWS、或專門從 Yandex、或從 Azure 等製作 Terraform 腳本。 不太適合。 我們必須在某個時候搬到某個地方。
在前三週，我們一直在尋找更好的方法。 因此，我們得出的結論是，在這種情況下，Kubernetes 就是我們的一切，因為它允許我們創建自動擴展的服務、自動部署，並獲得幾乎所有開箱即用的服務。 當然，所有服務都必須經過訓練才能與 Kubernetes、Docker 配合使用，團隊也必須學習。
我們有兩個集群。 測試和生產。 它們在硬體和設定方面完全相同。 我們將基礎設施實施為程式碼。 所有服務都會使用自動管道自動部署到功能分支、主分支、測試分支和 GitLab 三個環境。 這個最大限度地整合到GitLab中，最大限度地與Elastic、Prometheus整合。
我們有機會快速（對於後端在 10 分鐘內，對於前端在 5 分鐘內）通過所有測試、集成、運行功能測試、環境集成測試以及負載測試來對任何環境進行更改測試環境與我們想要在生產中獲得的環境大致相同。
關於測試
— 你幾乎測試了所有內容，很難相信你是如何寫所有內容的。 您能否告訴我們有關後端測試的資訊：涵蓋了多少內容，哪些測試？
弗拉基米爾： 已經編寫了兩種類型的測試。 首先是組件測試。 整個彈簧應用和底座的提升水平測試 。 這是對最高層級業務場景的考驗。 我不測試功能。 我們只測試一些大的事情。 例如，在測試中，模擬登入使用者的過程、使用者要求他可以去的地方的門票，以及請求訪問觀看串流。 使用者場景非常清晰。
在實際環境中運行的所謂整合測試中實現了大約相同的事情。 事實上，當下一次生產部署推出時，真正的基本場景也正在生產中運作。 相同的登錄，請求票證，請求訪問CloudFront，檢查串流是否確實與我的權限連接，檢查導演的介面。
目前我正在進行大約 70 個組件測試和大約 40 個整合測試。 覆蓋率非常接近 95%。 這是針對組件的，較少針對整合的，根本沒有那麼多需要。 考慮到該專案涉及各種程式碼生成，這是一個非常好的指標。 沒有其他辦法可以完成我們三個月內所做的事情。 因為如果我們手動測試，為我們的測試人員提供功能，她會發現錯誤並將其返回給我們進行修復，那麼調試程式碼的往返行程將非常長，我們將無法滿足任何截止日期。
尼古拉： 傳統上，要在更改某個功能時對整個平台進行回歸，需要坐兩天到處戳。
弗拉基米爾： 因此，當我估計一個功能時，我說我需要 4 天來使用兩支簡單的筆和 1 個 websocket，這是一個巨大的成功，Kolya 允許。 他已經習慣了這四天包括兩種測試，然後很可能就會起作用。
尼古拉： 我還寫了 140 個測試：元件+功能，它們做同樣的事情。 所有相同的場景都在生產、測試和生產中進行測試。 我們最近也新增了功能性基本 UI 測試。 透過這種方式，我們涵蓋了可能會崩潰的最基本的功能。
弗拉基米爾： 當然，值得一提的是負載測試。 有必要在接近真實負載的負載下測試平台，以便了解一切情況、Rabbit 發生了什麼、JVM 發生了什麼以及實際需要多少記憶體。
— 我不確定我們是否在串流端測試任何東西，但我記得我們聚會時轉碼器出現了問題。 我們測試過流嗎？
阿爾喬姆： 反覆測試。 組織聚會。 在組織聚會的過程中，大約有 2300 張 JIRA 門票。 這些只是人們為了聚會而做的一般事情。 我們將平台的一部分放到了一個單獨的聚會頁面上，該頁面由基里爾·托爾卡喬夫（Kirill Tolkachev）運營（).
說實話，沒有什麼大問題。 事實上，有幾次我們在 CloudFront 上發現了快取錯誤，我們很快就解決了它 - 我們只是重新配置了策略。 網站上的串流媒體系統中的人員錯誤明顯增加。
在會議期間，我必須寫更多的出口商，以便涵蓋更多的設備和服務。 在某些地方，我必須自己製造自行車，只是為了指標。 AV（音訊視訊）硬體的世界並不十分美好——你擁有某種你根本無法影響的裝置「API」。 事實並非如此，您就能獲得所需的資訊。 硬體供應商真的很慢，幾乎不可能從他們那裡得到你想要的東西。 總共有 100 多個硬件，它們不能返回您需要的東西，並且您編寫了奇怪且冗餘的導出器，借助它們您至少可以以某種方式調試系統。
Оборудование
— 我記得在會議開始之前我們購買了部分額外的設備。
阿爾喬姆： 我們購買了電腦、筆記型電腦和電池組。 目前我們可以在沒有電力的情況下生活40分鐘。 六月，聖彼得堡遭遇了嚴重的雷暴，所以我們遭遇了停電。 同時，一些提供者從不同的地點向我們提供光鏈路。 這實際上是 40 分鐘的建築停機時間，在此期間我們將打開燈光、聲音、攝影機等。
— 我們在網路上也有類似的故事。 在我們工作室所在的辦公室裡，我們在樓層之間拖著一張兇猛的網。
阿爾喬姆： 我們在樓層之間有 20 Gbit 的光纖。 再沿著樓層，某處有光學器件，某處沒有光學器件，但通道仍然少於千兆位元通道 - 我們在會議軌道之間在它們上運行視訊。 一般來說，在自己的基礎設施上工作非常方便；您很少可以在現場的線下會議上這樣做。
— 在我在 JUG Ru Group 工作之前，我看到了線下會議的硬體室是如何在一夜之間搭建起來的，那裡有一個大監視器，上面顯示著你在 Grafana 中構建的所有指標。 現在還有一個總部房間，開發團隊就坐在那裡，在會議期間修復一些錯誤並開發功能。 同時，還有一個監控系統，顯示在大螢幕上。 Artyom、Kolya 和其他人坐下來確保這一切不會掉落並且正常運作。
好奇心和問題
— 你說得很好，我們有亞馬遜串流媒體，有網頁播放器，一切都是用不同的程式語言編寫的，提供容錯和其他業務要求，包括支援法人實體的個人帳戶和個人，我們可以與使用OAuth 2.0的人集成，有反詐騙、用戶封鎖。 我們可以動態地推出更改，因為我們做得很好，而且都經過了測試。
我很想知道開始做某件事時會遇到哪些奇怪的事情。 當你開發後端、前端時，是否遇到過奇怪的情況，結果出現了一些瘋狂的東西，而你不知道該如何處理它？
弗拉基米爾： 在我看來，這種情況只發生在最近三個月。 每天。 正如你所看到的，我的頭髮都被拔掉了。
Vladimir Krasilshchik 三個月後，當某種遊戲問世時，沒有人知道如何處理它
每天都會有這樣的事情，當有那麼一個時刻，你拿著它，撕扯你的頭髮，或是意識到沒有別人，只有你能做到。 我們的第一個大型活動是 TechTrain。 6 月 2 日凌晨 2.0 點，我們還沒有推出生產環境，Kolya 正在推出它。 且個人帳戶無法作為使用OAuth2.0的授權伺服器。 我們將其轉變為 OAuth18 提供者以將平台連接到它。 我已經連續工作了大概 XNUMX 個小時，我看著電腦，沒有看到任何東西，我不明白為什麼它不工作，Kolya 遠端查看了我的程式碼，尋找 Spring 配置中的錯誤，找到了，LC 工作了，並且也在生產中。
尼古拉： 在 TechTrain 發布前一小時。
很多星星都聚集在這裡。 我們非常幸運，因為我們有一個超級團隊，每個人都受到在線做事的想法的啟發。 這三個月裡，我們都被「創造了 YouTube」這一事實所驅動。 我不讓自己胡思亂想，而是告訴大家一切都會好起來的，因為其實一切都早已計算好了。
關於性能
— 您能告訴我該網站上一條軌道上有多少人嗎？ 是否存在任何效能問題？
尼古拉： 正如我們已經說過的，不存在效能問題。 一場報告的最大參加人數為1300人，這是在Heisenbug上。
— 在地觀看有什麼問題嗎？ 是否可以透過技術描述和圖表來說明其工作原理？
尼古拉： 稍後我們會寫一篇文章討論這個問題。
您甚至可以在本地調試流。 會議開始後，事情變得更加容易，因為出現了我們可以隨時觀看的製作流程。
弗拉基米爾： 據我了解，前端開發人員在本地使用模擬進行工作，然後，由於向前端開發人員推出的時間也很短（5分鐘），因此檢查證書的情況沒有問題。
— 一切都經過測試和調試，甚至在本地也是如此。 這意味著我們將寫一篇包含所有技術特徵的文章，向您展示，用圖表告訴您一切，以及它是怎樣的。
弗拉基米爾： 你可以接受它並重複它。
- 3個月內。
總
— 考慮到這是一個小團隊在三個月內完成的，所有描述在一起聽起來很酷。
尼古拉： 一個大團隊不會這麼做。 但如果一小群人彼此溝通非常密切、良好且能夠達成一致，那麼就可以做到這一點。 他們沒有任何矛盾，架構是在兩天內發明的，最後確定的，實際上並沒有改變。 在堆積功能請求和變更方面，對傳入的業務需求有非常嚴格的促進作用。
— 夏季會議已經召開後，您的進一步任務清單上有哪些？
尼古拉： 例如，學分。 影片上出現蠕動線條，影片中某些位置會彈出窗口，具體取決於所顯示的內容。 例如，演講者想向聽眾提問，螢幕上會彈出一個投票，根據投票結果回傳給演講者本人。 在演示過程中以點讚、關注、評分等形式進行某種社交活動，以便您可以在適當的時候填寫反饋，而不會在以後因反饋表格而分心。 最初是這樣的。
並且還給整個平台添加了除了串流媒體和會議之外，也是一個會後狀態。 這些是播放清單（包括由用戶編輯的播放清單），可能是來自其他過去會議的內容，經過整合、標記、用戶可以訪問，也可以在我們的網站上查看（).
— 夥伴們，非常感謝你們的回答！
如果讀者中有參加過我們夏季會議的人，請分享您對播放器和廣播的印象。 什麼讓你方便，什麼讓你惱火，將來希望看到什麼？
如果您對該平台感興趣並希望看到它“在戰鬥中”，我們會在我們的網站上再次使用它 。 它們的範圍很廣，所以幾乎肯定有一個適合您。
來源： www.habr.com