Netflix 是網路電視市場的領導者——該公司創建並正在積極開發這一細分市場。 Netflix 不僅因其豐富的電影和電視劇目錄而聞名，這些電影和電視劇幾乎可以在地球的每個角落以及任何帶有顯示屏的設備上觀看，而且還因其可靠的基礎設施和獨特的工程文化而聞名。
DevOops 2019 上展示了 Netflix 開發和支援複雜系統方法的一個明顯範例 - Netflix 開發總監。 畢業於下諾夫哥羅德國立大學計算數學和數學系。 Sergey Lobachevsky 是 Netflix Open Connect - CDN 團隊的首批工程師之一。 他建立了用於監控和分析視訊資料的系統，推出了一項流行的評估網路連線速度的服務FAST.com，並且在過去幾年中一直致力於優化網路請求，以便Netflix 應用程式能夠盡快為用戶服務。
該報告得到了與會者的好評，我們為您準備了文字版本。
謝爾蓋在報告中詳細談到
- 關於什麼因素影響客戶端和伺服器之間的 Internet 請求的延遲；
- 如何減少這種延遲；
- 如何設計、維護和監控容錯系統；
- 如何在短時間內取得成果，並將業務風險降至最低；
- 如何分析結果並從錯誤中學習。
這些問題的答案不僅是那些在大公司工作的人所需要的。
每個開發和支援網路產品的人都應該了解並實踐所提出的原則和技術。
接下來是從演講者的角度來敘述。
網速的重要性
網路請求的速度與業務直接相關。 以購物產業為例：2009 年的亞馬遜 100 毫秒的延遲會導致 1% 的銷售額損失。
行動裝置越來越多，隨之而來的是行動網站和應用程式。 如果您的頁面載入時間超過 3 秒，您將失去大約一半的使用者。 和 Google 會考慮搜尋結果中頁面的載入速度：頁面速度越快，在 Google 的排名就越高。
對於延遲至關重要的金融機構來說，連線速度也很重要。 2015年，Hibernia Networks 紐約和倫敦之間耗資 400 億美元的電纜，可將城市之間的延遲減少 6 毫秒。 想像一下，減少 66 毫秒的延遲需要花費 1 萬美元！
根據 ，超過 5 Mbit/s 的連線速度不再直接影響典型網站的載入速度。 然而，連線延遲和頁面載入速度之間存在線性關係：
然而，Netflix並不是一個典型的產品。 延遲和速度對使用者的影響是分析和開發的一個活躍領域。 應用程式載入和內容選擇取決於延遲，但載入靜態元素和串流媒體也取決於連線速度。 分析和優化影響使用者體驗的關鍵因素是 Netflix 多個團隊積極開發的領域。 目標之一是減少 Netflix 裝置和雲端基礎設施之間的請求延遲。
在報告中，我們將特別關注使用 Netflix 基礎設施範例來減少延遲。 讓我們從實際的角度考慮如何處理複雜分散式系統的設計、開發和營運流程，並將時間花在創新和結果上，而不是診斷營運問題和故障。
Netflix 內部
數千種不同的設備支援 Netflix 應用。 它們由四個不同的團隊開發，分別為 Android、iOS、電視和網路瀏覽器製作不同版本的用戶端。 我們花費了大量的精力來改善和個人化用戶體驗。 為此，我們並行運行數百個 A/B 測試。
AWS 雲端中的數百個微服務支援個人化，提供個人化使用者資料、查詢排程、遙測、大數據和編碼。 流量可視化如下所示：
左邊是入口點，然後流量分佈在不同後端團隊支援的數百個微服務中。
我們基礎架構的另一個重要組成部分是 Open Connect CDN，它向最終用戶提供靜態內容 - 視訊、圖像、客戶端程式碼等。 CDN 位於自訂伺服器（OCA - Open Connect Appliance）上。 裡面有運行優化的 FreeBSD 的 SSD 和 HDD 驅動器陣列，以及 NGINX 和一組服務。 我們設計和優化硬體和軟體元件，以便這樣的CDN伺服器可以向用戶發送盡可能多的資料。
這些伺服器在網際網路流量交換點（Internet eXchange - IX）的「牆」如下所示：
Internet Exchange為網路服務供應商和內容供應商提供了相互「連接」的能力，以便更直接地在網際網路上交換資料。 全球大約有70-80個互聯網交換點安裝了我們的伺服器，並且我們獨立安裝和維護它們：
此外，我們也直接向網路供應商提供伺服器，讓他們安裝在自己的網路中，從而改善 Netflix 流量的在地化和使用者的串流品質：
一組 AWS 服務負責將客戶端的視訊請求分派到 CDN 伺服器，並配置伺服器本身 - 更新內容、程式碼、設定等。 對於後者，我們還建立了一個骨幹網絡，將互聯網交換點的伺服器與 AWS 連接起來。 骨幹網路是一個由光纖電纜和路由器組成的全球網絡，我們可以根據需要進行設計和配置。
上 ，我們的 CDN 基礎設施在高峰時段提供了大約 150/XNUMX 的全球互聯網流量，以及 Netflix 運營時間最長的北美地區 XNUMX/XNUMX 的流量。 令人印象深刻的數字，但對我來說最驚人的成就之一是整個CDN系統是由不到XNUMX人的團隊開發和維護的。
最初，CDN 基礎設施旨在傳輸視訊資料。 然而，隨著時間的推移，我們意識到我們也可以使用它來優化來自 AWS 雲端中客戶端的動態請求。
關於網路加速
如今，Netflix 有 3 個 AWS 區域，對雲端的請求的延遲將取決於客戶與最近區域的距離。 同時，我們有許多CDN伺服器用來傳送靜態內容。 有沒有辦法利用這個框架來加速動態查詢呢？ 然而，不幸的是，不可能快取這些請求——API 是個人化的，每個結果都是唯一的。
讓我們在 CDN 伺服器上建立一個代理並開始透過它發送流量。 會更快嗎？
物料
讓我們記住網路協定是如何運作的。 如今，網路上的大多數流量都使用 HTTP，這取決於底層協定 TCP 和 TLS。 為了讓客戶端連接到伺服器，它會進行一次握手，並且要建立安全連接，客戶端需要與伺服器交換訊息 100 次，並至少再傳輸一次資料。 如果每次往返延遲 (RTT) 為 400 毫秒，則我們需要 XNUMX 毫秒才能接收第一位資料：
如果我們將憑證放在CDN伺服器上，那麼如果CDN距離較近，客戶端和伺服器之間的握手時間可以顯著減少。 假設 CDN 伺服器的延遲為 30 毫秒。 那麼接收第一位就需要 220 ms：
但優點還不止於此。 一旦建立連接，TCP 就會增加擁塞視窗（它可以透過該連接並行傳輸的資訊量）。 如果封包遺失，則 TCP 協定的經典實作（如 TCP New Reno）會將開啟的「視窗」減少一半。 擁塞視窗的成長及其再次從遺失中恢復的速度取決於到伺服器的延遲（RTT）。 如果此連線僅到達 CDN 伺服器，則復原速度會更快。 同時，丟包是一種標準現象，尤其是對於無線網路而言。
由於用戶的流量，網路頻寬可能會減少，尤其是在高峰時段，導致交通擁堵。 然而，在網路上無法優先處理某些請求。 例如，優先考慮小型且對延遲敏感的請求，而不是載入網路的「繁重」資料流。 然而，在我們的例子中，擁有自己的骨幹網路允許我們在 CDN 和雲端之間的請求路徑的一部分上執行此操作，並且我們可以完全配置它。 您可以確保小資料包和對延遲敏感的資料包優先處理，大數據流稍後處理。 CDN離客戶端越近，效率就越高。
應用層協定（OSI Level 7）也會對延遲產生影響。 HTTP/2 等新協定優化了並行請求的效能。 但是，我們確實有 Netflix 用戶端使用不支援新協定的舊設備。 並非所有客戶端都可以更新或最佳化配置。 同時，CDN 代理和雲端之間具有完全的控制權，並且能夠使用新的、最佳的協定和設定。 舊協定無效的部分僅在客戶端和 CDN 伺服器之間運作。 此外，我們可以在CDN和雲端之間已經建立的連線上發出多路請求，從而提高TCP等級的連線利用率：
我們測量
儘管該理論有望改進，但我們並不急於立即在生產中啟動系統。 相反，我們必須先證明這個想法在實踐中可行。 為此，您需要回答幾個問題：
- 速度: 代理會更快嗎？
- 可靠性: 會不會常常壞？
- 複雜性: 如何與應用程式整合？
- 成本：部署額外的基礎設施需要多少錢？
讓我們詳細考慮評估第一點的方法。 其餘的也以類似的方式處理。
為了分析請求的速度，我們希望獲取所有用戶的數據，而無需花費大量時間進行開發，也不會中斷生產。 為此有幾種方法：
- RUM，或被動請求測量。 我們測量用戶當前請求的執行時間並確保完全的用戶覆蓋。 缺點是由於多種因素，例如請求大小、伺服器和客戶端的處理時間不同，訊號不太穩定。 此外，您無法在不影響生產的情況下測試新配置。
- 實驗室測試。 模擬客戶端的特殊伺服器和基礎設施。 在他們的幫助下，我們進行了必要的測試。 這樣我們就可以完全控制測量結果和清晰的訊號。 但設備和用戶位置並未完全覆蓋（尤其是在全球範圍內提供服務並支援數千種設備型號）。
如何結合這兩種方法的優點？
我們的團隊已經找到了解決方案。 我們編寫了一小段程式碼 - 一個範例 - 我們將其內建到我們的應用程式中。 探針使我們能夠從我們的設備進行完全受控的網路測試。 它的工作原理如下：
- 加載應用程式並完成初始活動後不久，我們就運行探針。
- 客戶端向伺服器發出請求並接收測試的“配方”。 配方是需要向其發出 HTTP(s) 請求的 URL 清單。 此外，配方還配置請求參數：請求之間的延遲、請求的資料量、HTTP(s) 標頭等。 同時，我們可以並行測試幾個不同的配方——在請求配置時，我們隨機確定要發布哪個配方。
- 選擇探針啟動時間，以免與用戶端上網路資源的主動使用發生衝突。 本質上，時間是在客戶端不活動時選擇的。
- 收到配方後，用戶端並行向每個 URL 發出請求。 對每個地址的請求都可以重複——即所謂的。 「脈衝」。 在第一個脈衝上，我們測量建立連接和下載資料所需的時間。 在第二個脈衝上，我們測量通過已建立的連線載入資料所需的時間。 在第三個之前，我們可以設定一個延遲，測量建立重連的速度等。
在測試過程中，我們測量了設備可以獲得的所有參數：
- DNS請求時間；
- TCP連線建立時間；
- TLS 連線建立時間；
- 接收第一個資料位元組的時間；
- 總載入時間；
- 狀態結果代碼。
- 所有脈衝完成後，樣本將載入所有測量結果以進行分析。
關鍵點是對客戶端邏輯、伺服器資料處理以及並行請求測量的最小依賴。 因此，我們能夠隔離和測試影響查詢效能的各種因素的影響，在單一配方中改變它們，並從真實客戶那裡獲得結果。
事實證明，該基礎設施不僅適用於查詢效能分析。 目前我們有 14 個活躍配方，每秒鐘超過 6000 個樣本，接收來自地球各個角落的資料和全設備覆蓋範圍。 如果Netflix從第三方購買類似的服務，每年將花費數百萬美元，而且覆蓋範圍也會更差。
實務中的測試理論：原型
透過這樣的系統，我們能夠評估 CDN 代理程式對請求延遲的有效性。 現在你需要：
- 創建代理原型；
- 將原型放在 CDN 上；
- 確定如何將客戶端定向到特定 CDN 伺服器上的代理；
- 將效能與沒有代理程式的 AWS 中的請求進行比較。
任務是盡快評估所提出的解決方案的有效性。 由於良好的網路庫的可用性，我們選擇 Go 來實現原型。 在每個 CDN 伺服器上，我們將原型代理安裝為靜態二進位文件，以最大程度地減少依賴性並簡化整合。 在最初的實作中，我們盡可能使用標準元件，並對 HTTP/2 連線池和請求復用進行少量修改。
為了在 AWS 區域之間進行平衡，我們使用了地理 DNS 資料庫，該資料庫與用於平衡客戶端的資料庫相同。 為了為客戶端選擇 CDN 伺服器，我們對 Internet Exchange (IX) 中的伺服器使用 TCP Anycast。 在此選項中，我們對所有 CDN 伺服器使用一個 IP 位址，客戶端將被導向到 IP 跳數最少的 CDN 伺服器。 在網路供應商（ISP）安裝的CDN伺服器中，我們無法控制路由器來設定TCP Anycast，因此我們使用 ，它將客戶引導至互聯網提供商以獲取視訊串流。
因此，我們有三種類型的請求路徑：透過開放網路到雲端、透過 IX 中的 CDN 伺服器或透過位於網路供應商的 CDN 伺服器。 我們的目標是了解哪種方式更好，以及與將請求發送到生產的方式相比，代理有什麼好處。 為此，我們使用以下採樣系統：
每條路徑都成為一個單獨的目標，我們來看看我們得到的時間。 為了進行分析，我們將代理結果合併為一組（選擇 IX 和 ISP 代理之間的最佳時間），並將其與沒有代理時向雲端請求的時間進行比較：
正如您所看到的，結果好壞參半 - 在大多數情況下，代理提供了很好的加速，但也有足夠數量的客戶端，情況會顯著惡化。
結果，我們做了幾件重要的事情：
- 我們評估了客戶端透過 CDN 代理程式向雲端發出請求的預期效能。
- 我們從所有類型的設備的真實客戶收到資料。
- 我們意識到該理論並未 100% 得到證實，並且使用 CDN 代理的初始報價對我們不起作用。
- 我們沒有冒險－我們沒有為客戶改變生產配置。
- 沒有任何東西被破壞。
原型2.0
因此，回到繪圖板並再次重複此過程。
我們的想法是，我們將確定每個客戶端的最快路徑，而不是使用 100% 代理，然後向那裡發送請求 - 也就是說，我們將執行所謂的客戶端引導。
如何實施？ 我們不能在伺服器端使用邏輯，因為...... 目標是連接到該伺服器。 需要有某種方法在客戶端上執行此操作。 理想情況下，用最少的複雜邏輯來完成此操作，以免解決與大量客戶端平台整合的問題。
答案是使用DNS。 在我們的例子中，我們有自己的 DNS 基礎設施，我們可以設定一個網域區域，我們的伺服器將是專制的。 它的工作原理如下：
- 用戶端使用主機向 DNS 伺服器發出請求，例如 api.netflix.xom。
- 請求到達我們的 DNS 伺服器
- DNS 伺服器知道該用戶端的最快路徑並發出對應的 IP 位址。
此解決方案具有額外的複雜性：獨裁 DNS 提供者看不到客戶端的 IP 位址，只能讀取用戶端使用的遞歸解析器的 IP 位址。
因此，我們的獨裁解析器必須不是為單一客戶端做出決定，而是為基於遞歸解析器的一組客戶端做出決定。
為了解決這個問題，我們使用相同的樣本，聚合每個遞歸解析器的客戶端測量結果，並決定將這組資料傳送到哪裡 - 使用 TCP Anycast 透過 IX 的代理程式、透過 ISP 代理程式或直接傳送到雲端。
我們得到以下系統：
產生的 DNS 引導模型可讓您根據用戶端到雲端連線速度的歷史觀察結果來引導用戶端。
同樣，問題是這種方法的效果如何？ 為了回答這個問題，我們再次使用我們的探針系統。 因此，我們配置演示者配置，其中一個目標遵循 DNS 控制的方向，另一個目標直接進入雲端（目前生產）。
因此，我們比較結果並評估有效性：
結果，我們學到了幾件重要的事情：
- 我們使用 DNS 引導評估了從客戶端到雲端的請求的預期效能。
- 我們從所有類型的設備的真實客戶收到資料。
- 所提出想法的有效性已被證明。
- 我們沒有冒險－我們沒有為客戶改變生產配置。
- 沒有任何東西被破壞。
現在談談困難的部分 - 我們將其投入生產
簡單的部分現在已經結束了——有一個工作原型了。 現在最困難的部分是為 Netflix 的所有流量推出解決方案，部署到 150 億用戶、數千台設備、數百個微服務以及不斷變化的產品和基礎設施。 Netflix 伺服器每秒接收數百萬個請求，不小心操作容易破壞服務。 同時，我們希望透過網路上數千個 CDN 伺服器動態路由流量，這些伺服器中的某些內容會在最不合時宜的時刻不斷變化和中斷。
而這一切，團隊有3名工程師負責系統的開發、部署和全面支援。
因此，我們將繼續談論安寧健康的睡眠。
如何繼續開發而不把所有時間都花在支援上？ 我們的方法基於三個原則：
- 我們減少了潛在的故障規模（爆炸半徑）。
- 我們正在為意外做好準備——儘管經過了測試和個人經驗，我們預計有些東西會被破壞。
- 優雅的降級——如果某些東西不能正常工作，它應該會自動修復，即使不是以最有效的方式。
事實證明，在我們的案例中，透過這種解決問題的方法，我們可以找到一個簡單有效的解決方案，並顯著簡化系統支援。 我們意識到我們可以為客戶端添加一小段程式碼並監視由連線問題引起的網路請求錯誤。 如果發生網路錯誤，我們會直接回退到雲端。 此解決方案不需要客戶團隊投入大量精力，但大大降低了我們意外故障和意外的風險。
當然，儘管有後退，我們在開發過程中仍然遵循明確的規則：
- 樣品測試。
- A/B 測試或金絲雀測試。
- 逐步推出。
透過範例，已經描述了該方法 - 首先使用定制的配方來測試更改。
對於金絲雀測試，我們需要獲得可比較的伺服器對，在這些伺服器上我們可以比較系統在更改之前和之後的工作情況。 為此，我們從許多 CDN 網站中選擇接收可比較流量的伺服器對：
然後我們在 Canary 伺服器上安裝更改後的版本。 為了評估結果，我們運行一個系統，將大約 100-150 個指標與控制伺服器樣本進行比較：
如果金絲雀測試成功，我們就會分批逐步發布。 我們不會同時更新每個網站上的伺服器 - 由於問題而失去整個網站對使用者服務的影響比在不同位置遺失相同數量的伺服器的影響更大。
一般來說，這種方法的有效性和安全性取決於收集的指標的數量和品質。 對於我們的查詢加速系統，我們從所有可能的元件收集指標：
- 來自客戶 - 會話和請求的數量、回退率；
- proxy－請求次數和時間的統計；
- DNS－請求的數量和結果；
- 雲端邊緣 - 在雲端處理請求的數量和時間。
所有這些都被收集到一個管道中，根據需要，我們決定將哪些指標發送到即時分析，將哪些指標發送到 Elasticsearch 或大數據以進行更詳細的診斷。
我們監控
在我們的例子中，我們正在對客戶端和伺服器之間請求的關鍵路徑進行更改。 同時，客戶端、伺服器上以及透過 Internet 傳輸的不同元件的數量是巨大的。 在數十個團隊的工作和生態系統的自然變化過程中，客戶端和伺服器上的變化不斷發生。 我們處於中間——在診斷問題時，我們很有可能參與其中。 因此，我們需要清楚地了解如何定義、收集和分析指標，以便快速隔離問題。
理想情況下，即時完全存取所有類型的指標和篩選器。 但指標很多，所以就出現了成本的問題。 在我們的例子中，我們將指標和開發工具分開如下：
為了檢測和分類問題，我們使用我們自己的開源即時系統 и - 用於可視化。 它將聚合指標儲存在記憶體中，可靠並與警報系統整合。 為了進行在地化和診斷，我們可以存取 Elasticsearch 和 Kibana 的日誌。 對於統計分析和建模，我們使用 Tableau 中的大數據和視覺化。
看來這種方法很難實施。 然而，透過分層組織指標和工具，我們可以快速分析問題，確定問題類型，然後深入了解詳細的指標。 一般來說，我們大約需要花1-2分鐘的時間來確定故障的根源。 此後，我們與特定團隊合作進行診斷 - 從幾十分鐘到幾個小時。
即使診斷很快完成，我們也不希望這種情況經常發生。 理想情況下，只有當服務受到重大影響時，我們才會收到嚴重警報。 對於我們的查詢加速系統，我們只有 2 個警報會通知：
- 客戶回退百分比 - 評估客戶行為；
- 探針錯誤百分比 - 網路組件的穩定性資料。
這些關鍵警報監視系統是否為大多數使用者運作。 我們會查看有多少客戶端在無法獲得請求加速時使用了回退。 儘管系統中發生了大量變化，但我們平均每週發出的嚴重警報少於 1 個。 為什麼這對我們來說就夠了？
- 如果我們的代理程式不起作用，則會有客戶端回退。
- 有一個自動轉向系統可以回應問題。
有關後者的更多詳細資訊。 我們的試用系統，以及自動確定客戶端請求到雲端的最佳路徑的系統，可以讓我們自動應對一些問題。
讓我們回到範例配置和 3 個路徑類別。 除了載入時間之外，我們還可以看看交付本身的事實。 如果無法載入數據，那麼透過查看不同路徑的結果，我們可以確定損壞的位置和內容，以及是否可以透過更改請求路徑來自動修復它。
Примеры：
這個過程可以自動化。 將其包含在轉向系統中。 並教導它響應性能和可靠性問題。 如果某些東西開始損壞，如果有更好的選擇，請做出反應。 同時，由於客戶的後備，立即反應並不重要。
因此，系統支持的原則可以表述為：
- 減少故障規模；
- 收集指標；
- 如果可以的話，我們會自動修復故障；
- 如果不能，我們會通知您；
- 我們正在開發儀表板和分類工具集以實現快速響應。
得到教訓
編寫原型並不需要太多時間。 就我們而言，4 個月後就準備好了。 有了它，我們收到了新的指標，在開發開始 10 個月後，我們收到了第一個生產流量。 然後繁瑣且非常困難的工作開始了：逐步產品化和規模化系統，遷移主要流量並從錯誤中學習。 然而，這個有效的過程不會是線性的——儘管盡一切努力，一切都無法預測。 快速迭代和響應新數據要有效得多。
根據我們的經驗，我們可以推薦以下內容：
- 不要相信你的直覺。
儘管我們的團隊成員經驗豐富，但我們的直覺總是讓我們失望。 例如，我們錯誤地預測了使用 CDN 代理的預期加速或 TCP 任播的行為。
- 從生產中獲取數據。
盡快存取至少少量的生產數據非常重要。 在實驗室條件下獲得獨特案例、配置和設置的數量幾乎是不可能的。 快速存取結果將使您能夠快速了解潛在問題並將其納入系統架構中。
- 不要聽從其他人的建議和結果 - 收集您自己的數據。
遵循收集和分析資料的原則，但不要盲目接受別人的結果和陳述。 只有您才能確切知道什麼對您的用戶有用。 您的系統和客戶可能與其他公司有很大不同。 幸運的是，現在有了分析工具並且易於使用。 您得到的結果可能與 Netflix、Facebook、Akamai 和其他公司聲稱的不同。 在我們的例子中，TLS、HTTP2 的效能或 DNS 請求的統計資料與 Facebook、Uber、Akamai 的結果不同 - 因為我們有不同的裝置、用戶端和資料流。
- 不必要地追隨時尚潮流並評估效果。
從簡單開始。 在短時間內製作一個簡單的工作系統比花費大量時間開發不需要的組件要好。 根據您的測量和結果解決重要的任務和問題。
- 為新的應用程式做好準備。
正如很難預測所有問題一樣，也很難提前預測其好處和應用。 向新創公司學習－他們適應客戶條件的能力。 就您而言，您可能會發現新問題及其解決方案。 在我們的專案中，我們設定了減少請求延遲的目標。 然而，在分析和討論過程中，我們意識到我們也可以使用代理伺服器：
- 平衡 AWS 區域之間的流量並降低成本；
- 對 CDN 穩定性進行建模；
- 配置 DNS；
- 配置 TLS/TCP。
結論
在報告中，我描述了Netflix如何解決加速客戶端和雲端之間的網路請求的問題。 我們如何使用客戶的採樣系統收集數據，並使用收集的歷史數據透過網路上最快的路徑路由客戶的生產請求。 我們如何利用網路協定的原理、我們的 CDN 基礎架構、骨幹網路和 DNS 伺服器來實現這項任務。
然而，我們的解決方案只是 Netflix 如何實施此類系統的一個範例。 什麼對我們有用。 我向大家報告的應用部分是我們遵循的發展原則和支持原則並且取得了良好的效果。
我們的問題解決方案可能不適合您。 然而，即使您沒有自己的 CDN 基礎設施，或者它與我們的基礎設施有很大不同，理論和設計原則仍然存在。
業務請求速度的重要性也仍然很重要。 即使是簡單的服務，您也需要做出選擇：在雲端提供者、伺服器位置、CDN 和 DNS 提供者之間。 您的選擇將影響您的客戶的網路查詢的有效性。 衡量和理解這種影響對你來說很重要。
從簡單的解決方案開始，關心你如何改變產品。 邊走邊學習，並根據來自客戶、基礎設施和業務的數據改進系統。 考慮設計過程中出現意外故障的可能性。 然後您就可以加快開發流程、提高解決方案效率、避免不必要的支援負擔並安然入睡。
今年 以線上格式。 您可以向 DevOps 之父之一約翰威利斯 (John Willis) 本人提問！
來源： www.habr.com