恍惚之间，想到 2025 年就要结束了。想起 2024 年没有写，就一起写了。
2023 年和开发商打了一年官司，人整个都不好了。2024 年又开始了坐班，从事基础设施即代码（IaC）的工作。2025 年中，开始远程办公。
算了一下，我从 2018 年开始接触 Pipeline as Code，到现在的 Infra as Code，已经有 6 年了。也从一个纯 Java 后端开发，转成了 DevOps / SRE。
接触 Pipeline as Code，也是因为看到团队的工程能力太差，就想着去改进，于是买了一本《SRE：Google 运维解密》来学习。就这样，我开始结合《持续交付》和《SRE》，基于 Jenkins 2.x + Ansible 来实践 Pipeline，自动化了团队中部分应用的部署。
我当时还只是一个 Java 后端开发，没有人要求我这么做，甚至没有人提过"自动化"。大家都忙着向上管理，也就没有人看到我的价值。我还是太单纯了，只想着技术。
后面机缘巧合，我跳到了另一个部门，从零开始，将原来手工配置、部署的流程自动化了，使用的是 Jenkins 2.x + Ansible + Docker Compose。当时部门还小，将近 10 个人，只有我 1 个运维。
平时，大家都以为运维只是运维。但是我是 Java 开发出身的，所以 Java 后端有什么设计或者架构不利于自动化的地方，我都会意识到，并帮他们一起改。这段经验也让我意识到，招运维时，一定要要求具备一定的后端开发能力，否则是没有什么发展潜力的。
在升级到架构 1.0 之后，我意识到：
-
- 基于 VM 的方式不利于将来发展，流量一旦上来，一定会出问题；
-
- YAML 不适合大规模的配置管理；
-
- 我无法简单地知道一次修改所带来的影响面。
于是我决定升级到架构 2.0：K8s + Istio。通常这应该是由应用架构师来完成的事情，但当时我也只是一个普通的运维工程师，并没有人要求我这样做。我还是太单纯了，只想着技术。
有人会问，你为什么没有直接上 K8s？因为我当时对 K8s 和业务都不太熟，步子一下子迈得太大，带来的复杂性，团队和我都承受不了。先把当前的琐事自动化，让变化可控，再进行演化。
其实，随便到网上找一找架构最佳实践就一大堆，但能知道什么时机该用这些实践的，才是真本事。
架构 2.0 并不只是简单地更换技术，连配置方式也发生了变化。我采用了一种行业里几乎没有人实践过的方式：Jsonnet + Bazel + 单仓。现在看来，是无比明智的选择。
也就是说，部门里所有系统的所有配置，都放在一个单仓库里，使用 Jsonnet 来描述，并通过 Bazel 进行构建。
架构 2.0 支撑着系统的运行至今。听说到现在，总共有 50 万+ 条配置。团队在我离开之后，运维人员也还只有两个人。
现在想想，支撑如此规模的系统，其实只需要两个运维（甚至一个人也可以，但需要 backup）。当时我还是太单纯了，只想着技术，应该向上争取更多的人。
自动化一家公司的系统，通常有两种方式：
-
• GUI 方式：通过控制台或平台界面进行配置和部署
-
• IaC 方式：通过 Terraform、CloudFormation 等代码来实现
我所在的基建团队（可以不太准确地理解为运维团队），每当有新开发接触 IaC 时，都会吐槽 IaC 难以理解，或者用户体验不好： 我部署一个版本到环境里，还要去代码仓库改代码？基建团队是傻的吗？不懂得开发一个平台？
有这样的吐槽是正常的。我已经见怪不怪了，也懒得去理这些外行的声音。但是当这些声音影响你在公司里的形象时，或者你的领导和这些外行一样想，你就要小心了。不要太单纯，不要只想着技术。
很多开发人员想不到的是：当基建团队接手一台正在飞行的飞机时，它往往已经破败不堪，甚至左右机翼大小不一样。基建团队的职责，是在不让飞机停下来的前提下，还要保证乘客有尽可能好的飞行体验。
说白了，你不可能让系统停下来，好让你创建一个自动化部署平台，再基于这个平台进行部署。
那么请问，当你面对这样一台"飞机"时，你会怎么办？
其实很简单：先让飞机不掉下来，至少不要那么容易掉。
飞机一旦掉下来，一切都白搭。我把这个阶段称为"飞机接手"阶段。
在这个阶段，你可能会遇到的问题包括：
-
- 基建人员不足；
-
- 对接手的飞机结构和飞行路线不熟；
-
- 正在飞行的飞机还时不时出点差错。
这些年的经验总结下来是：
-
- 先了解当前系统的架构和业务，边了解，边记录不符合持续交付原则的地方、容易出问题的点，以及真正的核心在哪里；
-
- 使用 IaC 描述现有架构，并部署一套新系统；
-
- 将流量切换到新系统，同时做好回滚方案；
-
- 废弃旧系统。
为什么一定要是 IaC？因为它可以：
-
- 快速实现版本化和自动化一切，而不需要等"平台"建好；
-
- 兼容当前的一切不一致，比如生产和测试环境不一致，也不需要为了新平台去大改旧系统的架构。
过了"飞机接手"阶段，才开始考虑建平台。当然，这也要看业务的发展情况，每家公司都不相同。
说到底，以前我还是太单纯了，太关注技术。技术问题反而都是容易的问题。真正难的是：
-
- 让所有人看到基建团队的工作；
-
- 让所有人理解基建团队工作的价值、重要程度以及难度在哪里------基建工作中，一个字母的错误，就可能让一架飞机坠毁；
-
- 对于不理解的团队，适当调低他们工作诉求的优先级；
-
- 不要让非技术人员或不相关的人来评价你的工作；
-
- 保持好的心态，工作就是工作；
-
- 有些时候，宁愿慢一点，也不要一味求快。
以上这些，对公司来说都是成本，但对基建团队而言，却是必不可少的功课。
就写这么多吧。希望对你有帮助。
最后，在冬至，祝你找到自己的意义。