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