字数 10496，阅读大约需 53 分钟
第14讲：谁来管数据，管什么？——数据治理
一、 上节回顾与热身
1. 上节核心回顾
同学们，早上好！欢迎回到《软考找老孙》的通关课堂。
上节课，我们一起学习了如何将一个已交付的项目“养好”，而不是仅仅“生好”，掌握了IT服务管理（ITSM）的精髓。通过学习，我们建立了两个核心认知：
- 1. 一个核心转变：“项目思维” -> “服务思维”
- • 我们用“盖房子 vs. 管酒店”的类比，彻底搞懂了“项目管理”（一次性交付）和“IT服务管理”（持续性运营）的本质区别。
- • 高项认知： 一个高项经理，不仅要对项目的“交付”负责，更要为项目上线后的“长期健康运营”去规划和思考。
- 2. 一个核心流程：“事件 -> 问题 -> 变更”的闭环
- • 我们用“智能门锁失灵的惊魂一夜”的故事，将服务台、事件管理（救火）、问题管理（找火源）、变更管理、配置管理这五大ITIL核心流程，串联成了一个完整的“持续改进”闭环。
- • 高项认知： 案例分析中，如果遇到运维相关的场景，能清晰地辨析“事件”和“问题”，并提出“建立问题管理流程”和“使用已知错误数据库（KEDB）”的建议，是得分的关键。
2. 上节课后作业精讲
上节课的第三个作业，极其经典，它触及了几乎所有IT组织都面临的“世纪难题”——研发（Dev）与运维（Ops）之间的“部门墙”。
场景复盘：
“智慧邻里”项目移交给运维部后，运维部抱怨“文档不全、代码烂、找不到人”，业务部抱怨“服务质量下降、响应慢”。两边都把矛头指向了你这个“生父”（项目经理）。你，怎么办？
我看了大家的作业，很多同学都提到了要“开复盘会”、“加强沟通”、“完善文档”。都对，但这些还只是“术”的层面。一个高项经理，必须能从“组织文化”和“流程再造”的高度，去提出系统性的解决方案。
这个问题，在现代IT领域，有一个专门的术语来描述，叫做“DevOps”。它就是为了打破这堵“墙”而生的。现在，看老孙如何用“DevOps”的思维，来主持这场“服务提升复盘会”，并拿出一份让所有人都无法拒绝的《DevOps转型行动方案》。
【“打破部门墙”复盘会全景推演】
(你组织了一场由你、业务部张总、运维部老王、以及原项目组的核心研发人员共同参加的会议)
(开场白：不指责，定基调——我们面对的是“共同的敌人”)
“各位，今天请大家来，不是为了互相指责。我们现在面临一个共同的敌人——低效的协作流程和下降的客户满意度。研发、运维、业务，我们都在同一条船上，船漏了，谁也跑不了。今天，我们就是要一起来‘补船’。”
“老王（运维）的痛苦，我理解。业务的抱怨，我也感同身受。这说明，我们过去那种‘研发管生，运维管养，生死不相往来’的瀑布式交接模式，已经行不通了。我建议，我们引入一种新的协作文化——DevOps，核心就是‘你中有我，我中有你，共同为最终的服务质量负责’。”
“为了将这个理念落地，我草拟了一份《DevOps转型行动方案》，基于业界成熟的CAMS模型（Culture文化, Automation自动化, Measurement度量, Sharing共享），希望能和大家一起探讨和完善。”
(你打开PPT，展示出精心准备的行动方案表格)
《“智慧邻里”运维体系DevOps转型行动方案 V1.0》
| 转型支柱 | 当前痛点 (Problem) | 行动方案 (Action) | 责任人 | 成功衡量指标 (Metric) |
|---|---|---|---|---|
| 文化 (Culture) | 出了问题，互相指责，研发和运维成了“敌人”。 | 1. 建立“无指责复盘(Blameless Postmortem)”机制，所有P1/P2级事件，必须在48小时内召开复盘会，只问“为什么”，不问“谁”。 2. 将团队的考核目标，从“个人KPI”转向“共同的团队OKRs”，比如“季度系统可用性达到99.95%”。 | 你(PM) | 1. “指责性”词汇（如“你的锅”）在复盘会纪要中出现的次数<1。 2. 团队成员在匿名调研中，对“跨部门协作顺畅度”的评分 > 4.0/5.0。 |
| 自动化 (Automation) | 发布过程靠手动，文档靠人写，极易出错且效率低下。 | 1. 投入资源，建立一套完整的“持续集成/持续部署(CI/CD)”自动化流水线，实现从代码提交到上线部署的全程自动化。 2. 推广“基础设施即代码(IaC)”，所有服务器环境的配置，都用代码（如Terraform）来管理，确保开发、测试、生产环境100%一致。 | 研发负责人 | 1. 应用的“部署频率”从每月1次，提升到每周2次。 2. 因“环境不一致”导致的BUG数量，降低90%。 3. “变更失败率” < 5%。 |
| 度量 (Measurement) | 服务质量好不好，全凭“感觉”，缺乏客观数据支撑。 | 1. 建立一个统一的、对全员透明的“服务质量监控仪表盘”（基于Grafana），实时展示核心服务的SLI（服务水平指标）。 2. 共同制定并承诺核心服务的SLA（服务水平协议），比如“在线支付服务可用性 > 99.99%”。 | 运维负责人 | 1. 核心服务的“平均故障修复时间(MTTR)”，从4小时降低到30分钟。 2. SLA未达标的次数，每季度 < 1次。 |
| 共享 (Sharing) | 知识在“人脑”里，责任在“部门间”，信息孤岛严重。 | 1. 建立统一的、唯一的知识库（如Confluence），所有架构图、接口文档、应急预案（Playbook）必须在此维护。 2. 实行“谁开发，谁运维(You build it, you run it)”原则，让核心应用的开发工程师，轮流参与到二线“值班(On-Call)”工作中来。 | 你(PM) | 1. 80%的生产事件，能在一线/二线得到解决，无需升级到三线专家。 2. 80%的生产事件，其解决方案，能在知识库中被找到。 |
(你总结道)
“各位，这份方案，本质上是要打破我们之间的‘墙’。让研发从第一天起，就为‘可运维性’负责；让运维，能更早地参与到架构设计中来。我们不再是‘上游’和‘下游’，我们是一个为同一个‘服务价值’负责的‘命运共同体’。我建议，我们先用一个季度的时间，来试点推行，大家看怎么样？”
【老孙划重点】
同学们，DevOps不是一个“工具”，它是一种“文化”和“实践”。它通过“自动化”来减少重复劳动和错误，通过“度量”来对齐目标，通过“共享”来打破信息孤岛。作为高项经理，你推动DevOps文化，就是在为你的组织，打造一台高速、高质量、低风险的“软件交付工厂”。这在论文中，是体现你管理先进性的绝佳素材。
二、 咱们今天聊点啥？（本讲目标）
好，热身结束。上节课，我们学习了如何“管好系统”。今天，我们要探讨一个更深刻的话题：如何“管好数据”。