高质效创新组织
数字化时代下科技运营转型探索实践
目录
数字化技术加速融合
创新与风险兼顾的研发管理体系
高效稳定的 IT 服务与运营体系
数字化 IT 投资管理
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
数字化技术加速融合01
G O P S 全球运维大会暨 X O p s 技术创新峰会
数字技术以各种形式融入企业原有技术体系，企业形成新的技术创新能力
技术广泛应用 技术运营管理变革
• 工具的自动化和智能化，要求更高工作效率和质量
• 决策过程的数据化和实时化，决策更加精准和高效。
以自动化提高工作效率
从
传
统
工
具
到
新
一
代
智
能
工
具
从经验决策到数据决策
传统工具+
经验决策
新一代智能工具
决策
工具革命
+决策革命
基于数据反
数据运营反馈与 馈提高决策
科学化、精
准化
工具
革命
决策
革命
DevOps的融合 多云和混合云策略 容器化和微服务架构
DevOps实践的普及正在
改变IT运营，通过持续集
成和持续部署流程，实现
更快的软件交付和更紧密
的开发与运营团队协作。
企业越来越多地采用多云和
混合云策略，这要求IT运营
能够管理多个云平台和本地
环境。
容器化技术（如Docker）和
微服务架构正在改变应用程
序的部署和管理方式，要求
IT运营适应这些新方法。
业务连续性和灾难恢复 数据驱动的决策
随着远程工作和分布式系统的普及，
确保业务连续性和有效的灾难恢复计
划变得更加重要。
随着大数据的深度和广泛应用，企业正在利用数据分
析来优化运营流程、提高客户满意度，并做出更加明
智的业务决策。
技术运营通过数据驱动持续改进。
微服务
• 小型化
• 去中心化
• 可扩展
• 松耦合
大数据
• 体量大
• 速度快
• 多样性
• 可视化
云计算
• 资源池化
• 快速弹性
• 服务化、标准化
• 灾难恢复、数据备份
人工智能
• 学习能力
• 推理能力
• 语言理解
• 自适应性
在市场快速变化和技术加速融合过程中，IT运营要确保变革顺利进行，同时为企业带来
持续的价值增长
IT运营面临的挑战.
业务发展对IT快速响应与灵活交付的挑战
技术融合加速对IT稳定运营管理的挑战
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
商业价值的不确定性对IT科学投资决策的挑战
DevOps目标是让研发更快，让业务更稳，让决策更准
快
稳
准
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
实现IT运营价值创造需要完成的模式转变
架构轻量化
持续化交付
管理自动化
厚平台、薄应
用、微服务
敏捷交付
开发运维一体
化DevOps
基于云架构的
管控模式
弹性资源管理
传统模式
单块架构
架构
瀑布式开发
开发运维分离
运营 交付
竖井式
物理资源
基础设施
ＡＰＩｓ
微服务
合
作
伙
伴
A
P
I
敏捷交付
第三方交付
开发运维一体化-持续交付
一体化
软件定义基础设施，服务化
新 IT 模式
松耦合
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
实现IT运营价值目标需要具备的六项能力
IT 成为价值中心
重点是让公司更好的实现
“提升客户体验、加快业
务创新交付、为运营提能
增效”业务价值
客户服务能力
02
数据决策能力
04
连续性保障能力
01
IT服务能力
05
快速交付能力
03
运营协同能力
06
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
创新与风险兼顾的研发管理体系02
G O P S 全球运维大会暨 X O p s 技术创新峰会
权责明确的高效的科技运营组织模式与运行机制
健康的科技运营系统能够应对环境变化、应对意外，并自我成长
组织模式：集中与分散的平衡
自组织性
• 团队充分自治
• 去中心化决策
• 创新文化 自适应性
• 快速响应技术环境的变化
• 灵活的工作流程
• 持续学习和进步 层次性
• 多层次管理结构
• 模块化设计
• 信息流动和协作
运行机制：资源共享与协同工作
• 需要提高对市场变化的适应性和灵活性时
• 决策分散、快速响应市场变化和客户需求
• 部门墙、高协调沟通成本、资源分散
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
• 各业务领域快速适应新技术和创新时
• 自治与合作并存、分权与集权平衡、灵活性与统一
性结合；激发各技术条线的创新和市场适应性
• 需要较高的管理能力和协调机制
集 • 企业规模较小，业务单一
中 • 快速决策和统一行动
式 • 组织结构：金字塔形
• 依赖性高层管理者、市场响应慢
分
散
式
联
邦
式
支撑业务方向一致性
15年-17年
快速响应市场
18年-20年
创新、个性化服务
21年-24年
需求管理：承载DevOps开发模式的PPR/PER/PIR管理
需求角度
项
目
角
度
IT采购类基础建设类
开发类
PPR
PER
PIR
• PPR遵循项目管理方式，有生命周期
和 阶段定义；
• PER/PIR遵循需求管理方式，完成上
线 即为结束；
• 需求来源归属PPR（项目）、PER（项
目 关联/系统功能完善）、PIR（问题）
1
2
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
三种开发模式：支持不同场景的需求实现，在高频发布场景下保证生产发布的质量
需求提出 需求分析 需求评审 需求设计 需求实现 需求验收
需求变更
瀑布模式 增量迭代模式 敏捷模式
开发类项目实施阶段 开发类迭代实现 开发类紧急变更
上线发版开发活动
架构设计 架构评审 UI/UE设计 系统设计
设计评审 编码实现 代码评审 单元测试
DevOps平台
项目/需求/紧
急变更
需求阶段
研发模式
关键活动
平台工具
需求生命周期
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
(1).需求管理：场景驱动，形成高效流动的“价值漏斗”
价值创造以需求的形式承载，需求管理的目标是有效识别并驱动价值流的快速流转。
传统IT的需求管理多是单向接收业务部门诉求，然后按研发流程进行需求分析、计划、开发测试和发布交付，在IT内部，价值流本身没
有问题。但在当下确出现了越来越多的交付问题，例如：
• IT花了时间和精力，投入了资源，但交付质量欠佳
• 需求来回拉扯，沟通成本高，效率低
• 需求交付的效果与用户预期偏差大，用户满意度低
• 以场景驱动，建立价值流漏斗，形成从输入到输出的全价值链交付。
• 从需求提出、评估分析、排期开发、测试验收、上线交付等各个环节进行全覆盖，对研发过程、数据、资源实现透明化。
• 业务部门可以快速得到反馈，研发部门能够理解需求本质，从而做出更准确的评估和方案。
• 需求和价值流的管理范围局限在IT内部无法适应数字
化转型所带来的快速响应市场的要求
• 业务部门、研发部门存在严重的协作鸿沟，导致目标、
资源、时间等诸多因素的不对称，并且相互交叉、干扰
需求管理和敏捷协作扩展到业务领域：
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
度量的目标是让效能可量化、可分析、可改进，通过数据驱动的方式更理性的评估
和改善效能
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
技术目标是持续提升研发流程的效率、保证规范的执行、提升质量和效率，
持续提升是精益的更高追求，寻找提升空间需要思考的问题是：
我们的流程是高效的吗？阻碍在哪里？
我们的规范落地执行情况如何？流程控制是否存在漏洞？
我们的研发质量和效率如何？短板在哪里？
度量指标能够客观反映现状，帮助我们看到现状与目标之间的差距
我们的最高目标始终是为了更好地支撑业务，要了解业务方最迫切所需，及时调整技术改进方向，使技术目标与业务目标保持协调
然而，这只是技术视野，我们还要了解业务方的期望，才能知道我们
的视野是否足够开阔，才能决定改进的方向，不能闭门造车
能够提供更全面的IT产品和更高效的IT服务
能够更快地响应需求及完成交付
能够为业务应用更稳定地提供更高质量的交付
完整的价值度量体系，量化产研关键活动，指标驱动效率和质量持续改进
风险控制
采取各种措施和方法，消灭、减少风险事件的发生，
或是降低风险事件发生时造成的损失。它反应的是当
线上系统或应用发生故障时，多久可以消除业务影响。
交付质量
目标是促进端到端高质量交付，避免不必
要的错误和返工，驱动内部、外部质量改
进。
交付效率
目标是促进端到端及早交付，用最短时间顺畅地
交付客户价值。它反应的是整个团队（包含产品、
开发、测试，部署）对用户需求的响应速度。
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
高效稳定的IT服务与运营体系03
G O P S 全球运维大会暨 X O p s 技术创新峰会
SRE稳定性时空：四个维度支撑整个稳定性保障作
业
技术管理和运维活动
故障和稳定性生命周期
稳定性保障对象
平台能力建设
稳定性保障体系指标度量
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
联邦制SRE模式：倡导SRE文化，推行联邦制SRE运维模式，促进研发、运维高效协
作
• “联”的优势：形成统一的规范、流程、工具 平
台框架体系，便于统一管理和生产高效运行
• “邦 ”的优势：各SRE团队职责边界清晰，能
够更高效、更便捷地服务于本团队的研发生产
工作SR
E
科技运营
SR
E
研发团队 A 研发团队 B
• 各团队SRE为 “邦”，分别开展监控巡检、变
更管控、 容量规划、 NCMDB 数据管理、
ONCALL应急（含演练）、问题复盘跟进等6
项核心工作
• 科技运营团队统筹共性的体系、流程、工具平
台，建立沟通协作机制，联系各团队SRE总
结 分享和推广最佳实践
运行机制
优势
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
服务容量和业务容量：建立服务SLO稳定性标准
效果1：建立服务稳定性的量化标准 效果2：基于服务稳定性标准的主动预防机制 效果3：建立服务稳定性可视化度量
建立业务、应用、组件等的服务稳定性量化标准，基于标
准观测服务状态。
明确标准，基于服务稳定性标准的主动预防机制
可视化生产所有服务的的稳定性运行情况 (错误消耗、SLA
达标情况等) 。
优化改进：分层梳理SLI、SLO、SLA 优化改进：建立服务治理闭环处理流程 优化改进：形成完备的稳定性度量体系
①分层梳理服务目录和服务级别 ③治理服务质量
建立服务SLO稳定性标准
②管理服务SLI/SLO/SLA
目标
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
发布管理：灵活多样的部署流水线，自动触发代码检查和自动测试，提升发布速度和质量
滚动发布模式蓝绿发布模式 金丝雀发布模式
发布前
v1
发布后
v1
流量模式
v1
v1
负载均衡
v1
负载均衡
v1
v2
v2
v2
v2
v2
v2
发布前
v1 v1
先发一台验证
v1 v1
滚动发布
v1 v1
流量模式
负载均衡
v1
负载均衡
v1
负载均衡
v1
v2
v2
v2
v2
v2
v2
v2
v2
v2
发布前
先发一台
再发若干台
流量模式
负载均衡
v1 v1 v1 v2 v2 v2
负载均衡
v1 v1 v1 v2 v2 v2
负载均衡
v1 v1 v1 v2 v2 v2
直到全部发完
负载均衡
v1 v1 v1 v2 v2 v2
说明：
1. 蓝绿部署，是指不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。
2. 金丝雀部署，也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩
大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。
3. 滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
CMDB配置管理：明确数据owner职责要求，cmdb数据消费唯一数据源和数据生产的
闭环机制提升的准确性
目标
覆盖全
支撑业务消费场景所需的所有IT资产全部纳管接入
数据准
配置数据记录的信息及时真实可靠，不存在异常或错误
NCMDB
数据权威，面向业务，支撑业务发展
策略
基于应用从上层往下建设cmdb，下层基础架构设施往上全覆盖
- 优先基于应用为中心，从上至下建设cmdb
- 其次建设基础公共资源，然后从数据中心设施到逻辑资源全覆盖
- 基于分层模型、第三范式最小冗余、面向对象思想建模
消费驱动数据准确性
- Cmdb作为运维体系的唯一数据源，以消费驱动数据准确性，以视图方式，随需应变的满足消费场景需求
- 数据校验规则：完整性、准确性、关联性
- 数据准确性问题闭环机制：根据POC原则，所有的问题分配工单，由owner分析原因并根本性解决
1 2
不准
不信
不用
信任
消费
准确
落
地
方
案
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
监控告警：构建以业务为导向的监控体系，快速明确业务影响，缩小故障域位置，
提升运维效率
在业务影响判断阶段：首先利用驾驶舱首层定位受影响的业务域，通过结果
指标快速识别问题区域。
通过二层看板进一步缩小故障范围，具体查看异常业务节点。
利用全息监控，将业务节点与服务异常关联起来，涵盖指标、日志和链路，
实现故障的全面诊断。
最后，通过风险预警大屏，追溯服务至对应的组件和基础设施，进行异常检
测和风险预警，确保及时响应和业务稳定性。这一流程通过分层诊断，从业
务域到具体节点，再到服务和基础设施，构建了一个系统化的故障分析和预
警机制，有效提升了故障定位的准确性和业务运维的效率。
落地实践
业务监控体系建设示意图 排障思路
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
问题管理：明确整改方案，有效追踪改进过程和效果
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
目标：
问题管理的最终目标是消除引起事件的深层次根源以防止事件再次发生，包括主动性问题管理和被动性问题管理两
类活动。被动性问题管理的目标是找到事件根因并纠正；主动性问题管理的目标是通过消灭基础设施的薄弱环节来
阻止事件的发生。
关键活动：
问题管理按期解决率：92%
• 问题由SRE登记，更新
• 明确的问题归类
• 详尽的记录根因和解决方案
• 已知错误由SRE登记，更新
• 由问题管理人员组织干系人评估方案
• 详尽的记录解决过程，监控进展
• 验收解决结果
• 识别问题的发展趋势，防止问题扩散到其他系统
• 定期或不定期分析问题、已知错误的处理情况，有助于优化问题
管理活动有效性
关键活动 主要内容 马上
问题控制
负责找出问题并调查根因，采取措施将问题转化为已知错误
1. 发现、记录问题
2. 问题归类
3. 调查和分为问题
4. 临时修复
错误控制
管理，控制并成功纠正已知错误的过程，通过变更申请实施变更，确
保 已知错误消除，避免事件发生
1. 发现、记录错误
2. 评价错误
3. 记录错误解决过程
4. 终止错误
5. 跟踪、监督问题和错误的解决过程
主动性问题管理
在事件发生前发现和解决有关问题和已知错误，以尽量减少问题和已
知 错误对业务的影响
问题报告
定期或不定期提供有关问题、已知错误和变更请求等方面的管理信息，
供科技部门决策依据
科技服务台：补足对故障全生命周期完整管理的能力
目标：
服务台从根本上来说，是用户和IT部门的唯一接口。通过集中方式提供服务。服务台的根本目的是提供受理人员支
持，并通过变通方法、解决方案或升级到处理人员支持等手段，帮助用户将IT服务恢复到正常工作状态。
关键活动：
关键活动 主要内容 马上
请求接收
1.接收来自电话、网络、电子邮件等方式反馈的服务请求、事件
2.将用户上报的服务请求、事件完整记录到系统中，对事件进行适当
的分类并分配优先级等属性
1.处理可预定义或模板化解决的服务请求
请求处理
2.将事件分配给最合适的事件响应人员小组/人员来处理
3.跟踪服务请求、事件的处理过程，确保所有的故障和服务请求能够
以闭环方式结束
请求反馈
1.根据用户的需要检查事件记录的处理进度，适时通知事件处理进展
服务台自主解决率：>80%
服务台当日反馈率：100%
• 由服务台统一管理，登记请求、事件
• 对事件有明确的分类、优先级
• 定义各等级请求服务级别
• 有服务请求处理流程且运行顺畅
• 有效保障请求处理时效
• 跟踪处理进展，反馈用户处理进展
• 确保所有保障以闭环方式结束
• 反馈服务请求、事件处理进展给用户
• 组织故障复盘并输出复盘会议纪要汇总、分析事件报告
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
无服务台，不ITSM
IT
服务台
客服团队
基础运维团队
业务研发团队
监控系统报警信息
统一服务窗口
中介服务请求
开启服务流程
对IT用户提供支持，面向业务输出价值
为IT部门赢得口碑，为二期工程（ITIL服务转移流程）创造条
件
服务台坐席
ITSM
运维和研发工程师
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
T h a n k s
G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站
