第二章 知己知彼
知彼知己，百战不殆；不知彼而知己，一胜一负；不知彼，不知己，每战必殆。《谋攻篇》
前面两章其实重点是在掰扯数智化，IT研发本身的数字化其实除了DevOps这一种手段之外还有很多，比如Low Code、RPA等等，AI都可以自动写代码了，还有啥是不可能的呢！不过本人能力有限，这点斤两也就敢玩玩DevOps，其他的碰都就不敢碰，接下来聚焦到DevOps的一些见解上。
3.1 剑锋所指
作为云原生重要组成部分的DevOps，跟云原生一样没有标准定义，不同的大厂都会结合自己的实际给出不同维度的注解。综合各家所言，我们可以重点提炼出DevOps的目标到底是什么呢？
|
|
|
|
|
Atlassian |
DevOps 团队包含了开发和 IT 运维，大家一起协作，共同参与产品的整个生命周期，一起为提升软件质量和加速软件开发过程而努力。 |
|
|
微软 |
DevOps 是人、过程和产品的结合，使能持续地向终端用户交付价值。 |
|
|
AWS |
DevOps 是文化理念、实践和工具等的组合，能够提升一个组织快速交付应用和服务的能力。 |
|
|
|
|
|
DevOps剑锋所指何处？想必真正要玩DevOps的你心里肯定有自己的小九九了，就不再赘述总结了，每个人都可以有自己的见地。
3.2 最佳实践
多数情况下，开发的目标是快速发布更多的新特性，而运维的目标是保证更高的系统可用性。DevOps 通过切实可行的最佳实践体系来拉齐这两个目标，在提升系统稳定性的同时加速产品交付到市场的速度。
这个最佳实践是什么呢？显而易见，就是形形色色的“无穷环”。
|
|
|
|
|
Atlassian |
|
计划（Plan） 构建（Build） 持续集成和部署 监控和告警 运维（Operate） 持续反馈 |
|
微软 |
|
计划（Plan） 构建（Build） 持续集成 部署（Deploy） 运维（Operate） 持续反馈 |
|
AWS |
|
构建（Build） 测试（Test） 发布（Release） 监控（Monitor） 计划（Plan） |
|
|
|
|
知彼部分是对《什么是 DevOps？看这一篇就够了！》（https://www.danielhu.cn/what-is-devops/）的解读，叫抄袭也行，还请原文作者多多海涵。
总结来讲，最佳实践都基本上指向了重要的三件套：(技术)工具、流程和文化。
文化转变
结合“开发”和“运营”，“DevOps”一词强调整合两个团队的活动以交付有效软件。 也就是说，范围不仅限于这些部门。所有参与软件开发和交付的人员都需要一致推进向用户交付有效软件的共同目标。
DevOps 的核心是创造一种共担责任、相互信任和开放沟通的文化。 对于开发团队来说，在本地构建能够运行不足以表明工作已经完成。 为了交付可用于生产的代码，开发者需要代码和发布间步骤的可见性。 这意味着打破孤岛并与质量保证、安全和基础架构团队合作，以了解其在流程中的作用。
工具和自动化
虽然手动流程可以让团队间的合作更加紧密，但使用工具将尽可能多的工作自动化可以带来更高效率。 构建、测试和部署步骤自动化可使工作得以更快完成，这也意味着可以更快得出这些阶段的结果。 自动化是 DevOps 方法的核心，能够实现紧密的反馈循环，这对于提高质量和消除浪费至关重要。
高效的流程
DevOps 出现在精益制造原则开始应用于软件开发的时候。 精益的重点是通过优化流程中的每个阶段、提高质量并营造尊重的氛围来消除浪费。DevOps 融合了大部分这种思想，并优化端到端流程，通过紧密反馈循环对正在构建的内容尽早提供反馈，提高软件开发效率。
这涉及更早地进行下游开发活动，并在发现问题后立即解决。无论是失败的测试、安全漏洞还是构建问题。
由于每个人都要分担向用户交付软件的责任，“在我的机器上能用”的陈旧回应已经不再适用。 使用 DevOps 方法，开发者可以更清楚地了解软件的使用方式和出现的挑战，从而更好地修正这些问题。
采用 DevOps 将敏捷的好处扩展到开发团队之外。 适应开发者的节奏并以较小的规模工作，可以更容易地发现和隔离问题，因为只有较少的变量在发挥作用。 同样，及时生成反馈可以避免在后续将弃置的测试和暂存构建上浪费精力。 反过来，这也将确保整个组织获得以较小增量工作的全部效益
3.3 查缺补漏
当我们在说DevOps建设时，到底要建设什么？说法千千万，选择自己偏信的信一信就行了，重点是结合自己所在境况，能够落地的，才是有价值的。
梳理已有的能力，比起跟其他大厂或竞品所标榜的能力来个开发常挂在嘴边的“拉齐”，来个知己知彼，至少各种半年、年度总结啥的有点存货可以拿出来讲讲。
以微软定义的 DevOps 8大能力为例，做了个简单的对照表，主要从工具、流程和文化三个角度进行。
持续计划 Continuous Planning
|
开宗明义 |
从简单云以及云效项目协作的功能来看，持续计划其实更侧重于于项目管理工具，基本上都是参考敏捷开发的主体思想，将IT研发迭代的工作流程、各工种协作、状态流转等整合进系统里。 类似功能的产品其实有很多，比如TAPD、Tower等。这些单纯只是研发工作流程的信息流转，不能链接作用到最终运行在Linux的“代码服务”跟着流转。比如，提测的时候把迭代分支代码，合并到测试分支，并且在测试环境发布本次变更。 持续计划是DevOps的源头，也是收尾处，这样才能成环。 |
|
已有能力 |
Jira+Wiki,这应该是很多公司的标配了。 |
|
欠缺能力 |
工具其实没啥好坏，真正有价值的是使用工具的人如何使用。工具够用就行，最多就是使用不方便、操作不友好这一大堆。要是问题在使用的人不懂做做计划、协调资源和控制进度，刀剑太锋利只会误伤人的手指。个人不是深度 持续计划使用者，所以感觉不出来欠缺啥。之前主要使用过TAPD、Tower。 |
|
备选能力 |
没调研，总之要私有化部署。公司的核心秘密不能放到别人机房。 |
|
个人理解 |
CP能力工具和文化的占比都不大，重要的是流程。制定执行流程的人，才是核心。 |
持续集成 Continuous Integration
|
理解与说明 |
持续集成，简称CI，是软件开发周期的一种实践，把代码仓库（Gitlab或者Github）、构建工具（如Jenkins）和测试工具（SonarQube）集成在一起，频繁的将代码合并到主干然后自动进行构建和测试。简单来说持续集成就是向源代码/版本控制系统定期提交变更，以便每位成员都在同一基础上构建。 每次提交都会触发一个构建和一系列自动化测试，以验证行为并确保所做变更没有破坏任何已有内容。 最关键的是自动化测试，也是最难的。是后续“持续质量”重点解决的问题范畴。 |
|
已有能力 |
但就CI的工具来地主家的余粮绰绰有余，在容器化建设之前Jenkins、Sonar等等工具早都有的。流程层面本来就不是问题，将这些工具通过各种Action串联起来。 自动化测试，也建设了专门的平台，而且还不止一个两个，外采的、自研的各式各样。 |
|
欠缺能力 |
看上去似乎是不缺什么能力的，但是实际中也并不是那么乐观。这种“不科学”的时刻，得要往“文化”上想一想了。 |
|
备选能力 |
|
|
个人理解 |
CI能力，工具和流程都很容易信手拈来，极致体验的使用的。重点在于得有这么一个文化，让研发和测试信服或者强制遵循。 |
持续交付 Continuous Delivery
|
开宗明义 |
鉴于CD既可以是Continuous Delivery又可以是Continuous Deployment，各种观点和分歧最后可能就分不清楚了。所以个人建议不加以区分了，笼统的来讲CD的能力，持续交付以由持续集成建立的构建和测试自动化为基础，将持续计划中的某个需求（泛指不仅仅是需求），从开发者到测试人员，再从测试人员到发布经理的交接，并最终把形成的“能力”发布到生产环境，交付给目标用户。 不论是手动还是自动，也不管有多少个环境，CD的最终目标就是向终端用户交付了价值。 |
|
已有能力 |
从18年开始的容器化建设，一开始就主攻的CD能力。部署自动化 |
|
欠缺能力 |
|
|
备选能力 |
|
|
个人理解 |
对于持续交付，资料太多、各家之言太杂乱反倒把最重要的部分给蒙蔽了。回归到码农的工作的本质，写好代码，最终要给用户“交付”一个东西（.exe/http://127.0.0.1:1024）。持续不断的，能够自动化的把写好的代码，变成终端用户可接受的那个“东西”，我觉得这就是CD了。 |
持续运维 Continuous Operations
|
开宗明义 |
监控、告警、日志、链路追踪；监控自动化、配置自动化、作业自动化、日志分析自动化。 持续运维可减少或消除计划性故障时间或中断，例如计划性维护。 如果可能，应将基础结构、应用程序和服务的持续监视与自动化修正相关联。 用户应该永远不会知道何时发生更新或增量发布。 |
|
已有能力 |
不论是人工手动，还是各种工具自动，公司再运维的投入比容器化是要大的。 |
|
欠缺能力 |
|
|
备选能力 |
|
|
个人理解 |
|
持续质量 Continuous Quality
|
开宗明义 |
构建可靠的自动化测试套件并在软件交付生命周期中执行各种扫描、测试，从而提高软件质量。 |
|
已有能力 |
代码质量扫描、测试覆盖率、单元测试覆盖率、Java项目标准化、静态分析等等 |
|
欠缺能力 |
|
|
备选能力 |
|
|
个人理解 |
交付质量，单纯的只有工具、流程建设肯定是不够的；单纯的只有测试人员也是不够的。 |
持续安全 Continuous Security
|
开宗明义 |
DevSecOps 强调了将安全性纳入软件开发生命周期 (SDLC) 的重要性。 将安全性融入团队的文化、流程和工具，可以避免孤岛并确保快速交付不会以牺牲安全为代价。 |
|
已有能力 |
主要是6种安全扫描工具 GitLeaks\AWVS\Nuclei\IAST\Twistlock\奇安信安全扫描 |
|
欠缺能力 |
|
|
备选能力 |
|
|
个人理解 |
|
持续协作 Continuous Collaboration
|
开宗明义 |
持续协作是支持对任何 DevOps 之旅至关重要的文化转变的做法。 持续协作使团队能够在计划的会议范围之外进行创新，并通过创建集成体验来促进团队内部的创新。可以使用技术和实践分解孤岛，即使没有理想的共同位置，团队也能一起工作。 从持续协作的角度回顾敏捷宣言，你将意识到，这实际上是关于进行协作和个人交互以实现真正的创新的价值。持续协作鼓励你重视：①个人与交互胜过进程与工具；②有效用的软件胜过全面的文档；③客户协作胜过合同协商；④响应变化胜过遵循计划 |
|
已有能力 |
|
|
欠缺能力 |
|
|
备选能力 |
|
|
个人理解 |
|
持续改进 Continuous Improvement
|
开宗明义 |
连续且坦诚地观察你的 DevOps 流程可使团队能够确定可能的改进点。所有的改进都需要改变，但并非所有的改变都是改进。 这就是为什么度量对于使用 DevOps 的组织来说是成功的关键因素。 正如 Peter Drucker 所说，“如果无法度量，就无法改善。” 缺乏有效的反馈机制使得难以提高应用对业务的影响。 这就是为什么有必要创建一个环境来促进以学习为中心的 DevOps 改进方法，并着重于基于数据进行调整。
|
|
已有能力 |
|
|
欠缺能力 |
|
|
备选能力 |
|
|
个人理解 |
|
3.4 结语
工具和能力都是散落的点，真正能体现水平的是如何形成良性的“无穷环”，如果觉得无穷太大了，那至少得是能够“闭环”。
经过4年多的容器化建设，以及相关研发能力的完备，DevOps的8大能力基本上是具备的，现在重中之重是如何进行“包装上架”。利用已有的平台，成体系的整合完备。
