政务与司法军警行业 ITSM 案例分析
政务与司法军警是两个常被并列讨论的行业：它们都不以「效率优先」为第一目标，安全、合规、可审计的权重远高于工单处理速度。直接搬商业企业那套 ITSM 打法——先把工单流程跑顺、再谈别的——在这两个行业往往水土不服。本章按行业分别拆解：真实特点、方案设计取舍、落地注意点。
一、数字政务行业
1.1 行业特点与典型痛点
数字政务的 IT 运维不是一个单位的事，而是一张网。省、市、县、乡多级纵向贯通，横向几十家委办局各有自己的业务系统，政务云与本地机房并存，信息中心名义上是「总包」，实际能直接调度的人财物却很有限。
从运维视角看，这个行业有四个绕不开的约束：
- 多层级、多主体协同。一个政务外网故障，可能涉及市政务云、运营商链路、区县接入点和某局的本地终端，责任边界天然模糊，工单如果不能把各委办局的运维接口人串进同一流程，最后就是互相转派、没人兜底。
- 等保与信创双重压力。核心政务系统普遍按等级保护三级建设，运维操作留痕、审计是硬性要求；同时信创替代进入深水区，国产 CPU、操作系统、数据库正在批量替换传统技术栈，运维工具本身必须先跑在国产化环境里，否则连被部署的资格都没有。
- 两类用户混在一个服务台。一边是内部公务员——办公电脑、VPN、业务系统权限、政务邮箱；另一边是外部市民和企业用户——通过 12345 热线、一网通办大厅触达的诉求。两者的诉求形态、响应预期、SLA 计算方式完全不同，用同一套服务目录和流程硬套，两边都不满意。
- 重建设、轻运维。政务信 息化以项目制推进，建设预算充足、运维预算偏薄，外包人员流动大，知识沉淀几乎为零——人一走，系统怎么维护就没人说得清。
| 痛点 | 具体表现 |
|---|---|
| 信息孤岛 | 各委办局系统独立建设，运维没有全局视图，故障定位要挨个打电话问 |
| 资产台账失真 | 政务云资源、本地设备、委办局自备设备三本账对不上，盘点靠 Excel |
| 服务入口混乱 | 市民热线、部门电话、微信群、OA 留言多渠道并行，工单无统一出口 |
| 流程无标准 | 依赖老师傅经验操作，操作不可追溯，等保检查时补记录 |
| 信创兼容盲区 | 新替换的国产 OS/数据库/中间件，传统监控工具采不到数据 |
1.2 适配的 ITSM 方案设计要点
服务目录必须双轨设计。 内部服务目录面向公务员用户，按「办公终端、网络接入、业务系统权限、账号邮箱」归类；对外侧不做开放式自助注册，工单来源主要是 12345 热线转派、大厅终端报障和上级督办件。边界要划清：12345 是市民诉求分类体系，ITSM 只承接其中「系统故障、账号权限、网络接入」类工单，政策咨询、投诉建议类仍走原有转办流程，不要硬塞进运维工单池。
服务台与身份认证。 内部入口对接统一身份认证（政务钉钉、政务微信或 CA 认证），避免再建一套账号体系；值班坐席按委办局设置二线接口人，一线服务台接单方负责分类、 转派、催办，不追求一线解决所有问题。
CMDB 建三层映射。 政务场景的配置管理不能只做设备台账，ECMDB 类工具至少要建出「业务系统—委办局—云资源/链路」三层关系：哪个系统归哪个局、跑在政务云哪台资源上、依赖哪条专线。这张图既是变更影响评估的依据，也是等保检查的直接材料。
监控联动要考虑政务云特殊性。 RadarDesk 类综合监控覆盖云宿主机、数据库、网络边界和关键业务系统可用性，告警自动转 ITSM 工单并按归属派到对应委办局运维接口人。注意：政务云上很多资源是租户形态，监控要支持 API 对接云平台，不能只靠 Agent 埋点。
权限与审计先行。 工单全流程留痕，按市局、区县局、外包人员分级授权，导出、批量操作、高权限变更全部记入审计日志。这部分功能不是锦上添花，是上线前的验收项。
1.3 落地启示与注意点
- 信创兼容要在 POC 阶段验证。 不要等项目上线才发现监控 Agent 跑不起来国产操作系统。POC 环境就应当包含国产 OS、国产数据库的采样测试，采不到数据的监控方案在政务场景里等于没有方案。
- SLA 不要照搬企业标准。 区县局往往没有专职运维，夜间值班只保核心业务系统（一网通办、政务服务平台），办公类工单按工作时间计算响应；一刀切 7×24 会把本来就薄的运维人力压垮。
- 分期上线比大而全现实。 政务运维预算按年拨付，合理顺序是：先工单+ 服务台（解决入口统一）→ 再 CMDB（满足台账与审计）→ 最后监控联动。一次性上全套，往往第一年预算花完、系统还没跑顺。
- 对外承诺要克制。 面向市民侧的工单只承诺「响应与进度可见」，修复时限按业务系统定级而定，不要在宣传里写死「X 分钟解决」——政务故障的处置权常常不在信息中心一家手里。
二、司法军警行业
2.1 行业特点与典型痛点
法院、检察院、监狱、公安系统的信息中心，和商业企业信息中心最大的区别只有一个字：稳。办案系统、庭审系统、监区管理系统、接处警系统停摆，影响的不是员工办公效率，而是执法活动本身和公共安全。
这个行业的运维约束可以归纳为四点：
- 网络物理隔离。 涉密网、内网、外网三网物理隔离，运维工具不能走公网 SaaS，必须本地化部署；运维终端的接入本身就要审批。这意味着任何「云端智能分析」「远程专家支持」的卖点，在这个场景里都不成立。
- 业务连续性要求极高。 庭审不能中断，监区监控不能黑屏，接处警系统不能掉线。夜间、节假日、重大活动期间的保障是常态，不是应急预案里的例外。
- 合规与审计最严。 等保三级起步，涉密系统还要过分级保护要求；运维操作全程留痕、变更必须审批、高危操作可回滚，审计记录要能调出来应付检查。
- 资源谱系复杂。 监区监控设备、专网通信、庭审记录系统、办公终端、机房服务器多品牌、多代际并存，老旧设备不能随便下线（业务还在跑），新系统又要接入。
| 痛点 | 具体表现 |
|---|---|
| 安全操作不可追溯 | 运维靠口头交接，变更无记录，检查时补材料补到加班 |
| 核心系统停机窗口模糊 | 各业务部门都要求「不能停」，变更只能挤深夜，排期打架 |
| 故障发现慢 | 靠用户报障才知道系统挂了，无主动监控，安全告警更慢半拍 |
| 资产账实不符 | 监区、分局、派出站点分散，设备台账多年不更新 |
| 多厂商互相推诿 | 网络、服务器、业务系统分属不同集成商，故障时三家互指 |
2.2 适配的 ITSM 方案设计要点
部署形态决定一切。 ITSM 平台、CMDB、监控系统全部本地化部署于内网，升级包和补丁经安全检查后离线导入。方案设计的第一步不是挑功能，而是确认部署架构是否过得了保密与等保审查。
服务目录按业务条线分区。 办案系统、庭审系统、监区安防系统、办公系统分别建服务目录，监区/安防类故障走特殊加急通道，与安保值班联动——这类工单不能按普通工单排队。
变更与发布管理从 严。 监管行业的变更风险远高于效率收益。ECMDB 建出业务拓扑后，变更申请必须标明影响的系统与人员范围，高危变更走审批与维护窗口，操作前快照、操作后回滚方案齐全。宁可慢，不可错。
监控与告警分级联动。 RadarDesk 对网络设备、服务器、数据库、业务系统可用性做统一监控，告警分级：核心执法系统告警自动生成 P1 工单，电话/短信通知值班负责人；一般告警转工作时间处理。监控平台自身也要高可用部署——监管场景里「运维系统自己先挂」是最被动的事故。
运维审计与堡垒机联动。 工单操作、登录记录、数据导出全部留痕归档，与堡垒机会话记录对应，满足等级保护和分级保护对「运维操作可追溯」的要求。
2.3 落地启示与注意点
- 顺序与商业企业相反。 商业项目常先上工单、再补 CMDB；监管行业建议先做资产盘点与 CMDB——台账本身就是监管检查的必查项，先把这关过了，后面的流程推广才有底气。
- 保密红线高于一切效率考虑。 厂商实施人员入场、远程支持、版本升级都按涉密管理流程审批；远程运维原则上不开放，驻场实施加离线文档是常态。任何要求把数据传出内网的功能设计，直接砍掉。
- SLA 分层而不是一刀切。 核心执法系统 7×24 保障，办公与行政系统工作时间保障；值班排班按此设计，不要承诺全系统全天候——运维人力撑不住，承诺了就是给自己埋雷。
- 对厂商的花哨概念保持警惕。 这个场景需要的是操作留痕完整、审计可查、流程可控，任何「智能压缩」式自动化卖点，如果代价是日志不全、操作不可追溯，都不要碰。监管行业出问题，查的就是那几条记录。
小结：政务与司法军警行业的 ITSM，效率是第二位的，安全、合规、可审计才是第一位。方案取舍的标准只有一条——任何功能如果过不了等保、分保或信创这三关，再好也不能上；先把合规底座打牢，再谈提效。