每個人都在談論開發和測試、培訓員工、提高積極性的流程，但當一分鐘的服務停機會花費大量資金時，這些流程還不夠。 當您在嚴格的 SLA 下進行金融交易時該怎麼辦？ 如何提高系統的可靠性和容錯能力，將開發和測試排除在外？
下一次 HighLoad++ 會議將於 6 年 7 月 2020 日至 XNUMX 日在聖彼得堡舉行。 詳情及門票 。 9 月 18 日 00:2018。 HighLoad++ 莫斯科 XNUMX、德里 + 加爾各答大廳。 論文和 .
葉夫根尼·庫佐夫列夫（Evgeniy Kuzovlev，以下簡稱“EC”）： - 朋友們，你們好！ 我的名字是庫佐夫列夫·葉夫根尼。 我來自 EcommPay 公司，具體部門是 EcommPay IT，該集團公司的 IT 部門。 今天我們將討論停機 - 如何避免停機，如何在無法避免的情況下盡量減少其後果。 主題如下：「當一分鐘的停機成本為 100 美元時該怎麼辦」？ 展望未來，我們的數字具有可比性。
EcommPay IT 是做什麼的？
我們是誰？ 我為什麼站在你面前？ 為什麼我有權利在這裡告訴你一些事情？ 我們將在這裡更詳細地討論什麼？
EcommPay 集團公司是國際收單機構。 我們在世界各地處理付款——俄羅斯、歐洲、東南亞（世界各地）。 我們設有 9 個辦事處，共有 500 名員工，其中約不到一半是 IT 專家。 我們所做的一切，從中賺錢的一切，都是我們自己做的。
我們自己編寫了所有產品（我們有相當多的產品 - 在我們的大型 IT 產品系列中，我們有大約 16 個不同的組件）； 我們自己寫作，自己發展。 目前，我們每天進行大約一百萬筆交易（數百萬筆可能是正確的說法）。 我們是一家相當年輕的公司——我們只有大約六年的歷史。
6年前，當這些人加入到這家公司時，這還是一家新創公司。 他們因一個想法而團結在一起（除了一個想法，別無他物），然後我們就跑了。 像任何新創公司一樣，我們跑得更快……對我們來說，速度比品質更重要。
在某個時刻，我們停了下來：我們意識到我們無法再以那樣的速度和品質生活，我們需要先專注於品質。 此時此刻，我們決定編寫一個正確、可擴展且可靠的新平台。 他們開始編寫這個平台（他們開始投資、開發開發、測試），但在某些時候他們意識到開發和測試並不能讓我們達到新的服務品質水準。
你製造了一種新產品，並將其投入生產，但仍然會在某個地方出現問題。 今天我們將討論如何達到新的品質水準（我們是如何做到的，關於我們的經驗），將開發和測試排除在外； 我們將討論操作可用的內容 - 操作本身可以做什麼，它可以為測試提供什麼以影響品質。
停機時間。 操作戒律。
始終是主要基石，我們今天實際上要討論的是停機時間。 一個可怕的字。 如果我們有停機時間，一切都會對我們不利。 我們正在跑去舉起它，管理員正在控制服務器 - 上帝保佑它不會掉落，正如他們在那首歌中所說的那樣。 這就是我們今天要講的內容。
當我們開始改變我們的方法時，我們制定了 4 條戒律。 我將它們呈現在幻燈片上：
這些誡命非常簡單：
- 快速找出問題所在。
- 更快地擺脫它。
- 幫助理解原因（稍後為開發人員提供）。
- 並標準化方法。
我想提請您注意第二點。我們正在消除問題，而不是解決問題。 決定是次要的。 對我們來說，首要的是保護使用者免受此問題的影響。 它會存在於某個孤立的環境中，但是這個環境不會和它有任何的連結。 其實我們會過一遍這四組問題（有的比較詳細，有的不太詳細），我會告訴你我們用了什麼，我們在解決方案方面有哪些相關經驗。
故障排除：它們何時發生以及如何處理？
但我們會亂序開始，我們將從第二點開始──如何快速解決問題？ 有一個問題——我們需要解決它。 “這件事我們該怎麼辦？” - 主要問題。 當我們開始考慮如何解決問題時，我們為自己制定了一些故障排除必須遵循的要求。
為了製定這些要求，我們決定問自己一個問題：「我們什麼時候會遇到問題」？ 事實證明，問題出現在四種情況：
- 硬體故障。
- 外部服務失敗。
- 更改軟體版本（相同部署）。
- 爆炸性負載成長。
我們不會談論前兩個。 硬體故障的解決方法非常簡單：必須複製所有內容。 如果這些是磁碟，則這些磁碟必須組裝在 RAID 中；如果這是伺服器，則必須複製該伺服器；如果您有網路基礎設施，則必須提供網路基礎設施的第二個副本，即，您將它並複製它。 如果發生故障，您可以切換到備用電源。 這裡很難再說什麼了。
二是外部服務失效。 對大多數人來說，系統根本不是問題，但對我們來說卻不是。 由於我們處理支付，因此我們是位於使用者（輸入卡資料）和銀行、支付系統（Visa、MasterCard、Mira 等）之間的聚合器。 我們的外部服務（支付系統、銀行）往往會失敗。 我們和您（如果您有此類服務）都無法影響這一點。
那該怎麼辦呢？ 這裡有兩個選擇。 首先，如果可以的話，您應該以某種方式複製此服務。 例如，如果可以的話，我們將流量從一項服務轉移到另一項服務：例如，卡是透過 Sberbank 處理的，Sberbank 遇到了問題 - 我們[有條件]將流量轉移到 Raiffeisen。 我們可以做的第二件事是非常快速地註意到外部服務的故障，因此我們將在報告的下一部分中討論回應速度。
事實上，在這四個方面，我們可以具體影響軟體版本的變化 - 採取行動，改善部署環境和負載爆炸性增長的情況。 事實上，我們就是這麼做的。 在這裡，再次，一個小註釋......
在這四個問題中，如果有云，其中有幾個問題可以立即解決。 如果您使用 Microsoft Azhur、Ozone 雲，或使用我們的 Yandex 或 Mail 雲，那麼至少硬體故障會成為他們的問題，並且在硬體故障的情況下，一切都會立即變得正常。
我們是一家有點不傳統的公司。 這裡每個人都在談論“Kubernets”，談論雲端——我們既沒有“Kubernets”，也沒有雲端。 但我們在許多資料中心都有硬體機架，我們被迫依賴這些硬體生活，我們被迫對這一切負責。 因此，我們將在這個背景下進行討論。 那麼，關於問題。 前兩項已從括號中取出。
更改軟體版本。 基地
我們的開發人員無法進入生產環境。 這是為什麼？ 只是我們是通過了PCI DSS認證的，我們的開發者根本就沒有進入「產品」的權利。 就是這樣，期間。 完全沒有。 因此，開發責任恰好在開發提交建置版本時結束。
我們擁有的第二個基礎，這也對我們有很大幫助，是缺乏獨特的未記錄的知識。 我希望你也一樣。 因為如果不是這樣的話，你就會遇到問題。 當這種獨特的、未記錄的知識沒有在正確的時間、正確的地點出現時，就會出現問題。 假設您有一個人知道如何部署特定組件 - 該人不在，他正在度假或生病 - 就是這樣，您遇到了問題。
這是我們所達到的第三個基礎。 我們經歷了痛苦、血和淚水才得出這個結論——我們得出的結論是，我們的任何構建都包含錯誤，即使它是沒有錯誤的。 我們自己決定了這一點：當我們部署某些東西時，當我們將某些東西投入生產時，我們的建置會出現錯誤。 我們已經形成了我們的系統必須滿足的要求。
更改軟體版本的要求
有三個要求：
- 我們必須迅速回滾部署。
- 我們必須盡量減少部署不成功的影響。
- 而且我們必須能夠快速並行部署。
完全按照這個順序！ 為什麼？ 因為，首先，在部署新版本時，速度並不重要，重要的是對你來說，如果出現問題，能夠快速回滾並將影響降到最低。 但是，如果您在生產中有一組版本，結果發現存在錯誤（突然沒有部署，但存在錯誤） - 後續部署的速度對您很重要。 為了滿足這些需求，我們做了什麼？ 我們採用了以下方法：
這是眾所周知的，我們從未發明過它 - 這是藍/綠部署。 這是什麼？ 您必須為安裝了應用程式的每組伺服器擁有一份副本。 該副本是「熱」的：其上沒有流量，但任何時候該流量都可以發送到該副本。 該副本包含先前的版本。 在部署時，您將程式碼部署到非活動副本。 然後將部分（或全部）流量切換到新版本。 因此，為了將流量從舊版本更改為新版本，您只需要執行一項操作：您需要更改上游的平衡器，更改方向 - 從一個上游到另一個上游。 這樣非常方便，解決了快速切換和快速回滾的問題。這裡第二個問題的解決方案是最小化：您可以僅將部分流量發送到新線路，即具有新代碼的線路（例如，2%）。 而這2%並不是100%！ 如果你因為部署不成功而損失了 100% 的流量，那很可怕；如果你損失了 2% 的流量，那雖然令人不快，但並不可怕。 此外，使用者很可能甚至不會注意到這一點，因為在某些情況下（並非全部），同一使用者按 F5 將被帶到另一個工作版本。
藍/綠部署。 路由
然而，並非一切都那麼簡單「藍/綠部署」...我們所有的元件都可以分為三組：
- 這是前端（我們的客戶看到的付款頁面）；
- 處理核心；
- 用於支付系統（銀行、MasterCard、Visa...）的適配器。
這裡有一個細微差別 - 細微差別在於線路之間的路由。 如果你只是切換 100% 的流量，就不會有這些問題。 但如果你想轉換 2%，你就會開始問問題：“如何做到這一點？” 最簡單的事情很簡單：你可以透過隨機選擇在nginx中設定循環，你有2%在左邊，98%在右邊。 但這並不總是合適的。
例如，在我們的範例中，使用者透過多個請求與系統進行互動。 這是正常的：2、3、4、5 個請求 - 您的系統可能相同。 如果對您來說重要的是所有使用者的請求都到達第一個請求所在的同一行，或者（第二點）所有使用者的請求都到達切換後的新行（他可以更早開始使用系統，切換之前），-那麼這個隨機分佈不適合你。 然後有以下選項：
第一個選項是最簡單的，基於客戶端的基本參數（IP 哈希）。 你有一個IP，你把它從右到左除以IP位址。 那麼我所描述的第二種情況將適合您，當部署發生時，使用者已經可以開始使用您的系統，並且從部署那一刻起，所有請求都將轉到一個新行（例如，到同一行）。如果由於某種原因這不適合您，並且您必須將請求發送到用戶最初的初始請求所在的行，那麼您有兩個選擇...
第一個選擇：你可以購買付費的 nginx+。 有一種黏性會話機制，根據使用者的初始請求，為使用者指派一個會話並將其綁定到一個或另一個上游。 會話生命週期內的所有後續使用者請求都會傳送到會話發布的同一上游。這不適合我們，因為我們已經有了常規的 nginx。 切換到 nginx+ 並不是因為它很貴，而是它對我們來說有點痛苦，而且不太對勁。 例如，「Sticks Sessions」對我們不起作用，原因很簡單，「Sticks Sessions」不允許基於「非此即彼」的路由。 在那裡，您可以指定我們「Sticks Sessions」做什麼，例如，透過 IP 位址或透過 IP 位址和 cookie 或透過後參數，但「非此即彼」在那裡更複雜。
因此，我們來到了第四種選擇。 我們對 nginx 進行了升級（這是 openresty）——這是同一個 nginx，它還支援包含最後的腳本。 你可以編寫最後一個腳本，給它一個“開放休息”，當用戶請求到來時，最後一個腳本將被執行。
事實上，我們編寫了這樣一個腳本，將自己設定為“openresti”，在這個腳本中我們透過連接“Or”對 6 個不同的參數進行排序。 根據一個或另一個參數的存在，我們知道使用者來到了一頁或另一頁、一行或另一行。
藍/綠部署。 的優點和缺點
當然，可能可以讓它變得更簡單（使用相同的“粘性會話”），但我們也有這樣的細微差別，即不僅用戶在一筆交易的一次處理的框架內與我們交互......但支付系統也會與我們互動：在我們處理交易（透過向支付系統發送請求）後，我們會收到一個冷卻。
比方說，如果在我們的電路內部，我們可以在所有請求中轉發用戶的IP 位址，並根據IP 位址劃分用戶，那麼我們就不會告訴相同的「Visa」：「夥計，我們是一家如此復古的公司，我們似乎為了國際化（在網站上和在俄羅斯）...請在附加欄位中向我們提供用戶的 IP 位址，您的協議是標準化的」！ 很明顯，他們不會同意。
因此，這對我們不起作用——我們做了 openresty。 因此，透過路由，我們得到了這樣的結果：因此，藍/綠部署有我提到的優點和缺點。
兩個缺點：
- 你需要費心去處理路由；
- 第二個主要缺點是費用。
你需要兩倍的伺服器，你需要兩倍的營運資源，你需要花費兩倍的精力來維護整個動物園。
順便說一句，在這些優點中，還有一件事是我之前沒有提到的：您可以為負載成長做好準備。 如果您的負載呈爆炸式增長，您擁有大量用戶，那麼您只需將第二行包含在50 到50 的分佈中- 您的集群中就會立即擁有x2 伺服器，直到您解決擁有更多伺服器的問題。
如何快速部署？
我們討論瞭如何解決最小化和快速回滾的問題，但問題仍然是：“如何快速部署？”
這裡簡短而簡單。- 您必須有一個 CD 系統（持續交付）——沒有它您就無法生存。 如果您有一台伺服器，則可以手動部署。 我們有大約一千個半千個伺服器和一個半千個手柄，當然 - 我們可以建立一個像這個房間大小的部門來部署。
- 部署必須是並行的。 如果您的部署是順序的，那麼一切都會很糟糕。 一台伺服器很正常，你一整天都會部署一千台伺服器。
- 同樣，對於加速來說，這可能不再是必要的。 在部署期間，通常會建置專案。 你有一個 web 項目，有一個前端部分（你在那裡做一個 web pack，你編譯 npm - 類似的東西），這個過程原則上是短暫的 - 5 分鐘，但這 5 分鐘可以保持批判性。 例如，這就是為什麼我們不這樣做：我們刪除了這 5 分鐘，我們部署了工件。
什麼是神器？ 工件是一個組裝的構建，其中所有組裝部件都已完成。 我們將此工件儲存在工件儲存中。 我們曾經使用過兩個這樣的儲存空間——它是Nexus，現在是jFrog Artifactory。我們最初使用「Nexus」是因為我們開始在java應用程式中實踐這種方法（它非常適合）。 然後他們把一些用PHP寫的應用程式放在那裡； 而「Nexus」已經不合適了，因此我們選擇了jFrog Artefactory，它幾乎可以人工化所有東西。 我們甚至已經達到這樣的程度：在這個工件儲存庫中，我們儲存我們為伺服器收集的自己的二進位套件。
爆炸性負載成長
我們討論了更改軟體版本。 接下來我們面臨的是負載的爆炸性增加。 在這裡，我的意思可能是負載的爆炸性增長並不完全正確...
我們寫了一個新系統——它是面向服務的、時尚的、漂亮的、到處都是工人、到處排隊、到處非同步。 在這樣的系統中，資料可以流經不同的流。 對於第一個事務，可以使用第 1 個、第 3 個、第 10 個工作人員，對於第二個事務，可以使用第 2 個、第 4 個、第 5 個工作人員。 今天，假設早上你有一個使用前三個工作人員的資料流，到了晚上它發生了巨大的變化，一切都使用了其他三個工作人員。
事實證明，您需要以某種方式擴展工作人員，您需要以某種方式擴展您的服務，但同時防止資源膨脹。
我們已經定義了我們的要求。 這些要求非常簡單：服務發現、參數化——建構這種可擴展系統的一切都是標準的，除了一點——資源折舊。 我們說過，我們還沒有準備好攤銷資源，以便伺服器加熱空氣。 我們選擇了“Consul”，我們選擇了“Nomad”，它管理我們的工人。為什麼這對我們來說是一個問題？ 讓我們回顧一下。 我們現在擁有大約 70 個支付系統。 例如，早上，流量通過 Sberbank，然後 Sberbank 崩潰了，我們將其切換到另一個支付系統。 在 Sberbank 之前我們有 100 名員工，之後我們需要為另一個支付系統大幅增加 100 名員工。 所有這一切都希望在沒有人類參與的情況下發生。 因為如果有人參與，就應該有一名工程師 24/7 坐在那兒，他只應該做這件事，因為當你身後有 70 個系統時，這種故障會經常發生。
因此，我們研究了具有開放IP的Nomad，並編寫了我們自己的東西，Scale-Nomad - ScaleNo，它大致執行以下操作：它監視隊列的增長並根據動態減少或增加工作人員的數量隊列的。 當我們這樣做時，我們想：“也許我們可以開源它？” 然後他們看著她——她就像兩個戈比一樣簡單。
到目前為止我們還沒有開源它，但是如果在報告之後突然意識到你需要這樣的東西，你需要它，我的聯繫方式在最後一張幻燈片中 - 請寫信給我。 如果有至少3-5人，我們將贊助。
怎麼運作的？ 我們來看看吧！ 展望未來：左邊有一塊我們的監控：這是一行，上面是事件處理的時間，中間是交易的數量，下面是worker的數量。如果你看一下，這張照片有個小問題。 在最上面的圖表中，其中一張圖表在 45 秒內崩潰了——其中一個支付系統出現故障。 立即，流量在 2 分鐘內引入，佇列開始在另一個支付系統上成長，那裡沒有工作人員（我們沒有利用資源 - 相反，我們正確地處置了資源）。 我們不想供暖——人數很少，大約 5-10 名工人，但他們無法應付。
最後一張圖顯示了一個“駝峰”，這意味著“Skaleno”使這個數量增加了一倍。 然後，當圖表下降一點時，他就減少一點——工人的數量會自動改變。 這就是這個東西的工作原理。 我們討論了第二點——「如何快速擺脫原因」。
監控。 如何快速找出問題所在？
現在第一點是“如何快速識別問題？” 監控！ 我們必須快速了解某些事情。 哪些事情我們該快速理解？
三件事！- 我們必須快速了解並了解我們自身資源的表現。
- 我們必須快速了解故障並監控外部系統的效能。
- 第三點是識別邏輯錯誤。 這是當系統為您工作時，根據所有指標一切正常，但出現問題。
我可能不會在這裡告訴你任何很酷的事情。 我將成為明顯隊長。 我們尋找市場上有什麼。 我們有一個“有趣的動物園”。 這就是我們現在擁有的動物園：
我們使用Zabbix來監控硬件，監控伺服器的主要指標。 我們使用 Okmeter 作為資料庫。 我們將“Grafana”和“Prometheus”用於所有不適合前兩個的其他指標，有些使用“Grafana”和“Prometheus”，有些使用“Grafana”與“Influx”和Telegraf。一年前我們想用 New Relic。 很酷的東西，它可以做一切。 但儘管她能做一切，她卻是如此昂貴。 當我們的伺服器數量增長到 1,5 台時，一家供應商找到我們說：“讓我們簽訂明年的協議。” 我們看了價格，說不，我們不會這樣做。 現在我們正在放棄New Relic，我們還有大約15台伺服器處於New Relic的監控之下。 結果證明這個價格絕對是瘋狂的。
我們自己實作了一個工具 - 這就是調試器。 起初我們叫它“Bagger”，但後來一位英文老師經過，哈哈大笑，把它改名為“Debagger”。 這是什麼？ 事實上，這個工具可以在 15-30 秒內對每個組件進行測試，就像系統的「黑盒子」一樣，對組件的整體性能進行測試。
例如，如果有一個外部頁面（付款頁面），他只需打開它並查看它應該是什麼樣子。 如果正在處理，他會發送測試“交易”並確保該“交易”到達。 如果這是與支付系統的連接，我們會在可能的情況下相應地發出測試請求，並確保一切正常。
哪些指標對於監控很重要？
我們主要監控什麼？ 哪些指標對我們來說很重要？
- 前端的反應時間/RPS是一個非常重要的指標。 他立即回答說你有問題。
- 所有佇列中已處理的訊息數。
- 工人數量。
- 基本正確性指標。
最後一點是“業務”，“業務”指標。 如果你想監控同樣的事情，你需要定義一兩個指標作為你的主要指標。 我們的指標是吞吐量（這是成功交易數量與總交易流量的比率）。 如果它每隔 5-10-15 分鐘發生變化，就意味著我們遇到了問題（如果變化劇烈）。
對我們來說，這是我們的一個董事會的範例：
左側有 6 個圖表，這是根據線條排列的 - 工作人員數量和隊列中的消息數量。 右側 - RPS、RTS。 以下是相同的「業務」指標。 在「業務」指標中，我們可以立即看到中間的兩個圖表出了問題……這只是我們身後另一個已經崩潰的系統。我們要做的第二件事是監控外部支付系統的崩潰。 在這裡，我們採用了 OpenTracing——一種允許您追蹤分散式系統的機制、標準、範例； 它被改變了一點。 標準 OpenTracing 範例表示，我們為每個單獨的請求建立追蹤。 我們不需要這個，我們將它包裝在摘要、聚合追蹤中。 我們製作了一個工具，可以讓我們追蹤我們身後系統的速度。
該圖向我們顯示，其中一個支付系統在 3 秒內開始回應 - 我們遇到了問題。 而且，這個東西在出現問題的時候就會做出反應，間隔20-30秒。存在的第三類監控錯誤是邏輯監控。
說實話，我不知道在這張投影片上畫什麼，因為我們長期以來一直在市場上尋找適合我們的東西。 我們沒有找到任何東西，所以我們必須自己做。
邏輯監控是什麼意思？ 好吧，想像一下：您為自己創建了一個系統（例如，Tinder 克隆）； 你成功了，啟動了它。 成功的經理Vasya Pupkin 將其放在手機上，看到那裡有一個女孩，喜歡她......但喜歡的人不會發給那個女孩- 喜歡的人會發給來自同一商務中心的保安Mikhalych。 經理下樓，然後納悶：“為什麼這個保安米哈雷奇對他笑得那麼愉快？”在這種情況下……對我們來說，這種情況聽起來有點不同，因為（我寫道）這是一種聲譽損失，間接導致經濟損失。 我們的情況恰恰相反：我們可能會遭受直接的經濟損失——例如，如果我們進行了一筆交易，本來是成功的，但實際上卻不成功（反之亦然）。 我必須編寫自己的工具，使用業務指標追蹤一段時間內成功交易的數量。 市場上沒找到東西！ 這正是我想要傳達的想法。 市場上沒有任何東西可以解決此類問題。
這是關於如何快速識別問題的問題。
如何確定部署原因
我們解決的第三組問題是，當我們發現問題之後，解決掉它之後，最好了解原因，然後去開發，去測試，然後做一些事情。 因此，我們需要調查，我們需要提出日誌。
如果我們談論日誌（主要原因是日誌），我們的大部分日誌都在 ELK Stack 中 - 幾乎每個人都有相同的日誌。 對某些人來說，可能不在ELK中，但如果你寫千兆位元組的日誌，那麼遲早你會來到ELK。 我們以 TB 為單位編寫它們。
這裡有問題。 我們修復了它，為用戶糾正了錯誤，開始挖掘那裡的東西，爬進 Kibana，在那裡輸入交易 ID，並得到像這樣的腳布（顯示了很多）。 這塊腳布中絕對沒有任何東西是透明的。 為什麼？ 是的，因為不清楚哪個部分屬於哪個worker，哪個部分屬於哪個元件。 在那一刻，我們意識到我們需要追蹤 - 就是我談到的 OpenTracing。一年前我們就想到了這一點，把注意力轉向市場，那裡有兩個工具——「Zipkin」和「Jaeger」。 「Jager」其實就是這樣一個思想繼承者，「Zipkin」的思想繼承者。 Zipkin 中的一切都很好，除了它不知道如何聚合，它不知道如何在追蹤中包含日誌，只有時間追蹤。 「Jager」也支持這一點。
我們研究了“Jager”：你可以檢測應用程序，你可以用 Api 編寫（然而，當時 PHP 的 Api 標準尚未獲得批准 - 這是一年前的事，但現在它已經獲得批准），但是絕對沒有客戶。 「好吧，」我們想，並寫信給我們自己的客戶。 我們得到了什麼？ 大概是這樣的：
在 Jaeger 中，為每個訊息建立 Span。 也就是說，當使用者開啟系統時，對於每個傳入請求，他會看到一兩個區塊（1-2-3 - 來自使用者的傳入請求數，區塊數）。 為了方便用戶，我們在日誌和時間追蹤中添加了標籤。 因此，如果出現錯誤，我們的應用程式將使用適當的錯誤標籤來標記日誌。 您可以按錯誤標籤進行過濾，並且僅顯示包含此錯誤區塊的範圍。 如果我們擴大跨度，就會是這樣的：
跨度內有一組痕跡。 在本例中，這是三個測試跟踪，第三個跟踪告訴我們發生了錯誤。 同時，這裡我們看到一個時間軌跡：頂部有一個時間刻度，我們可以看到這個或那個日誌被記錄的時間間隔。因此，我們的一切進展順利。 我們編寫了自己的擴充並將其開源。 如果你想使用跟踪，如果你想在 PHP 中使用“Jager”，有我們的擴展，歡迎使用，正如他們所說：
我們有這個擴充功能 - 它是 OpenTracing Api 的客戶端，它是作為 php 擴充功能製作的，也就是說，您需要組裝它並將其安裝在系統上。 一年前沒有什麼不同。 現在還有其他類似組件的客戶端。 這取決於你：要么你用作曲家抽出組件，要么你使用擴展。企業標準
我們討論了三誡。 第四誡是標準化方法。 這是關於什麼的？ 是關於這個的：
為什麼這裡要用「公司」這個詞呢？ 不是因為我們是一家大公司或官僚公司，不！ 我想在這裡使用「公司」這個詞，因為每個公司、每個產品都應該有自己的標準，包括你。 我們有什麼標準？
- 我們有部署規定。 沒有他，我們哪裡也去不了，我們不能。 我們每週部署大約 60 次，也就是說，我們幾乎不間斷地部署。 同時，例如，我們在部署法規中對週五部署有一個禁忌 - 原則上我們不進行部署。
- 我們需要文件。 如果沒有相關文檔，任何新組件都不會投入生產，即使它是在我們的研發專家的筆下誕生的。 我們需要他們提供部署說明、監控圖以及該元件如何運作以及如何對其進行故障排除的粗略描述（好吧，正如程式設計師可以編寫的那樣）。
- 我們解決的不是問題的原因，而是問題本身──我已經說過了。 對我們來說，保護使用者免受問題困擾非常重要。
- 我們有許可。 例如，如果我們在兩分鐘內丟失了 2% 的流量，我們不會將其視為停機。 這基本上不包含在我們的統計中。 如果百分比更高或是暫時的，我們已經算了。
- 我們總是寫事後分析。 無論我們發生什麼，任何人在生產中表現異常的情況都會反映在事後分析中。 事後剖析是一份文件，其中寫下發生在您身上的事情、詳細的時間安排、您採取的糾正措施以及（這是強制性的！）您將採取哪些措施來防止將來發生這種情況。 這是強制性的，也是後續分析所必需的。
什麼被視為停機？
這一切導致了什麼？這導致了這樣一個事實：（我們在穩定性方面遇到了一些問題，這對客戶和我們都不適合）在過去的 6 個月裡我們的穩定性指標是 99,97。 可以說，這並不是很多。 是的，我們有一些值得努力的事情。 在這個指標中，大約有一半是穩定性，可以說，不是我們的穩定性，而是我們的Web應用防火牆的穩定性，它站在我們面前，作為服務使用，但客戶並不關心這一點。
我們學會了晚上睡覺。 最後！ 六個月前我們還不能。 在這篇有結果的註解上，我想做一個註解。 昨晚有一篇關於核反應器控制系統的精彩報導。 如果編寫這個系統的人能聽到我的話，請忘記我所說的「2% 不是停機時間」。 對您來說，2% 是停機時間，即使是兩分鐘！
就這樣！ 你的問題。
關於平衡器和資料庫遷移
觀眾提問（以下簡稱 - B）： - 晚上好。 非常感謝您提供這樣的管理報告！ 關於平衡器的一個簡短問題。 你提到你有一個WAF，也就是說，據我了解，你使用某種外部平衡器...
知識庫： – 不，我們將我們的服務用作平衡器。 在這種情況下，WAF對我們來說只是一個DDoS防護工具。
在： – 能簡單介紹一下平衡器嗎？
知識庫： – 正如我已經說過的，這是 openresty 中的一組伺服器。 我們現在有 5 個專門回應的保留群組...也就是說，專門運行 openresty 的伺服器，它只代理流量。 因此，要了解我們持有多少：我們現在有數百兆位元的常規流量。 他們應付自如，感覺良好，甚至不給自己太大壓力。
在： ——也是一個簡單的問題。 這是藍/綠部署。 例如，您如何進行資料庫遷移？
知識庫： - 好問題！ 看，在藍/綠部署中，我們為每條線路都有單獨的隊列。 也就是說，如果我們談論從工作程序傳輸到工作程序的事件佇列，則藍線和綠線有單獨的佇列。 如果我們談論的是資料庫本身，那麼我們故意盡可能地縮小範圍，將所有內容實際上移到佇列中；在資料庫中，我們只儲存一堆交易。 我們的事務堆疊對於所有行都是相同的。 對於這種情況下的資料庫：我們不會將其分為藍色和綠色，因為兩個版本的程式碼都必須知道事務發生了什麼。
朋友們，我還有一個小獎品可以激勵你們──一本書。 我應該獲得最佳問題獎。
在： - 你好。 感謝您的報告。 問題是這樣的。 您可以監控付款，可以監控與之通信的服務...但是，如何進行監控，以便某人以某種方式來到您的付款頁面，進行付款，並且該項目將錢記入他的貸方？ 也就是說，您如何監控行銷人員是否有空並已接受您的回電？
知識庫： – 在這種情況下，「商家」對我們來說是與支付系統完全相同的外部服務。 我們監控商家的反應速度。
關於資料庫加密
在： - 你好。 我有一個稍微相關的問題。 您擁有 PCI DSS 敏感資料。 我想知道如何將 PAN 儲存在需要傳輸到的佇列中？ 你使用任何加密嗎？ 這就引出了第二個問題：根據 PCI DSS，有必要在發生變化（管理員被解僱等）時定期重新加密資料庫 - 在這種情況下，可訪問性會發生什麼？
知識庫： - 好問題！ 首先，我們不將 PAN 儲存在佇列中。 原則上，我們無權以明確的形式將 PAN 儲存在任何地方，因此我們使用一種特殊的服務（我們稱之為「Kademon」）——該服務只做一件事：接收訊息作為輸入並發送輸出一條加密訊息。 我們用這個加密訊息儲存所有內容。 因此，我們的密鑰長度低於千字節，因此這是嚴肅可靠的。在： – 您現在需要 2 KB 嗎？
知識庫： – 好像就在昨天，還是 256...那麼，還有哪裡呢？！
因此，這是第一個。 其次，現有的解決方案支援重新加密過程 - 有兩對「keks」（金鑰），它們提供了加密的「decks」（key 是金鑰，dek 是加密金鑰的派生物） 。 如果啟動該程式（定期發生，從 3 個月到±一些），我們會下載一對新的“蛋糕”，並重新加密資料。 我們有單獨的服務，可以刪除所有資料並以新的方式對其進行加密； 資料儲存在加密金鑰的識別碼旁邊。 因此，一旦我們使用新密鑰加密數據，我們就會刪除舊密鑰。
有時需要手動付款...
在： – 也就是說，如果某些操作退款到了，你還會用舊金鑰解密嗎？
知識庫： - 是的。
在： ——然後還有一個小問題。 當發生某種故障、跌倒或事件時，需要手動推送交易。 有這樣一種情況。
知識庫： - 是的，有時。
在： – 您從哪裡取得這些資料？ 或者你自己去這個儲存設施嗎？
知識庫： – 不，當然，我們有某種後台系統，其中包含支援我們的介面。 如果我們不知道交易處於什麼狀態（例如，直到支付系統回應逾時），我們就無法知道先驗，也就是說，我們只能完全放心地分配最終狀態。 在這種情況下，我們將事務分配到特殊狀態以進行手動處理。 第二天早上，一旦支援人員收到支付系統中保留此類交易的訊息，他們就會在此介面中手動處理它們。
在： - 我有一些問題。 其中之一是 PCI DSS 區域的延續：如何記錄他們的電路？ 這個問題是因為開發人員可以在日誌中放入任何內容！ 第二個問題：如何推出修補程式？ 在資料庫中使用句柄是一種選擇，但可能有免費的修補程式 - 那裡的過程是什麼？ 而第三個問題可能與RTO、RPO有關。 您的可用性是99,97，幾乎是四個XNUMX，但據我了解，您有第二個資料中心、第三個資料中心和第五個資料中心...您如何同步它們、複製它們以及其他所有內容？知識庫： - 讓我們從第一個開始。 第一個問題是關於日誌的嗎？ 當我們寫入日誌時，我們有一個屏蔽所有敏感資料的層。 她看著面具和附加字段。 因此，我們的日誌中包含已屏蔽的資料和 PCI DSS 電路。 這是分配給測試部門的常規任務之一。 他們需要檢查每項任務，包括他們編寫的日誌，這是程式碼審查期間的常規任務之一，以控制開發人員沒有寫下任何內容。 資訊安全部門大約每周定期進行一次後續檢查：選擇性地獲取最後一天的日誌，並透過測試伺服器上的特殊掃描分析儀運行這些日誌來檢查所有內容。
關於熱修復。 這包含在我們的部署法規中。 我們有一個關於修補程序的單獨條款。 我們相信，我們會在需要時全天候部署修補程式。 一旦版本組裝完畢，一旦運行，一旦我們有了工件，我們就會有一名系統管理員在接到支援電話後值班，他會在需要時部署它。關於「四個九」。 我們現在的這個數字已經真正達到了，我們在另一個資料中心爭取到了。 現在我們有了第二個資料中心，我們開始在它們之間進行路由，跨資料中心複製的問題確實是一個不小的問題。 我們曾經嘗試使用不同的方法來解決這個問題：我們嘗試使用相同的“狼蛛” - 它對我們來說沒有成功，我會立即告訴你。 這就是為什麼我們最終手動訂購“sens”。 事實上，我們系統中的每個應用程式都在資料中心之間非同步運行必要的「更改完成」同步。
在： – 如果你得到了第二個，為什麼不得到第三個？ 因為還沒有人有裂腦…
知識庫： – 但我們沒有裂腦。 由於每個應用程式都是由多主機驅動的，因此請求來自哪個中心對我們來說並不重要。 我們已經準備好接受這樣一個事實：如果我們的一個資料中心發生故障（我們依賴於此）並且在使用者請求切換到第二個資料中心的過程中，我們實際上已經準備好失去該使用者； 但這些將是單位，絕對單位。
在： - 晚安. 感謝您的報告。 您談到了調試器，它在生產中運行一些測試事務。 但請告訴我們有關測試交易的資訊！ 它有多深？
知識庫： – 它經歷整個組件的完整週期。 對於元件來說，測試事務和生產事務之間沒有區別。 但從邏輯角度來看，這只是系統中的一個單獨項目，僅執行測試事務。
在： -你在哪裡把它剪掉？ 這裡核心發送...
知識庫： – 在這種情況下，我們落後於“Kor”進行測試交易...我們有一個路由這樣的東西：“Kor”知道要發送到哪個支付系統- 我們發送到一個假支付系統，該系統只是提供一個http訊號並且就這樣。
在： – 請告訴我，您的應用程式是用一個巨大的整體編寫的，還是將其分割成一些服務甚至微服務？
知識庫： – 我們沒有一個整體，當然，我們有一個服務導向的應用程式。 我們開玩笑說我們的服務是由單體組成的——它們確實非常大。 很難將其稱為微服務，但這些是分散式機器的工作人員在其中運行的服務。
如果伺服器上的服務受到損害...
在： – 那我有下一個問題。 即使它是一個整體，您仍然說您擁有許多這樣的即時伺服器，它們基本上都處理數據，問題是：“如果其中一個即時伺服器或應用程式遭到破壞，任何單獨的鏈接，他們有某種訪問控制嗎？ 他們誰能做什麼？ 我應該聯繫誰以獲取什麼資訊？
知識庫： - 當然是。 安全要求相當嚴格。 首先，我們有開放的資料流動，而連接埠只是我們事先預測流量流動的連接埠。 如果組件透過 5-4-3-2 與資料庫（例如與 Muskul）通信，則只有 5-4-3-2 對其開放，其他連接埠和其他流量方向將不可用。 此外，您需要了解，在我們的生產中大約有 10 個不同的安全環路。 即使應用程式以某種方式受到損害（上帝保佑），攻擊者也將無法存取伺服器管理控制台，因為這是一個不同的網路安全區域。在： – 在這種情況下，對我來說更有趣的是，你與服務簽訂了某些合約- 他們可以做什麼，透過什麼「行動」他們可以相互聯繫......並且在正常流程中，一些特定的服務需要一些行，另一行是「操作」列表。 在正常情況下，他們似乎不會求助於其他人，而且他們還有其他職責。 如果其中一個受到損害，是否能夠破壞該服務的「操作」？...
知識庫： - 我明白。 如果在正常情況下完全允許與另一台伺服器進行通信，那麼是的。 根據 SLA 合同，我們不會監控您只被允許前 3 個“操作”，並且不允許您執行後 4 個“操作”。 這對我們來說可能是多餘的，因為原則上我們已經有一個四級電路保護系統。 我們更喜歡用輪廓來保護自己，而不是在內部。
Visa、MasterCard 和 Sberbank 如何運作
在： – 我想澄清有關將使用者從一個資料中心切換到另一個資料中心的一點。 據我所知，Visa和MasterCard使用8583二進制同步協定進行操作，並且有混合的情況。 我想知道，現在我們的意思是轉換 - 是直接“Visa”和“MasterCard”還是在支付系統之前、處理之前？
知識庫： - 這是混音之前的情況。 我們的混音位於同一個資料中心。
在： – 粗略地說，你們有一個連結點嗎？
知識庫： – “Visa” 和 “MasterCard” – 是的。 原因很簡單，例如，維薩卡和萬事達卡需要對基礎設施進行大量投資才能簽訂單獨的合約以獲得第二對混合卡。 它們被保留在一個數據中心內，但如果上帝保佑，我們的混合連接 Visa 和 MasterCard 的數據中心死掉了，那麼我們將失去與 Visa 和 MasterCard 的連接......
在： – 如何保留？ 我知道Visa原則上只允許一次轉接！
知識庫： – 他們自己提供設備。 無論如何，我們收到的設備內部完全冗餘。
在： – 所以這個展台是他們的 Connects Orange 的？..
知識庫： - 是的。
在： – 但這個案例呢：如果你的資料中心消失了，你要如何繼續使用它？ 還是交通就停止了？
知識庫： - 不。 在這種情況下，我們只需將流量切換到另一個管道，這自然對我們來說會更貴，對我們的客戶來說也會更貴。 但流量不會透過我們直接連接Visa、MasterCard，而是透過有條件的Sberbank（很誇張）。
如果我冒犯了俄羅斯聯邦儲蓄銀行的員工，我深感抱歉。 但根據我們的統計，在俄羅斯銀行中，俄羅斯聯邦儲蓄銀行跌幅最大。 俄羅斯聯邦儲蓄銀行每個月都會出事。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com