簡(jiǎn)介這份《云平臺(tái)運(yùn)維與運(yùn)營(yíng)服務(wù)方案》面向互聯(lián)網(wǎng)企業(yè)的運(yùn)維工程師、技術(shù)管理者及IT服務(wù)從業(yè)者系統(tǒng)梳理了云計(jì)算環(huán)境下從服務(wù)設(shè)計(jì)到執(zhí)行落地的完整運(yùn)維體系幫助解決資源管理、服務(wù)保障與持續(xù)優(yōu)化等實(shí)際問題。資源包內(nèi)含1個(gè)docx文檔約1MB結(jié)構(gòu)清晰、章節(jié)完整便于按模塊查閱與內(nèi)部培訓(xùn)引用。文檔圍繞運(yùn)營(yíng)運(yùn)維服務(wù)、ITSS服務(wù)保障體系、駐場(chǎng)服務(wù)、運(yùn)維團(tuán)隊(duì)配置及詳細(xì)服務(wù)任務(wù)設(shè)計(jì)展開重點(diǎn)覆蓋資源監(jiān)測(cè)、資源配置與優(yōu)化、服務(wù)監(jiān)控、事件處理、運(yùn)維流程、日常巡檢、備份恢復(fù)、應(yīng)急預(yù)案管理以及服務(wù)質(zhì)量監(jiān)督與報(bào)告等模塊并引入ITSS的PPTR組成要素與PIOIS生命周期框架為標(biāo)準(zhǔn)化運(yùn)維提供可落地的參考路徑。目前已有140人學(xué)習(xí)適合需要搭建規(guī)范化運(yùn)維體系、完善服務(wù)流程或編寫運(yùn)維方案的技術(shù)人員參考借鑒。1. 云平臺(tái)運(yùn)維與運(yùn)營(yíng)服務(wù)方案從駐場(chǎng)救火到體系化交付的分水嶺很多團(tuán)隊(duì)第一次接云平臺(tái)運(yùn)維項(xiàng)目都是被一句“你們派人駐場(chǎng)就行”帶進(jìn)坑里的。真到了現(xiàn)場(chǎng)才發(fā)現(xiàn)甲方要的不是一個(gè)會(huì)重啟服務(wù)的工程師而是一整套能寫進(jìn)驗(yàn)收文檔、能扛住季度考核、能說清楚“錢花在哪、SLA 怎么算”的運(yùn)營(yíng)服務(wù)體系。云平臺(tái)運(yùn)維與運(yùn)營(yíng)服務(wù)方案本質(zhì)是把“人、流程、工具、指標(biāo)”四件事打包成可交付、可計(jì)費(fèi)、可復(fù)盤的工程文件而不是一份堆滿術(shù)語的 PPT。它解決的核心問題是當(dāng) IaaS 層OpenStack、K8s、虛擬化已經(jīng)跑起來之后日常巡檢、故障響應(yīng)、變更管理、容量規(guī)劃、成本核算這些事由誰做、按什么標(biāo)準(zhǔn)做、做到什么程度算合格。適合誰看一是準(zhǔn)備投標(biāo)或接手云平臺(tái)運(yùn)維項(xiàng)目的技術(shù)負(fù)責(zé)人二是被臨時(shí)拉去寫運(yùn)維方案的一線工程師三是想把駐場(chǎng)服務(wù)從“賣人頭”升級(jí)成“賣服務(wù)”的運(yùn)維主管。ITSS 和 ITIL 的區(qū)別在這里會(huì)反復(fù)出現(xiàn)——ITIL 告訴你流程該怎么設(shè)計(jì)ITSS 告訴你服務(wù)能力該怎么度量?jī)烧卟皇嵌x一而是方案里必須同時(shí)落地的兩條線。2. 方案骨架怎么搭從服務(wù)目錄到 SLA 的四層結(jié)構(gòu)一份能落地的云平臺(tái)運(yùn)維與運(yùn)營(yíng)服務(wù)方案結(jié)構(gòu)上必須回答四個(gè)問題服務(wù)什么、怎么服務(wù)、服務(wù)到什么程度、服務(wù)不好怎么辦。這四個(gè)問題對(duì)應(yīng)服務(wù)目錄、服務(wù)流程、SLA 指標(biāo)和考核機(jī)制缺一層方案在評(píng)審會(huì)上就會(huì)被問住。2.1 服務(wù)目錄把“運(yùn)維”拆成可報(bào)價(jià)的條目服務(wù)目錄是整個(gè)方案的地基。很多方案翻車就是因?yàn)榉?wù)目錄寫得太虛比如“負(fù)責(zé)云平臺(tái)日常運(yùn)維”這種話甲方看了不知道你到底干什么乙方執(zhí)行時(shí)也不知道邊界在哪。常見做法是按資源類型和服務(wù)級(jí)別兩個(gè)維度拆。按資源類型拆云平臺(tái)運(yùn)維通常覆蓋計(jì)算資源虛擬機(jī)、容器、裸金屬、存儲(chǔ)資源塊存儲(chǔ)、對(duì)象存儲(chǔ)、文件存儲(chǔ)、網(wǎng)絡(luò)資源VPC、負(fù)載均衡、專線、平臺(tái)服務(wù)數(shù)據(jù)庫(kù)中間件、消息隊(duì)列、監(jiān)控告警。按服務(wù)級(jí)別拆分為基礎(chǔ)運(yùn)維巡檢、監(jiān)控、告警響應(yīng)、標(biāo)準(zhǔn)運(yùn)維變更、發(fā)布、備份恢復(fù)、高級(jí)運(yùn)維性能調(diào)優(yōu)、架構(gòu)優(yōu)化、容災(zāi)演練。服務(wù)類別典型條目響應(yīng)時(shí)效交付物基礎(chǔ)運(yùn)維每日巡檢、告警處理15 分鐘內(nèi)響應(yīng)巡檢日?qǐng)?bào)、告警臺(tái)賬標(biāo)準(zhǔn)運(yùn)維變更實(shí)施、版本發(fā)布按變更窗口變更單、回滾記錄高級(jí)運(yùn)維容量評(píng)估、容災(zāi)演練按項(xiàng)目排期評(píng)估報(bào)告、演練總結(jié)運(yùn)營(yíng)支撐成本分析、資源優(yōu)化月度輸出成本月報(bào)、優(yōu)化建議這張表的價(jià)值在于每一條都能對(duì)應(yīng)到人天報(bào)價(jià)也能對(duì)應(yīng)到驗(yàn)收標(biāo)準(zhǔn)。駐場(chǎng)服務(wù)最怕的就是“什么都干”最后變成“什么都干不好”。2.2 服務(wù)流程ITIL 落地時(shí)只保留五個(gè)核心流程ITIL 完整版有幾十個(gè)流程真落到云平臺(tái)運(yùn)維項(xiàng)目里能跑起來的通常只有五個(gè)事件管理、問題管理、變更管理、配置管理、發(fā)布管理。別貪多流程越多駐場(chǎng)工程師填單子的時(shí)間越多真正干活的時(shí)間越少。事件管理的核心是分級(jí)。我一般按影響范圍和業(yè)務(wù)優(yōu)先級(jí)分四級(jí)P1 是核心業(yè)務(wù)不可用P2 是核心業(yè)務(wù)降級(jí)P3 是非核心業(yè)務(wù)受影響P4 是咨詢和需求。分級(jí)不是為了好看是為了決定誰被叫醒、多久必須給出第一個(gè)回復(fù)。變更管理是云平臺(tái)運(yùn)維里最容易出事的環(huán)節(jié)。血淚經(jīng)驗(yàn)是所有變更必須有回滾方案且回滾方案必須在上變更窗口前驗(yàn)證過。我見過太多團(tuán)隊(duì)寫“回滾方式恢復(fù)備份”結(jié)果真出事時(shí)發(fā)現(xiàn)備份是三天前的恢復(fù)要四個(gè)小時(shí)。配置管理在云平臺(tái)場(chǎng)景下落地形式通常是 CMDB。CMDB 不要求大而全但必須覆蓋虛擬機(jī)清單、網(wǎng)絡(luò)拓?fù)洹⒋鎯?chǔ)掛載關(guān)系、關(guān)鍵應(yīng)用依賴關(guān)系。沒有 CMDB故障排查就是黑匣子只能靠工程師的記憶。2.3 SLA 指標(biāo)別只寫可用性 99.9%SLA 是運(yùn)營(yíng)服務(wù)方案里最容易被甲方挑戰(zhàn)的部分。只寫“可用性 99.9%”是不夠的因?yàn)榭捎眯栽趺此?、誰來統(tǒng)計(jì)、統(tǒng)計(jì)周期多長(zhǎng)這些不寫清楚季度考核時(shí)一定扯皮。我一般會(huì)建議 SLA 至少包含四類指標(biāo)可用性指標(biāo)平臺(tái)可用率、單資源可用率、性能指標(biāo)CPU/內(nèi)存/存儲(chǔ) IO 的告警閾值達(dá)標(biāo)率、響應(yīng)指標(biāo)事件響應(yīng)時(shí)長(zhǎng)、故障恢復(fù)時(shí)長(zhǎng)、服務(wù)指標(biāo)變更成功率、巡檢完成率、工單閉環(huán)率。提示SLA 里的每個(gè)指標(biāo)都要寫明數(shù)據(jù)來源。比如可用率是來自監(jiān)控平臺(tái)還是來自甲方業(yè)務(wù)側(cè)撥測(cè)這兩個(gè)口徑可能差出好幾個(gè)百分點(diǎn)。2.4 考核機(jī)制把 SLA 換算成錢考核機(jī)制是運(yùn)營(yíng)服務(wù)方案和普通運(yùn)維方案的分水嶺。沒有考核SLA 就是一張廢紙。常見做法是把服務(wù)費(fèi)拆成基礎(chǔ)服務(wù)費(fèi)和考核服務(wù)費(fèi)兩部分基礎(chǔ)部分覆蓋人力成本考核部分和 SLA 達(dá)標(biāo)率掛鉤。考核周期通常按月或按季度。計(jì)算方式舉例考核服務(wù)費(fèi) 基數(shù) × 達(dá)標(biāo)率系數(shù)達(dá)標(biāo)率 95% 以上系數(shù)為 190% 到 95% 為 0.8低于 90% 為 0.6。具體數(shù)字可以談但機(jī)制必須在合同里寫清楚。3. 駐場(chǎng)服務(wù)怎么排班人天測(cè)算與技能矩陣駐場(chǎng)服務(wù)是云平臺(tái)運(yùn)維項(xiàng)目里成本占比最大的部分也是方案里最容易拍腦袋的部分。很多方案寫“安排 3 名工程師駐場(chǎng)”但為什么是 3 名、這 3 個(gè)人分別干什么、夜班怎么排、請(qǐng)假了誰頂這些不寫清楚執(zhí)行時(shí)一定出問題。3.1 人天測(cè)算從服務(wù)目錄倒推人力人天測(cè)算不能憑感覺要從服務(wù)目錄倒推。方法是把服務(wù)目錄里每一條服務(wù)的預(yù)估工作量列出來乘以頻次再除以單人有效工時(shí)。舉個(gè)例子假設(shè)服務(wù)目錄里有這些條目每日巡檢 1 次每次 1 人天每周變更 2 次每次 0.5 人天每月成本分析 1 次每次 2 人天事件響應(yīng)按每月 20 次每次 0.25 人天。那么月度總工作量 1×22 0.5×8 2×1 0.25×20 22 4 2 5 33 人天。按每人每月 21 個(gè)工作日算至少需要 1.6 人實(shí)際排班要按 2 人配置留出冗余。這還沒算夜班和節(jié)假日。如果 SLA 要求 7×24 響應(yīng)那夜班必須單獨(dú)排通常采用輪班制3 人輪班才能覆蓋一個(gè) 7×24 崗位。3.2 技能矩陣駐場(chǎng)團(tuán)隊(duì)不能只有一種人云平臺(tái)運(yùn)維駐場(chǎng)團(tuán)隊(duì)常見的翻車場(chǎng)景是招了一個(gè)會(huì) Linux 的工程師結(jié)果現(xiàn)場(chǎng)要調(diào) OpenStack 網(wǎng)絡(luò)、要寫 Ansible 腳本、要看 K8s 日志一個(gè)人扛不住。所以方案里必須定義技能矩陣。角色必備技能加分技能配置建議一線運(yùn)維Linux 常用命令、監(jiān)控工具、工單系統(tǒng)腳本編寫、網(wǎng)絡(luò)基礎(chǔ)2-3 人二線運(yùn)維OpenStack/K8s 運(yùn)維、數(shù)據(jù)庫(kù)基礎(chǔ)自動(dòng)化工具、容器編排1-2 人技術(shù)負(fù)責(zé)人架構(gòu)設(shè)計(jì)、變更評(píng)審、客戶溝通成本優(yōu)化、容災(zāi)設(shè)計(jì)1 人運(yùn)營(yíng)支撐數(shù)據(jù)分析、報(bào)表編寫、流程管理財(cái)務(wù)基礎(chǔ)、合同管理0.5-1 人一線運(yùn)維負(fù)責(zé)日常巡檢和告警響應(yīng)二線運(yùn)維負(fù)責(zé)復(fù)雜故障和變更實(shí)施技術(shù)負(fù)責(zé)人負(fù)責(zé)方案把控和客戶對(duì)接運(yùn)營(yíng)支撐負(fù)責(zé)成本分析和報(bào)表。小項(xiàng)目可以一人多崗但技能覆蓋不能有盲區(qū)。3.3 排班與交接把“隨時(shí)能找到人”寫進(jìn)流程7×24 駐場(chǎng)服務(wù)的排班常見做法是白班 9:00-18:00夜班 18:00-次日 9:00周末和節(jié)假日輪值。排班表至少提前一個(gè)月公布臨時(shí)換班必須走審批。交接班是容易被忽視的環(huán)節(jié)。我一般要求交接班必須完成三件事告警臺(tái)賬確認(rèn)、未閉環(huán)工單移交、當(dāng)日變更計(jì)劃同步。交接記錄要留痕可以是郵件也可以是工單系統(tǒng)里的交接單。沒有交接記錄出了問題就是一筆糊涂賬。4. 工具鏈怎么選監(jiān)控、自動(dòng)化與工單系統(tǒng)的落地組合云平臺(tái)運(yùn)維方案里工具鏈?zhǔn)恰斑\(yùn)營(yíng)服務(wù)”區(qū)別于“人肉運(yùn)維”的關(guān)鍵。但工具不是越多越好選型原則是能覆蓋核心場(chǎng)景、能集成、團(tuán)隊(duì)能維護(hù)。下面按監(jiān)控、自動(dòng)化、工單三條線說。4.1 監(jiān)控體系從資源監(jiān)控到業(yè)務(wù)撥測(cè)監(jiān)控是運(yùn)維的眼睛。云平臺(tái)監(jiān)控通常分三層基礎(chǔ)設(shè)施監(jiān)控CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、平臺(tái)服務(wù)監(jiān)控OpenStack API 響應(yīng)、K8s Pod 狀態(tài)、數(shù)據(jù)庫(kù)連接數(shù)、業(yè)務(wù)監(jiān)控核心接口可用性、響應(yīng)時(shí)間。常見組合是 Prometheus Grafana Alertmanager。Prometheus 負(fù)責(zé)采集和存儲(chǔ)Grafana 負(fù)責(zé)展示Alertmanager 負(fù)責(zé)告警路由。如果云平臺(tái)是 OpenStack還需要額外采集 Nova、Neutron、Cinder 的服務(wù)狀態(tài)。# prometheus.yml 片段采集 OpenStack 服務(wù)狀態(tài) scrape_configs: - job_name: openstack-api metrics_path: /metrics static_configs: - targets: [controller01:9100, controller02:9100] relabel_configs: - source_labels: [__address__] target_label: instance這段配置的作用是讓 Prometheus 定期抓取 OpenStack 控制節(jié)點(diǎn)的指標(biāo)。targets里填控制節(jié)點(diǎn)地址metrics_path是暴露指標(biāo)的路徑。實(shí)際部署時(shí)控制節(jié)點(diǎn)上需要跑 node_exporter 或?qū)ｉT的 OpenStack exporter。參數(shù)調(diào)整主要在抓取間隔默認(rèn) 15 秒大規(guī)模環(huán)境可以放寬到 30 秒減少存儲(chǔ)壓力。告警規(guī)則要分級(jí)。P1 告警直接電話通知P2 告警發(fā)企業(yè)微信或釘釘P3 告警只記錄不通知。告警太多等于沒有告警我一般要求 P1 告警每月不超過 5 次超過就說明閾值設(shè)錯(cuò)了。4.2 自動(dòng)化運(yùn)維Ansible 做配置腳本做巡檢自動(dòng)化是降低駐場(chǎng)人力的核心手段。云平臺(tái)運(yùn)維場(chǎng)景下Ansible 是最常用的配置管理工具因?yàn)樗鼰o Agent、上手快、和 Linux 運(yùn)維習(xí)慣匹配。# 巡檢腳本檢查所有計(jì)算節(jié)點(diǎn)服務(wù)狀態(tài) ansible compute -m shell -a systemctl is-active nova-compute -i inventory.ini # 批量收集磁盤使用率 ansible all -m shell -a df -h | grep -v tmpfs -i inventory.ini disk_report.txt第一條命令檢查所有計(jì)算節(jié)點(diǎn)的 nova-compute 服務(wù)是否運(yùn)行compute是 inventory 里定義的主機(jī)組。第二條命令收集所有節(jié)點(diǎn)的磁盤使用率并輸出到文件。-i指定 inventory 文件里面按組定義主機(jī)地址和登錄憑證。巡檢腳本的關(guān)鍵是輸出要結(jié)構(gòu)化方便后續(xù)匯總。我一般會(huì)把結(jié)果寫成 CSV 或 JSON再用 Python 腳本生成日?qǐng)?bào)。純文本輸出只適合臨時(shí)排查不適合日常運(yùn)營(yíng)。4.3 工單與 CMDB別用 Excel 管配置工單系統(tǒng)是運(yùn)營(yíng)服務(wù)的流程載體。小項(xiàng)目可以用開源工單系統(tǒng)大項(xiàng)目通常用甲方指定的 ITSM 平臺(tái)。不管用什么工單必須和 CMDB 關(guān)聯(lián)否則查故障時(shí)不知道影響范圍。CMDB 的落地難點(diǎn)是數(shù)據(jù)準(zhǔn)確性。常見做法是自動(dòng)發(fā)現(xiàn) 人工確認(rèn)。自動(dòng)發(fā)現(xiàn)靠 Ansible 或監(jiān)控平臺(tái)采集人工確認(rèn)靠變更流程卡點(diǎn)——任何變更必須更新 CMDB不更新不予實(shí)施。這個(gè)規(guī)矩一開始會(huì)有人抱怨但堅(jiān)持三個(gè)月后CMDB 的準(zhǔn)確率能到 90% 以上。5. 避坑與排查駐場(chǎng)服務(wù)里最容易翻車的五件事5.1 現(xiàn)象SLA 達(dá)標(biāo)率很高但甲方滿意度很低原因SLA 指標(biāo)只覆蓋了技術(shù)層面沒覆蓋服務(wù)體驗(yàn)。比如故障確實(shí)在 30 分鐘內(nèi)恢復(fù)了但過程中甲方問了三次進(jìn)展沒人主動(dòng)同步。解決在 SLA 里增加“故障溝通”指標(biāo)要求 P1/P2 故障每 30 分鐘主動(dòng)同步一次進(jìn)展直到恢復(fù)。這個(gè)指標(biāo)不占太多人力但能顯著提升滿意度。5.2 現(xiàn)象變更成功率低每次變更都出問題原因變更方案沒有經(jīng)過評(píng)審或者評(píng)審流于形式。常見情況是工程師自己寫方案自己實(shí)施沒人檢查回滾步驟。解決變更必須走三級(jí)評(píng)審——技術(shù)負(fù)責(zé)人審方案、二線運(yùn)維審回滾、甲方審窗口。回滾方案必須包含具體命令和預(yù)期耗時(shí)不能寫“恢復(fù)備份”這種模糊描述。5.3 現(xiàn)象駐場(chǎng)工程師離職后新人接手要一個(gè)月原因知識(shí)沒有沉淀所有信息都在離職工程師的腦子里或本地電腦上。解決強(qiáng)制要求所有操作留痕巡檢記錄、變更記錄、故障處理記錄必須上傳到共享平臺(tái)。每周做一次知識(shí)分享把本周處理的問題寫成案例。新人入職第一周只做一件事讀歷史工單和案例庫(kù)。5.4 現(xiàn)象監(jiān)控告警天天響但都是誤報(bào)原因告警閾值設(shè)得太敏感或者沒有做告警收斂。比如一臺(tái)虛擬機(jī) CPU 瞬間沖到 90% 就告警但實(shí)際業(yè)務(wù)沒受影響。解決告警規(guī)則要加持續(xù)時(shí)間條件比如 CPU 持續(xù) 5 分鐘超過 90% 才告警。同時(shí)做告警分組同一臺(tái)主機(jī)的多個(gè)告警合并成一條。每月復(fù)盤一次告警把誤報(bào)率高的規(guī)則調(diào)掉。5.5 現(xiàn)象成本月報(bào)做出來甲方說數(shù)據(jù)不對(duì)原因成本核算口徑和甲方財(cái)務(wù)口徑不一致。比如云平臺(tái)按資源規(guī)格算成本甲方財(cái)務(wù)按實(shí)際使用量算成本。解決方案里就要明確成本核算口徑最好在項(xiàng)目啟動(dòng)會(huì)上和甲方財(cái)務(wù)對(duì)齊。常見做法是提供兩套數(shù)據(jù)一套按資源規(guī)格的理論成本一套按實(shí)際用量的分?jǐn)偝杀??？趶綄戇M(jìn)方案每月按固定格式輸出。6. 把方案變成可復(fù)用的運(yùn)營(yíng)資產(chǎn)一個(gè)季度復(fù)盤模板方案寫完只是開始真正讓運(yùn)營(yíng)服務(wù)值錢的是持續(xù)復(fù)盤。我一般會(huì)在每個(gè)季度末做一次運(yùn)營(yíng)復(fù)盤輸出一份固定格式的復(fù)盤報(bào)告。這份報(bào)告不只是給甲方看也是團(tuán)隊(duì)自己迭代的依據(jù)。復(fù)盤報(bào)告包含四個(gè)部分SLA 達(dá)成情況、事件與問題分析、成本與資源優(yōu)化、下季度改進(jìn)計(jì)劃。SLA 部分用表格列出各項(xiàng)指標(biāo)的達(dá)標(biāo)率和趨勢(shì)事件部分統(tǒng)計(jì) P1/P2 故障次數(shù)、平均恢復(fù)時(shí)長(zhǎng)、根因分布成本部分對(duì)比預(yù)算和實(shí)際支出列出優(yōu)化建議改進(jìn)計(jì)劃部分明確下季度的三個(gè)重點(diǎn)動(dòng)作。復(fù)盤維度關(guān)鍵指標(biāo)數(shù)據(jù)來源輸出頻率SLA 達(dá)成可用率、響應(yīng)時(shí)長(zhǎng)、變更成功率監(jiān)控平臺(tái)、工單系統(tǒng)月度事件分析P1/P2 次數(shù)、MTTR、根因分類事件臺(tái)賬季度成本優(yōu)化資源利用率、閑置資源占比云平臺(tái) API、成本報(bào)表月度改進(jìn)計(jì)劃行動(dòng)項(xiàng)、負(fù)責(zé)人、完成時(shí)間團(tuán)隊(duì)評(píng)審季度這個(gè)模板的好處是每次復(fù)盤不用從零開始想寫什么照著填就行。填了三個(gè)季度之后你會(huì)發(fā)現(xiàn)哪些指標(biāo)在改善、哪些問題反復(fù)出現(xiàn)。反復(fù)出現(xiàn)的問題才是方案真正需要改的地方。我自己的習(xí)慣是每季度復(fù)盤時(shí)至少砍掉一條沒人看的報(bào)表增加一條能驅(qū)動(dòng)行動(dòng)的指標(biāo)。運(yùn)營(yíng)服務(wù)方案不是越厚越好是越用越準(zhǔn)越好。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取