这是鼎叔的第一篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。
多年大厂技术总监和质量通道委员经验，横跨多个不同领域，微信公众号“敏捷测试转型”，欢迎多多交流。
认真读完阿里巴巴的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