2018 年对许多人来说是艰难与变革的一年，势如破竹的发展势头似乎被打破，小微创新型企业生存艰难。“产业互联网”“企业数字化转型”等寻求从内破局的呼声也越来越高。
有趣的是，类似的情况不是第一次出现。1999 年金融海啸来袭，经济下行周期内，大家都寄希望于当时先进的信息技术，希望能以此提升自身的管理水平，增强企业竞争力。导致当年 ERP 进入中国后迅速走红，令无数缺乏管理经验的中国企业心驰神往。
而到了数字化转型的浪潮之年，这个风口上的词变成了 DevOps（/de'vɒps/）。大家纷纷开始讨论要不要采用 DevOps 、DevOps 到底有没有那么神奇。

Google Trends 中 DevOps 历年的热度数据

  
DevOps 到底是什么2018 年，我们走访了近百个分布在各行各业中的 IT 团队，意外的发现，大多数的 IT 团队寻求改革并非来源于部门内部的自我革新，[  /blog/IT]而是来源于业务部门的服务压力[/url]。正如同当年企业寻找 ERP，今天的企业将目光投向了 DevOps。但是 DevOps 并非像 ERP 那样可以直接部署的东西，而是一种由主流互联网巨头们所总结出来的的研发管理理念，是 Google、Netflix 等大型互联网公司实现快速迭代的秘诀。

作为一家专注于研发 DevOps 工具链的公司创始人，我在接触客户的时候，发现一个很有趣的现象：所有人都想“做” DevOps 并期待其能为他们带来商业上的成功，却对 DevOps 的核心理念知之甚少。这很大一部分原因是市面上对 DevOps 有着各种各样的说法，导致大家概念的混淆。想要弄清楚 DevOps 到底是什么，必须先从它的本质说起。

软件开发最高效的组织形式是“One Man Work”，只有一个人干活，写个小项目，从需求到开发，从测试到部署全部独立完成，非常高效。但随着业务的增长，项目开始逐渐变得庞大，变成团队，出现了分工，出现了产品经理、项目经理、开发、数据、测试、运维等等角色。这些角色间存在天然的工作目标上的矛盾。

举个例子，对于运维来说，稳定压倒一切，新 Feature 越少越好。而对于研发来说，却希望能开发更多的功能。这种矛盾会导致大量的资源和时间的浪费。就像两匹马拉一辆车，如果马头向着的方向不一致，肯定是没法全速前进的。

DevOps 的理念就是希望能打破这种屏障，让研发（Development）和运维（Operations）一体化，让团队从业务需求出发，向着同一个目标前进。

字面意思上说 DevOps 是指“开发运维一体化”，即通过工具辅助开发完成运维的部分工作，减少成本。但深入理解了 DevOps 之后，你会发现 DevOps 其实是一种软件研发管理的思想，方法论，他追求的是一种没有隔阂的理想的研发协作的状态，可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我们认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。


比如 Google 提出的 5 个 DevOps 原则，这套原则中必须依赖于工具辅助的部分只有后两点，更多的则是对于开发组织形式的内省：

• 精简组织架构；
• 愿意承担一部分试错带来的损失；
• 分阶段地一小步一小步地进行转型；
• 最大化地利用工具和自动化流程；
• 对所有的过程和结果进行记录和分析。
  

所以 DevOps 不是简单的开发软件化，而是企业的学习能力不断提升的结果，将企业改造成敏捷应对的学习型组织，运用新的工具，优化组织架构和流程，不断地进行自我革命和创新的方式。工具是辅助，而非基础。


困难重重的 DevOps


落地在弄清楚了 DevOps 的宏观定义之后，我们再来观察一下 DevOps 目前在国内的实践现状。根据南京大学 «DevOps 中国•2018 年度调研» 的调研报告，目前设有 DevOps 实践团队的公司中，科技和互联网行业占比接近 70%。其他行业的从业者对 DevOps 的认知还存在一定的不足。

这与我们的调研走访体验一致：大多数企业都愿意尝试运用 DevOps ，但是在实践 DevOps 中，普遍碰到了比较大的困难。主要是以下三个原因：

对 DevOps 有不切实际的预期部分团队为了做 DevOps 而做 DevOps，并没有真正的从业务的角度出发来考虑。

如前文所说，DevOps 不是银弹，高水平的研发团队在 DevOps 实践中将快速找到研发质量与业务增长的平衡点。但对于许多仍然在使用中心化的研发组织形式的团队来说，DevOps 的尝试无法立即获得肉眼可见的增长数据，思索与尝试带来的对团队的训练可能会是第一份收获。

步子迈得太大新生代互联网公司诞生于 DevOps 理念已经相对成熟的年代，且互联网公司天生地将迭代速度作为追求目标之一，使得这些公司能够在发展的初期，就将 DevOps 的理念融入到公司的架构设计中。

上图是 Netflix 的整个系统架构。如此复杂的系统架构同时还能每天迭代几十个版本，无法通过传统的研发管理模式来维护，只有通过实践 DevOps 的理念，来优化组织的分工、资源和能效，才能得以实现。在这样的组织里，已经不需要有人了解所有模块是做什么，每个人只需要对自己的模块负责。

而很多企业，为了巩固和提高自己的市场竞争力，非常急于达成上述高效的状态，并且希望能一步到位。国内其实大部分团队都没到大规模实践 DevOps 的时间点，有些团队甚至连分支开发、并行开发的方式都没有。我给这类的企业建议是：不要想着一口气吃成个胖子，一步一步来，先理解 DevOps 的理念和对业务的实际意义，然后搭建一只小的 DevOps 团队来承接一项新业务，旧的业务仍然使用旧系统，双轨并行，等待小团队适应了 DevOps 的管理节奏之后再向其他团队进行推广。

之前出过一篇关于 DevOps 的专题报告[  /blog/dev-report]《四周年 · 专题报告：双速 IT》[/url]，也可以作为参考。

Toolchain Crisis实践 DevOps 的原则中很重要的一点就是对工具的运用及依赖工具搭建合适企业的自动化流程。但是目前市面上缺乏成熟的 DevOps 工具链，各个服务商的细分工具层出不穷，企业为了搭建整套 DevOps 流程，需要研究几十种工具，并选取其中的 7-8 种进行落地实践。非常依赖于管理者的项目经验，没有 DevOps 经验的团队起步将会比较困难。

以 CODING 为例。2018 年之前 CODING 产品仅有任务及代码管理模块。我们是这样进行工作的：产品经理在 CODING 上撰写文档创建任务，研发 Leader 将任务分配给开发，开发完成后提交代码，并创建 MR，我们在本地部署了 Jenkins 进行持续集成进行构建和测试，再由其他工程师进行人工评审，通过后并到发布分支，进行预发布，再通过持续集成进行构建，自建 Docker registry 进行构建物管理。构建出的 Docker 镜像在测试环境和预发布环境上依次进行自动化测试及人工测试，测试通过后，使用我们运维自己搭建的工具进行部署管理。

目前 CODING 每天都进行产品迭代，可以快速响应用户需求并保证服务质量，但搭建这一整套的流程高度依赖于团队能力，门槛非常高。

为了降低工具的成本和使用门槛，包括  CODING 在内的很多云服务厂商都在做打通全流程的 DevOps 工具链的尝试，希望可以做到让企业开箱即用，低成本的践行 DevOps 理念，不过目前产品仍处于迭代期，无法满足所有企业的需求。


DevOps 是未来的趋势既然 DevOps 这么难，坑这么多，为什么还要做呢？因为这是企业未来的长期诉求。

从大趋势上分析，未来所有企业都将是软件企业，制造软件、服务软件、构建于软件。比如全世界最大的出行公司 Uber，其实是一个软件公司，而非出租车公司。从企业自身诉求出发，中国的中大型企业已经逐步进入了创新驱动的阶段。无论是供给侧改革还是智能制造 2025 都要求企业修炼内功，提高效率促进创新。过去几年中在塑造前沿行业的 DevOps 理念将在 2019 年左右成为主流，成为企业能否在行业内脱颖而出的关键性因素。

在 Statsia 2018 年的报告中，有超过 72% 的企业或多或少地开始践行 DevOps 的理念，其中完整采用 DevOps 的比例高达 17% ，而在 2017 年这个数字仅有 10%。

真正能够实践 DevOps 的团队也会为自身的业务[  /blog/DevOps]带来巨大的提升[/url]。根据 Puppt 的2017 DevOps State Report，DevOps 型团队将部署频率提高46倍，交付速度提高 440 倍。

可见，在国际上来说，DevOps 已经处于企业爆发性需求的前夜。而在国内公司中，新兴企业的成功实践也在为中国企业的 DevOps 输送方法论与有经验的专家。

字节跳动可以说是 DevOps 最佳践行者之一。在其创始人张一鸣看来：

公司的业务越复杂，人越多，组织就越大。这导致信息失效、（下属）向上管理和业务变大。他把类似组织的负规模效应称为“自嗨”，这是他所不能接受的。

故而字节跳动在组织架构上，总共只有 3 个核心部门：技术、Growth 和商业化，分别负责研发、推广和收入。

今日头条、抖音、西瓜视频……字节跳动的每款 App 都基于这三个部门来发展。在项目开始时，公司会为每个项目设置虚拟项目组，由三个核心部门抽调人员组成，试水成功后直接推广。所有产品共用一条技术线，快速试错。针对 App 类产品的快速迭代的业务特性，字节跳动依据 DevOps 理念对组织架构进行调整和优化，从结构上保证了技术支持业务创新的能力。


Why Now？DevOps 的理念和优势被说了很多年，但一直都只在少量公司有能力实践。

软件的工程化历史还比较短暂，业务需求与技术理念都日新月异，前两年大量的团队还在为了研发新的业务疲于奔命，没有精力关注研发效能升级的问题。许多团队的研发管理还停留在靠微信喊话和 Excel 管理的阶段。

而如今，在市场遇冷和企业数字化转型的契机下，更多的公司开始将目光放在企业内部的效率提升和研发成本的控制上。

在 Netflix、Google 这样发展比较久的的巨型公司可以耗费大量的内部资源从底层服务开始从零搭建 DevOps 流程。而像字节跳动这样的新型公司可以如此快速实现敏捷，也得益于云服务的逐步成熟。

尤其是在当前环境下，运维业务逐步多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，越来越多的团队选择使用 Docker kubernetes 等技术提升运维能力。同时，云厂商的 SaaS、IaaS 和 PaaS 服务相对于传统的运维业务帮助企业节省大量硬件维护的成本和时间，让企业能专注于业务的发展与创新。


结语孙子兵法有云，凡兵法韬略，在道不在术。面对日新月异的的市场，企业必须逼迫自己不断的进行革新来应对市场变化。就像马化腾在互联网大会上提到的，现在互联网已经发展到了深水区，甚至是无人区。只有不断的迭代，迅速反应，才能应对未来的变化，而这也正是 DevOps 所强调的。



作者：CODING_DevOps
链接：[  /p/8773fcee4894]p/8773fcee4894[/url]
来源：简书

2018 年对许多人来说是艰难与变革的一年，势如破竹的发展势头似乎被打破，小微创新型企业生存艰难。“产业互联网”“企业数字化转型”等寻求从内破局的呼声也越来越高。
有趣的是，类似的情况不是第一次出现。1999 年金融海啸来袭，经济下行周期内，大家都寄希望于当时先进的信息技术，希望能以此提升自身的管理水平，增强企业竞争力。导致当年 ERP 进入中国后迅速走红，令无数缺乏管理经验的中国企业心驰神往。
而到了数字化转型的浪潮之年，这个风口上的词变成了 DevOps（/de'vɒps/）。大家纷纷开始讨论要不要采用 DevOps 、DevOps 到底有没有那么神奇。

Google Trends 中 DevOps 历年的热度数据

  
DevOps 到底是什么2018 年，我们走访了近百个分布在各行各业中的 IT 团队，意外的发现，大多数的 IT 团队寻求改革并非来源于部门内部的自我革新，[  /blog/IT]而是来源于业务部门的服务压力[/url]。正如同当年企业寻找 ERP，今天的企业将目光投向了 DevOps。但是 DevOps 并非像 ERP 那样可以直接部署的东西，而是一种由主流互联网巨头们所总结出来的的研发管理理念，是 Google、Netflix 等大型互联网公司实现快速迭代的秘诀。

作为一家专注于研发 DevOps 工具链的公司创始人，我在接触客户的时候，发现一个很有趣的现象：所有人都想“做” DevOps 并期待其能为他们带来商业上的成功，却对 DevOps 的核心理念知之甚少。这很大一部分原因是市面上对 DevOps 有着各种各样的说法，导致大家概念的混淆。想要弄清楚 DevOps 到底是什么，必须先从它的本质说起。

软件开发最高效的组织形式是“One Man Work”，只有一个人干活，写个小项目，从需求到开发，从测试到部署全部独立完成，非常高效。但随着业务的增长，项目开始逐渐变得庞大，变成团队，出现了分工，出现了产品经理、项目经理、开发、数据、测试、运维等等角色。这些角色间存在天然的工作目标上的矛盾。

举个例子，对于运维来说，稳定压倒一切，新 Feature 越少越好。而对于研发来说，却希望能开发更多的功能。这种矛盾会导致大量的资源和时间的浪费。就像两匹马拉一辆车，如果马头向着的方向不一致，肯定是没法全速前进的。

DevOps 的理念就是希望能打破这种屏障，让研发（Development）和运维（Operations）一体化，让团队从业务需求出发，向着同一个目标前进。

字面意思上说 DevOps 是指“开发运维一体化”，即通过工具辅助开发完成运维的部分工作，减少成本。但深入理解了 DevOps 之后，你会发现 DevOps 其实是一种软件研发管理的思想，方法论，他追求的是一种没有隔阂的理想的研发协作的状态，可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我们认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。


比如 Google 提出的 5 个 DevOps 原则，这套原则中必须依赖于工具辅助的部分只有后两点，更多的则是对于开发组织形式的内省：

• 精简组织架构；
• 愿意承担一部分试错带来的损失；
• 分阶段地一小步一小步地进行转型；
• 最大化地利用工具和自动化流程；
• 对所有的过程和结果进行记录和分析。
  

所以 DevOps 不是简单的开发软件化，而是企业的学习能力不断提升的结果，将企业改造成敏捷应对的学习型组织，运用新的工具，优化组织架构和流程，不断地进行自我革命和创新的方式。工具是辅助，而非基础。


困难重重的 DevOps


落地在弄清楚了 DevOps 的宏观定义之后，我们再来观察一下 DevOps 目前在国内的实践现状。根据南京大学 «DevOps 中国•2018 年度调研» 的调研报告，目前设有 DevOps 实践团队的公司中，科技和互联网行业占比接近 70%。其他行业的从业者对 DevOps 的认知还存在一定的不足。

这与我们的调研走访体验一致：大多数企业都愿意尝试运用 DevOps ，但是在实践 DevOps 中，普遍碰到了比较大的困难。主要是以下三个原因：

对 DevOps 有不切实际的预期部分团队为了做 DevOps 而做 DevOps，并没有真正的从业务的角度出发来考虑。

如前文所说，DevOps 不是银弹，高水平的研发团队在 DevOps 实践中将快速找到研发质量与业务增长的平衡点。但对于许多仍然在使用中心化的研发组织形式的团队来说，DevOps 的尝试无法立即获得肉眼可见的增长数据，思索与尝试带来的对团队的训练可能会是第一份收获。

步子迈得太大新生代互联网公司诞生于 DevOps 理念已经相对成熟的年代，且互联网公司天生地将迭代速度作为追求目标之一，使得这些公司能够在发展的初期，就将 DevOps 的理念融入到公司的架构设计中。

上图是 Netflix 的整个系统架构。如此复杂的系统架构同时还能每天迭代几十个版本，无法通过传统的研发管理模式来维护，只有通过实践 DevOps 的理念，来优化组织的分工、资源和能效，才能得以实现。在这样的组织里，已经不需要有人了解所有模块是做什么，每个人只需要对自己的模块负责。

而很多企业，为了巩固和提高自己的市场竞争力，非常急于达成上述高效的状态，并且希望能一步到位。国内其实大部分团队都没到大规模实践 DevOps 的时间点，有些团队甚至连分支开发、并行开发的方式都没有。我给这类的企业建议是：不要想着一口气吃成个胖子，一步一步来，先理解 DevOps 的理念和对业务的实际意义，然后搭建一只小的 DevOps 团队来承接一项新业务，旧的业务仍然使用旧系统，双轨并行，等待小团队适应了 DevOps 的管理节奏之后再向其他团队进行推广。

之前出过一篇关于 DevOps 的专题报告[  /blog/dev-report]《四周年 · 专题报告：双速 IT》[/url]，也可以作为参考。

Toolchain Crisis实践 DevOps 的原则中很重要的一点就是对工具的运用及依赖工具搭建合适企业的自动化流程。但是目前市面上缺乏成熟的 DevOps 工具链，各个服务商的细分工具层出不穷，企业为了搭建整套 DevOps 流程，需要研究几十种工具，并选取其中的 7-8 种进行落地实践。非常依赖于管理者的项目经验，没有 DevOps 经验的团队起步将会比较困难。

以 CODING 为例。2018 年之前 CODING 产品仅有任务及代码管理模块。我们是这样进行工作的：产品经理在 CODING 上撰写文档创建任务，研发 Leader 将任务分配给开发，开发完成后提交代码，并创建 MR，我们在本地部署了 Jenkins 进行持续集成进行构建和测试，再由其他工程师进行人工评审，通过后并到发布分支，进行预发布，再通过持续集成进行构建，自建 Docker registry 进行构建物管理。构建出的 Docker 镜像在测试环境和预发布环境上依次进行自动化测试及人工测试，测试通过后，使用我们运维自己搭建的工具进行部署管理。

目前 CODING 每天都进行产品迭代，可以快速响应用户需求并保证服务质量，但搭建这一整套的流程高度依赖于团队能力，门槛非常高。

为了降低工具的成本和使用门槛，包括  CODING 在内的很多云服务厂商都在做打通全流程的 DevOps 工具链的尝试，希望可以做到让企业开箱即用，低成本的践行 DevOps 理念，不过目前产品仍处于迭代期，无法满足所有企业的需求。


DevOps 是未来的趋势既然 DevOps 这么难，坑这么多，为什么还要做呢？因为这是企业未来的长期诉求。

从大趋势上分析，未来所有企业都将是软件企业，制造软件、服务软件、构建于软件。比如全世界最大的出行公司 Uber，其实是一个软件公司，而非出租车公司。从企业自身诉求出发，中国的中大型企业已经逐步进入了创新驱动的阶段。无论是供给侧改革还是智能制造 2025 都要求企业修炼内功，提高效率促进创新。过去几年中在塑造前沿行业的 DevOps 理念将在 2019 年左右成为主流，成为企业能否在行业内脱颖而出的关键性因素。

在 Statsia 2018 年的报告中，有超过 72% 的企业或多或少地开始践行 DevOps 的理念，其中完整采用 DevOps 的比例高达 17% ，而在 2017 年这个数字仅有 10%。

真正能够实践 DevOps 的团队也会为自身的业务[  /blog/DevOps]带来巨大的提升[/url]。根据 Puppt 的2017 DevOps State Report，DevOps 型团队将部署频率提高46倍，交付速度提高 440 倍。

可见，在国际上来说，DevOps 已经处于企业爆发性需求的前夜。而在国内公司中，新兴企业的成功实践也在为中国企业的 DevOps 输送方法论与有经验的专家。

字节跳动可以说是 DevOps 最佳践行者之一。在其创始人张一鸣看来：

公司的业务越复杂，人越多，组织就越大。这导致信息失效、（下属）向上管理和业务变大。他把类似组织的负规模效应称为“自嗨”，这是他所不能接受的。

故而字节跳动在组织架构上，总共只有 3 个核心部门：技术、Growth 和商业化，分别负责研发、推广和收入。

今日头条、抖音、西瓜视频……字节跳动的每款 App 都基于这三个部门来发展。在项目开始时，公司会为每个项目设置虚拟项目组，由三个核心部门抽调人员组成，试水成功后直接推广。所有产品共用一条技术线，快速试错。针对 App 类产品的快速迭代的业务特性，字节跳动依据 DevOps 理念对组织架构进行调整和优化，从结构上保证了技术支持业务创新的能力。


Why Now？DevOps 的理念和优势被说了很多年，但一直都只在少量公司有能力实践。

软件的工程化历史还比较短暂，业务需求与技术理念都日新月异，前两年大量的团队还在为了研发新的业务疲于奔命，没有精力关注研发效能升级的问题。许多团队的研发管理还停留在靠微信喊话和 Excel 管理的阶段。

而如今，在市场遇冷和企业数字化转型的契机下，更多的公司开始将目光放在企业内部的效率提升和研发成本的控制上。

在 Netflix、Google 这样发展比较久的的巨型公司可以耗费大量的内部资源从底层服务开始从零搭建 DevOps 流程。而像字节跳动这样的新型公司可以如此快速实现敏捷，也得益于云服务的逐步成熟。

尤其是在当前环境下，运维业务逐步多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，越来越多的团队选择使用 Docker kubernetes 等技术提升运维能力。同时，云厂商的 SaaS、IaaS 和 PaaS 服务相对于传统的运维业务帮助企业节省大量硬件维护的成本和时间，让企业能专注于业务的发展与创新。


结语孙子兵法有云，凡兵法韬略，在道不在术。面对日新月异的的市场，企业必须逼迫自己不断的进行革新来应对市场变化。就像马化腾在互联网大会上提到的，现在互联网已经发展到了深水区，甚至是无人区。只有不断的迭代，迅速反应，才能应对未来的变化，而这也正是 DevOps 所强调的。



作者：CODING_DevOps
链接：[  /p/8773fcee4894]p/8773fcee4894[/url]
来源：简书