简介面向运维人员、运维团队负责人及信息技术服务管理者这份PDF系统梳理了信息技术运维服务要求规范的核心内容能够帮助组织统一服务范围、标准、流程与责任划分解决运维工作缺乏制度依据、问题响应和变更管理混乱等常见问题。文档参照信息技术基础设施库ITIL与国际标准ISO/IEC 20000给出术语定义、编制原则和服务管理体系并细化一线支持、系统管理员、网络管理员等运维角色的职责以及服务台、事件管理、问题管理、配置管理、变更管理、发布管理、服务级别管理等主要流程适合用于制度建设、流程优化和人员培训。资源包共包含1个PDF文件大小仅656KBPDF格式便于打印存档、在线预览与团队内部传阅内容按章节组织、目录清晰可按需查阅。目前已有187人学习下载对于需要建立或完善运维服务规范的个人和团队具有直接参考价值。1. IT运维服务要求规范先定服务目录再谈自动化巡检《IT运维服务要求规范.pdf》最怕被写成制度宣讲。团队往往翻一遍就存入网盘真到凌晨故障时大家按经验救人不按流程响应规范成了审计时才想起的东西。我理解的 IT 运维服务要求规范不是把管理制度复制成文档而是把服务器、网络设备、数据库、核心业务接口整理成一条条可巡检、可报警、可审计的服务链每个服务有唯一编号、负责人、响应时限以及能算出 99.9% 可用性的指标。这里按一线运维团队的常见做法把这份 PDF 变成能被监控、被 CI 检查的运维基线。无论你现在是运维工程师、SRE、平台开发还是刚接手合规体系都能直接照着落。先定服务目录再谈 SLO、告警和自动化检查是我在多个团队验证过的最短路径。2. 把“IT运维服务要求规范”拆成服务目录和 SLO用 Pandoc 生成 PDF2.1 用 YAML 描述 IT 运维服务目录作为规范的事实来源服务目录是整个规范的第一张表也是最容易写成废纸的一张表。如果只放在 Word 里后续做监控、工单、变更评审都要人肉翻译。我一般在动手写规范前先建一份service_catalog.yaml把服务目录结构化再让文档和巡检配置都从这份清单生成。services: - id: SVC-0101 name: 核心交易API category: 应用服务 owner: team-payment sli: metric: http_request expr: availability slo: availability: 99.9 response_time_ms: 300 incident: level: P1 response_minutes: 15 - id: SVC-0203 name: 数据库集群 category: 基础设施 owner: team-dba sli: metric: node_ping expr: reachability slo: availability: 99.95 incident: level: P1 response_minutes: 15这份 YAML 是后续所有自动化的依据。字段里刻意不写“系统描述”只写服务编号、负责人、SLO 和事件响应时间。因为规范一旦进入审计评审人不会去读大段文字能判真假的只有id、slo、incident这几个键。服务编号建议按业务域而不是物理机划分SVC-0101 表示交易域的核心 APISVC-0203 表示数据域的数据库集群编号在发布后要冻结否则告警路由和工单系统都要跟着改。如果你的公司之前推行过软件需求规格说明规范可以直接借鉴它的“可验证”写法。运维要求也一样只有能被探针、查询或日志验证的才写进 SLO不能验证的内容另开一个“管理要求”章节避免两类标准混在一张表里。这样评审时可以直接拿 PDF 对照监控大屏不需要一遍遍电话确认。2.2 为每个服务设置可巡检的 SLI 与 SLO规范里不要写“保证系统稳定”而要写成“核心交易 API 在自然月内可用性不低于 99.9%单次响应时间 P95 不超过 300ms”。这里有三个高频坑第一把 SLI 定义成模糊的“正常”却不说明正常由哪个探针判定第二把 SLO 设成 100%100% 意味着没有错误预算告警必然疲劳第三账期没写清楚业务说要 99.9%运维按周算财务按月算最后谁都没错。下面这组换算值可以直接抄进规范可用性 SLO每月允许不可用时间5 分钟窗口错误率告警建议99.9%43.8 分钟0.1%99.95%21.9 分钟0.05%99.99%4.4 分钟0.01%这个表的逻辑是把月度 SLO 换算成错误预算再除以滚动时间窗口得到告警阈值。实际落地时规范正文只写 SLO告警阈值放在监控规则里避免两份文件各说各话。很多人把 IT 运维服务规范做成一张责任矩阵贴在墙上却没有评估手段我的做法是直接约定 SLI 的数据来源例如 SVC-0101 的可用性等于采集网关里非 5xx 请求占全部请求的比例。这样监控团队能实现交付时也能拿同一个公式核账。2.3 用 Pandoc 将规范文档生成中文 PDF既然标题给的是 PDF最终交付物就该用版本管理的源文件生成。常见做法是 Markdown 维护源文件再由 Pandoc 导出成带目录的 PDF而不是直接拿 Word 另存为。命令一般是这样pandoc IT运维服务要求规范.md \ -o IT运维服务要求规范.pdf \ --pdf-enginexelatex \ -V CJKmainfontNoto Sans CJK SC \ -V geometry:margin2.5cm \ --toc --toc-depth2--pdf-enginexelatex指定 XeLaTeX 引擎为了中文字体走系统字体而不是默认的拉丁字体CJKmainfont指定中文字体这里用的Noto Sans CJK SC是常见开源字体--toc --toc-depth2生成目录并把目录控制在二级章节。执行前需要安装 TeX Live 和字体包如果生成的 PDF 中文全部消失或显示成方块优先检查字体名写没写对。源文件进 Git 还有一个好处每次修订都能看到 diff评审人不再争论“v2 最终版”和“v3 再也不改版”只需要看 commit 里 SLO 数值的变化。3. 巡检与事件响应把规范里的时限变成 Prometheus 规则3.1 从 SLI 计算可用性先解决“阈值是谁定的”规范定完 SLO下一个问题是“怎么知道没达标”。我见过不少团队在监控里写死 99.9% 告警却没搞清阈值应该由服务负责人基于 SLO 反推而不是监控管理员拍脑袋。正确顺序是SLO 决定错误预算错误预算除以时间窗口得到滚动错误率上限。( sum(rate(http_requests_total{jobSVC-0101,status~5..}[5m])) / sum(rate(http_requests_total{jobSVC-0101}[5m])) ) * 100这条 PromQL 计算最近 5 分钟 5xx 错误率单位是百分比。status~5..是正则匹配 500、501 等状态码如果网关返回的 4xx 不代表服务故障就不要计入。这里最容易踩的坑是漏掉聚合维度当服务有多个实例时如果只对每台机器的 rate 求平均低流量实例的抖动会被放大。正确做法是用sum without(instance)先聚合让结果代表整个服务的错误率具体写法看 3.3 节。3.2 事件分级表响应时限直接影响告警路由IT 运维服务要求规范里最刚性的是事件分级表。它不能只写“重大故障”和“一般故障”两个词要能被 Alertmanager 直接消费。下面是我常用的四级表级别影响描述响应时限通知渠道默认升级P1核心服务不可用或数据存在丢失风险15 分钟电话 企业微信群机器人值班长 30 分钟内拉起二线P2关键功能受损但有临时规避30 分钟企业微信群 邮件2 小时协同处理P3非关键功能异常或性能劣化4 小时工单系统 邮件次日复盘并反馈改进项P4咨询、变更请求、监控调优8 小时工单系统服务台闭环写这张表时建议把“响应”和“修复”分开。响应是第一次有人接单确认修复是最终恢复很多规范把两个时间混在一起导致告警升级逻辑无法实现。实际操作中响应时限对应告警通知后的 ack 时限修复时限对应事件关闭时限。若事件 30 分钟没有被确认工单系统应自动把事件升级到值班长。这一条要显式写进 PDF再在告警路由里实现。3.3 告警规则里写明服务编号与影响级别避免告警无人认领事件分级表最终要落到告警规则否则只是纸面表态。Prometheus 的 alerting rules 要把服务编号和级别贴到 labels让 Alertmanager 路由可以直接按severity分组。可用的规则片段如下groups: - name: itops-sla rules: - alert: SVC0101ErrorBudgetBurn expr: | ( sum without(instance)( rate(http_requests_total{jobSVC-0101,status~5..}[5m]) ) / sum without(instance)( rate(http_requests_total{jobSVC-0101}[5m]) ) ) 0.001 and on(job) (time() - process_start_time_seconds{jobSVC-0101} 900) for: 10m labels: service_id: SVC-0101 severity: page annotations: summary: SVC-0101 五分钟错误率超过 0.1%这段规则有三点值得拆开讲。第一sum without(instance)让多实例指标被聚合时保留 job 维度计算得到整体错误率避免低流量实例被放大。第二and on(job) (time()-process_start_time_seconds 900)过滤掉刚启动 15 分钟内的实例避免发布期间的 5xx 触发误报。第三for: 10m表示指标连续 10 分钟达到阈值才进入告警这个参数能在“求稳”和“敏感”之间取平衡P1 服务可以改成for: 2mP3 服务保留 15 分钟。规则文件本身最好由第 2 章的 YAML 渲染生成才能保证 job 名称和规范里的服务编号不漂移。4. 用 OpenAPI 3 与 Conftest 把规范检查变成代码规范门槛4.1 接口清单先按 openapi3 规范描述再谈自动化断言运维规范和研发规范的交汇点是接口契约而接口契约的载体是 openapi3 规范。很多团队说自己在做接口自动化断言规范真到落地却发现断言脚本里到处写死 URL 和响应码接口定义一变就失效。问题通常出在第一步文档没有用 openapi3 规范固定结构。我建议把每个对外服务的接口文档纳入合入门槛先跑 schema 校验再跑契约测试最后才生成断言。npx redocly/cli lint api/openapi.yamlredocly/cli是常见的 OpenAPI 3.0/3.1 lint 工具默认会检查路径、参数、响应状态码是否存在。对接口自动化断言规范来说真正有意义的是强制了operationId和responses的存在。若团队已有 Spectral也可以换成spectral lint api/openapi.yaml -r .spectral.yaml-r指定自定义规则集例如“所有 POST 接口必须有 201 响应定义”“所有响应必须有 schema”。这一步通过后自动化测试框架才能按operationId生成稳定的请求模板而不是在用例里散落人肉维护的 URL。4.2 用 Conftest 检查代码规范里的服务元数据接口契约只覆盖 API覆盖不到 Kubernetes 集群里的资源配置。要把 IT 运维服务要求规范落实到每次发布还需要一个能检查 YAML 有没有带服务编号和 SLO 注解的工具。我一般使用 Conftest它把 Rego 策略应用到任意 YAML 和 JSON 上很适合做这类代码规范扫描。先看一段待检查的 Service 抽象片段apiVersion: v1 kind: Service metadata: name: payment-api annotations: slo.ops.example/availability: 99.9 slo.ops.example/response_time_ms: 300 ops.example/owner: team-payment对应的 Rego 检查规则package main import future.keywords.if import future.keywords.in required_anns : [ slo.ops.example/availability, slo.ops.example/response_time_ms, ops.example/owner, ] deny[msg] if { some service in input service.kind Service not service.metadata.annotations msg : sprintf(服务 %s 缺少 annotations, [service.metadata.name]) } deny[msg] if { some service in input service.kind Service anns : service.metadata.annotations some required in required_anns not anns[required] msg : sprintf(服务 %s 未声明 %s, [service.metadata.name, required]) }这段 Rego 遍历输入数组找出所有kind Service的资源再检查三个必填注解。future.keywords.in提供some x in input的遍历语法sprintf用来生成可读的违规信息。运行方式很简单conftest test -p ops/ service.yaml-p指定策略目录Conftest 会用.rego文件逐一比对输入文件。如果资源里没有声明可用性和负责人命令会输出拒绝信息退出码为非 0。这样就把“检查代码规范”从个人自觉变成 CI 的强制行为没有 SLO 和 owner 的服务不能上线。4.3 把检查接入流水线规范不合格就不合并有了 Conftest 和 openapi3 校验之后下一步是放进合并请求流程。GitLab CI 的写法大致如下ops-spec-check: stage: test script: - conftest test -p ops/ k8s/ - npx redocly/cli lint api/openapi.yaml only: changes: - k8s/**/* - api/**/* - ops/**/*这段流水线在 MR 上执行两类检查一类扫描k8s/下所有资源配置保证每个 Service 都有 SLO 注解另一类扫描 OpenAPI 文档保证契约描述没有结构性错误。only: changes避免每次提交都重复执行只在相关目录变动时触发。配合本地 pre-commit 钩子开发者在 push 前就能发现缺注解而不是等流水线失败再返工。检查对象命令失败处理Kubernetes 资源配置conftest test -p ops/ k8s/阻断 Merge Request接口文档npx redocly/cli lint api/openapi.yaml阻断 Merge RequestPrometheus 告警规则promtool check rules rules/*.yml阻断发布5. 用 pdfplumber 让 IT运维服务要求规范.pdf 自动查对监控配置规范发布后最容易被忽略的是“配对上”PDF 里写了服务编号Prometheus 里却没有同样 job或者监控里有的 job 在规范中根本不存在。常见做法是写一个小脚本把 PDF 当数据源去对照prometheus.yml里的job_name。下面用 pdfplumber 提取表格里的服务编号并与采集配置比对。import pdfplumber import re import yaml import sys service_ids set() with pdfplumber.open(IT运维服务要求规范.pdf) as pdf: for page in pdf.pages: for table in page.extract_tables(): for row in table: if row and row[0]: cell row[0].strip() if re.fullmatch(rSVC-\d{4}, cell): service_ids.add(cell) with open(prometheus.yml, r, encodingutf-8) as f: conf yaml.safe_load(f) configured_jobs { item[job_name] for item in conf.get(scrape_configs, []) } missing sorted(service_ids - configured_jobs) orphan sorted(configured_jobs - service_ids) if missing: print(规范中定义但采集配置缺失, missing) if orphan: print(采集配置中存在但规范未覆盖, orphan) if missing or orphan: sys.exit(1) print(PDF 规范与监控配置一致)这个脚本假设规范 PDF 里的服务目录表第一列是SVC-四位数的服务编号且prometheus.yml的job_name与服务编号保持一致。extract_tables()返回页面中的所有表格行re.fullmatch过滤掉非服务编号对比时同时查找“规范有但监控没有”的漏采集以及“监控有但规范没有”的孤儿任务。放进 CI 每天运行一次任何一边更新后不一致都会让任务失败问题不会留到月度复盘才暴露。表格第一列不能混入空单元格否则提取会丢数据。可以用 pdfplumber 的page.find_tables()先检查表格边界再决定是否调整规范模板。这一步其实逆向验证了第 2 章的价值如果源文件是结构化 YAML这类校验直接对 YAML 更快不必解析 PDF。把 PDF 当作验收基线来用规范才真正从“给人看”变成“给系统对账”建议团队先做两个小改动把服务编号命名规则限制为SVC-\d{4}把prometheus.yml里的 job 命名与规范对齐。之后规范评审、巡检、CI 都能围绕同一个编号体系运转。本文还有配套的精品资源点击获取