华为云DevOps系列之—— DevOps 转型

总体概览：DevOps 实施阶段

• 访谈评估
  • 首先对研发团队的各个角色进行访谈和自评估，从每个角色自己角度了解其所处环节的状况
  • 了解研发中每个过程可能涉及到的不同部门的不同角色，以及上下游衔接情况
• 过程建模
  • 根据访谈和评估结果，将 DevOps 过程分成 15 个子过程进行评级并提出改进建议和落地方案
• 持续改进
  • 以上评估/建模/改进过程将在整个咨询服务过程中迭代进行，按照 3个月/6个月/12个月的阶段，提出每个阶段的状态评估和改进建议，并配合我们的实施团队提供 DevOps 落地服务

准备阶段

一、选择合适的试点项目

• 在实施团队DevOps的过程中要先选择合适的试点项目，选择的标准可以参考以下三个方面
• 绿地项目与棕地项目
  • 绿地项目和棕地项目最初用于描述城市规划和建设项目。2014 年 DevOps 企业峰会上分享的转型案例中，棕地项目所占的比例超过 60%
    • Green field: 大部分是试点项目，全新的软件项目，有机会构建全新的应用和基础设施，对已有的代码库、流程和团队没有太多顾虑
    • Brown field: 已服务客户的产品或服务，大部分有很多技术债务，没有自动化测试，紧耦合架构
    • 改进棕地项目时，不但要努力降低复杂性，提高可靠性和稳定性，而且还应该更快，更安全，更容易变更；团队可能更愿意尝试
• 兼顾在 SOR 记录型系统和 SOE 交互性系统
  • Gartner 双模 IT：SOR 侧重于做得正确，SOI 侧重于做得快速
  • 高绩效组织能够兼顾高水平的生产能力和可靠性，每一位客户都应该同时享有速度和质量
  • 两者都合适做试点
    
• 从最有同理心和最乐于创新的团队开始，扩大 DevOps 的范围
  • 发现创新者和早期使用者
  • 赢得沉默的大多数，识别 “钉子户”
  • 尽早展示成果并积极宣传，将大目标分解成渐进式的小步骤
    

二、组建全功能团队

“系统设计受限于组织自身的沟通结构，组织规模越大，灵活性就越差，这种现象也就越明显” —— Melvin Conway, 1968

• 康威指出：系统设计受限于组织自身的沟通结构
  • 第一定律：组织沟通方式会通过系统设计表达出来
  • 第二定律：时间再多一件事情也不可能做得完美，但总有时间做完一件事情
  • 第三定律：线型系统和线型组织架构间有潜在的异质同态特性
  • 第四定律：大的系统组织总是比小系统更倾向于分解
• 软件开发团队的结构对软件产品的架构和成果有巨大的影响
• 利用康威定律组织团队，减少工作交接次数，提升交付速度和成功率
• 小团队独立运作，彼此充分解耦，避免过多的沟通与协调
• 松耦合架构
  • 面向服务架构 SOA，由限界上下文的松耦合服务组成
  • 微服务架构
• 两个披萨原则，保持小规模
• Robert Fernandez 博士定义了组织结构类型的3种类型
  

三、团队成熟度评估

• 价值
  
• 能力
  
• 角色
  
• 评估之后的结果分为以下5个 level
  
• DevCloud 为企业提供专业评估诊断，对被评估对象在 DevOps 领域方面的能力或现状进行分析、评判并给出建议
  • DevOps 成熟度评估【主观评估】：主观评估就是基于主观信息或依据做出判断的评估方式（eg：问卷调查）
  • 用户故事成熟度评估【客观评估】：客观评估是基于客观事实或数据做出判断的评估方式（eg：基于系统数据进行计算得出结论）

四、绘制价值流图，识别阻碍点

• 召集所有关键成员，绘制价值流图
• 记录主要的步骤和细节，让相关干系人拥有同样的视图
• 重点分析和优化，识别阻碍：需要等待数周甚至数月的工作；引发或处理重大返工的工作
• 确定想要改进的度量指标，通过探索各种假设，然后分析结果，不断迭代和重复，将获得的经验用于下一次实验

• LT：Lead Time，是一个过程从发起到执行完毕之间间隔的时间。在精益生产中为缩短和预测价值流中的前置时间。可以采用这些方式：减小批量尺寸、减少在制品、避免返工、确保不把次品传递到下游、持续不断的全局优化
• C/A：Complete & Accurate，返工效能比率，关注返工指标
• 可视化价值流图要注意以下4点
  • 端到端的流程映射
  • 识别浪费，低效，瓶颈
  • 确定改进度量指标
  • 创建改进故事板

价值流分析实例

• 日常作业活动耗时：最短耗时约 73分钟，最长耗时约 15小时

实施阶段

一、知识储备

一、确定实施的优先级

二、基础知识培训、理论准备

软件研发过程：管理属性和工程属性

• 项目规划
  • 使用 DevCloud 提供端到端的需求版本管理能力，每个工作项上都可以设置迭代字段代表需求所需的项目规划；而与这一需求相关的任务/测试用例/缺陷/问题等可以相互关联
    
• 软件交付
  • 某一版本规划中的任务等工件驱动开发人员完成编码后，开发人员可以将代码变更与工作项进行关联
  • 同时 DevCloud 构建服务会自动生成交付版本号，并将其所包含的的代码变更与之关联，因而形成了从 “版本规划” 到 “交付版本” 的跟踪能力
  • 同时，使用构建服务还可以保证交付版本完全受控，确保开发/测试/交付版本的一致性
    

二、推动落地团队级敏捷举措

三、推动 DevOps 工程实践举措

四、推动实施企业级 DevOps 举措

• 在 DevOps 转型成功的路上，实现企业级敏捷是转型成功的最理想状态
• 企业规模化 DevOps 转型怎么实现：我们采用变革八步曲结合华为变革流程，通过多循环迭代，最终完成企业 DevOps 转型
  

企业级 DevOps 落地策略：组建专门的转型团队

• DevOps转型面临的一个固有挑战：与公司当前的业务发生冲突，公司仍采取各种措施延续和保护当前的运作流程。为了适应市场变化，需要改变工作方式，需要组建转型团队以确保转型过程中从管理层到基层团队目标一致、沟通高效、响应快速，从而有效实现组织转型目标。其关键点是 确保组织管理层深度参与

企业级 DevOps 落地策略：设置转型路径与蓝图

• 第一阶段闭环：开发测试融合，组建研发部门内部的跨职能团队，提升自动化水平，降低修复成本
• 第二阶段闭环：需求开发测试融合，将产品、研发、测试等角色融合，组建跨职能团队，提升产品交付价值与质量
• 第三阶段闭环：研发运营一体化，实施产品自运营、自运维，打破了市场、研发、运维部门之间的壁垒，更多角色融入交付链路，提升业务响应力，建立价值反馈流
• 第四阶段闭环：目标是逐步实现所有业务线都以跨职能团队为最小组织单元，实现业务敏捷性，持续提升企业的市场竞争力

回顾总结：DevOps 转型整体方案

思考题

（单选题）以下对于 Two-Piaaz 团队规模说法正确的是？

• A. 团队一般大于15人小于20人
• B. 团队人数为两张披萨切成的块数
• C. 两个披萨能让队员吃饱的人数
• D. 做两个披萨需要的人数

答案：C

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊