尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
編輯 | 張嬋
隨著虛擬化技術和雲計算技術的普及，IT 互聯網基礎設施發生了很大的變化，底層的計算、存儲、網路等資源也越來越複雜，需要有平台能管理好這些資源，盡量將工作流程自動化，將運維人員從繁重的手動工作中解救出來。而現在工具的更新迭代也越來越快，如何構建這樣的平台提高軟件構件和交付的效率也是很多團隊面臨的問題。InfoQ 記者採訪了攜程系統研發部雲平台高級研發經理周昕毅，來了解攜程容器雲自動化運維平台的建設情況。
背景
攜程容器雲自動化運維平台是攜程容器雲基礎設施的管理工具。攜程容器雲承載著攜程機票、酒店、交通等業務線數千個應用，近 10 萬個容器實例，整體容量年增長率超過 40%。
運維平台從 2016 年開始建設，主要分為三個建設時期。
1. 平台初期 (2016.01 ~ 2017.01) 主要解決 OpenStack 架構下的運維問題。這個階段平台提供的能力包括：
- 宿主機的自動上線，
- 平台監控及日志收集，
- 故障排查工具、提升工程師排障效率。
這個階段的特點是關注標準化推進，包括宿主機標準化、監控標準制定、日志標準和規範落地。
2. Mesos 階段 (2017.02 ~ 2018.02) 在標準化的基礎上，平台開始提供 SDN 網路、雲存儲、容器遷移等自動化工具，管理覆蓋面更廣。
這個階段整個容器雲的容量增長很快，依靠平台的能力，團隊得以繼續維持容器雲持續高效運行。
3. Kubernetes 階段 (2018.03 ~ 至今) ，Mesos 的開源社區活躍度在 2017 年底開始逐步降低，雖然 Mesos 簡單穩定使用起來又熟悉，但是我們發現越來越多的需求需要定制開發，平台維護成本也變高，並且生產版本老舊，編排能力和范式弱，升級成本不亞於遷移。
容器雲基礎設施在 2018 年開始全面轉向 Kubernetes。在 Kubernetes 運維管理的基礎上，運維平台逐步開始提供容量規劃與預警、故障關聯及合併、容器實例自動遷移、應用自動擴縮容等能力。Kubernetes 擁有龐大的生態，遷移到 Kubernetes 也讓未來的技術路線更加清晰。不過 Kubernetes 本身有一定的複雜度，團隊需要時間熟悉，短期內也有穩定性的風險。
自動化運維平台架構設計
運維平台搭建初期主要關注三個方面：配置管理、監控管理、日志管理。
1. 配置管理相關工具先後嘗試過 SaltStack、Ansible 和 Rundeck。在大規模集群管理的實踐中，SaltStack 性能最好、可靠性最高，目前運維平台使用 SaltStack 進行配置管理，Ansible/Rundeck 相比而言更適合中小規模的平台管理。
2. 監控管理工具嘗試過 Zabbix 和 Promethus，當前使用攜程自研的 Hickwall 監控系統，針對容器監控做了額外的定制開發。
配圖 1: 攜程自研 HICKWALL 監控平台
3. 日志管理嘗試了 ElasticBeats、Kafka、ELK 等主流開源工具，目前基於 ELK 給用戶提供了一站式日志檢索和關聯查詢的能力。
為了將配置、監控、日志三個模塊進行整合，提升工程師日常運維工作效率，平台引入了 Stackstorm，在平台建設中貫徹事件驅動運維的理念。Stackstorm 是一個功能強大的開源自動化平台，可將所有應用程序，服務和工作流程連接起來。它跟傳統化運工具有些區別。我們開發的聊天機器人也可以和 StackStorm 工具做集成，提高排障的效率。
初期運維平台架構（包括 Openstack 時期和 Mesos 時期）如下圖：
運維平台通過 SaltStack 進行配置管理，做到配置標準化的落地；其他公司的最佳實踐、Docker/ 內核 /K8S 等版本升級、線上環境出現的各類異常和故障會促使我們不斷修訂運維標準，通過 StackStorm 流程灰度發布到平台各套環境中。
經過近三年演進，運維平台當前架構（即 Kubernetes 時期）如下圖：
圍繞雲平台三大核心資源：計算、網路、存儲進行統一平台化管理，實踐數據驅動運維。在應用運維層面，平台會關注 CPU 和內存資源使用率，為應用提供容量建議，並針對符合條件的應用進行自動擴縮容。
網路管理方面，除了網段和 IP 地址的分配管理，平台也收集丟包、延遲、帶寬使用等監控數據，提升網路服務質量。
平台建設的挑戰
運維平台初期建設以開發運維工具為主，解決工作中遇到的實際問題：部分機器配置不統一導致線上出問題，宿主機安裝配置耗時長且需要人工介入，重要告警淹沒在海量的其他告警信息中得不到及時處理。
隨著時間推進，平台變得很龐大，工具鏈很多，工程師需要熟悉多個技術棧。因此需要用產品化的思維來進行運維平台演進，即把運維平台當成產品來設計，不再堆疊各種工具 case by case 解決問題，而是梳理清楚雲平台的核心運維管理流程，對未來可能出現的需求進行提前規劃。
經過對需求的整理我們發現，容器雲運維平台的核心還是在於對核心資源（計算、網路、存儲）進行高效管理。提升資源的交付速度，提升工程師對平台的控制力，提升平台基礎設施的穩定性，促進知識分享和沉淀，是運維平台存在的意義。
在平台從 Mesos 遷移到 Kubernetes 的過程中，需要做到用戶無感知，IP、源信息不變，進行跨系統操作，這個過程中的一些要點有：
- 同 AZ 的 Mesos 遷移到 Kubernetes 按物理機維度遷移；
- 拆解遷移過程為多個 checkpoint，支持回滾；
- 使用 Stackstorm 自動化 pipeline。
標準化是自動化運維的基石，其重要性毋庸置疑。我們主要通過工具 + 流程 + 巡檢三套武器來保證平台的標準化推進。
SaltStack 管控了所有服務器的核心配置文件，用戶無法自行修改。SaltStack 配置修改有嚴密的流程，宿主機上下線也有嚴格的流程管控。在此基礎上，我們建設了自動化巡檢工具，定期掃描所有服務器和核心服務的狀態和配置信息，一旦有異常立即會發出警告。
自動化運維平台實踐
攜程容器雲自動化運維平台的一些基礎運維工作包括：服務器上下線，生產環境異常排查，服務監控，硬件故障維修，應用性能預警，資源管理，容量管理等。
自動化運維平台做到了服務器上下線的自動化，提供工具提升生產環境異常的排查效率，通過運維數據的積累、進行資源使用情況和容量預估。以下是幾個實踐案例。
智能告警
樣例中的第一種類型的告警比較好理解，監控告訴我們 kube-state-metrics 服務連不上了，隨後又恢復了，這個時候工程師不需要立即響應，可以事後查一下該服務 up and down 相關日志。第二種類型的告警是在告警發出時，平台進行了關聯計算，把可能引發該告警的服務 Error Log 發送在告警信息中，工程師收到告警後點擊 Error Log 鏈接可以查看詳情、快速判斷故障 Root Cause。
宿主機維護、自動上下線、通知相關用戶
隨著平台規模大了，也會出現硬件故障需要進行宿主機維修的情況，為了給用戶更好的體驗，運維平台做到了自動化的通知機制，從流程上保證業務運行的持續性和穩定性，有特殊需求的用戶也可以方便的提前介入處理。
容量管理
容量管理往往是老板比較關心的，因為涉及到花錢。每個季度到底投多少錢買宿主機？動態調度的能力有沒有？應用有波峰和波谷的，盡量把波峰的應用挫開，我們需要對它進行資源使用情況的預判，這樣才能做到彈性計算。
為了做到容量管理我們主要借助了監控系統、 Hadoop 平台以及自己運維的監控工具，最終通過 PAAS 平台做到容器彈性的調度。最終目標是把資源合理利用出去，同時又保證一定的穩定性。
這是我們容量的整體情況，會發現它的內存基本上用的非常滿，這個集群它的 CPU 資源也是用的比較滿，我們會從一些維度去做整體的分析和個別的分析。
自動化運維平台的規劃
攜程自動化運維項目中嘗試使用了大數據實時計算相關技術 (Spark/Spark Streaming)，並通過數據倉庫建設，相關模型和算法調整，提升資源使用率和容量預估的準確性。
自動化運維平台整體設計思路不變，即進一步提升對核心資源高效管理的能力，加速運維工程師知識積累和沉淀。同時需要擁抱新技術，比如 AIOps，通過更強大的工具讓運維平台有更多的能力。AIOps 概念的產生及周邊生態的活躍，對自動化運維平台起到很好的促進作用，運維平台數據和流程的積累可以為後續 AIOps 平台的建設提供支撐，讓 AIOps 平台在雲平台運維管理中落地。
平台的下一步的規劃是雲原生運維平台建設，以及混合雲運維管理平台建設。
寫在最後
在線應用的底層基礎設施變更具有一定風險，需要投入較多人力進行遷移方案設計，「給高速飛行中的飛機換零件」，挑戰在於：運行中的系統給遷移方案帶來了諸多先天限制，原則上只允許成功，不允許失敗。現在雲計算的發展日新月異，不斷有新的技術和架構出現，各領風騷三五年，要求架構師們具備一定的技術前瞻性和敏銳的嗅覺，同時在設計架構時需要考慮底層變更的成本。在技術和工具的選型上，首先需要明確自己所在組織的實際需求，找到最適合自己的；另外如果使用開源方案，那麼必然要選擇社區活躍度高的。
在 2019 年的背景下，如果沒有歷史包袱的企業進行運維自動化平台建設，可以嘗試基於 Kuberenetes 進行基礎平台建設。
從攜程的實踐經驗看，如果從平台設計之初就考慮兼容多種底層架構，那麼遷移就會很順滑。「唯一不變的是變化」。相反，如果設計時就想著一套架構用十年，開弓沒有回頭箭，底層架構的遷移就無法順利進行。
作者簡介
周昕毅，攜程系統研發部雲平台高級研發經理。現負責攜程容器雲平台運維，Cloud Storage 及 Cloud Network 基礎設施研發及運維。