我们都知道DevOps诞生于互联网企业。Netflix、AWS等互联网企业号称每天往生产环境部署成百上千次。如此之快的部署频率让众多传统企业垂涎欲滴。所以大量的传统企业都纷纷投入巨资打造自己的DevOps基础设施 ，希望就此可以显著提高开发效率，加快新项目或新产品的投产速度。但是，他们对于DevOps基础架构是什么样子，需要具备哪些能力，如何构建，并没有一个很清晰的规划。
要想规划与打造适合传统企业的DevOps基础设施，首先需要弄清楚它必须具备哪些能力。我们尝试从基础、开发、测试、运维、项目管理五个维度来分析对DevOps的需求，从而探索DevOps基础设施与之对应的能力，并映射到一款业界流行的软件工具来承载这个能力。需要注意的是这里的目的是具象与实例化，而不是推荐使用某款软件工具。大家要根据自身实际来进行工具选型。
基础
对于DevOps来说，最重要的基本能力就是健全的云计算能力。对于传统企业来说，就是要构建完善的云平台。DevOps所需的高度自动化必须得有强大的云平台支撑。如基础设施即代码，弹性伸缩等高效的实践，没有云平台的保障，根本实现不了。云是DevOps基础设施架构的基石。没有完善的云平台与云计算能力，基本上不用考虑DevOps。云平台主要从以下3个方面对DevOps提供支撑（括号内为承载此能力的软件工具）：
1. 基于IaaS的自服务与环境编排能力（VMWare）
2. 基于PaaS的弹性伸缩能力（K8s）
3. 基于SaaS的软件服务能力
其中，自服务主要指的是环境的按需快速生成；环境编排主要指的是基础设施即代码；弹性伸缩主要指的是对于计算、存储、网络等资源的自动扩容机制。
云平台
对于传统企业来说，考虑到安全性，一般还是会优先考虑自建私有云，至少是混合云。当然，完全选择公有云也是可以的。如果企业有这个胆识与魄力完全基于公有云搭建云平台，某种意义上也反映出它的DevOps规划是完善与考虑周全的。对于他们来说，构建DevOps基础设施或许是一件把握十足的事情。
开发
对于开发来说，最重要的需求来自三方面：开发效率、代码质量、实时反馈。对应的能力如下：
1. 开发效率
1.1 分布式代码管理能力（GitLab）
1.2 持续集成能力（Jenkins）
1.3 持续部署能力（Jenkins）
1.4 依赖管理能力（Nexus）
2. 代码质量
2.1 静态代码扫描能力（Sonar/Fortify/InSpec）
2.2 执行单元测试能力（Jenkins）
2.3 测试环境制品管理能力（Nexus）
3. 实时反馈
3.1 可视化能力（电视墙）
3.2 构建与单元测试结果通知的能力（Email）
DevOps对开发的支持能力
需要解释的第一点是在代码管理上，分布式的代码管理会比中央式的代码管理高效。中央式的代码仓库依赖中心化的代码托管服务器，如果它有问题或者网络中断，代码将不能被提交，这将严重影响开发效率；分布式的代码仓库是去中心化的，并没有中央代码托管服务器，每个开发者本机都是一份完整的代码副本，这意味着即使网络出现问题了，开发者仍然可以提交代码。除此之外，分布式代码仓库提供的灵活性也是中央式代码仓库所不能比拟的。所以，这里我们选择GitLab作为代码仓库，而不建议使用SVN等的中央代码仓库。
第二点是在依赖管理上。一个具象化的例子是关于Maven依赖的管理。在很多传统企业里面，尤其是金融企业，外网访问权限是受限的，很多开发人员都不能访问外网。所以非常有必要在内网建立所谓的私库，作为代理与外网的公共库同步。开发人员在本地构建时通过访问私库来解决依赖问题。如果没有建立私库，开发人员必须得花费大量时间解决依赖问题。而且这种问题在日后有新的依赖引入时会不断出现，开发人员将为此焦头烂额，开发效率严重受影响。
另外在代码扫描上，由于企业安全性的要求，比较全面的是从质量、安全和合规三个方面进行扫描。Sonar、Fortify、InSpec与此三个能力对应。还有从架构方面进行扫描的，但考虑到相关的技术其实还不是特别成熟，暂不考虑。不过有这方面特殊要求的可以深入研究一下。
对于持续集成，持续部署与执行单元测试，通常是通过持续交付流水线来串联实现，所以把承载能力的工具都归结到Jenkins上。需要注意的一点是这里的持续部署指的是部署到测试环境，并不包括生产环境。我把对生产环境的部署放到运维。实际上，对于大都数传统企业来说，现阶段很难做到真正意义上的DevOps to Production。能做到DevOps to Pre-Production，甚至只是DevOps to UAT就已经很不错了。造成这样的原因是复杂而多方面的，包括要满足监管的需要，要通过生产环境审批的流程等等，这里就不展开了。
可视化是为了实时展现持续交付流水线执行情况与单元测试的执行报告，提高团队的反馈速度与响应力。它需要可视化设备，如大屏幕电视，CI报警灯的支持；同时，我们也需要通过邮件的方式把自动化构建与单元测试的结果自动发送给相关的人员。
测试
而对于测试来说，最主要的需求来自测试效率与实时反馈两方面。对应所需的能力如下：
1. 测试效率
1.1 自动化测试能力（Jenkins）
1.2 并行测试能力(Selenium-Grid)
2. 实时反馈
2.1 可视化能力（电视墙）
2.2 测试结果通知的能力（Email）
DevOps对测试的支持能力
比较好的实践是通过持续交付流水线串联自动化测试，在测试环境部署成功后触发自动化测试。另外自动化测试种类繁多，对应的工具也比较多，例如利用Jmeter来 实施接口测试或者轻量级的压力测试，利用Cucumber来实施BDD测试等，这里就不一一列出了。另外，为了提供测试的效率，有必要考虑把自动化测试用例分组，进行并行测试。这需要具备快速的测试执行环境生成能力，应该通过基础设施即代码在云平台的PaaS层满足。
与开发一样，测试阶段也需要测试报告的可视化与结果通知。
运维
而对于运维来说，最主要的需求来自变更风险控制、实时运维反馈、生产事件响应三方面。对应所需的能力如下：
1. 变更风险控制
1.1 生产环境变更管理能力（Service Desk）
1.2 生产环境制品管理能力（Nexus）
1.3 生产环境自动部署能力（CodeDeploy）
2. 实时运维反馈
2.1 生产环境运行状况监控能力（Prometheus）
2.2 可视化能力（Grafana / 电视墙）
2.3 生产事件响应
2.4 实时告警能力（Support Mobile）
2.5 生产事件管理能力（Service Desk）
2.6 知识传承能力（Confluence）
DevOps对运维的支持能力
正如在分析开发阶段所需能力时所说的，我把对生产环境的部署放到运维。原因是企业的持续交付流水线往往都打不通到生产环境。表面的原因是因为要遵循ITSM，一个历史久远的被大量企业广泛采纳的IT服务管理框架，所以存在一个生产变更的手工审批流程，深层次的原因就复杂了，这里不展开。变更管理与事件管理的理念也来自于ITSM 。但随着DevOps的流行，ITSM似乎显得过于重量级，与DevOps的理念相违背。于是业界有人提出轻量级ITSM，但也仅仅是提出，没有看到进一步的落地细节。所以，对于传统企业来说，在运维阶段，还是不得不具备变更审批管理与事件管理的能力以遵循ITSM，否则将会有合规审计的风险。
另外，对于运维来说，知识的传承非常重要，非常有必要建立运维的知识库。一方面 有利于对事件的复盘回顾，另一方面也有助于日后参加运维的人员尽快熟悉与掌握系统的运维技能。
这里需要注意的一点是Service Desk不是某一款软件的名字，而是ITIL（信息技术基础架构库，可认为是ITSM的落地实现）里面承载变更管理与事件管理的工具统称。业界有很多产品实现，但基本不开源，也没有一款是公认比较好的，所以这里不表明具体产品。
另外，On-call Support 人员通过随身携带Support Mobile随时对生产环境提供支持， 在产生生产问题时接收短信或者电话告警。所以在告警的能力上还要考虑与运营商系统的对接。
项目管理
对于项目管理，最主要的需求是迭代支持、分析度量、变更追踪、实时反馈四个方面。对应所需的能力如下：
1. 迭代支持
1.1 产品代办列表管理能力（Jira）
1.2 用户故事管理能力（Jira）
1.3 分析度量
1.4 数据统计能力（Jira）
2. 变更追踪
2.1 需求、代码变更、CI关联能力（Jira）
2.2 用户故事与设计、测试等相关文档关联能力（Jira / Confluence）
3. 实时反馈
3.1 可视化能力（TV / 物理看版）
DevOps对项目管理的支持能力
DevOps基础设施架构规划全景
综合以上5点分析，可以得出一个传统企业的DevOps基础设施架构架构规划的全景图：
DevOps基础设施架构全景图
其中，三角形的左侧负责构建底层的云平台，是整个DevOps基础架构的基石；三角形右侧是DevOps基础架构需要具备的能力，对应的工具示例以及其在云平台的部署层次。这个架构不是一成不变的，而是应该随着实际需求变化而持续演化，能力也要跟着持续提升。
通过这幅全景图，我们可以看到大部分的能力都以SaaS服务的形式呈现。这意味着企业可以建立中心化的SaaS服务提供给所有开发团队使用。并行测试的执行环境通过PaaS平台按需自动生成，测试执行完毕后自动销毁。唯一比较特殊的是持续集成。首先我在这里是把持续集成放在了IaaS层。原因稍后解释。如果是基于Jenkins，可以利用其Master-Slave机制实现分布式并行构建。Master作为控制的Host，主要负责任务分配与调度，利用虚拟机部署IaaS层比较合适；slave作为执行机，利用容器部署在PaaS，在构建时立刻拉起，构建完毕后立刻销毁。
中心化 vs 去中心化
来到这里，肯定有人会有疑问，为什么这里我不把持续集成作为SaaS 服务？或者干脆直接引入成熟的DevOps效能平台取代零散的工具链不更好吗？不需要自己从0开始一步一步搭建啊？在我之前咨询过的客户里面，的确有很多是直接引入如阿里云效，微软TFS等成熟的第三方DevOps平台供所有团队使用，自研能力强的甚至会构建自己的一站式DevOps效能平台。
基于云效或TFS的中心化DevOps效能平台
这种中心化的效能平台固然是大势所趋，但是使用不当它可能会引起两个很严重的问题。第一个问题是缺乏灵活性。越偏向开发端，越需要灵活性。企业内的项目都是千差万别的，它们对CI/CD等的需求也往往差异巨大；即使是雷同的项目，在对编译构建上的一些细枝末节的差别也很可能导致它们的持续交付流水线设计非常不一样。中心化的DevOps效能平台往往不能提供足够的灵活性满足这些需求，反而导致开发者必须适应其限制来设计流水线。第二个问题是运维支持跟不上。企业往往把中心化的DevOps效能平台作为产品提供运维支持，运维人员才几个人，却要支持整个开发部门所有开发人员的DevOps需求，支持响应肯定跟不上。由此而引出的来自开发者的抱怨在我自己的工作经历中曾多次遇到过。如果是自研的平台，问题可能更严重，可能连一些基本的需求都还没实现，开发者就要开始使用；开发者提的新的需求更不知道要等到什么时候才能上线。以上提到的种种问题的结果就是开发团队会慢慢抛弃中心化的DevOps效能平台，选择自己搭建自己的持续集成平台。 最后形成的状况是中心化DevOps效能平台与团队自建的CI共存，并且团队自建的比例还会不低。这就是我不把持续集成作为SaaS服务的原因。所以，不是我建议去中心化，团队自建DevOps基础设施，而是现实情况它会自然而然地往那个方向演化。中心化与去中心化并存。因此，管理者所要做的是，在保证总体可控的情况下，提供足够的灵活性，允许团队自由选择，切莫一刀切，并规划提供足够开放的接口，与团队自建的CI对接，统一度量数据，以此打造高响应力的DevOps基础设施。
网友评论