人人都说要体验 DevOps，确信自己走在正确的道路上？

兵家必争的 DevOps 平台 

DevOps 的概念也炒了几年了，仿佛是治疗所有公司痛点的神药。DevOps 本没有如此玄幻，但市场热度居高不下，如今 DevOps 平台已经成为各大企业推广 DevOps 之路上的兵家必争产品。

早在 DevOps 尝鲜时代，没什么人能真正搞懂 DevOps （当然，至今其实仍然有很多伪 DevOps），为了追求敏捷，大家使用了各种各样的工具，犹如在组装一台神奇的兼容机，有钱的请人装，没钱的自己装，样貌丑陋，性能也并不好，并且大家发现要玩起来简直要各方神人聚集才能玩得转。于是，明明是追求敏捷，却变成了学习研究各种工具。

大厂由于人多物博，率先折腾出了一套自己的平台，然后开始向市场撒毒，宣扬着谁有了平台谁就能市场制霸。但花了钱的主们用了一段时间后总觉着味儿不是那么太对，因为这些 DevOps 平台看起来也没啥技术含量，功能跟那些单独的服务系统比，甚至还逊色一些，莫不是上当受骗了？甚至有些企业按耐不住，开始了自建平台之旅。

引入 DevOps 到底想解决什么

然而现实是残酷的，无论是引入大厂产品，还是自建平台，很少有企业能够真正从 DevOps 中受益，除了 KPI 上去了，GDP 贡献了，并没有体现出其他更多的价值。

从痛点出发，必定才是正确的思路。

是因为市场追捧 DevOps，所以我们要用 DevOps 平台吗？

是因为大厂用 DevOps 平台，所以我们也要用吗？

是因为要快点快点再快点，所以才要用 DevOps 平台吗？

应该都不是，但多数人说不清，总觉得目前状况，用 DevOps 就对了。

• 发布周期长，用 DevOps 就对了

• 测试自动化，用 DevOps 就对了

• 运维自动化，用 DevOps 就对了

• 团队协作差，用 DevOps 就对了

看，是不是像极了万能的热水？

口渴喝热水是对的，治病你也跟我说喝热水，R U kidding me？

所以引入 DevOps 到底想解决什么？这个比单纯搞个 DevOps 平台更重要。

是否具有 DevOps 体质

DevOps 的原始意义虽然只是作用于运维领域，但是人嘛，毕竟是高级物种，会举一反三，于是运用到方方面面，如今在产品需求、开发、测试、交付运维、技术支持各个领域都会见到 DevOps 的身影，犹如一颗万能药，包治百病。

但 DevOps 运用得好，秒杀对手，要是运用得不好，直接送人头。有些企业号称落地了 DevOps，其实顶多就算个持续集成，各种自动化；有些企业搞上了 DevOps，绿皮变高铁，什么都快，死得也快。所以 DevOps 治不治病，一看有没有对症，二看是否有 DevOps 体质。

中医看病，讲究望闻问切，啥病都是同一副药，你觉得病能治好？引入 DevOps 也是一样的道理，工具层面只是药材，根据企业现状和问题，定制服务才是药方。

实践出真知

既然很多人说不清 DevOps，那就难得糊涂一下，DevOps 是门实践课，纸上谈兵永远找不到适合自己的方案。有人说，那不成了乱折腾了？我说它是实践课，没说任意放养穷折腾啊，既然是课，还是得有专业知识的老师指导的。

讲真，市场上能聊 DevOps 知识的人很多，搞 DevOps 工具的人也很多，但真正能落地方案的专家却很少，为啥这样？其实也挺符合自然规律的，就像懂医学的人很多，懂药材的人也很多，但能治病的老中医专家有多少？临床经验很重要，疑难杂症见得多了，你以为的大病，在人家眼里就是个小痛。但话说回来，多数人都觉得专家号比较贵，宁可挂个普通号，然后根据自己的经验吃点药，这是人性，无可厚非。

经验哪里来？从实践中来。在哪里实践？可以直接花钱买个商业服务，也可以自己搭建一套工具链，只不过工具有很多，甚至相同功能的工具也有很多，这必然会给大家成为实践 DevOps 路上的一个绊脚石。

一键部署 Open DevOps

如果对专项工具不是那么的痴迷，不妨试试我这套组合，我不给任何一个工具做广告，也不想破坏一些生态平衡，所以该项目仅用作大家学习和体验 DevOps，请勿用在商业场合。

▲ Open DevOps Portal

项目地址：

https://github.com/QualitySphere/OpenDevOps

本着初心，因此全套工具链一键启动，尽可能的减少大家对于工具层面的部署配置，初始化通过脚本做了自动化（该项目并未完结，因此并不是所有服务都能自动初始化）

快速开始

1.  获取脚本

git clone https://github.com/QualitySphere/OpenDevOps.git

2.  进入 ODO 主目录

cd OpenDevOps

3.  修改 docker-compose.yaml 中的 odo-portal 关于 environment 的部分，localhost 替换成主机的 IP 或者是 域名

4.  启动 ODO services

./odoctl start all

5.  访问 ODO-Portal http://ODO-HOST-IP

完了？

对，完了，就这么简单。

如果你是某工具的专家，可以再定制一些功能，如果对这些工具比较生疏，建议先快速开始一套再说，更多细节可以进 GitHub 项目慢慢品，不在此处占用太多篇幅。

DevOps 实践比平台更重要

整套工具链覆盖: 

• 产品管理

• 项目管理

• 研发管理

• 部署管理

• 质量管理

然而要运作 DevOps 只靠这些工具支撑是不够的，还需要参考一系列的流程规范，但仅仅是参考，因为不同的企业或者团队，都有自己的一套打法，十八般武艺各有各的精彩，找到自己最趁手兵器，结合心法，才能练就一番绝世武功。

所谓心法，是需要体会的，因此不同的人，会有不同的感悟，同样一套心法，有人立地成佛，有人走火入魔，大多数是平平庸庸两手空，师傅指导很重要。

▲ DevOps 莫比乌斯环

在后续的文章中，会继续分享一些各项管理实践，均可以在 Open DevOps 平台上体验体验。

写在最后

正如大家看到的，工具链作为 DevOps 金字塔最底层，其实是落地中最容易实现的一个工作，人民币玩家和非人民币玩家都能搞定。

▲ DevOps 金字塔

但很多人把精力花在了这个最容易实现的部分，所以我做了 Open DevOps 分享出来，仅希望大家能够用最少的精力跳过这一环节，从而能够进入到真正需要大家一起实践总结经验的阶段。Open DevOps 以后可能会更换其中的一些工具，希望有更多的人受益。

-- END --

作者：Will，软件质量保障专家，DevOps 落地专家。曾担任某大型全球分布式存储产品测试交付负责人，某容器平台解决方案 DevOps 产品质量负责人，现任一家零售业大数据人工智能平台质量负责人。

QQ群号：763628645

QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过