你好，哈布爾！ 我支持 Highload IT 系統已經有十年了。 我不會在本文中寫有關設定 nginx 在 1000+ RPS 模式下工作的問題或其他技術問題。 我將分享我對此類系統的支援和運作過程中出現的問題的觀察。
監控
技術支援不會等到內容為「為什麼......網站無法再次運行？」的請求到達。 網站崩潰後一分鐘內，支援人員應該已經發現問題並開始解決它。 但該網站只是冰山一角。 它的可用性是最先受到監控的之一。
網上商店的剩餘貨品不再從ERP系統到達時怎麼辦？ 或是為客戶計算折扣的 CRM 系統已停止回應？ 該網站似乎正在運行。 有條件的 Zabbix 收到 200 回應。 值班班沒有收到監控的任何通知，正在開心地觀看新一季權力的遊戲第一集。
監控通常僅限於測量記憶體、RAM 和伺服器處理器負載的狀態。 但對於企業來說，在網站上取得產品的可用性更為重要。 叢集中一台虛擬機的有條件故障將導致流量停止流向該虛擬機，並且其他伺服器上的負載將增加。 公司不會虧錢。
因此，除了監控伺服器作業系統的技術參數外，還需要配置業務指標。 直接影響金錢的指標。 與外部系統（CRM、ERP 等）的各種互動。 在一定時間內的訂單數量。 成功或不成功的客戶授權和其他指標。
與外部系統交互
任何年營業額超過十億盧布的網站或行動應用程式都會與外部系統互動。 從上述 CRM 和 ERP 開始，到將銷售資料傳輸到外部大數據系統以分析購買情況並為客戶提供他肯定會購買（實際上不會購買）的產品結束。 每個這樣的系統都有自己的支援。 與這些系統的通訊常常會帶來痛苦。 特別是當問題是全局性的並且您需要在不同的系統中進行分析時。
有些系統會為其管理員提供電話號碼或電報。 在某個地方，您需要寫信給經理或存取這些外部系統的錯誤追蹤器。 即使在一家大公司的背景下，不同的系統也經常在不同的應用程式會計系統中運作。 有時無法追蹤應用程式的狀態。 您將收到一個條件 Jira 中的請求。 然後，在第一個 Jira 的評論中，您在另一個 Jira 中放置了指向該問題的連結。 在應用程式的第二個 Jira 中，已經有人寫了一則評論： 您需要致電條件管理員 Andrey 來解決問題。 等。
這個問題的最佳解決方案是創建一個單一的溝通空間，例如在 Slack 中。 邀請外部系統運作過程中的所有參與者加入。 還有一個追蹤器，以免重複應用程式。 應用程式應該在一個地方進行跟踪，從監控通知到未來錯誤解決方案的輸出。 你會說這是不現實的，歷史上曾發生過我們在一個追蹤器中工作，而他們在另一個追蹤器中工作的情況。 不同的系統出現了，它們有自己自治的IT團隊。 我同意，因此這個問題需要從 CIO 或產品負責人層面來解決。
您與之互動的每個系統都應提供支援即服務，並具有明確的 SLA，以按優先順序解決問題。 條件管理員安德烈（Andrey）有時間跟你講講時就不行了。
瓶頸人
項目（或產品）中的每個人是否都有一個人去度假引起了上級的震動？ 這可以是 DevOps 工程師、分析師或開發人員。 畢竟，只有 DevOps 工程師才知道哪些伺服器安裝了哪些容器，出現問題時如何重新啟動容器，一般來說，任何複雜的問題沒有他就無法解決。 分析師是唯一知道複雜機制如何運作的人。 哪些資料流流向哪裡。 根據對哪些服務的請求的哪些參數，我們將收到哪些回應。
誰能快速理解日誌中出現錯誤的原因並及時修復產品中的嚴重錯誤？ 當然是同一個開發商。 還有其他人，但由於某種原因只有他了解系統的不同模組是如何運作的。
這個問題的根源是缺乏文檔。 畢竟，如果描述了系統的所有服務，那麼無需分析師就可以處理問題。 如果 DevOps 從繁忙的日程中抽出幾天時間來描述解決典型問題的所有伺服器、服務和說明，那麼在他不在的情況下問題可以在沒有他的情況下得到解決。 你不需要在度假時在海灘上快速喝完啤酒，然後尋找 Wi-Fi 來解決問題。
支援人員的能力和責任
在大型專案中，公司不會剋扣開發人員的薪資。 他們正在從類似的計畫中尋找昂貴的中老年人。 有了支持，情況就有些不同了。 他們正試圖以各種可能的方式降低這些成本。 公司僱用廉價的昨天的 Enikey 工人並大膽地投入戰鬥。 如果我們談論的是澤列諾格勒一家工廠的名片網站，那麼這種策略是可能的。
如果我們談論的是大型線上商店，那麼每一小時的停機成本都超過了 Enikey 管理員的月薪。 讓我們以年營業額1億盧布為起點。 這是評級中任何在線商店的最低營業額 。 將此金額除以每年的小時數，即可得到超過 100 盧布的淨損失。 如果你不計算夜間時間，你可以放心地將金額加倍。
但錢不是最重要的，對吧？ （不，當然是主要的）還有聲譽損失。 知名網路商店的倒閉可能會在社交網路和專題媒體上引起一波評論。 廚房裡的朋友們的談話風格是“不要在那裡買任何東西，他們的網站總是癱瘓”，根本無法衡量。
現在要承擔責任。 在我的實踐中，曾經出現過這樣的情況：當班管理員沒有及時回應監控系統發出的站點不可用的通知。 一個夏天的星期五傍晚，莫斯科一家知名網店的網站靜靜地躺著。 週六早上，該網站的產品經理不明白為什麼網站打不開，Slack 中的支援和緊急通知聊天中一片寂靜。 這樣的錯誤讓我們損失了六位數，而這位值班人員也因此失去了工作。
責任是一項很難培養的技能。 一個人要嘛有，要嘛沒有。 因此，在訪談中，我試圖透過各種問題來識別它的存在，間接表明一個人是否習慣於承擔責任。 如果一個人回答說他選擇大學是因為父母這麼說，或是因為妻子說他收入不夠換工作，那麼最好不要和這樣的人交往。
與開發團隊互動
當使用者在使用產品過程中遇到簡單問題時，支援人員會自行解決。 嘗試重現問題、分析日誌等等。 但是當產品出現Bug時該怎麼辦呢？ 在這種情況下，支援人員會將任務分配給開發人員，這就是樂趣的開始。
開發人員不斷超負荷。 他們正在創造新的功能。 透過銷售修復錯誤並不是最有趣的活動。 完成下一個衝刺的最後期限即將到來。 然後來自支持部門的不愉快的人過來說：“立即停止一切，我們有問題。” 此類任務的優先順序最低。 特別是當問題不是最關鍵並且站點的主要功能正常工作時，並且當發布經理不會睜著眼睛到處跑並寫下：“緊急將此任務添加到下一個版本或修補程序中。”
具有正常或低優先權的問題會從一個版本轉移到另一個版本。 對於「任務什麼時候完成？」的問題您將收到以下格式的答案：“抱歉，現在有很多任務，請詢問您的團隊領導或發布經理。”
生產力問題比創造新功能更重要。 如果用戶不斷發現錯誤，那麼負評很快就會到來。 聲譽受損是很難恢復的。
開發和支援之間的互動問題由 DevOps 解決。 該縮寫通常以特定人員的形式使用，該人員幫助創建開發測試環境、建立 CICD 管道並快速將經過測試的程式碼投入生產。 DevOps 是一種軟體開發方法，流程中的所有參與者都相互密切交互，有助於快速建立和更新軟體產品和服務。 我的意思是分析師、開發人員、測試人員和支援人員。
在這種方法中，支援和開發並不是具有各自目的和目標的不同部門。 開發涉及運營，運營涉及開發。 分散式團隊的名言：「問題不在我這邊」不再那麼頻繁地出現在聊天中，最終用戶變得更高興了一些。
來源： www.habr.com