






















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服务的平台。
浪费和困境是软件开发过程中导致交付延迟的主要因素:
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。