这是鼎叔的第一篇原创文章。
行业大牛和刚毕业的小白,都可以进来聊聊。
多年大厂技术总监和质量通道委员经验,横跨多个不同领域,微信公众号“敏捷测试转型”,欢迎多多交流。
认真读完阿里巴巴的DevOps实践指南(2021版)电子书,推荐给大家,说说个人的想法。
本来写了3500字的流水账读书笔记,太长了,该用思维导图重新画了一遍,方便看看。
企业专家联袂编写的指南,相对于专业敏捷咨询公司的书籍,在指导上更具项目实战性,感觉都是来自于大量的企业内部实践的提炼,形成完整的体系。
我没想到可读性也很强,语言朴实易懂,完全没有拽各种技术大词,也不会因为作者众多导致内容割裂,可以一口气读完,收获不少。提炼一些个人感触比较深的点如下:
1 类似敏捷的双环模型,既然是面向业务价值交付,干脆把DevOps叠加上业务(Business),变成BizDevOps。
DevOps本身是敏捷理论和精益思想的工程实践,本职还是要打通所有研发关键角色的竖井,并让所有角色受益,单个职能团队再专业也没有办法提高整体效能。
2 DevOps实施的价值主张,总结很精致:业务驱动的协作模式(局部工作对业务可见);产品导向的交付模式(让技术团队成为利润中心,而不是产品中心);特性为核心的持续交付(单应用持续部署,单需求按需发布);应用为核心的运维(能按应用独立管理)
3 业务,产品,技术三层的交付工作空间,互相解耦又互相协同,给不同角色使用,连接了过程资产,打通了客户价值,按活动有序沉淀。
这三层对应三个互相嵌套的反馈闭环:第一个环达成业务目标,第二个环交付产品效能,第三个环对齐技术工程。
敏捷团队把人当作自发主体,而不只是资源。因此,我们把事情交给多功能团队,而不是把人分给一个个事情,衡量交付团队就看长期业务价值和响应度。
因此我们打造的是产品制研发团队,而不是项目制研发团队。
4 规模化实施DevOps的原则
毕竟多数业务的研发人员规模远超单一特性团队的上限,规模化实施DevOps的目标是让更多业务系统化的受惠,不应该简单照搬复杂的规模化框架。具体原则是:业务驱动原则,去规模化原则(先去规模化再水平拓展),渐进原则。
5 提升持续交付工程能力的经验,有些值得借鉴的新思路,近一年来琢磨很久的持续测试+精准化+智能化,在阿里实践指南里有明确的方法推荐。
-
云端开发,开箱即用,代码管控更安全,研发过程效率更容易度量。
-
智能推荐最合适的代码评审人(挺神奇的智能),评审耗时预估,方便评审人安排,节约沟通成本。
-
借助成熟的扫描工具做好代码规约保障,包括智能补丁推荐化,组合工具进行安全检查和服务应用的过程检查。工具包括敏感信息检测,源伞漏洞检测,依赖包漏洞检测。
源伞商业扫描工具,我在上家公司组织小伙伴做了专项评测,也和厂家做了多次交流,确实在扫描深度,发现遗漏问题的能力,要高于常见商业扫描工具。
-
精准测试技术层面的做法大同小异,这里有新意的是:明确把“应用代码与用例的关联关系”定义为基线;对于不同层级的自动化测试代码覆盖率进行聚合,甚至包括线上代码覆盖率;保存各个分支版本的覆盖率关联关系,一旦测试用例失败立刻呈现对比信息。
-
构建效率不高的四个表现:同步时间长,单次时间长,构建步骤多,重复构建次数多。解决思路是从空间(产物大小)和时间(工具提速)两方面进行优化,建立依赖树,缓存依赖树,共享依赖树来解决共享问题。
6 持续运维-一站式监管控
我最感兴趣的是AI OPS机器人,在之前的公司,人工处理流程响应实在劳师动众,真正做决策的人很少,一堆人围观。流程设计处于两难选择:如果流程复杂严密,使用意愿大幅下降,如果流程非常简单,很多场景还是得靠人喊。
流程机器人可以起到弹性流程的作用,自动把干系人拉群,想看详细信息或定制化查询,点击机器人提供。
7 业务运维监控体系,分为业务监控,应用监控和云资源监控。而最常见的核心故障-黄金指标:流量(跌零或者大幅变化),延时(突然飙高),错误(服务返回错误总量)
AI也用在了资源智能监控的领域,为了提高报警的准确性,单一的指标判断是难以满意的,通过历史趋势自动学习数据曲线的周期规律,结合专家经验标准,近期在线预测,对波动毛刺和干扰攻击的排除,可以训练出更精准的智能告警。
最终的目标是智能运维编排,无人值守发布,无人介入的运维
8 对持续集成和发布的误区:理想的敏捷发布是每次发布少量代码,现实却是为了降低风险,人们倾向与更多的评审和更多内容的一次性发布,这个反而延长了发布时间和带来更多的问题,典型的负反馈。
9 阿里的DevOps能力成熟度模型,从4大类和10个能力来定义,评估值分为L0-L4五档,分别从手工,辅助工具,部分自动化交付,端到端自动化,自运维自治理,这五个阶段
原文电子书下载:
https://developer.aliyun.com/topic/devops?share_source=wechat