由於運維的瑣碎、故障出現的不確定性以及解決問題的不可控性的存在， 所以讓運維人痛並快樂著。
運維的角度看：好的架構不是設計出來的， 而是一步步的演進出來的。
命運就是這麼難以捉摸,當你拼盡一切前進時才發現前無大道,想放棄一切後退之時卻後路盡絕,最後生無可戀的縱身一躍時,希望卻不知何時悄然而至。
• 運維自動化平臺構建
第一階段：標準化
OS級別基礎環境一致， 設定檔統一管理， 軟體安裝目錄一致， 操控方式一致， 監控方式一致， 日誌格式一致， 標準化基礎建設以便將來使用起來方便。
第二階段：自動化
減少回應時間， 減少人為因素的故障， 對業務流程進行固化， 將手工腳本化為介面可作業系統， 許可權管理聚合在一起， 統一管控伺服器等。
第三階段：平臺化
相對於自動化來講平臺化， 講究的更為人性化， 遮罩硬代碼， 使各方人員的操作習慣形成工作流， 然後給大家更大的自主權。 比如可自主的申請許可權操作、可自主的發佈遊戲版本、可自主的查看各集群報錯等。
• 運維任務調度平臺構建
遊戲運維日常內容種類繁多、零散、多變， 當以定制化系統來應對時， 會經常需要麻煩開發人員改動代碼來適應運維場景， 所以借鑒OA、CMS系統定制化工作流以此來應對， 這樣減少開發人員相應的工作量，
第一：定制工作流
基於運維人員對各個工作流統一命名、統一部署、統一使用， 使得基礎環境一致性得以落地使用， 並將日常工作內容固化。
工作流元素：工作流(多個)任務節點(具有優先順序)(多個)進程節點(具有優先順序)
工作流參數：在執行過程中可替換
在定制過程中儘量保證工作流的原子性， 一個工作流只做一件事。 不要出現歧義
第二：執行工作流
定制的工作流可在任意集群上執行， 執行工作流， 工作流上可填寫所需變數內容。 每個任務節點單獨展示， 使運維方便定位問題， 方便定位發生在哪個伺服器。
第三：工作流程執行引擎
工作流之間沒有優先順序、任務節點之間有優先順序、進程節點之間有優先順序， 所以 工作流之間是並行關係， 任務節點之間是串列關係， 進程節點之間是串列關係。 在描述這一切時忽略了伺服器之間並行的關係， 而所有的任務節點其實是作用到伺服器上， 同一個任務節點的不同進程節點是在同一台伺服器上執行的。 在工作流數增大或者單個工作流延時比較長的情況下， 需要考慮分佈執行的情況， 用生產者和消費者加鎖的方案解決。
