2020 年 9 月 28 日清晨公尺哈遊辦公區域，《原神》運維團隊與 opsmind 重保團隊嚴陣以待，迎接提瓦特大陸第一批旅行者。
新年伊始，《原神》運維團隊為我們揭示了《原神》運維自動化技術的探索實踐經歷。
運維自動化是必然，時間是我們唯一要跑贏的敵人。
與公尺哈遊現有專案對比，《原神》在伺服器數量及運維工作量上都面臨較大挑戰，如何通過運維自動化工具支撐超大規模集群的發布管理沒有經驗可尋。
然而，是採用自研還是商業方案是首先面臨的決策，運維工具的效率、穩定性及滿足遊戲上線要求是重中之重。要想在短時間內由 0 到 1 自研運維自動化工具是一項低投入產出且高風險的技術投資。在時間和人力不充裕的情況下，選擇採用現有的商業方案顯得可行性更高。在待考察的方案中，不乏一些在運維行業內比較知名的商業化方案。在深入調研後，發現這些方案各有優缺點，比如有些平台功能不足無法滿足定製化的需求；而有些產品研發與交付服務是割裂的，如果出現 bug 或新的功能需求，須由產品研發團隊評估後才能排期立項，少則數月、多則半年，甚至可能 石沉大海。
在探索過程中，opsmind 低**運維開發平台的產品形態非常特別，能通過很少的人力，在短時間內搭建起一體自動化運維平台，切中《原神》的痛點。並且可以快速的以週為單位進行 bug 修復、功能更新迭代，而《原神》運維開發只需要專注自動化工作流的設計編排以及業務方的需求實現。
由於《原神》面向的是全球使用者，大陸、海外包含多個區服，伺服器量大，上線時又要保證任務下發百分百無誤；這對公尺哈遊和 opsmind 都是很大的挑戰。面對 100% 成功率的目標，雙方一同配合查詢影響成功率的問題點，在多層**、自動檢測專線健康度、優化超時處理機制、資料進一步壓縮等措施下，最終以 100% 的任務下發成功率完美支撐了《原神》的上線。
對遊戲行業來說，快速迭代、快速發布是普遍需求。在追求效率的同時，更加強調質量。為了提公升運維質量以及與其他部門的配合效率，需要快速搭建起貼近自有業務場景的運維平台。包括監控、發布自動化、cmdb 等，並且資料彼此互通，可提供給遊戲研發及其他部門或系統使用。基於這個目標，《原神》運維團隊與 opsmind 從建模設計、工作流業務劃分、頁面的配置、自定義指標的收集與下發策略等幾方面入手，在乙個月內將整個體系搭建起來。為了整體替換老系統，並相容老系統對外輸出的 api，opsmind 開發 endpoint 功能，通過 endpoint，《原神》運維團隊可自定義 api 呼叫格式，驅動工作流執行。
「因為 opsmind 產品的靈活性、功能的全面性，使它可以滿足《原神》專案運維的所有需求，這是乙個很大的優勢，這就使我們可以把其他工具都扔掉只留 opsmind 。可以說《原神》和 opsmind 是相互成就，相互成長。」《原神》專案運維團隊表示。
《原神》是一款研發難度極具挑戰性的遊戲，《原神》的運維工作也同樣極具挑戰性。經過一年的合作，opsmind 在產品和效能上有了很大的提公升，實現了高速成長。
「希望 opsmind 近階段在做的監控系統效能優化工作能取得乙個很好的成果，這也會極大提公升《原神》運維的工作效率。此外，對於 opsmind 正在做的平台側的改造，使互動變得簡便，可以降低平台的使用門檻，提高配置效率，也是我們非常期待的。」《原神》專案運維團隊負責人表示。
運維自動化實踐筆記
由兩部分組成，bs架構的omserver作為ui客戶端互動和saltstack作為主控端服務。選擇saltstack的原因 1.基於python，便於二次開發 2.saltstack使用訊息佇列zeromq傳輸資料，更快更穩，ansible基於ssh協議傳輸資料 3.使用salt ssh 安裝 sa...
運維自動化
1，cobbler安裝環境準備 安裝epel epel release 6 8.noarch.rpm x86 64 epel release 6 8.noarch.rpm x86 安裝系列依賴環境 要是區域網用，建議關閉iptables 或是放行25151 80 69埠 和關閉selinux 檢視狀...
自動化運維
考慮的因素 源 打包為映象 發布到映象庫 利用k8s發布到物理機器執行，以服務的形式對外提供服務 目前的做法 0 建立乙個執行遠端命令的框架 1 每個應用建立乙個部署檔案指令碼 a 指定元 位址 c 同步源 到目標主機 d 接受指令碼引數 vername 2 版本號，映象tag fromport 3...