摘要

随着DevOps在企业内逐步推进，作为其最为重要一环的DevOps工具链会逐步构建起来——无论是基于开源的解决方案还是自研的系统。这个过程中，如何能够打造出易用的DevOps工具链，从而真正的实现DevOps的目标：

1. 从持续交付的角度审视DevOps工具链的各环节所要达到的目标。

2. 定义DevOps工具链易用性的范围和意义。

3. 结合DevOps工具链目标结合案例来探讨如何实现易用性。

理念

我们觉得开发和运维需要交付到一个运行的系统。如果运行的系统承载的是运行的业务的话，系统是不应该宕机的。在这基础上，我们认为“谁构建，谁运维”。区别于合作形式的，我们强调的是研发更多承担运维的职责，研发去做大部分测试的工作，包括上线的部署、性能的监控以及容量的测试。运维人员可以更专业性地提供运维相关的工具。

理念->体系

从一开始的理念通过持续交付这样现有的开源工具去打磨工具链条。

上图这个简单的架构图是我们现在做得比较多的一个解决方案，做了一段时间后我们也在其中发现了一些问题，这些问题促使我们开始做自己的工具生态。

理念->体系->工具

在这基础上，我们分析了很多工具类软件是怎么做的，并且也慢慢做了自己的工具链条。

在这过程中有一些问题不断地被提及，我们需要重复地和产品、研发去沟通。

系统为什么要这样架构？软件设计为什么要选择不完美的方案？同样的问题为什么要研发多种工具？为什么屡试不爽的设计理念不起作用？

隐藏在这些问题背后的共性就是我们今天要讨论的，怎样打造一个易用的工具链。

最关键的是一个“易”字，它代表了两个意思。第一个意思是简易。也就是工具设计的架构本身要足够简单，这样才容易扩展，相互之间容易配合。

第二个意思是易用。使用者在使用它的时候应该不造成过多的负担，能快速地解决问题。

我们在DevOps落地和工具链研发过程中遇到的问题以及解决问题的所思所做，是我今天所要分享的内容。

简易和易用为什么这么重要呢？

如果我们从产品的用户体验要素模型去看的话，在我们讲到易用性的时候，大家都是知道的，因为作为用户每天都在用不同的互联网工具。

但是当我们谈到2C和谈到2B的时候，它们的易用性完全是在两个层面。

2C强调的是要让用户尽量减少思考决策的东西，保持粘性。但是2B讲的是直接影响到解决义务问题的效率。

业务问题和用户问题能够直接影响到简易性，影响体现在架构、设计和交互。

部署流水线每次只生成一次二进制包，测试或运维人员手工选择需要的某个版本，将其部署到相应的环境中。操作人员应该可以看到所有构建版本和它们的状态（通过的阶段、包含的修改、提交注释等），一切都是为了了尽快得到反馈。必须能够看到每个环境中都部署了哪个版本，建立全程的追溯性。

技术人员是整个工具链的使用者。他们的特点就是自视甚高，但有些事标准极低——能用就行；能够并行处理大量信息，却在一些事上特别较真。

经验一

实现层面上分离，服务上整合。

关注点分离，各自独立发展。有些系统有自己的复杂性，必要时可以通过视图集成。

做系统的时候，我们只做一件事，并且把这件事做好。这样带来的好处是10个系统做10件事比一个系统做10件事好，因为它的复杂度低。

一站式系统大部分都是反人类的，只在真正需要时才给出一站式的视图。

经验二

设计上需要的关注点分离。

经验三

在设计层面上，包括架构、软件设计等，简单性都要大于完美性。

假如更新轮值排班表，有四个方案。

方案1：追求人员信息的准确性，不考虑历史信息。IPD⼈人员删除、人员排班信息调整，无历史信息。

方案2：无实时查询，历史数据跑批沉淀。沉淀阶段内的数据仍然不一致。

方案3：修改即沉淀。

方案4：缩短沉淀周期，缩小数据错误范围。

方案3和方案4哪一个更好？取决于具体的诉求到底是什么，但是我们真正做的时候会选择方案4。

经验四

做工具链的时候一定要关注到高级的使用情况。基于DSL命令行的工具特点是扩展性更好，效率更高。

当提供命令行的时候一定要要防止来自脚本的诱惑。如果脚本的处理不是业务上原子的话，那么脚本不应该成为系统的组成部分。

经验五

Just work。当你去使用一个电视或者遥控器的时候，只关注怎么用它，并不关心它背后实现的逻辑。

如图所示，从这个层面来看，通过这两个界面的对比就会发现，上面界面最大的问题就是这个流程暴露了太多内部实现的细节，而下面的界面只关注重点的阶段。

上面的界面还有一个巨大的问题在于测试是否通过和人工测试是属于两个抽象层面上的东西，在这个层面上不需要了解太多的细节，关键的阶段是发生了什么事。所以我们应该呈现出这样一个界面。

经验六

重在当下。如果是做部署的话，只关心最近一次发生的时间和情况，在历史上的列表可以先隐藏起来。

经验七

隐藏非关键信息。配置完成在使用过程中，只有在出了问题的情况下才会关注细节。整个工具链的信息非常丰富，所以只要出错的时候再提醒，告知细节性的信息。

经验八

业务为线，不要堆砌功能。以项目为单元，文件为基本的组成部分进行调试、开发和编辑。

经验九

突出使用，分离配置。当我们去使用一个工具链产品的时候，10%的时间是在配置工作流，一旦配置好，90%的时间都不需要再改动了。如果工具有这样一个 “用得多，变得少”的特点，重点突出使用的部分，把配置的部分简化一些，把功能隐藏起来，把配置慢慢地剥离开。

经验十

简化操作。整个2B工具链的研发都是解决效率的问题。DevOps里有一个重大的问题，如果每一次的构建生成一个版本，而且之后都是基于这个版本来做测试上线的话，就需要check整个生命周期的状态。

所以我们要建立一个全流程追踪的体系。

DevOps虽然没有大家想得那么复杂，但是也没有那么简单。

今天的分享就到这里，谢谢大家！

原创： IT大咖说

摘要

随着DevOps在企业内逐步推进，作为其最为重要一环的DevOps工具链会逐步构建起来——无论是基于开源的解决方案还是自研的系统。这个过程中，如何能够打造出易用的DevOps工具链，从而真正的实现DevOps的目标：

1. 从持续交付的角度审视DevOps工具链的各环节所要达到的目标。

2. 定义DevOps工具链易用性的范围和意义。

3. 结合DevOps工具链目标结合案例来探讨如何实现易用性。

理念

我们觉得开发和运维需要交付到一个运行的系统。如果运行的系统承载的是运行的业务的话，系统是不应该宕机的。在这基础上，我们认为“谁构建，谁运维”。区别于合作形式的，我们强调的是研发更多承担运维的职责，研发去做大部分测试的工作，包括上线的部署、性能的监控以及容量的测试。运维人员可以更专业性地提供运维相关的工具。

理念->体系

从一开始的理念通过持续交付这样现有的开源工具去打磨工具链条。

上图这个简单的架构图是我们现在做得比较多的一个解决方案，做了一段时间后我们也在其中发现了一些问题，这些问题促使我们开始做自己的工具生态。

理念->体系->工具

在这基础上，我们分析了很多工具类软件是怎么做的，并且也慢慢做了自己的工具链条。

在这过程中有一些问题不断地被提及，我们需要重复地和产品、研发去沟通。

系统为什么要这样架构？软件设计为什么要选择不完美的方案？同样的问题为什么要研发多种工具？为什么屡试不爽的设计理念不起作用？

隐藏在这些问题背后的共性就是我们今天要讨论的，怎样打造一个易用的工具链。

最关键的是一个“易”字，它代表了两个意思。第一个意思是简易。也就是工具设计的架构本身要足够简单，这样才容易扩展，相互之间容易配合。

第二个意思是易用。使用者在使用它的时候应该不造成过多的负担，能快速地解决问题。

我们在DevOps落地和工具链研发过程中遇到的问题以及解决问题的所思所做，是我今天所要分享的内容。

简易和易用为什么这么重要呢？

如果我们从产品的用户体验要素模型去看的话，在我们讲到易用性的时候，大家都是知道的，因为作为用户每天都在用不同的互联网工具。

但是当我们谈到2C和谈到2B的时候，它们的易用性完全是在两个层面。

2C强调的是要让用户尽量减少思考决策的东西，保持粘性。但是2B讲的是直接影响到解决义务问题的效率。

业务问题和用户问题能够直接影响到简易性，影响体现在架构、设计和交互。

部署流水线每次只生成一次二进制包，测试或运维人员手工选择需要的某个版本，将其部署到相应的环境中。操作人员应该可以看到所有构建版本和它们的状态（通过的阶段、包含的修改、提交注释等），一切都是为了了尽快得到反馈。必须能够看到每个环境中都部署了哪个版本，建立全程的追溯性。

技术人员是整个工具链的使用者。他们的特点就是自视甚高，但有些事标准极低——能用就行；能够并行处理大量信息，却在一些事上特别较真。

经验一

实现层面上分离，服务上整合。

关注点分离，各自独立发展。有些系统有自己的复杂性，必要时可以通过视图集成。

做系统的时候，我们只做一件事，并且把这件事做好。这样带来的好处是10个系统做10件事比一个系统做10件事好，因为它的复杂度低。

一站式系统大部分都是反人类的，只在真正需要时才给出一站式的视图。

经验二

设计上需要的关注点分离。

经验三

在设计层面上，包括架构、软件设计等，简单性都要大于完美性。

假如更新轮值排班表，有四个方案。

方案1：追求人员信息的准确性，不考虑历史信息。IPD⼈人员删除、人员排班信息调整，无历史信息。

方案2：无实时查询，历史数据跑批沉淀。沉淀阶段内的数据仍然不一致。

方案3：修改即沉淀。

方案4：缩短沉淀周期，缩小数据错误范围。

方案3和方案4哪一个更好？取决于具体的诉求到底是什么，但是我们真正做的时候会选择方案4。

经验四

做工具链的时候一定要关注到高级的使用情况。基于DSL命令行的工具特点是扩展性更好，效率更高。

当提供命令行的时候一定要要防止来自脚本的诱惑。如果脚本的处理不是业务上原子的话，那么脚本不应该成为系统的组成部分。

经验五

Just work。当你去使用一个电视或者遥控器的时候，只关注怎么用它，并不关心它背后实现的逻辑。

如图所示，从这个层面来看，通过这两个界面的对比就会发现，上面界面最大的问题就是这个流程暴露了太多内部实现的细节，而下面的界面只关注重点的阶段。

上面的界面还有一个巨大的问题在于测试是否通过和人工测试是属于两个抽象层面上的东西，在这个层面上不需要了解太多的细节，关键的阶段是发生了什么事。所以我们应该呈现出这样一个界面。

经验六

重在当下。如果是做部署的话，只关心最近一次发生的时间和情况，在历史上的列表可以先隐藏起来。

经验七

隐藏非关键信息。配置完成在使用过程中，只有在出了问题的情况下才会关注细节。整个工具链的信息非常丰富，所以只要出错的时候再提醒，告知细节性的信息。

经验八

业务为线，不要堆砌功能。以项目为单元，文件为基本的组成部分进行调试、开发和编辑。

经验九

突出使用，分离配置。当我们去使用一个工具链产品的时候，10%的时间是在配置工作流，一旦配置好，90%的时间都不需要再改动了。如果工具有这样一个 “用得多，变得少”的特点，重点突出使用的部分，把配置的部分简化一些，把功能隐藏起来，把配置慢慢地剥离开。

经验十

简化操作。整个2B工具链的研发都是解决效率的问题。DevOps里有一个重大的问题，如果每一次的构建生成一个版本，而且之后都是基于这个版本来做测试上线的话，就需要check整个生命周期的状态。

所以我们要建立一个全流程追踪的体系。

DevOps虽然没有大家想得那么复杂，但是也没有那么简单。

今天的分享就到这里，谢谢大家！

原创： IT大咖说