可持续运维
最近在看 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....