最近在看 archlinux infrastructure 仓库中的代码，这个仓库是 archlinux 运维开发团队的运维仓库, 他们以代码化的方式实现了可持续的运维。

可持续的运维意味着什么：

  • 随着时间的流逝和运维人员更换，运维操作不会丢失，服务器不会成为黑盒；
  • 无论服务器是 1 台还是 1 万台，都能保证长期的可操作、可维护、强一致性。这里的例子有
    • k8s 集群持续升级到安全版本，无论是一个还是多个集群，中间件的升级方式基本一致（服务的持续更新）；
    • 新人可通过阅读运维代码，实现对现有服务、架构的了解，具备运维代码技能基础后（面试通过后），即具备持续运维的能力（人力资源的持续更新）；

这里的代码化，主要是通过 ansible，以 yaml 的方式，将服务器的状态（跑什么服务，需要什么配置等）保存到 git 版本控制系统内, 并通过 gitlab 进行协作和持续迭代。

代码化运维的优势：

第一、版本化优势。因为所有的运维操作都通过 ansible 记录到了 gitlab 仓库，任何公司内部员工都可以知道服务器上发生的所有改动。比如：

  • 可通过 git 查到某台服务器上的某个服务是怎么部署的、何时部署的、谁做的部署或者改动
  • 可直接在仓库内确认服务器是否需要更新配置而无须登陆任何生产服务器（手动登录服务器是危险的）
  • 可直接在一个仓库内查到所有架构信息。避免架构黑盒对梳理、优化运维架构会有非常大的作用

第二、服务器状态版本化。以 nginx 集群配置为例，nginx 集群状态以相应的 git commit 保存在 gitlab 内，如果 nginx 的改动导致了故障，可以通过 git checkout <commit_id> 快速的回退 nginx 的运维代码，重新执行 ansible 即可恢复服务。有的人会问，我在改动 nginx 配置的时候:

cp nginx.conf nginx.conf.bak

故障时:

cp -f nginx.conf.bak nginx.conf && nginx -s reload

就好了。为何还需要代码化？一方面，试设想如果你的集群有 30 台，每台服务器上都要执行上述操作的时候，会出现大量的人为操作，出错的可能性变大了。其次，在持续运维的过程中，会涉及到多次改动，如果 30 台服务器，都要改 30 次，就会在服务器上存在 30 个不同的 nginx.conf.bak，这对排查问题是不利的（在版本化的运维内，可以通过 git diff <commit1> <commit2> nginx.conf 快速定位配置改动的差异）。

第三、质量提升。质量下滑在大规模集群运维中是恶梦，1 个错误如果应用到所有服务器上（比如 100 台服务器），就会产生 100 个错误，因此质量提升对可持续运维非常重要。代码化如何提高质量呢？git 和 gitlab 提供了多人协作的能力，所有的运维代码会在 gitlab 上进行代码评审（code review），人人都可以提交运维代码，但只有经过评审的、可靠的运维代码才会被合并到主分支，并最终由具备相应权限和经验的人应用到生产服务器上。运维质量在一次次的评审、迭代中逐渐提高。

第四、高效率。当我们通过协作具备高质量的运维代码后，无论是管理 1 台服务器，还是管理 100 台服务器，操作成本几乎一致，执行对应的运维代码，ansible 会将改动应用到所有服务器上（无论多少台），我们只需确保 1 台服务器上的运维操作是可靠的，后面的 99 台也将都是可靠的。

这里的例子有：

  • 确保一套 k8s 集群能通过运维代码稳定升级后，其他机房的 k8s 集群也能稳定升级
  • 确保某个生产服务能通过运维代码稳定升级后，其他机房的生产服务也能稳定升级
  • 确保一个 Linux 分发版本能通过运维代码稳定升级后，其他机房的该 Linux 分发版本也能稳定升级

传统的手动运维存在简单操作手动重复执行的情况，大量重复性操作易导致人为失误，降低运维人员积极性。没人敢管、没人想管（三不管问题），就是积极性下降和责任制导致的，最终在人的层面导致了运维的不可持续。人会疲惫但代码不会。还是以 nginx 配置更新为例，如果有 100 台 nginx 服务器需要更新配置，传统的作法是修改一台服务器，测试没问题后通过 scp、rsync 同步到另外 99 台服务器，并在每台上面执行 nginx -t && nginx -s reload，这里面的人为操作很多。代码化的好处是我们只需要提交 nginx 配置的改动，推送到 gitlab 评审，通过评审后由具备权限的人执行运维代码即可，ansible 会完成 100 台 nginx 服务器的配置更新、可靠性检查，人为操作大大减少。

第五、安全性提高。因为有可靠的评审流程和高效的运维效率，一方面，运维会逐渐变得稳定可靠，人为失误会大大减少。其次，高效率会让运维人员的积极性恢复、提高（因为简单的操作，只需做 1 遍，而不是做 100 遍）安全修复也会变得更加及时和可靠。

第六、自动化。通过 gitlab、gitlab-runner，可以解决一些简单但是操作成本极高的问题，比如：

  • 自动更新所有服务器的账号密码
  • 自动检查所有服务器的安全补丁安装情况
  • 自动检查所有服务器最近登录情况

运维的可持续性（在时间层面、在人员流动的职场中），其实要解决的是一系列的问题，需要避免运维黑盒、避免大规模运维中的低效、避免运维人员积极性下降等。

理想与现实终有差距。不忘记理想，但活在现实里。