字数 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》