DevOps的设计实践

1. 起源

起初对于DevOps的概念的理解仅仅停留在“使用Bamboo自动化部署服务到指定环境上”，当我们开始尝试着对DevOps的流程开始做推广，首先确定的方案是，推动各组使用Bamboo做CI/CD的集成，第二是针对当前项目面临管理混乱的痛点问题，进行项目发版采用语义化版本管理。但正如康威定律所言，“设计系统的组织其产生的设计等价于组织间的沟通结构。”，我们不能仅仅在一次讨论中确定的方案就企图变革组织间的长达几年的沟通协作习惯。并且DevOps也不简单是一个普适的解决方案，它是一个平台（Platform）、流程（Process）和人（People）的有机整合。

DevOps关系图

1.1 文化

根据martinfowler博客中发表的对DevOps文化的见解（如下图），他认为DevOps文化中最重要的原则是责任共担和质量导向。在这点上，我认为我司有天然的优势，在项目开展的初期，包括当前项目运行生命周期中，研发包揽了大部分运维工作。可以说我们不从来不缺敢于担责的“勇士”。但同时，在我司大幅扩招的现状中，加强流程管理，保证这种文化的延续，同时在人员流动中能动态的加强文化导向，这是DevOps指导思想中重要的一环。

DevOps文化

1.2 工具

工具 = 平台+ 流程，首先，平台最重大的意义是承载企业内部的标准化流程，平台固化的每种流程，都可以用来解决某些实际问题，这样就会形成一下特征：

• 吸附效应：平台会不断地吸收中小型的工具，逐渐成为一个能力集合体。
• 规模效应：平台的成本不会随着使用方的扩展而线性增加，能够实现规模化。
• 积木效应：平台具备基础通用共享能力，能够快速搭建新的业务实现。

1.3 赋能

通过平台赋能，所有人都能以相同的操作，获得相同的结果。这样一来，跨领域之间的交接和专家就被平台所取代，当一件事情不再依赖于个人的时候，等待的浪费就会大大降低，平台就成了组织内部的能力集合体。

1.4 价值

任何方法论不结合企业实际的现状来分析都是耍流氓（无处不在的康威定律），那么对于我司的实际现状，建立这一套体系能解决哪些问题呢？在和研发童鞋讨论问题的时候，能看到他们往往是处于只见树木不见森林的状态，整个“森林”往往是被少数的人所掌握的，这点在季度述职时候已经被不少人提出来过。诚然我们作为安全公司，部分产品是敏感且需要保密的，但是从整个层次和架构来讲，我们需要适配一套流程，达到对技术开放，对数据加密，安全的流程正是SecDevOps需要解决的问题。同时这也很切合“三步工作法”中流动原则，只有把复杂的流程简单化，可视化我们才有机会让更多的人看见森林。而目前结合生态，软件交付的效率和质量成了当今企业的核心价值和核心竞争力，DevOps作为软件工程的第三次革命，总结来看它的价值体现在以下两点：

• 高效的软件交付: 在很多时候，高效软件能做到高效率和高质量，所以这是一个鱼和熊掌兼得的故事。
• 激发团队创造力： DevOps的另一大理念可以认为它是为了改善软件从业人员的生存状态，提升他们的幸福水平，Don't Repeat Yourself，解放重复性劳动，我们甚至用更宝贵的时间，做有助于自己提升的事情。

1.5 行为准则

让一切软件交付过程的手动环节，都是未来可以尝试进行优化的方向。DevOps倡导职责共担，持续改进是需要将规则内建于工具之中，并通过工具来指导实践。如果仅仅是把线下的流程搬到线上执行，是没法发挥DevOps真正的价值。说到底，工具没法解决人的问题，这样一条看似取巧的路径，却没法解决企业的根本问题。这时候，就需要文化闪亮登场了。
总而言之，DevOps 中的文化和工具，本身就是一体两面，我们既不能盲目地奉行工具决定论，上来就大干快干地采购和建设工具，也不能盲目地空谈文化，在内部形成一种脱离实际的风气。我们要做的是关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。

2.建设

2.1我们要做哪些事？

研发运营一体化

从上图中可以看到，我们的目标是建设研发运营一体化平台，从开发到交付再到技术运营形成一个完整的闭环的流程。
根据《DevOps实践指南》中提出来的三步工作法，建设DevOps平台一共有三步：
第一步：流动。通过工作可视化，限制在制品数量，并注入一系列的工程实践，从而加速从开发到运营的流动过程，实现低风险的发布。
第二步：反馈。通过注入流动各个过程的反馈能力，使缺陷在第一时间被发现，用户和运营数据第一时间展示，从而提升组织的响应能力。
第三步：持续学习和试验。没有任何文化和流程是天生完美的，通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步。

2.1.1 敏捷管理

敏捷管理不仅仅与研发敏捷，同时也要针对于业务敏捷，开发更少的功能，聚焦用户价值，持续快速验证，就成了产品需求管理的核心思想。

另外通过“研发一体化流程”图示，我们也能见微知著。在我司目前在产品使用JIRA的看板形式做需求管理，这套流程在敏捷业务管理中已经有很好的天然优势，我们需要做的是打通产品和开发的交流屏障，这部分流程以及功能，在我们的排期中暂时靠后，现未有具体实施方案，目前仅给出 BizDevOps 的核心理念：

• 对齐业务和开发目标、指标；
• 把握安全、合规指标；
• 及时对齐需求，减少无用开发；
• 体现 DevOps 的价值；
• 让开发团队开始接触业务，不单单是执行，调动积极性。

2.1.2 持续交付

关于持续交付功能，是初期内我们重点投入的阶段，这也是作为研发真正的用武之地，首先面临着第一个问题，自研OR开源？在我们开始做DevOps之前，已经有了部分在用的优秀开源工具作为支撑点，Jira、Bamboo、BitBucket。这些工具一定程度上减少了我们初期的工作量，在后续的项目计划中，我们做了基础存储，权限、DevOps流程等多方调研。关于存储和权限这类基础架构目前都有着成熟的开源解决方案。但是DevOps流程关联公司TOG的业务性质，以及目前的项目现状，我们选择自研平台，主要的规划方向有：
1.版本控制、变更管理
主要核心思想是：版本变更标准化，将一切纳入版本控制，全流程可追溯和单一可信数据源。，一套标准化的规则和行为习惯，可以降低协作过程中的沟通成本，一次性把事情做对，这也是标准和规范的重要意义。
2.持续构建和持续集成、部署与发布的模式
主要核心思想是：用自动化的方式完成从项目编译到发布的流程
3.环境的搭建管理、元数据、初始数据的管理
这是目前我们项目发布中的瓶颈，配置、初始化数据应当纳入版本控制，同时制定标准的业务流程；
4.度量与反馈
针对于交付效率、交付能力、交付质量做指标统计，以及建立可视化平台。主要的指标包括，需求前置时间、开发前置时间、发布频率、发布前置时间、交付吞吐量、线上缺陷密度、线上缺陷分布等。
5.内建质量、保证测试
内建质量有两个核心原则 ：

• 问题发现得越早，修复成本就越低；

• 质量是每个人的责任，而不是质量团队的责任。
  保证测试方面，主要是联合研发人员推行单元测试以及联合测试人员积极推行自动化测试建设。

  
  
  图片来源：“DevOps Handbook"
  
  

  由上图可见，单元测试是快速减少问题的最有效手段，UI 测试更加关注模块集成后的联动逻辑，是集成测试最有效的手段。

2.2 我们在做哪些事？

在为期近4个月的DevOps实践中，我们主要做了三件事情，部分项目Bamboo的集成、基础架构的建设、DevOps平台的开发。

2.2.1 Bamboo的集成

初期我们做了一些关于DevOps的调研和实践，在尽可能采用开源项目的原则上，依赖于现有的技术结构，摸出了一套关于Bamboo的使用流程

Bamboo流程

如图所示，主要内嵌于Bamboo的阶段性Task定义，结合编译组件Maven（Nodejs）、Script、Docker等构建出的一套方案。另一方面，受限于各组的项目安全性和独立性，同时提供了绑定了与编译环境相关的Bamboo agent方案。在一定程度上部署流程达到了一次编辑，终生运行的效果，直到现在，在FlowInsight、FlowAI项目中Bamboo自动化都取得了比较好的效果。

2.2.2 基础架构的建设

基础架构建设

从图中能看到，我们主要做了容器化和虚拟化实例构造。
虚拟化包括构建FlowAI、FlowInsight等多个测试、预发布环境，以保证基础功能可验证。
容器化采用搭建一套Kubernetes的集群，在之上部署了高可用的存储方案，包括采用rook-ceph做源存储，上层的MySQL、Redis等的落盘依赖于CephFS三副本存储方案，保证了一节点宕机下数据仍然完整。
其次基于Ceph构建了对象存储管理，接口层采用AWS S3，提供DevOps的包管理存储以及提供其他组大批量文件存储。同时搭建了Jumpserver堡垒机，针对与各个集群环境，提供了用户与机器的权限和审计管理。搭建了基于Nexus的制品仓库，功能包括多项编译制品文件如Maven私有仓库、Docker私有仓库的代理、上传下载功能。
总结来看，我们的基础架构主要出于以下方面的考量：

• 保证内部数据和文件交互的便捷
• 保证内部数据和文件的高可用
• 保证多环境展开测试、发布流程
• 积累云原生技术方案

2.2.3 DevOps平台开发

开源OR自研？这永远是一个需要不断权衡和取舍问题，之前我们已经谈论到持续交付要做的事情有哪些，当开源组件不能Cover我们当下的流程，自研平台自然得上线了

DevOps平台设计

基于上图我们可以看到FlowDevOps平台的基本的交互和流向。平台开发到现在经历了四个小版本的迭代，主要包含以下几个特性：

• 强约束语义化版本控制，保证项目对各模块的统一管理
• 集成自动化工具，解放生产效率
• 约束脚本、配置、初始化数据纳入模板版本控制

值得一提的是，我们选型了Jinja2作为配置模块统一管理，对各个环境公共组件的地址存放与平台，保证了服务离线部署中各类连接出错的问题。同时这种方式对业务的侵入较小，符合我们短期内提升部署效率的预期。

2.3 取得的效果和面临的问题

诚然，DevOps的建设在短期内已经做了不小的工作量，但是还是存在一定程度的问题。包括以下方面：

2.3.1 成熟度

成熟度模型

根据全球云计算峰会成熟度模型预估来看

• 环境和部署: 我们的自动化部署到某些环境，创建一套新环境比较简单可靠，属于基础阶段。
• 流程管理：这是我比较悲观的一点，我们的流程管理大部分还是靠人的经验来管理，属于原始阶段。
• 配置管理： 目前我们已经具备了把源代码、配置、数据脚本、部署脚本纳入版本控制的能力。但这部分功能还在推广，属于半基础阶段。
• 构建和持续集成：得益于Bamboo的自动化构建，我们部分项目在这个阶段有很好的收益，但是我们缺少自动化测试能力，目前属于半可持续化阶段。
• 运维监控和度量：我们的在部分项目应该有比较完善的监控度量手段，但是没有一整套方便部署，适用于多项目的运维监控平台、所以目前属于原始阶段。
  从总的方面来看，我们的DevOps建设还处于初期阶段，并且在这个阶段中还有个大量的工作需要去做。那么回到本文开头提到的概念，DevOps它是平台（Platform）、流程（Process）和人（People）的有机整合。它不是单单一个人的事情，需要我们每个项目组、每位同事坚持责任共担和质量导向才能取得良好的成效。

3.未来

3.1 云原生

在我司云原生于我们似乎是非常遥远的，陌生的技术栈，各类反直觉的故障。但是为什么我还是坚持认为云原生是我们未来建立DevOps，以及发展基础设计的最佳实践呢？引用CNCF对云原生的官方定义：

Cloud native computing uses an open source software stack to deploy
applications as microservices, packaging each part into its own container, and
dynamically orchestrating those containers to optimize resource utilization.
云原生使用一种开源软件技术栈来部署微服务应用，将每个组件打包到它自己的容器中，并且通过动态编排来优化资源的利用率。

关键词有开源软件、微服务应用、容器化部署和动态编排，虽然我们目前部分业务场景有传输相关的瓶颈，容器化则可能带来更大的存储体积。但从宏观角度来看，这并不是大部分项目的现状，而我们更多的项目核心的问题在于数据量大、业务和配置复杂、依赖模块多。而云原生应用天生就和DevOps 是绝配，自带高可用、易维护、高扩展、持续交付的光环，同时原生支持微服务、不可变基础设施以及服务网格这些技术领域，能天然解决业务复杂，依赖模块多的现状。
这也是我在基础设施建设工作中，坚持积累云原生技术方案的原因，云原生的技术方案，我始终认为它能大大推进我司效率建设和技术发展。即便我们在云原生的方案技术积累还不足够，比如还不能确认大数据在容器中运行的效率这类技术问题，但是当我们建设起更具效率的运营一体化流程，也就有更多的资本去进行试错，这片星辰大海等待我们去探索。

3.2 持续改进

我们都期待完美，但在绝大多数时候，任何事情都不可能完美。软件更是如此，DevOps亦是如此。我们能做的就是基于每次的反馈，一点点的改进流程，一次次的反思提高。在不断的持续改进中，可能永远触及不到完美，但是就像美国著名女演员莉莉·汤姆林（Lily Tomlin）的那句经典名言所说的那样：The road to success is always under construction.（通往成功的道路，永远在建设之中）。