一、再谈DevOps定位
本文讲的是给DevOps打上最佳实践的标签，之前我们同事已经谈过DevOps的定位，但随着越来越多的交流和实施，我们发现大部分客户会提出这些要求：
很显然，这些想法都很实际，又都存在着一些问题，拿第一个说法（给一些工具或系统做统一门户）举例：
很多客户企业确实已经用了不少开源或商业产品，只是现在都是一个个独立存在，没有统一登录、认证，使用起来比较麻烦，所以提出了第一个要求，并认为这就一定程度上实现了DevOps。
但事实上，这个做法对旨在精益的目标来说，显然是不够的：
- 我们还是不知道某个系统需求最终跑在了哪些机器上
- 我们也不知道现在并发的20个项目中哪些项目存在风险
- 同样我们可能基于现有的信息，也不知道敏捷发布火车一年能开几回
所以，在我们定位里，DevOps不是简单的集成或整合，而是一条数字化生产线，覆盖从需求到最终运营的全周期；
当然也少不了对于质量、安全方面的支撑，为IT运营提供足够的保障。
想一次性从需求做到运营往往是一个理想，更多的是选择生命周期中最需优化的点来逐步建设，但现在也看到一个现象：
越来越多的厂商开始研发DevOps产品，有的基于项目管理工具衍生，有的从运维工具开始，有的从容器云过渡，有的从开发平台着手，貌似大家把所有工作都归结为DevOps。
显然在定位上犯了一个问题，就像之前很多人说一切皆代码、一切皆*的，而忽略了DevOps的初衷（当然我们不排除丰富一切对IT生产线有用的能力，但不能把一切都强行说成DevOps）。
其实SAFe中给了DevOps一个比较有原则、并且接地气的定义：
DevOps重在快速交付，通过将研发管理与部署交付的紧密结合，驱动企业敏捷。
所以，我们应该首先着眼在交付流水线上，通过可视化协同、标准化、一定的自动化等手段，让企业、让团队在流水线上更好的协作。
接着在运营并持续产生数据的基础上，通过各维度的度量手段，快速发现瓶颈，逐步优化，迭代建设并形成企业数字化标准。
绝不是不管三七二十一，上来就买个容器云、或者智能调度、或者自动运维、甚至是不切实际的“零运营”产品，然后考虑怎么迁移。
二、谈谈几个实践设计
回到今天的重点，分享一下我们在DevOps实施中的一些实践设计。
回想起2015-2016年初，我们也很喜欢给客户讲：开发者如何通过提交代码到git，触发jenkins开始构建，打包出镜像，通过与配置管理配合，一键发布到容器云。
就像下面的阿里云的这张图：
但是当我们拿着初期产品（可能叫原型更合适），去POC和客户实施时，往往面临的是这些业务问题：
比如很多集团要支持二级单位模式，那应该是什么样的部署要求，如何做数据的隔离？
又比如客户办公网和测试网肯定是单向的，那对于自动化测试（尤其是带设备的，比如手机真机测试肯定是放在办公网的），该如何应对自动部署和测试用例的推送执行？
类似问题一实施起来就遇到很多，这个片子先准备了下面几个实践：
- 刚才一直在说需求跑在哪些机器上，这是个典型的数据打通的问题，或者叫数字化问题，那数据关联我们怎么考虑的
- 版本，现在不同于以前单块架构，微服务架构下，有着各类都叫版本的元信息，比如发布版本、api版本、快照版本、产品规划版本等，是否建立了规范机制和关联性管理能力
- 看板，做DevOps的自然之道看板的重要性，但不同的角色，期望从看板中看到的信息肯定是有所区别的，该如何设计看板
- 租户的问题对于很多大集团运营是不可避免的，平台该如何考虑租户的数据隔离，被集成的系统又改如何配合
- 安全，这个领域比较大，我这边谈到的只是平台本身的一些安全处理，应对合规审计等要求
先说说数据关联性处理的实践：
要想需求知道运行在哪里，至少必须打通上述的几个环节：
- 需求到任务的拆分，这个很简单，无论jira、禅道，这都是必须支撑的
- 任务到编码的关联，或者可以这么说，提交的代码必须知道是完成了哪个或哪些任务，这个有几种实现方式，一则是完成任务时，输入commitid，一则是提交代码时，统一模板，再通过hook将关联关系持久化。显然第二种更优。
- 编码与构建的关联，本质上是要建立每次构建涵盖了哪些新增的Commit信息的管理，这个也有几种实现方式，一则是编译信息体现到库上，后续远程获取增量，一则是完全自身存储，相当于完全接管commit信息的存储。两者没有太多优劣，都可以。
- 构建与部署的关联，其实是每次部署关联的工件信息的持久化，这个倒不是难事。
基于上述环节的打通，当然还要把变更、升级等结合进去，想做到信息打通就不难了。
再说一个关联的例子，之前我们有同时讲过我们平台上的部署三部曲：部署设计、部署转换、上线运维。不仅仅是部署，为什么要做在线的很多设计呢？
传统模式下，架构师写架构设计文档，包括应用架构、部署架构、数据架构等，但随着项目的执行，后续实际开发、构建、部署和文档上难免有偏差，好像也很少有人再反向更新文档保持所有同步了。
那为何不将设计放到在线，同时提供多版本管理，支撑优化变更，指导后续工作呢？
比如部署架构，后续可生成部署计划；
比如接口设计，后续可查看变更，在线文档化；
比如应用架构，后续指导构建依赖，某个构建应该触发哪些构建；
这就是我们为什么要把设计阶段很多工作在线化的关起来的原因，做到各阶段的关联性驱动和管控。
接着说说第二个实践，现在对于版本这个词的管理，比以前复杂太多了：
记得万达客户实施时，客户自身就把这些版本规则、信息等做了严格的规范，什么地方用几位表示，何时变更。
那对于DevOps平台来说，重在建立关联信息的看板，为不同的角色提供不同的信息图，看板的实践中正好也提到了一些版本的问题。
我们就接着来说说看板的实践，很多人第一反应是需求或任务看板，这个当然是必须的，不过可视化协同的不仅仅是需求或任务，很多信息都需要看板的方式呈现。
比如：
这是面向交付的看板，可以清楚的看到本次发布到底已经过了哪些环境的验证，最终走到PROD的，事实上就是发布的版本。同时对于发布的版本，内部对应的组件（或服务）具体的版本是什么，也要呈现出来。
这个看板对于项目经理和架构师很重要，可清楚看到版本一次次持续交付的过程。
再比如：
这个看板其实做的不太好（正在改），其实应该是一个项目环境全集的展示，体现出目前项目的所有环境中到底部署的是什么版本，运行状态如何。
再比如：
这是流水线，涉及到了多个环境部署、测试知道最后生产上线，这是团队成员在稳定期到最终发布的中间迭代环节，不同的人关注不同的活动，项目经理关注执行阶段与执行情况。
再比如：
面对PMO，可能有些企业是CTO，会关注当前所有项目的状态，这张图与IBM的JAZZ中的一个图类似，显示一些项目处于预警状态，另一些是健康状态，椭圆大小代表项目的计划人月多少，越大的越要关注。有这种看板，就不用找每个项目经理沟通或开会了，只要关注有风险项目即可。
再比如：
这是项目的基础信息看板，项目经理关注里程碑的情况（延期、进行中、完成等），由此再深入到具体的需求、任务、Bug等具体信息。
很多企业都有二级单位，DevOps同样会开发给二级单位使用，这就涉及到了对于租户能力支撑的实践：
业界租户方案主要是应用隔离和数据隔离，对于devops产品来说，显然数据隔离足够了，对于数据隔离，又有逻辑数据隔离（每张表带租户字段）和物理数据隔离（分库）两种方式。
目前我们的产品设计是两者都支持，前者应对数据量不大的情况，后者应对隔离要求很高且量很大的情况。
上图应对的是第二种租户设计，更多的通过申请+初始化的方式，同时绑定不同二级域名，解决入口问题。
除了DevOps平台本身，对于集成的三方系统，也要考虑租户能力的支撑：
比如Jenkins，建议共享，通过给work node打label，来区分租户；
再比如Nexus，建议每个租户三个独立产品库，当然，如果采用artifactory则更好了
再说说今天的最后一个实践，关于安全的问题，首先DevOps本身定位在管理了多套环境，那平台本身该如何部署：
DevOps本身一般部署于生产环境中，通过部署引擎与各环境打通；而对于nexus、或者harbor，目前实施客户中既有可多环境共享的，也有通过多环境同步的。
对于平台本身，也要注意：
三、普元DevOps核心
一个是领域概念的设计：
还是从产品、项目、组织、集成、部署领域考虑，通过流水线将能力串联
另一个是我们的核心观点：
DevOps平台需覆盖产品、项目的全周期
DevOps平台更重要的是提供最佳实践
DevOps平台，重在让所有角色在流水线上协作，共同驱动过程的精益
DevOps平台，管理前移，有效指导和约束后续工作
所谓打通，不是一味的打通部门墙，更重要的对于各阶段管理对象的关联性打通
对于已有系统，DevOps平台不仅仅是通过新的工具链实现快速交付，更是一种驱动优化的变革
DevOps平台，并不是自动化一切，而是在可控中有选择的自动化
最后，对于最佳实践这种东西，仁者见仁，每个企业都有不同的需求和想法，需要在建设期一步一步的做进来（当然，这就要求产品本身的延展性设计等）。
原文发布时间为： 2017-06-05
本文作者：顾伟
本文来自云栖社区合作伙伴EAWorld，了解相关信息可以关注EAWorld。
