凤凰项目&DevOps实践指南

CD过程中能不能抽象出来一些模型：资源申请，配置变更，包更新，冒烟与回归测试，回滚，灰度发布，其他。

 

在低信任度和命令式的文化环境中，更多的变更控制和更多的测试反而让问题再次出现的可能性变得更高。

 

生产环境变更失败带来的负面影响：

• 在变更申请表格中增加更多的问题
• 增加审批步骤
• 增加审批时间

增加更多的问题会让人们倾向于把大量变更一起送审以减少送审次数，减慢反馈，并增加开发和运维之间的gap。

增加审批步骤，由远离一线的管理者进行审批，反而会降低成功的可能性。做事的人和做决策的人离得越远，结果就越差。

 

严格的发布章程和自动化发布审批功能。开发一个仪表盘，从三个视角自动化审视一次发布是否可行：

系统。我的产品情况如何

价值流。上下游依赖关系

环境。平台，事件。

 

全局基础设施的变更，需要做好灰度，监控，故障切换，全面测试，演练。

 

人为错误并不是问题的原因，恰恰相反，人为错误是我们提供的方法或工具存在设计缺陷而导致的后果。

 

DevOps三要义：

• 实现工作快速的从左向右流动。即从开发部门到运维部门再到客户流动。为了最大限度地优化流动，需要采取多项措施：对工作进行可视化、缩小工作批量大小、缩短工作间隔时间、通过质量内建防止缺陷向下游传递，持续地针对局部目标进行优化。相关实践包括：持续构建，持续集成，自动化测试与部署，按需搭建环境，限制在制品数量，构建可安全实施变更的系统和组织。
• 从右到左，持续地对各个阶段的工作进行监控和快速反馈。通过强化反馈回路来杜绝问题复发，或是使我们能在问题复发时更快地进行定位和修复。这种方式让我们能够从源头把控质量，并把相关知识内嵌到流程之中，从而构建更为安全的工作体系，将灾难性的故障扼杀在摇篮里。通过及时发现问题、群策群力解决问题直至找到更有效的应对措施，持续缩短和强化反馈回路，这几乎是所有现代流程优化方法的核心概念，它能为组织创造出更多学习与改进的契机。
• 打造高信任度的生机型企业文化，支持活跃、严谨、科学的探索和冒险，促使组织从成功和失败中汲取经验和知识。此外，持续缩短和强化反馈回路也让工作体系的安全性与日俱增，使团队能更好地承担风险进行探索，获得比竞争对手更强的学习能力，进而在市场竞争中胜出。

DevOps三要义的实际应用：使用价值流图辅助优化流程，选取度量的成果以建立快速反馈，以及通过沉浸式学习体验打造持续学习与探索的文化。

 

DevOps Platform的目标“更快的交付价值”。

度量指标：业务的部署频率，部署时长，变更失败率，事故数量，平均修复时间， 开发周期（RM?）。

措施：绘制价值流图+沉浸式学习。

绘制价值流图的关键：每一步的耗时，某一步必须等待(半成品)

 

实现第一要义的关键：理解工作流，找到瓶颈点并可视化瓶颈点，开发可视化工作管理工具，减小每次代码从开发到部署到生产环境的时间(持续构建，集成，测试，持续部署)，通过内建质量杜绝向下游传递缺陷，并持续的优化全局目标

实现第二要义的关键：让等待时间可视化。缩短问题检测周期，实现快速修复。持续的缩短和放大反馈环。

实现第三要义的关键：建立信任文化，无责任复盘，主动承担风险。

 

等待时间是“忙碌时间百分比”除以“空闲时间百分比”。一个资源的忙碌时间是50%，则空闲时间也是50%，等待时间就是50%除以50%，也就是1个时间单位。如果一个资源90%的时间是忙碌的，那么等待时间是90%除以10%,也就是9个时间单位。换言之，我们的任务排队等待的时间，将是资源有90%空闲时间都9倍。

 

有4种类型的IT运维工作：业务项目、IT运维项目、变更、计划外项目。

 

半成品是个隐形杀手，尽可能的减少半成品。

 

根据瓶颈资源所能完成工作的速度来安排工作。

 

在看板上按类别列出所要完成的事情，并对每一个事情给出相关状态(在办，进行中，完成，卡住)

 

技术价值流：把业务构想转化为向客户交付的价值，由技术驱动的服务所需要的流程。

前置时间：从工单创建后开始计时，从工作开始做结束。

处理时间：从实际开始处理这个工作时开始计时，不包含这个工作在队列中排队等待的时间。

要想办法把重点放在缩短前置时间上。如果工作时部署，则前置时间是部署前的开发测试。常见的约束点是：环境搭建、代码部署、陪着变更的等待时间、测试的准备和执行、紧密耦合的架构。

 

如果开发人员能快速独立的开发、集成和验证代码，并能将代码部署到生产环境中。这样，我们就能快速获得反馈。

 

返工指标：bug fix, outage, rca等计划外的工作，都是返工。

 

开发、运维和安全等不同职能部门之间的良好合作是成功的关键。这些部门之间目标相左会影响重要目标的顺利达成。

 

什么是"啊哈"时刻？采用了某种新的方式，极大的提升了生产效率或取得了比预期大的多的成功。

 

IT运维不只是工单驱动的手工操作，而是能够通过自助服务平台和API来提升开发人员的生产效率，让他们能自助地创建开发环境，测试和部署代码，监控和显示业务运行的状态等。通过这种方式，IT运维人员变得更像是开发人员，融入到产品开发过程中，而该产品则是开发人员在生产中用来安全快速的测试，部署和运行IT服务的平台。

 

浪费和困境是软件开发过程中导致交付延迟的主要因素：

• 半成品：尚未完成的工单，未完成的设计或代码或文档。半成品会随着时间的推移最终失去价值。
• 额外的工序：额外的审核步骤，下游用不上的文档。
• 额外的功能：客户完全不用或很少使用的功能。
• 任务切换：人换项目，人离职。
• 等待：瓶颈点。
• 移动：过多的会议。
• 缺陷：信息缺失需要二次确认。
• 非标操作或手工操作：所有能自定化带人工的操作。