DevOps平台这些功能没有做好，事故发生是迟早
想象这样一个场景：
某天K8s集群不知道什么原因挂了，然后DevOps工程师重新部署一套K8s，然后将应用部署到新的集群。当DevOps工程师通过容器平台自动化部署服务X到K8s时，服务X起不来。经查，原因是该node下没有服务X的v30版本Docker镜像，而且远程的制品仓库也没有。再深层次的原因是业务开发人员遵从了“降本增效”的建议，在制品仓库中设置了自动清理3个月自动清理的功能。v30版本在3个月前就已经被制品库删除。
这时，业务开发人员开始想办法从以前部署的代码版本（v30版本对应的commit）中重新构建一个Docker镜像。但是他们发现怎么构建都不成功。经查，原因是前端代码依赖的一个库Y，最近做了一个不兼容老版本的改动。再深层次原因是前端代码的依赖管理文件package.json中定义的依赖，在定义时使用了“自动升级”子版本的功能。如下：
{
"dependencies": {
"a": "^1.81.0",
"b": "^5.2.0",
}
}而业务开发人员也不知道依赖Y是在哪个版本做了不兼容的改动。所以业务人员需要花“大力气”才能构建出v30版本的镜像。
当然，作为SRE，应该还要想到另一个办法来补救：服务X运行过的节点上应该还保留着该镜像版本，可以将其导出，再手工重新上传到镜像仓库中。
以上场景为什么会发生？事情就是这么巧合！K8s挂了，部署应用又刚好找不到Docker镜像，Docker镜像又刚好被自动化清理了，某个应用又刚好无法进行镜像重建。
我们的DevOps平台应该如何设计以避免以上场景的发生呢？
个人总结下来，发生以上场景的根本原因有两个：
1. 制品缺少生命周期管理，或者生命周期管理存在缺陷；
2. 应用代码没有遵从可重复构建原则：使用同样的源代码，每次构建出来的结果应该是一致的。
制品生命周期管理
DevOps平台对制品的生命周期管理存在缺陷，是出现上文所提到的事故的重要原因之一。
为什么？我们不应该设置3个月自动清理吗？答案是确定的。
错误的是不应该清理运行环境中正在运行的制品版本。
这时，我们就应该清楚真正的问题出现在哪里了：制品库并不知道哪些制品是正在被使用的。
为什么会不知道呢？因为通常DevOps平台下的制品平台、发布平台、代码托管平台、测试平台是由不同的团队分别建设的，它们是一个个的信息孤岛。
那么，我们应该通过什么方式来解决制品不知道哪些制品正在被使用的呢？
简单地说就给制品打标签。各个平台在制品平台上给制品打标签，制品平台根据标签而采用不同的处理方式。
比如，当发布平台部署服务X v41版本后，就自动在制品平台上给服务X的v41版本打一个while_using:prod，如果是灰度发布，还可以打：while_using: prod_grey。同时将之前v40版本上的while_using标签移除。
而制品平台在执行3个月自动清理时，就自动跳过有标签以"while_using"开头的制品。
但是，这个机制依然可能存在问题。就是在v41版本被自动清理后，某天业务开发需要使用v40进行问题复现，怎么办？
这时就要求我们的团队要做到可重复构建了。
可重复构建
在持续集成领域，有一个重要原则叫做“可重复构建”(Repeatable Builds)。
它的意思是，使用同样的源代码，每次构建出来的结果应该是一致的，不应该有不同。
它也代表了团队的一种工程化能力。
前端代码是不可重复构建的典范。看看npm的官方案例，就知道了，大量使用自动升级依赖版本策略。
我们的DevOps平台该如何避免出现不可重复构建的现象呢？也就是通过平台来实现团队的可重复构建的能力。
可以在几个层面实现：
1. 在写代码的层面。当用户在IDE或者VSCODE中定义依赖时，相关插件，就提示不可重复构建；
2. pre-commit层面。当用户在本地commit时，就运行pre-commit脚本检测，检测到不可重复构建，就禁止用户提交代码；
3. 在CI流水线层面。出现不可重复构建，就直接停止构建。
在2，3实现不可重复构建功能，成本是相对较低的。
寻找新的职业机会和挑战
正如文章中提到的方法改进和案例分析结果所示，经过在DevOps/SRE领域5年的深耕，现在我正在积极寻找广州、深圳或者远程，新的职业机会和挑战。
如果贵公司或团队正好有相关领域的招聘需求，比如需要有强大技术能力和实践经验的专业人员来推进DevOps能力的发展，我非常期待能有机会为贵公司创造价值。这也正是我决定发表并公开分享这篇文章的初衷。
感兴趣的招聘人员可以直接与我联系交流相关招聘事宜。我微信号：zhaizhijun0 。或者邮箱：[email protected]
以下是我的其它代表作品：
SQL文件管理方式影响研发团队效能和系统稳定性，这里有解决方案了...
DevOps平台两种实现模式
我是如何进行日志降本的
我是如何将同事的代码改成DDD风格的
我正在开发的开源工程：https://github.com/Open-Platform-Engineering/Open-Platform-Engineering