简介这是一份面向企业信息化负责人、运维服务商投标人员及IT运维从业者的信息系统运维服务方案标书范本可用于投标文件编制、运维体系搭建与内部管理制度参考。压缩包共1个文件为doc格式文档整体约1.97MB内容以章节化正文编排便于直接套用与二次修改。文档围绕项目概况、需求分析、目标设定展开重点阐述运维服务管理体系建设包括IT服务管理概述、服务支持与服务提供流程、服务磨合、主动服务、战略规划三阶段规划路径以及运维服务质量管理与规范建立并给出信息系统运行保障方案涉及统一服务台建设、文档管理制度、一般信息化设备运维、例行维护流程与防病毒服务等内容。目前已有334人学习下载适合作为运维投标或制度落地的实操参照帮助读者快速形成结构完整、条理清晰的运维服务方案文本减少从零撰写的时间成本。1. 信息系统运维服务方案标书从评分表倒推而不是从模板抄起很多人接手「信息系统运维服务方案标书」的第一件事是翻出上一份文档改项目名和日期。真正决定能不能中标的从来不是页数而是评标办法里那一列分值——技术分往往占 40 到 60 分评标专家在一份技术标上停留的时间通常不超过二十分钟找不到得分点就等于没写。这份文档的本质是一份带量化承诺的执行契约服务范围、响应时限、人员配置、工具手段、考核口径每一句都必须能被验证、能被扣款。写得太虚专家打低分写得太满中标后自己扛不住考核。它面向投标负责人、售前技术、运维项目经理也面向那些手里有一线运维经验、却不知道怎么把经验翻译成评标语言的工程师。下面按拆解需求、量化 SLA、写实人员流程、对齐报价与终审的顺序把一份能落地的方案讲清楚。2. 把信息系统运维服务需求拆成可响应的条款矩阵2.1 招标文件里真正决定成败的四类内容拿到一份招标文件先别急着看技术需求书。真正要先读透的是另外几块它们决定你有没有资格进入技术评分环节。第一类是投标人须知前附表。这里写着废标条件、装订份数与密封要求、签字盖章要求、保证金缴纳方式、递交截止时间。技术方案写得再好密封口没盖骑缝章一样出局。第二类是评标办法尤其是技术评分细则的逐条分值这份细则其实就是标书的写作大纲分值高的条目必须写得厚。第三类是技术需求书服务范围清单、SLA 具体数值、人员资质要求、备品备件要求都藏在这里负偏离超过允许项数通常直接废标。第四类是合同条款付款节点、季度考核办法、扣款标准、是否续签决定了方案里的承诺要不要留余量。举个常见情况技术需求书写「运维服务期限一年」合同条款写「按季度考核考核得分低于 80 分扣减当季服务费的 10%」。那么方案里的年度计划就必须能拆到季度可检查的动作否则考核时无据可依。提示招标文件里的「★」「▲」条款要单独拉一张清单逐条确认是正偏离、完全响应还是负偏离。负偏离的容忍数量通常写在评标办法里超出即废标与价格无关。2.2 用「需求—响应—证据」三列矩阵把条款锁死读完文件后把所有技术要求拆成条目做成一张条款矩阵。这张表是后续写作的施工图也是自查工具。表格通常包含五列。条款编号原文要求摘要响应结论响应位置支撑证据3.2.1提供 7×24 小时故障受理完全响应第 4.2 节第 18 页值班排班表、呼叫中心截图3.2.4一般故障 4 小时内恢复完全响应第 3.3 节第 12 页近三年同类项目 MTTR 统计3.3.2项目经理具备高级职称完全响应第 4.1 节第 16 页证书扫描件、社保缴纳证明3.4.1核心数据库双机热备正偏离第 3.1 节第 9 页冗余架构说明图做这张表有两个好处。一是写作时不会漏条二是评标专家拿着评分表逐条找分时你给了他明确页码。有些招标方甚至要求投标文件里附这张偏离表那就更要提前做好。「响应位置」这一列建议直接写章节号和页码定稿后再核一遍页码因为排版时会整体位移。「支撑证据」要写清是哪类材料证书、合同复印件、工具截图、统计报表评标时可能被要求提供原件核验。2.3 星号条款与废标项排查技术标里最容易翻车的地方不是不会写而是写了不该写的。政府采购和国企招标里常见几类红线值得单独过一遍。一是暗标要求。部分项目技术标采用暗标评审正文中不得出现投标人名称、logo、人员真实姓名、能识别企业的项目案例名称。这类项目里人员简历要写成「项目经理 A男45 岁持有高级职称」而不是写真实姓名和单位。二是资质证书有效期。项目经理的信息系统项目管理师证书、ITIL 认证、厂商工程师认证都要确认在投标截止日仍在有效期内。证书过期属于实质性不响应。三是行业特殊要求。医疗信息系统的运维项目通常要求承诺数据不出院、驻场人员签署保密协议、变更操作必须双人复核并留存审计日志。教育、金融类项目类似电网、能源类还会加安全生产条款。这些内容在方案里要有独立小节明确承诺不能混在通用条款里一笔带过。四是报价超预算。有些项目技术分再高也没用报价超过预算上限直接废标或不计分这个数字一般写在投标人须知里。注意条款矩阵做完后让一个没参与写作的同事拿着招标文件逐条核对响应位置交叉检查能发现 80% 以上的漏条问题。3. 服务目录与 SLA 指标运维服务方案的量化骨架3.1 服务目录的四层拆分运维服务方案最容易写成「我们提供全方位的运维服务」这种空话。要让人信服得先把服务目录拆细。常见的做法是分四层每层写清服务项、服务方式、服务频次、交付物。层级覆盖对象典型服务项服务方式L1 基础设施层机房、UPS、精密空调、核心交换、防火墙、负载均衡环境巡检、配置备份、固件升级、链路切换演练驻场 定期巡检L2 平台层操作系统、虚拟化平台、数据库、中间件性能调优、补丁管理、账号权限核查、备份恢复验证远程 现场支持L3 应用层业务系统、对外接口、报表服务可用性监控、日志分析、版本发布配合、数据订正远程为主L4 终端与桌面办公 PC、打印机、会议室音视频、自助终端故障报修、系统重装、外设调试、资产盘点驻场上门四层拆完每一层再给出一份年度服务计划写清每月做什么。评标专家看到「每季度做一次数据库备份恢复演练并提交报告」比看到「保障数据安全」要放心得多。对医疗信息系统这类 7×24 不停机的场景L3 层还要单独列出停机窗口申请流程明确只有经过医务和信息科双签才能执行影响业务的变更。3.2 可用率与 MTTR 的计算口径SLA 数字不能只写结论要写计算公式和统计口径。同一句「系统可用率不低于 99.9%」口径不同结果差好几倍。可用率的常见算法是统计周期内的总时长减去不可用时长再除以总时长。争议点在两个地方计划停机算不算不可用、部分功能不可用算不算不可用。方案里必须写清否则考核时扯皮。# sla_calc.py —— 按约定口径计算可用率与 MTTR def availability(total_min, down_min, planned_min0): total_min: 统计周期总分钟数 down_min: 非计划不可用分钟数 planned_min: 经审批的计划停机分钟数默认扣除 effective total_min - planned_min # 有效服务时长 return (effective - down_min) / effective * 100 def mttr(fault_minutes, fault_count): 平均修复时间单位分钟 return fault_minutes / fault_count if fault_count else 0 # 例季度 90 天2 次非计划故障共 45 分钟计划停机 120 分钟 print(%.4f%% % availability(90 * 24 * 60, 45, 120)) # 99.9653% print(%.1f 分钟 % mttr(45, 2)) # 22.5 分钟这段代码的价值不在计算本身而在于它把口径固定下来了。planned_min参数默认为 0意味着如果招标方不同意扣减计划停机把参数去掉即可方案里的承诺就变成更严的口径。effective变量刻意不参与 MTTR 计算因为 MTTR 只关心故障本身的修复效率和停机窗口无关。常见误用是把「响应时间」当成「解决时间」写进 SLA。响应时间指从受理到工程师开始处理解决时间指业务恢复可用两者差一个数量级。方案里两个指标都要有并且分别给出承诺值。3.3 事件分级与响应升级表故障不分级SLA 就是一笔糊涂账。按业务影响范围分级再给每级配响应时限、到场时限、升级路径这是运维服务方案里最实的一块内容。级别判定标准响应时限到场时限解决时限升级对象P1 紧急核心业务系统全停影响对外服务5 分钟30 分钟2 小时项目经理 甲方负责人P2 严重主要功能不可用或性能严重下降15 分钟2 小时8 小时技术负责人P3 一般个别用户受影响有替代方案30 分钟次日3 个工作日二线工程师P4 咨询使用咨询、需求登记、优化建议2 小时不适用5 个工作日一线工程师这张表的每一行都要能被考核。解决办法是在方案里同时写明统计来源工单系统自动打点受理时间取工单创建时间解决时间取工单关闭时间中途挂起需注明原因并经甲方确认。挂起时间是否从时限中扣除也要提前约定。对 P1 事件方案里还要写清前 30 分钟的动作序列确认影响范围、通知谁、是否启动应急预案、是否启用备用链路。这一段写具体了比写十页组织架构图更有说服力。4. 人员、流程、工具章节怎么写才不像空话4.1 人员组织与岗位职责的写法人员章节常见的失败写法是贴一张金字塔组织图然后写「配备经验丰富的技术团队」。评标专家想看的是多少人、什么岗位、什么资质、怎么排班、请假了谁顶。建议按岗位写每个岗位给出一段说明加一行资质要求。项目经理通常要求持有信息系统项目管理师或同等级证书具备三年以上同类项目管理经验。技术负责人要求具备数据库或中间件厂商中级以上认证。一线驻场工程师按甲方作息配置若是 7×24 场景至少配 3 人轮班并设置备岗。排班表要写进方案。例如工作日 8:00—18:00 驻场 2 人其余时段 1 人电话值班、30 分钟内可远程接入、2 小时内可到现场。节假日安排同样列出。备岗机制写清任何岗位缺勤超过一个工作日由二线专家池中同技能等级人员顶替顶替人员名单事先报备。人员稳定性也是评分点。可以写承诺项目期内关键岗位更换不超过一次且提前 15 个工作日书面报备并完成不少于 5 个工作日的交接。4.2 事件、问题、变更三大流程流程章节要写成「可执行的动作序列」而不是「建立完善的流程体系」。事件管理流程按八步写受理记录、分类定级、初步诊断、一线处理、升级二线、解决验证、用户回访、关闭归档。每一步写清输入、输出、时限、责任人。回访环节容易被忽略但它是甲方感知服务质量的直接入口方案里写「P1、P2 事件关闭后 24 小时内由项目经理电话回访并记录」是加分项。问题管理管的是根因。事件关闭后重复发生三次以上的故障自动转入问题管理输出根因分析报告和临时规避措施进入已知错误库。知识库的条目数量可以定年度目标例如每年新增不少于 100 条并且要求每条经过技术负责人审核。变更管理要写清窗口和回退。标准变更走预授权例如新增监控项、调整告警阈值普通变更提前 3 个工作日报审重大变更提前 10 个工作日报审必须有回退方案和回退验证步骤。所有变更留存操作记录和审计日志涉及医疗、金融数据的变更执行双人复核。4.3 巡检脚本与监控工具举证工具章节最忌讳只列产品名。写「采用 Zabbix 进行监控」没有信息量写清监控对象、采集频率、告警阈值、告警收敛规则才有说服力。日常巡检可以用脚本固化下来方案里附上脚本清单和输出样例能显著提升可信度。#!/usr/bin/env bash # ops_daily.sh —— 主机层日常巡检采集输出 Markdown 日报 # 用法: bash ops_daily.sh /tmp/ops_daily.md set -uo pipefail OUT${1:-/tmp/ops_daily.md} # 输出文件路径缺省写到 /tmp DISK_WARN85 # 根分区使用率告警阈值百分比 SERVICESsshd crond mysqld nginx # 需要巡检的关键服务列表 { echo # 巡检日报 $(date %F %T) $(hostname) echo echo | 项目 | 数值 | 阈值 | 结论 | echo | --- | --- | --- | --- | # 根分区使用率 disk$(df -P / | awk NR2 {gsub(%,,$5); print $5}) [ $disk -ge $DISK_WARN ] flag告警 || flag正常 echo | 根分区使用率 | ${disk}% | ${DISK_WARN}% | ${flag} | # 内存使用率取整 mem$(free | awk /^Mem:/ {printf %d, $3*100/$2}) [ $mem -ge 90 ] flag告警 || flag正常 echo | 内存使用率 | ${mem}% | 90% | ${flag} | echo echo ## 关键服务状态 for s in $SERVICES; do if systemctl is-active --quiet $s; then echo - ${s}: 运行中 else echo - ${s}: 未运行 fi done echo echo 近 24 小时登录失败次数: $(lastb 2/dev/null | wc -l) } $OUT echo 已生成: $OUT脚本的第一个参数决定日报落盘位置便于接入定时任务后按日期归档。DISK_WARN和内存阈值分开写是因为磁盘增长通常缓慢、可预测内存波动大用同一个阈值会误报。SERVICES用空格分隔的字符串而不是数组是为了兼容较老的 bash 版本。set -uo pipefail中刻意不加-e因为单项采集失败不应该中断整个日报生成。方案里附上这段脚本后再补一句「日报每日 8:30 前推送至甲方运维群异常项自动转为工单」工具就从名词变成了动作。4.4 应急预案与演练记录应急预案要按场景写不按部门写。常见场景至少覆盖数据库实例宕机、存储阵列故障、核心网络中断、机房断电、勒索软件感染、核心人员离职、上游厂商停止支持。每个场景给出五要素触发条件、处置步骤、责任人、恢复目标、演练频次。恢复目标用 RTO 和 RPO 表示例如核心数据库 RTO 不超过 2 小时、RPO 不超过 15 分钟。这两个数字必须和备份策略对得上如果 RPO 写 15 分钟备份策略就不能是每日一次全备。演练要写频次和交付物。常见承诺是每半年一次桌面推演、每年一次实战演练演练后 5 个工作日内提交报告包含发现问题清单和整改计划。5. 报价口径、绩效域自检与终审脚本5.1 运维费用科目怎么和报价对齐技术标和报价表经常对不上方案里写了 5 人驻场报价表里只有一个总包价。评审时容易被要求澄清澄清不好还会被质疑低于成本价。稳妥的做法是让两边科目一一对应。下表是常见的拆分方式。费用科目包含内容计量方式报价依据硬件维保费服务器、存储、网络设备原厂或第三方维保按设备台数/年设备清单 维保报价单软件维保费数据库、中间件、虚拟化平台订阅与升级按套/年厂商续保报价驻场服务费驻场人员薪酬、社保、管理成本按人月人员配置表远程支持费二线、三线专家按需支持按年包干服务目录工作量估算备件耗材费硬盘、电源、光模块、打印耗材按实际或包干近三年消耗统计应急响应费P1 事件现场支持、灾后恢复按次或包干历史事件频次培训与文档费用户培训、操作手册、年度总结按次培训计划不少地方财政对信息系统运维开支的科目和标准有专门规定比如江西省省本级出台的信息系统建设及运维服务开支管理暂行办法对运维费用构成和列支口径做了约束。如果项目资金来自同类渠道报价表的科目名称最好与之保持一致减少被要求澄清的概率。5.2 用项目绩效域做技术标自检信息系统项目管理师的知识体系里绩效域是一套现成的自检框架。写完后按下面的方式对照一遍能发现方案的结构性缺口。绩效域映射到标书的检查点常见缺口干系人是否区分了甲方信息科、业务部门、终端用户三类诉求只写「满足甲方要求」团队岗位、资质、排班、备岗、培训计划是否齐全缺备岗和离职顶替机制交付服务目录、交付物清单、验收标准是否明确交付物只有「服务报告」四个字测量SLA 指标、统计口径、考核办法是否闭环有指标无统计来源不确定性应急预案、风险清单、备用方案是否覆盖只写「制定应急预案」规划年度计划是否拆到季度和月度只有一张甘特图把这张表当成终审清单用逐项在方案里找到对应段落并标注页码找不到的补写写得虚的改实。5.3 终审脚本关键词覆盖与数值一致性检查定稿前用脚本做一遍机械检查比人眼翻 PDF 可靠。重点查两件事评分细则里的关键词是否都出现以及全文数值是否自相矛盾。# bid_check.py —— 技术标终审辅助关键词覆盖 数值一致性 import re from pathlib import Path REQUIRED [服务范围, 响应时限, 值班, 备品备件, 应急预案, 知识库, 考核, 保密, 交接, 培训] NUMERIC [99.9, 7×24, 30分钟, 4小时, 2小时, 15分钟] def check(path): text Path(path).read_text(encodingutf-8) print( 必备关键词 ) for kw in REQUIRED: print(f[{命中 if kw in text else 缺失}] {kw}) print(\n 关键数值出现次数 ) for n in NUMERIC: cnt text.count(n) tag 仅 1 处核对口径 if cnt 1 else (未出现 if cnt 0 else 正常) print(f{n}: {cnt} 次 ({tag})) print(\n 页面残留标记 ) for m in re.findall(r(TODO|待补|XX公司|某某|占位), text): print(发现待处理标记:, m) if __name__ __main__: check(technical_bid.md)脚本里REQUIRED列表应该直接从评标办法的技术评分细则里抄每条分值对应的名词都放进去。NUMERIC列表的价值在于抓一致性如果「2小时」只在全文出现一次很可能某一处承诺和别处对不上需要人工确认是不是笔误。re.findall那一段专门抓写作过程中留下的占位符这类标记一旦漏进正式投标文件是很尴尬的失分点。运行完脚本后还要做两件机器做不了的事把正文里的章节号和页码重新核一遍确认条款矩阵里的引用没有因排版位移而失效再让一个没参与写作的人只看评分表、不看正文试着从目录里找出每一条得分的落点找不到的就是还没写到位的地方。本文还有配套的精品资源点击获取 信息系统运维服务方案标书：从评分表倒推与SLA量化落地
简介这是一份面向企业信息化负责人、运维服务商投标人员及IT运维从业者的信息系统运维服务方案标书范本可用于投标文件编制、运维体系搭建与内部管理制度参考。压缩包共1个文件为doc格式文档整体约1.97MB内容以章节化正文编排便于直接套用与二次修改。文档围绕项目概况、需求分析、目标设定展开重点阐述运维服务管理体系建设包括IT服务管理概述、服务支持与服务提供流程、服务磨合、主动服务、战略规划三阶段规划路径以及运维服务质量管理与规范建立并给出信息系统运行保障方案涉及统一服务台建设、文档管理制度、一般信息化设备运维、例行维护流程与防病毒服务等内容。目前已有334人学习下载适合作为运维投标或制度落地的实操参照帮助读者快速形成结构完整、条理清晰的运维服务方案文本减少从零撰写的时间成本。1. 信息系统运维服务方案标书从评分表倒推而不是从模板抄起很多人接手「信息系统运维服务方案标书」的第一件事是翻出上一份文档改项目名和日期。真正决定能不能中标的从来不是页数而是评标办法里那一列分值——技术分往往占 40 到 60 分评标专家在一份技术标上停留的时间通常不超过二十分钟找不到得分点就等于没写。这份文档的本质是一份带量化承诺的执行契约服务范围、响应时限、人员配置、工具手段、考核口径每一句都必须能被验证、能被扣款。写得太虚专家打低分写得太满中标后自己扛不住考核。它面向投标负责人、售前技术、运维项目经理也面向那些手里有一线运维经验、却不知道怎么把经验翻译成评标语言的工程师。下面按拆解需求、量化 SLA、写实人员流程、对齐报价与终审的顺序把一份能落地的方案讲清楚。2. 把信息系统运维服务需求拆成可响应的条款矩阵2.1 招标文件里真正决定成败的四类内容拿到一份招标文件先别急着看技术需求书。真正要先读透的是另外几块它们决定你有没有资格进入技术评分环节。第一类是投标人须知前附表。这里写着废标条件、装订份数与密封要求、签字盖章要求、保证金缴纳方式、递交截止时间。技术方案写得再好密封口没盖骑缝章一样出局。第二类是评标办法尤其是技术评分细则的逐条分值这份细则其实就是标书的写作大纲分值高的条目必须写得厚。第三类是技术需求书服务范围清单、SLA 具体数值、人员资质要求、备品备件要求都藏在这里负偏离超过允许项数通常直接废标。第四类是合同条款付款节点、季度考核办法、扣款标准、是否续签决定了方案里的承诺要不要留余量。举个常见情况技术需求书写「运维服务期限一年」合同条款写「按季度考核考核得分低于 80 分扣减当季服务费的 10%」。那么方案里的年度计划就必须能拆到季度可检查的动作否则考核时无据可依。提示招标文件里的「★」「▲」条款要单独拉一张清单逐条确认是正偏离、完全响应还是负偏离。负偏离的容忍数量通常写在评标办法里超出即废标与价格无关。2.2 用「需求—响应—证据」三列矩阵把条款锁死读完文件后把所有技术要求拆成条目做成一张条款矩阵。这张表是后续写作的施工图也是自查工具。表格通常包含五列。条款编号原文要求摘要响应结论响应位置支撑证据3.2.1提供 7×24 小时故障受理完全响应第 4.2 节第 18 页值班排班表、呼叫中心截图3.2.4一般故障 4 小时内恢复完全响应第 3.3 节第 12 页近三年同类项目 MTTR 统计3.3.2项目经理具备高级职称完全响应第 4.1 节第 16 页证书扫描件、社保缴纳证明3.4.1核心数据库双机热备正偏离第 3.1 节第 9 页冗余架构说明图做这张表有两个好处。一是写作时不会漏条二是评标专家拿着评分表逐条找分时你给了他明确页码。有些招标方甚至要求投标文件里附这张偏离表那就更要提前做好。「响应位置」这一列建议直接写章节号和页码定稿后再核一遍页码因为排版时会整体位移。「支撑证据」要写清是哪类材料证书、合同复印件、工具截图、统计报表评标时可能被要求提供原件核验。2.3 星号条款与废标项排查技术标里最容易翻车的地方不是不会写而是写了不该写的。政府采购和国企招标里常见几类红线值得单独过一遍。一是暗标要求。部分项目技术标采用暗标评审正文中不得出现投标人名称、logo、人员真实姓名、能识别企业的项目案例名称。这类项目里人员简历要写成「项目经理 A男45 岁持有高级职称」而不是写真实姓名和单位。二是资质证书有效期。项目经理的信息系统项目管理师证书、ITIL 认证、厂商工程师认证都要确认在投标截止日仍在有效期内。证书过期属于实质性不响应。三是行业特殊要求。医疗信息系统的运维项目通常要求承诺数据不出院、驻场人员签署保密协议、变更操作必须双人复核并留存审计日志。教育、金融类项目类似电网、能源类还会加安全生产条款。这些内容在方案里要有独立小节明确承诺不能混在通用条款里一笔带过。四是报价超预算。有些项目技术分再高也没用报价超过预算上限直接废标或不计分这个数字一般写在投标人须知里。注意条款矩阵做完后让一个没参与写作的同事拿着招标文件逐条核对响应位置交叉检查能发现 80% 以上的漏条问题。3. 服务目录与 SLA 指标运维服务方案的量化骨架3.1 服务目录的四层拆分运维服务方案最容易写成「我们提供全方位的运维服务」这种空话。要让人信服得先把服务目录拆细。常见的做法是分四层每层写清服务项、服务方式、服务频次、交付物。层级覆盖对象典型服务项服务方式L1 基础设施层机房、UPS、精密空调、核心交换、防火墙、负载均衡环境巡检、配置备份、固件升级、链路切换演练驻场 定期巡检L2 平台层操作系统、虚拟化平台、数据库、中间件性能调优、补丁管理、账号权限核查、备份恢复验证远程 现场支持L3 应用层业务系统、对外接口、报表服务可用性监控、日志分析、版本发布配合、数据订正远程为主L4 终端与桌面办公 PC、打印机、会议室音视频、自助终端故障报修、系统重装、外设调试、资产盘点驻场上门四层拆完每一层再给出一份年度服务计划写清每月做什么。评标专家看到「每季度做一次数据库备份恢复演练并提交报告」比看到「保障数据安全」要放心得多。对医疗信息系统这类 7×24 不停机的场景L3 层还要单独列出停机窗口申请流程明确只有经过医务和信息科双签才能执行影响业务的变更。3.2 可用率与 MTTR 的计算口径SLA 数字不能只写结论要写计算公式和统计口径。同一句「系统可用率不低于 99.9%」口径不同结果差好几倍。可用率的常见算法是统计周期内的总时长减去不可用时长再除以总时长。争议点在两个地方计划停机算不算不可用、部分功能不可用算不算不可用。方案里必须写清否则考核时扯皮。# sla_calc.py —— 按约定口径计算可用率与 MTTR def availability(total_min, down_min, planned_min0): total_min: 统计周期总分钟数 down_min: 非计划不可用分钟数 planned_min: 经审批的计划停机分钟数默认扣除 effective total_min - planned_min # 有效服务时长 return (effective - down_min) / effective * 100 def mttr(fault_minutes, fault_count): 平均修复时间单位分钟 return fault_minutes / fault_count if fault_count else 0 # 例季度 90 天2 次非计划故障共 45 分钟计划停机 120 分钟 print(%.4f%% % availability(90 * 24 * 60, 45, 120)) # 99.9653% print(%.1f 分钟 % mttr(45, 2)) # 22.5 分钟这段代码的价值不在计算本身而在于它把口径固定下来了。planned_min参数默认为 0意味着如果招标方不同意扣减计划停机把参数去掉即可方案里的承诺就变成更严的口径。effective变量刻意不参与 MTTR 计算因为 MTTR 只关心故障本身的修复效率和停机窗口无关。常见误用是把「响应时间」当成「解决时间」写进 SLA。响应时间指从受理到工程师开始处理解决时间指业务恢复可用两者差一个数量级。方案里两个指标都要有并且分别给出承诺值。3.3 事件分级与响应升级表故障不分级SLA 就是一笔糊涂账。按业务影响范围分级再给每级配响应时限、到场时限、升级路径这是运维服务方案里最实的一块内容。级别判定标准响应时限到场时限解决时限升级对象P1 紧急核心业务系统全停影响对外服务5 分钟30 分钟2 小时项目经理 甲方负责人P2 严重主要功能不可用或性能严重下降15 分钟2 小时8 小时技术负责人P3 一般个别用户受影响有替代方案30 分钟次日3 个工作日二线工程师P4 咨询使用咨询、需求登记、优化建议2 小时不适用5 个工作日一线工程师这张表的每一行都要能被考核。解决办法是在方案里同时写明统计来源工单系统自动打点受理时间取工单创建时间解决时间取工单关闭时间中途挂起需注明原因并经甲方确认。挂起时间是否从时限中扣除也要提前约定。对 P1 事件方案里还要写清前 30 分钟的动作序列确认影响范围、通知谁、是否启动应急预案、是否启用备用链路。这一段写具体了比写十页组织架构图更有说服力。4. 人员、流程、工具章节怎么写才不像空话4.1 人员组织与岗位职责的写法人员章节常见的失败写法是贴一张金字塔组织图然后写「配备经验丰富的技术团队」。评标专家想看的是多少人、什么岗位、什么资质、怎么排班、请假了谁顶。建议按岗位写每个岗位给出一段说明加一行资质要求。项目经理通常要求持有信息系统项目管理师或同等级证书具备三年以上同类项目管理经验。技术负责人要求具备数据库或中间件厂商中级以上认证。一线驻场工程师按甲方作息配置若是 7×24 场景至少配 3 人轮班并设置备岗。排班表要写进方案。例如工作日 8:00—18:00 驻场 2 人其余时段 1 人电话值班、30 分钟内可远程接入、2 小时内可到现场。节假日安排同样列出。备岗机制写清任何岗位缺勤超过一个工作日由二线专家池中同技能等级人员顶替顶替人员名单事先报备。人员稳定性也是评分点。可以写承诺项目期内关键岗位更换不超过一次且提前 15 个工作日书面报备并完成不少于 5 个工作日的交接。4.2 事件、问题、变更三大流程流程章节要写成「可执行的动作序列」而不是「建立完善的流程体系」。事件管理流程按八步写受理记录、分类定级、初步诊断、一线处理、升级二线、解决验证、用户回访、关闭归档。每一步写清输入、输出、时限、责任人。回访环节容易被忽略但它是甲方感知服务质量的直接入口方案里写「P1、P2 事件关闭后 24 小时内由项目经理电话回访并记录」是加分项。问题管理管的是根因。事件关闭后重复发生三次以上的故障自动转入问题管理输出根因分析报告和临时规避措施进入已知错误库。知识库的条目数量可以定年度目标例如每年新增不少于 100 条并且要求每条经过技术负责人审核。变更管理要写清窗口和回退。标准变更走预授权例如新增监控项、调整告警阈值普通变更提前 3 个工作日报审重大变更提前 10 个工作日报审必须有回退方案和回退验证步骤。所有变更留存操作记录和审计日志涉及医疗、金融数据的变更执行双人复核。4.3 巡检脚本与监控工具举证工具章节最忌讳只列产品名。写「采用 Zabbix 进行监控」没有信息量写清监控对象、采集频率、告警阈值、告警收敛规则才有说服力。日常巡检可以用脚本固化下来方案里附上脚本清单和输出样例能显著提升可信度。#!/usr/bin/env bash # ops_daily.sh —— 主机层日常巡检采集输出 Markdown 日报 # 用法: bash ops_daily.sh /tmp/ops_daily.md set -uo pipefail OUT${1:-/tmp/ops_daily.md} # 输出文件路径缺省写到 /tmp DISK_WARN85 # 根分区使用率告警阈值百分比 SERVICESsshd crond mysqld nginx # 需要巡检的关键服务列表 { echo # 巡检日报 $(date %F %T) $(hostname) echo echo | 项目 | 数值 | 阈值 | 结论 | echo | --- | --- | --- | --- | # 根分区使用率 disk$(df -P / | awk NR2 {gsub(%,,$5); print $5}) [ $disk -ge $DISK_WARN ] flag告警 || flag正常 echo | 根分区使用率 | ${disk}% | ${DISK_WARN}% | ${flag} | # 内存使用率取整 mem$(free | awk /^Mem:/ {printf %d, $3*100/$2}) [ $mem -ge 90 ] flag告警 || flag正常 echo | 内存使用率 | ${mem}% | 90% | ${flag} | echo echo ## 关键服务状态 for s in $SERVICES; do if systemctl is-active --quiet $s; then echo - ${s}: 运行中 else echo - ${s}: 未运行 fi done echo echo 近 24 小时登录失败次数: $(lastb 2/dev/null | wc -l) } $OUT echo 已生成: $OUT脚本的第一个参数决定日报落盘位置便于接入定时任务后按日期归档。DISK_WARN和内存阈值分开写是因为磁盘增长通常缓慢、可预测内存波动大用同一个阈值会误报。SERVICES用空格分隔的字符串而不是数组是为了兼容较老的 bash 版本。set -uo pipefail中刻意不加-e因为单项采集失败不应该中断整个日报生成。方案里附上这段脚本后再补一句「日报每日 8:30 前推送至甲方运维群异常项自动转为工单」工具就从名词变成了动作。4.4 应急预案与演练记录应急预案要按场景写不按部门写。常见场景至少覆盖数据库实例宕机、存储阵列故障、核心网络中断、机房断电、勒索软件感染、核心人员离职、上游厂商停止支持。每个场景给出五要素触发条件、处置步骤、责任人、恢复目标、演练频次。恢复目标用 RTO 和 RPO 表示例如核心数据库 RTO 不超过 2 小时、RPO 不超过 15 分钟。这两个数字必须和备份策略对得上如果 RPO 写 15 分钟备份策略就不能是每日一次全备。演练要写频次和交付物。常见承诺是每半年一次桌面推演、每年一次实战演练演练后 5 个工作日内提交报告包含发现问题清单和整改计划。5. 报价口径、绩效域自检与终审脚本5.1 运维费用科目怎么和报价对齐技术标和报价表经常对不上方案里写了 5 人驻场报价表里只有一个总包价。评审时容易被要求澄清澄清不好还会被质疑低于成本价。稳妥的做法是让两边科目一一对应。下表是常见的拆分方式。费用科目包含内容计量方式报价依据硬件维保费服务器、存储、网络设备原厂或第三方维保按设备台数/年设备清单 维保报价单软件维保费数据库、中间件、虚拟化平台订阅与升级按套/年厂商续保报价驻场服务费驻场人员薪酬、社保、管理成本按人月人员配置表远程支持费二线、三线专家按需支持按年包干服务目录工作量估算备件耗材费硬盘、电源、光模块、打印耗材按实际或包干近三年消耗统计应急响应费P1 事件现场支持、灾后恢复按次或包干历史事件频次培训与文档费用户培训、操作手册、年度总结按次培训计划不少地方财政对信息系统运维开支的科目和标准有专门规定比如江西省省本级出台的信息系统建设及运维服务开支管理暂行办法对运维费用构成和列支口径做了约束。如果项目资金来自同类渠道报价表的科目名称最好与之保持一致减少被要求澄清的概率。5.2 用项目绩效域做技术标自检信息系统项目管理师的知识体系里绩效域是一套现成的自检框架。写完后按下面的方式对照一遍能发现方案的结构性缺口。绩效域映射到标书的检查点常见缺口干系人是否区分了甲方信息科、业务部门、终端用户三类诉求只写「满足甲方要求」团队岗位、资质、排班、备岗、培训计划是否齐全缺备岗和离职顶替机制交付服务目录、交付物清单、验收标准是否明确交付物只有「服务报告」四个字测量SLA 指标、统计口径、考核办法是否闭环有指标无统计来源不确定性应急预案、风险清单、备用方案是否覆盖只写「制定应急预案」规划年度计划是否拆到季度和月度只有一张甘特图把这张表当成终审清单用逐项在方案里找到对应段落并标注页码找不到的补写写得虚的改实。5.3 终审脚本关键词覆盖与数值一致性检查定稿前用脚本做一遍机械检查比人眼翻 PDF 可靠。重点查两件事评分细则里的关键词是否都出现以及全文数值是否自相矛盾。# bid_check.py —— 技术标终审辅助关键词覆盖 数值一致性 import re from pathlib import Path REQUIRED [服务范围, 响应时限, 值班, 备品备件, 应急预案, 知识库, 考核, 保密, 交接, 培训] NUMERIC [99.9, 7×24, 30分钟, 4小时, 2小时, 15分钟] def check(path): text Path(path).read_text(encodingutf-8) print( 必备关键词 ) for kw in REQUIRED: print(f[{命中 if kw in text else 缺失}] {kw}) print(\n 关键数值出现次数 ) for n in NUMERIC: cnt text.count(n) tag 仅 1 处核对口径 if cnt 1 else (未出现 if cnt 0 else 正常) print(f{n}: {cnt} 次 ({tag})) print(\n 页面残留标记 ) for m in re.findall(r(TODO|待补|XX公司|某某|占位), text): print(发现待处理标记:, m) if __name__ __main__: check(technical_bid.md)脚本里REQUIRED列表应该直接从评标办法的技术评分细则里抄每条分值对应的名词都放进去。NUMERIC列表的价值在于抓一致性如果「2小时」只在全文出现一次很可能某一处承诺和别处对不上需要人工确认是不是笔误。re.findall那一段专门抓写作过程中留下的占位符这类标记一旦漏进正式投标文件是很尴尬的失分点。运行完脚本后还要做两件机器做不了的事把正文里的章节号和页码重新核一遍确认条款矩阵里的引用没有因排版位移而失效再让一个没参与写作的人只看评分表、不看正文试着从目录里找出每一条得分的落点找不到的就是还没写到位的地方。本文还有配套的精品资源点击获取