高质效创新组织：数字化时代下科技运营转型探索实践

张炜马上消费金融科技运营部负责人 张炜 公司职位马上消费金融-科技运营部负责人 拥有超过16年的技术运营管理经验，目前担任马上消费金融股份有限公司的科技运营部门负责人。 在公司成功实施了多项DevOps实践，提升软件交付的速度和质量，同时确保了生产环境的高可用性和稳定性，基本形成需求到生产端到端闭环运营管理。 数 字 化 技 术 加 速 融 合 目录 创 新 与 风 险 兼 顾 的 研 发 管 理 体 系 高 效 稳 定 的I T服 务 与 运 营 体 系 数 字 化I T投 资 管 理 数字化技术加速融合 数字技术以各种形式融入企业原有技术体系，企业形成新的技术创新能力 技术运营管理变革 •工具的自动化和智能化，要求更高工作效率和质量•决策过程的数据化和实时化，决策更加精准和高效。 以自动化提高工作效率 容器化和微服务架构 多云和混合云策略 DevOps的融合 容器化技术（如Docker）和微服务架构正在改变应用程序的部署和管理方式，要求IT运营适应这些新方法。 DevOps实践的普及正在改变IT运营，通过持续集成和持续部署流程，实现更快的软件交付和更紧密的开发与运营团队协作。 企业越来越多地采用多云和混合云策略，这要求IT运营能够管理多个云平台和本地环境。 数据驱动的决策 业务连续性和灾难恢复 随着远程工作和分布式系统的普及，确保业务连续性和有效的灾难恢复计划变得更加重要。 随着大数据的深度和广泛应用，企业正在利用数据分析来优化运营流程、提高客户满意度，并做出更加明智的业务决策。技术运营通过数据驱动持续改进。 在市场快速变化和技术加速融合过程中，IT运营要确保变革顺利进行，同时为企业带来持续的价值增长 业务发展对IT快速响应与灵活交付的挑战 IT运营面临的挑战. 技术融合加速对IT稳定运营管理的挑战 商业价值的不确定性对IT科学投资决策的挑战 DevOps目标是让研发更快，让业务更稳，让决策更准 实现IT运营价值创造需要完成的模式转变 创新与风险兼顾的研发管理体系 权责明确的高效的科技运营组织模式与运行机制 健康的科技运营系统能够应对环境变化、应对意外，并自我成长 自组织性 组织模式：集中与分散的平衡 需求管理：承载DevOps开发模式的PPR/PER/PIR管理 三种开发模式：支持不同场景的需求实现，在高频发布场景下保证生产发布的质量 (1).需求管理：场景驱动，形成高效流动的“价值漏斗” 价值创造以需求的形式承载，需求管理的目标是有效识别并驱动价值流的快速流转。 传统IT的需求管理多是单向接收业务部门诉求，然后按研发流程进行需求分析、计划、开发测试和发布交付，在IT内部，价值流本身没有问题。但在当下确出现了越来越多的交付问题，例如： •需求和价值流的管理范围局限在IT内部无法适应数字化转型所带来的快速响应市场的要求 •IT花了时间和精力，投入了资源，但交付质量欠佳 •需求来回拉扯，沟通成本高，效率低 •业务部门、研发部门存在严重的协作鸿沟，导致目标、资源、时间等诸多因素的不对称，并且相互交叉、干扰 •需求交付的效果与用户预期偏差大，用户满意度低 需求管理和敏捷协作扩展到业务领域： •以场景驱动，建立价值流漏斗，形成从输入到输出的全价值链交付。•从需求提出、评估分析、排期开发、测试验收、上线交付等各个环节进行全覆盖，对研发过程、数据、资源实现透明化。•业务部门可以快速得到反馈，研发部门能够理解需求本质，从而做出更准确的评估和方案。 度量的目标是让效能可量化、可分析、可改进，通过数据驱动的方式更理性的评估和改善效能 技术目标是持续提升研发流程的效率、保证规范的执行、提升质量和效率，持续提升是精益的更高追求，寻找提升空间需要思考的问题是： 我们的流程是高效的吗？阻碍在哪里？我们的规范落地执行情况如何？流程控制是否存在漏洞？我们的研发质量和效率如何？短板在哪里？ 度量指标能够客观反映现状，帮助我们看到现状与目标之间的差距 然而，这只是技术视野，我们还要了解业务方的期望，才能知道我们的视野是否足够开阔，才能决定改进的方向，不能闭门造车 能够提供更全面的IT产品和更高效的IT服务能够更快地响应需求及完成交付能够为业务应用更稳定地提供更高质量的交付 完整的价值度量体系，量化产研关键活动，指标驱动效率和质量持续改进 交付效率 交付质量 风险控制 目标是促进端到端及早交付，用最短时间顺畅地交付客户价值。它反应的是整个团队（包含产品、开发、测试，部署）对用户需求的响应速度。 目标是促进端到端高质量交付，避免不必要的错误和返工，驱动内部、外部质量改进。 采取各种措施和方法，消灭、减少风险事件的发生，或是降低风险事件发生时造成的损失。它反应的是当线上系统或应用发生故障时，多久可以消除业务影响。 高效稳定的IT服务与运营体系 联邦制SRE模式：倡导SRE文化，推行联邦制SRE运维模式，促进研发、运维高效协作 运行机制 •各团队SRE为“邦”，分别开展监控巡检、变更 管 控、容 量 规 划、NCMDB数 据 管 理、ONCALL应急（含演练）、问题复盘跟进等6项核心工作•科技运营团队统筹共性的体系、流程、工具平台，建立沟通协作机制，联系各团队SRE总结分享和推广最佳实践 优势 •“联”的优势：形成统一的规范、流程、工具平台框架体系，便于统一管理和生产高效运行•“邦”的优势：各SRE团队职责边界清晰，能够更高效、更便捷地服务于本团队的研发生产工作 服务容量和业务容量：建立服务SLO稳定性标准 建立服务SLO稳定性标准 目标 效果1：建立服务稳定性的量化标准 效果2：基于服务稳定性标准的主动预防机制 效果3：建立服务稳定性可视化度量 建立业务、应用、组件等的服务稳定性量化标准，基于标准观测服务状态。 可视化生产所有服务的的稳定性运行情况(错误消耗、SLA达标情况等)。 明确标准，基于服务稳定性标准的主动预防机制 优化改进：形成完备的稳定性度量体系 优化改进：建立服务治理闭环处理流程 优化改进：分层梳理SLI、SLO、SLA ③治理服务质量 ②管理服务SLI/SLO/SLA ①分层梳理服务目录和服务级别 发布管理：灵活多样的部署流水线，自动触发代码检查和自动测试，提升发布速度和质量 说明：1.蓝绿部署，是指不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。 2.金丝雀部署，也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。3.滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。 CMDB配置管理：明确数据owner职责要求，cmdb数据消费唯一数据源和数据生产的闭环机制提升的准确性 监控告警：构建以业务为导向的监控体系，快速明确业务影响，缩小故障域位置，提升运维效率 排障思路 在业务影响判断阶段：首先利用驾驶舱首层定位受影响的业务域，通过结果指标快速识别问题区域。 通过二层看板进一步缩小故障范围，具体查看异常业务节点。 利用全息监控，将业务节点与服务异常关联起来，涵盖指标、日志和链路，实现故障的全面诊断。 最后，通过风险预警大屏，追溯服务至对应的组件和基础设施，进行异常检测和风险预警，确保及时响应和业务稳定性。这一流程通过分层诊断，从业务域到具体节点，再到服务和基础设施，构建了一个系统化的故障分析和预警机制，有效提升了故障定位的准确性和业务运维的效率。 问题管理：明确整改方案，有效追踪改进过程和效果 目标： 问题管理的最终目标是消除引起事件的深层次根源以防止事件再次发生，包括主动性问题管理和被动性问题管理两类活动。被动性问题管理的目标是找到事件根因并纠正；主动性问题管理的目标是通过消灭基础设施的薄弱环节来阻止事件的发生。 科技服务台：补足对故障全生命周期完整管理的能力 目标： 服务台从根本上来说，是用户和IT部门的唯一接口。通过集中方式提供服务。服务台的根本目的是提供受理人员支持，并通过变通方法、解决方案或升级到处理人员支持等手段，帮助用户将IT服务恢复到正常工作状态。 关键活动： 无服务台，不ITSM 对IT用户提供支持，面向业务输出价值为IT部门赢得口碑，为二期工程（ITIL服务转移流程）创造条件 感谢大家观看