人人都说自己在做 DevOps。
你的招聘启事上这么写，你的领英主页也这么写。新来的工程副总裁肯定也在他第一次全员大会上指着一张画着无限循环图的幻灯片说过这句话。
然而不知为何，部署仍然要花三天时间，自 2019 年以来预发布环境就再也没和生产环境保持一致过，而且只要某个周五下午的一次糟糕上线，就能立刻引发一场全面事故。
那么，到底发生了什么？
DevOps 究竟是什么
我们先从那个没人能达成共识的定义说起。
- DevOps 不是一种工具。
- 它不是一个职位名称。
- 它也不是你能从供应商那里买来的东西，无论他们多么努力地向你推销。
DevOps 是一种文化和实践，它将软件开发（Dev）与信息技术运维（Ops）融合为统一的工作流程——目标是更快、更可靠地交付软件，并减少凌晨两点被电话叫醒的次数。
其核心理念包括：
∙ 持续集成（CI） —— 开发人员频繁合并代码，自动化测试能尽早发现问题
∙ 持续交付（CD） —— 代码始终处于可部署状态，发布变得平淡无奇且常规化
∙ 基础设施即代码（IaC） —— 你的服务器通过版本控制的配置文件定义，而不是由早已离职的某位员工在控制台上手动点击搭建而成
∙ 监控与可观测性 —— 在客户告诉你之前，你就已经知道系统哪里出问题了
∙ 协作 —— 开发团队和运维团队协同工作，而不是互相把任务“扔过墙”
很简单，对吧？
旁白：其实一点也不简单。
为什么人人都声称自己在做 DevOps，但大多数其实并没有
DevOps 的问题在于——它在纸面上听起来太美好了：更快的发布！更少的宕机！工程师终于能在晚上睡个好觉！
但一旦你试图在一家拥有真实遗留系统、真实员工（这些人早在 Docker 出现之前就已形成固定工作方式）的公司里真正落地 DevOps，事情就会迅速变得复杂起来。
“我们在做 DevOps”通常意味着“我们装了 Jenkins”
安装一个 CI/CD 工具并不等于 DevOps。这只是一个起点。但如果你的流水线每次运行要 45 分钟，时不时因无人理解的原因失败，而且每逢截止日期就被绕过——那你并没有 DevOps，你只有一堆昂贵的构建日志。
没人愿意谈论的文化问题
真正的 DevOps 要求开发和运维共同承担生产环境的责任。这意味着开发人员关心系统可用性，而运维人员关心部署速度。
在大多数公司，开发人员把代码“扔过墙”给运维，运维又把责任“扔回墙”给开发。要让这两个团队真正协作，需要的是组织层面的变革，而不仅仅是引入一个新工具。而组织变革——该怎么委婉地说呢——简直是一场彻头彻尾的噩梦。
“等以后再修复流水线吧”
DevOps 基础设施中的技术债是极其真实的。所有人都知道构建系统一团糟，所有人都清楚部署脚本全靠 Bash 脚本和侥幸心理勉强维持。但总有一个新功能要上线，于是流水线的技术债不断累积……
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
