链接：/question/55874411/answer/608052871
DevOps 到底是什么
年，我们走访了近百个分布在各行各业中的 IT 团队，意外的发现，大多数的 IT 团队寻求改革并非来源于部门内部的自我革新，而是来源于业务部门的服务压力。正如同当年企业寻找 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 中国• 年度调研» 的调研报告，目前设有 DevOps 实践团队的公司中，科技和互联网行业占比接近 70%。其他行业的从业者对 DevOps 的认知还存在一定的不足。
这与我们的调研走访体验一致：大多数企业都愿意尝试运用 DevOps ，但是在实践 DevOps 中，普遍碰到了比较大的困难。主要是以下三个原因：
对 DevOps 有不切实际的预期
部分团队为了做 DevOps 而做 DevOps，并没有真正的从业务的角度出发来考虑。
如前文所说，DevOps 不是银弹，高水平的研发团队在 DevOps 实践中将快速找到研发质量与业务增长的平衡点。但对于许多仍然在使用中心化的研发组织形式的团队来说，DevOps 的尝试无法立即获得肉眼可见的增长数据，思索与尝试带来的对团队的训练可能会是第一份收获。
步子迈得太大
新生代互联网公司诞生于 DevOps 理念已经相对成熟的年代，且互联网公司天生地将迭代速度作为追求目标之一，使得这些公司能够在发展的初期，就将 DevOps 的理念融入到公司的架构设计中。
上图是 Netflix 的整个系统架构。如此复杂的系统架构同时还能每天迭代几十个版本，无法通过传统的研发管理模式来维护，只有通过实践 DevOps 的理念，来优化组织的分工、资源和能效，才能得以实现。在这样的组织里，已经不需要有人了解所有模块是做什么，每个人只需要对自己的模块负责。
而很多企业，为了巩固和提高自己的市场竞争力，非常急于达成上述高效的状态，并且希望能一步到位。国内其实大部分团队都没到大规模实践 DevOps 的时间点，有些团队甚至连分支开发、并行开发的方式都没有。我给这类的企业建议是：不要想着一口气吃成个胖子，一步一步来，先理解 DevOps 的理念和对业务的实际意义，然后搭建一只小的 DevOps 团队来承接一项新业务，旧的业务仍然使用旧系统，双轨并行，等待小团队适应了 DevOps 的管理节奏之后再向其他团队进行推广。
之前出过一篇关于 DevOps 的专题报告《四周年 · 专题报告：双速 IT》，也可以作为参考。
Toolchain Crisis
实践 DevOps 的原则中很重要的一点就是对工具的运用及依赖工具搭建合适企业的自动化流程。但是目前市面上缺乏成熟的 DevOps 工具链，各个服务商的细分工具层出不穷，企业为了搭建整套 DevOps 流程，需要研究几十种工具，并选取其中的 7-8 种进行落地实践。非常依赖于管理者的项目经验，没有 DevOps 经验的团队起步将会比较困难。
以 CODING 为例。 年之前 CODING 产品仅有任务及代码管理模块。我们是这样进行工作的：产品经理在 CODING 上撰写文档创建任务，研发 Leader 将任务分配给开发，开发完成后提交代码，并创建 MR，我们在本地部署了 Jenkins 进行持续集成进行构建和测试，再由其他工程师进行人工评审，通过后并到发布分支，进行预发布，再通过持续集成进行构建，自建 Docker registry 进行构建物管理。构建出的 Docker 镜像在测试环境和预发布环境上依次进行自动化测试及人工测试，测试通过后，使用我们运维自己搭建的工具进行部署管理。
目前 CODING 每天都进行产品迭代，可以快速响应用户需求并保证服务质量，但搭建这一整套的流程高度依赖于团队能力，门槛非常高。
为了降低工具的成本和使用门槛，包括 CODING 在内的很多云服务厂商都在做打通全流程的 DevOps 工具链的尝试，希望可以做到让企业开箱即用，低成本的践行 DevOps 理念，不过目前产品仍处于迭代期，无法满足所有企业的需求。
链接：/question/55874411/answer/608052871
