Привет！
我叫 Mikhail，是 Sportmaster 公司的 IT 副總監。我想分享我們如何應對大流行期間出現的挑戰的故事。
在新現實的第一天，Sportmaster 通常的線下交易格式凍結了，我們線上管道的負載（主要是送貨到客戶地址方面）增加了 10 倍。在短短幾週內，我們將龐大的線下業務轉變為線上業務，並根據客戶的需求調整服務。
基本上，我們的副業變成了我們的核心業務。每個線上訂單的重要性都大大增加。有必要節省客戶為公司帶來的每一盧布。
為了快速回應客戶請求，我們在公司總部開設了一個額外的聯絡中心，現在每周可以接到約 285 通電話。同時，我們將 270 家商店轉移到新的非接觸式安全營運模式，使顧客能夠收到訂單，員工也能夠維持工作。
在轉型過程中，我們主要遇到兩個問題。首先，我們線上資源的負載顯著增加（謝爾蓋將告訴您我們如何處理這個問題）。其次，罕見的（新冠疫情之前）操作的流量增加了很多倍，這反過來又需要大量的快速自動化。為了解決這個問題，我們必須快速地從原來的主力區域轉移資源。埃琳娜會告訴你我們是如何處理這個問題的。
網上服務運作
Kolesnikov Sergey，負責線上商店和微服務的運營
從我們的零售店開始對訪客關閉的那一刻起，我們就開始記錄用戶數量、應用程式中下的訂單數量以及應用程式請求數量等指標的增長。
18月31日至XNUMX月XNUMX日訂單數線上支付微服務請求數網站下的訂單數量
在第一張圖中，我們看到增加了大約 14 倍，在第二張圖中，增加了 4 倍。我們認為應用程式的回應時間指標最具指示性。
在這張圖中，我們看到了前沿和應用程式的回應，並且我們自己確定我們沒有註意到任何成長。
這主要是因為我們在2019年底就開始了準備工作。現在我們的服務是預留的，在實體伺服器、虛擬化系統、docker以及裡面的服務層面保證容錯。同時，我們伺服器資源的容量使我們能夠承受多種負載。
在整個故事中幫助我們的主要工具是我們的監控系統。確實，直到最近，我們還沒有一個單一的系統可以讓我們收集所有層面的指標，從實體設備和硬體層級到業務指標層級。
正式上，公司內部有監控，但通常是分散的，並且屬於特定部門的職責範圍。事實上，當事件發生時，我們幾乎從來沒有對到底發生了什麼有共同的理解，沒有溝通，這常常導致繞圈尋找和隔離問題以便解決。
在某些時候，我們認為並決定我們已經受夠了——我們需要一個統一的系統來全面了解整個情況。我們的堆疊中包含的主要技術包括作為警報和指標儲存中心的Zabbix、用於收集和儲存應用程式指標的Prometheus、用於記錄和儲存整個監控系統資料的Stack ELK，以及用於視覺化的Grafana、Swagger 、Docker以及其他有用的和您熟悉的東西。
同時，我們不僅使用市場上現有的技術，也開發一些我們自己的技術。例如，我們提供用於系統相互整合的服務，即某種用於收集指標的 API。另外，我們正在開發自己的監控系統 - 在業務指標層面，我們使用 UI 測試。 Telegram 中還有一個用來通知團隊的機器人。
我們也試圖讓團隊可以存取監控系統，以便他們可以獨立儲存和使用他們的指標，包括為一些未廣泛使用的狹窄指標設定警報。
在整個系統中，我們力求盡快主動並定位事件。另外，我們的微服務和系統的數量最近顯著增長，集成的數量也相應增長。作為在整合層面優化事件診斷流程的一部分，我們正在開發一個系統，允許您進行跨系統檢查並顯示結果，從而使您能夠發現與導入和系統互動相關的主要問題。彼此。
當然，我們在作業系統方面還有成長和發展的空間，我們正在積極致力於這方面的工作。您可以閱讀有關我們的監控系統的更多信息 .
技術測試
Orlov Sergey，網路與行動開發能力中心負責人
自從實體店關閉以來，我們從發展角度面臨各種挑戰。首先，負載激增。顯然，如果不採取適當的措施，那麼當系統承受高負載時，它可能會變成南瓜，或者性能完全下降，甚至失去其功能。
第二個方面則較不明顯，即高負載下的系統必須非常快速地進行更改，以適應業務流程的變化。有時一天幾次。許多公司有一個規則，如果行銷活動很多，則無需對系統進行任何更改。完全沒有，只要能用就讓它用。
我們基本上經歷了一個無盡的黑色星期五，在此期間有必要改變系統。系統中的任何錯誤、問題或故障都會為企業帶來巨大的損失。
展望未來，我會說我們設法應對這些測試，所有系統都承受住了負載，很容易擴展，並且我們沒有遇到任何全局技術故障。
系統承受高突波負載的能力取決於四個支柱。第一個是監控，您在上面讀到。如果沒有內建的監控系統，幾乎不可能發現系統瓶頸。一個好的監控系統就像家居服；它應該舒適並且適合您。
第二個方面是測試。我們非常重視這一點：我們為每個系統編寫經典單元、整合測試、負載測試和許多其他測試。我們也在編寫測試策略，同時嘗試提高測試水平，直到不再需要手動檢查。
第三個支柱是 CI/CD 管道。建置、測試和部署應用程式的過程應盡可能自動化；不應有人工幹預。 CI/CD Pipeline 這個主題很深，我只簡單介紹一下。唯一值得一提的是，我們有一個 CI/CD 管道清單，每個產品團隊都會在能力中心的幫助下完成清單。
這是清單
這樣，很多目標就達成了。這是 API 版本控制和功能切換，以避免發布序列，並在測試完全自動化、無縫部署等層級實現各種測試的覆蓋範圍。
第四個支柱是架構原理和技術方案。我們可以長時間談論架構，但我想強調一些我想重點關注的原則。
首先，您需要為特定任務選擇專用工具。是的，這聽起來很明顯，而且很明顯，釘子應該用錘子釘進去，手錶應該用專用螺絲起子拆卸。但在我們這個時代，許多工具都在努力實現通用化，以便涵蓋最大的使用者群體：資料庫、快取、框架等等。例如，如果採用 MongoDB 資料庫，它適用於多文檔事務，而 Oracle 資料庫適用於 json。似乎一切都可以用於一切。但如果我們代表生產力，那麼我們需要清楚地了解每種工具的優點和缺點，並使用我們完成任務所需的工具。
其次，在設計系統時，複雜性的每次增加都必須合理。我們必須時時牢記這一點；低耦合的原則是人人都知道的。我認為應該應用在具體服務的層面，應用在整個系統的層面，應用在建築景觀的層面。沿著負載路徑水平擴展每個系統組件的能力也很重要。如果你有這個能力，擴充就不是什麼難事。
談到技術解決方案，我們要求產品團隊準備一套新的建議、想法和解決方案，並實施這些建議、想法和解決方案，為下一波工作負載做好準備。
克什
有必要有意識地對待本地和分散式快取的選擇。有時在同一個系統中使用兩者是有意義的，例如，我們的系統中的某些數據本質上是展示緩存，也就是說，更新的來源位於系統本身的後面，並且系統不會改變這個數據。對於這種方法，我們使用本地咖啡因快取。
並且存在系統在運行過程中主動更改的數據，這裡我們已經使用 Hazelcast 的分散式快取。這種方法使我們能夠在真正需要的地方利用分散式快取的優勢，並在不需要它的情況下最大限度地降低循環 Hazelcast 叢集資料的服務成本。我們已經寫了很多關於快取的文章。 и .
此外，在 Hazelcast 中將序列化器更改為 Kryo 也為我們帶來了很好的推動。 Hazelcast 中從 ReplicatedMap 到 IMap + Near Cache 的過渡使我們能夠最大限度地減少叢集中的資料移動。
一點建議：在大量快取失效的情況下，有時可以採用預熱第二個快取然後切換到它的策略。看起來，透過這種方法，我們應該得到雙倍的記憶體消耗，但實際上，在實踐這種方法的系統中，記憶體消耗減少了。
反應式堆疊
我們在相當多的系統中使用反應式堆疊。在我們的例子中，這是帶有協程的 Webflux 或 Kotlin。當我們期望輸入輸出操作緩慢時，反應式堆疊特別好。例如，呼叫慢速服務、使用檔案系統或儲存系統。
最重要的原則是避免阻塞呼叫。反應式框架有少量在背景執行的即時服務執行緒。如果我們不小心允許自己進行直接的阻塞調用，例如 JDBC 驅動程式調用，系統將簡單地停止運作。
嘗試將錯誤轉換為您自己的運行時異常。程式執行的實際流程轉向反應式框架，程式碼執行變成非線性。因此，使用堆疊追蹤來診斷問題非常困難。這裡的解決方案是為每個錯誤創建清晰、客觀的運行時異常。
Elasticsearch
使用Elasticsearch時，不要選擇未使用的資料。原則上，這也是非常簡單的建議，但最常見的是被遺忘的內容。如果需要一次選擇10萬筆以上的記錄，就需要使用Scroll。打個比方，它有點像是關聯式資料庫中的遊標。
除非必要，否則不要使用後置過濾器。由於主樣本資料量較大，此操作對資料庫的負載很大。
在適用的情況下使用批次操作。
API
設計 API 時，請考慮盡量減少傳輸資料的要求。對於前端來說尤其如此：正是在這個交會處，我們超越了資料中心的管道，並且已經在致力於連結我們與客戶的管道。如果有最輕微的問題，過多的流量就會導致負面的使用者體驗。
最後，不要丟掉一大堆數據，要清楚消費者和供應商之間的合約。
組織變革
Eroshkina Elena，IT 副總監
在隔離發生、需要大幅加快線上發展步伐、引進全通路服務的那一刻，我們已經處於組織轉型的過程中。
我們的部分結構按照產品方法的原則和實踐轉移到工作中。目前已經組建了團隊，負責每個產品的營運和開發。這類團隊中的員工 100% 參與，並使用 Scrum 或看板來建立他們的工作，取決於他們更喜歡什麼，建立部署管道，實施技術實踐，品質保證實踐等等。
幸運的是，我們的大部分產品團隊都從事線上和全通路服務領域。這使我們能夠在最短的時間內（認真地說，實際上是兩天內）切換到遠端工作模式，而不會損失效率。客製化流程使我們能夠快速適應新的工作條件，並保持相當快的新功能交付速度。
另外，我們還需要加強那些處於線上業務前沿的團隊。在那一刻，我們清楚地意識到，我們只能利用內部資源來做到這一點。大約 50 人在兩週內改變了他們以前工作的領域，並參與了對他們來說是新產品的工作。
這不需要任何特殊的管理工作，因為除了組織我們自己的流程、產品的技術改進和品質保證實踐之外，我們還教導我們的團隊進行自組織——在不涉及行政資源的情況下管理自己的生產流程。
我們能夠將管理資源準確地集中在當時需要的地方 - 與業務進行協調：現在對我們的客戶來說什麼是重要的，應該首先實現什麼功能，需要做什麼來提高我們的吞吐能力交付和處理訂單。所有這些以及明確的角色模型使得在此期間能夠將真正重要和必要的內容加載到我們的生產價值流中。
顯然，在遠距工作和快速變化的情況下，當業務指標依賴於每個人的參與時，你不能僅僅依靠「我們一切順利嗎？」系列中的內心感受。是的，看起來不錯。”需要生產過程的客觀指標。我們有這些，任何對產品團隊指標感興趣的人都可以使用它們。首先是團隊本身、業務、分包商和管理階層。
每兩週一次，每個團隊都會進行一次狀態評估，分析指標 10 分鐘，識別生產過程中的瓶頸，並制定聯合解決方案：可以採取哪些措施來消除這些瓶頸。如果任何發現的問題超出了團隊的影響範圍，或者超出了可能已經遇到類似問題的同事的專業知識，您可以在這裡立即向管理層尋求幫助。
然而，我們明白，為了實現倍數加速（而這正是我們為自己設定的目標），我們仍然需要學習很多東西，並將其落實到日常工作中。目前，我們正在繼續將我們的產品方法擴展到其他團隊和新產品。為此，我們必須掌握一種新的形式——方法學家線上學校。
方法學家，幫助團隊建立流程、建立溝通和提高工作效率的人，本質上是變革的推動者。目前，我們第一批畢業生正在與團隊合作並幫助他們取得成功。
我認為當前的情況為我們帶來了機會和前景，也許我們自己還沒有完全意識到。但我們現在獲得的經驗和實踐證明，我們選擇了正確的發展道路，未來我們不會錯過這些新的機遇，也能夠有效應對Sportmaster將面臨的挑戰。
發現
在這個困難時期，我們制定了軟體開發所依據的主要原則，我認為這對每家從事此業務的公司都適用。
人。這就是一切的基礎。員工必須享受他們的工作並了解公司的目標以及他們所從事的產品的目標。當然，他們還可以在職業上得到發展。
Технология。公司有必要採取成熟的方法來使用其技術堆疊並在真正需要的地方建立能力。聽起來非常簡單明了。並且經常被忽略。
流程。正確組織產品團隊和能力中心的工作，與企業建立互動，以便作為合作夥伴與其合作，這一點非常重要。
總的來說，我們就是這樣生存下來的。我們這個時代的主要論點再次得到了證實，額頭上響起了一聲響亮的咔噠聲
即使您是一家規模龐大的線下企業，擁有許多商店和經營所在的許多城市，也要發展您的線上業務。這不僅僅是一個額外的銷售管道或一個漂亮的應用程序，您還可以透過它購買東西（而且因為競爭對手也有漂亮的應用程式）。這不是一個可以幫助您度過難關的以防萬一的備胎。
這是絕對必要的。為此，不僅您的技術能力和基礎設施必須做好準備，您的人員和流程也必須做好準備。畢竟，您可以在幾個小時內快速購買額外的記憶體、空間、部署新執行個體等。但人員和流程需要提前為此做好準備。
來源： www.habr.com