本系列内容是我们在不同项目的维护过程中总结的关于DevOps/SRE方面的最佳实践，我们将致力于在项目上尽最大的努力来推行这些最佳实践。我们希望这些最佳实践能对项目的稳定运营提供帮助，也希望刚接触DevOps/SRE的新人能通过学习这些最佳实践来提升自己在这方面的水平。
因为DevOps/SRE涉及到的方方面面比较多，一次性完成的工作量太大，所以我们决定分阶段来完成，这一次发布的是“应用开发和部署”这个部分的内容，后续我们将逐步发布“云平台与网络”，“操作系统和服务”，“用户与权限”，“监控与可视化”，“数据与备份”，“敏感数据”，“故障与应急响应”这几部分的内容。
所谓“最佳实践”应该是最适合自己的实践，而不一定是最先进的，而且每一种实践本身也存在一定的局限性，所以我们在描述了对应实践的优点的同时，也把可能存在的缺点写了出来，就是希望大家在看到它的好处的时候，也能知道可能存在的风险在那里，理性地去评估到底是不是要采用相应的实践，所以这里总结的最佳实践请适度取用，不要为了“最佳”而实践。
我们深知自己在诸多方面存在一定的局限性，相关的内容可能存在一些不足，而且最佳实践本身会随着技术更新等因素不停地变化，我们将会把蓝皮书内容同步发布在Github上（ https://github.com/toc-lib/DevOps-SRE-best-practice） ，希望引发更广范围的传播和讨论。也请使用PR或Issue的方式来提出你的不同的观点和更好的建议，谢谢。
在传统的运维环境中，由于条件的限制无法快速的提供新的基础设施和环境，所以通常在业务的依赖环境如操作系统内核，服务，类库，运行时版本等需要变化时，我们会根据需要在现有的环境上做持续性变更。而且我们还可能会在机器上运行一些临时任务，做调试和排错等，很多的时候，这些操作对应的变化并不具有可追溯性，甚至不可以恢复到之前的状态。这样，刚开始统一配置的无差别的一批机器随着时间的推移慢慢的就会变得各自具有一些独有的特性。另外还有一些类型的服务，比如数据库，存储等，其业务本质就导致了集群中的每一台机器具有独特的属性。当我们在维护这些服务的时候，需要根据每台机器的特性来做不同的管理和配置，而且一旦机器出现故障的时候，也很难去创建出一样的机器来替代。因为这种情形和养宠物类似，比如我们会给宠物起一个名字，它也需要悉心照料，生病的时候要带去看病，所以我们称这种服务模式为宠物模式。
而在具有云原生能力的平台上，我们可以按需定制基础镜像，也能快速的从这个基础镜像中创建出运行环境，我们的变更就可以基于基础镜像来做更新和版本迭代。这样当某一台机器发生了故障，我们可以快速的复制出一台一模一样的机器来替代。如果需要做一些临行性的操作和变化，在任务结束之后，也可以销毁这台已经发生了变化的机器，使用一台新的机器来替代，使整个集群恢复到一个最初的收敛状态。这个场景和我们现实生活中的规模化牲口养殖类似，对应的我们称这种服务模式为牲口模式。
大家所熟知的无状态应用，就是牲口模式的最常用的一种实现方式。在业务的设计和实施过程中，我们建议把逻辑和数据分离，在逻辑运行环境不要兼顾数据存储工作，比如请求的session相关的数据，不要保存在本地，而是把它放在一个共享数据服务中，从而达到无状态的目的，这样就可以对逻辑运行环境进行牲口化的管理方式。
向前兼容指低版本的系统、程序或技术能优雅处理（例如：忽略其不理解的部分）高版本的系统、程序或技术。向前兼容技术的目标是让旧系统能够识别为新系统生成的数据，简单的说就是旧版本的系统可以接受新版本的数据，是旧版本对新版本的兼容。
我们建议在做业务升级时候，设计你的业务具有向前兼容的能力，以应对升级失败时某一功能模块或者依赖无法随之回滚的风险。比如说在有数据库字段变化的升级中，在正式对数据库做变动之前，基于旧的业务流程做代码层面更新，使其可以兼容数据库将要发生的改动并加以部署。在数据库升级完成之后，如果新的业务流程上线后不幸出现重大的问题等情况需要回滚时，回滚之后的代码仍然可以兼容数据库的变化，而不用对数据库也进行回滚，毕竟数据库的回滚成本非常高。
当生成容器镜像时，应当使用唯一性标识来给容器镜像打标签，唯一标识可以更好的标记当次生成的镜像，避免出现多个同名标签但不同的版本镜像被使用的情况。例如多次部署都使用了latest标签的镜像，可能因为拉取和缓存策略导致不同节点使用了不同版本的镜像，从而导致功能上的不一致，在这种情况下，并不能很方便地判断出某个节点部署的是哪一个版本。
唯一标识最好有一定的含义，不仅可以用来区分产物，还可以获取到本次构建的关键信息。比如git提交哈希等关联性比较强的标识。虽然时间戳也是一个唯一性比较强的标识，但是关联性相对较差，如果长度不足，也有一定的几率产生碰撞。可以考虑使用组合型标签，比如使用时间戳，build号，版本号等根据自己的需求来组合生成唯一标识，这样的标签本身就包含了很丰富的信息。
不建议单纯使用pipeline的build序号来作为镜像的标签，如果需要更换CI工具或者重建pipeline时，这个序号将会被重置而可能产生重复，除非在构建脚本中加入偏移量。而且不同的CI工具获取这个序号的方法也有所不同，对于迁移并不友好。虽然它的可追溯性看起来较好，但是单纯的Build序号和代码之间并没有直接的关联。
如果不是需要对外公开发布的镜像，并不建议对同一镜像打上多个不同标签。因为绝大部分的情况下，我们只会选用其中一个标签在所有的地方使用，多个标签的实际意义并不会很大。
如果制品库支持immutable特性，强烈建议开启这个功能，防止因为意外情况导致对已上传的镜像的覆盖。
#!/usr/bin/env bash
GIT_HASH=$(git rev-parse HEAD)
docker build --rm -t "myapp:${GIT_HASH}" . 应该在不同环境中使用相同的构建产物来部署，避免对不同的环境生成不同的构建产物，以确保环境的一致性，同时也保证部署在不同环境中的业务代码是测试和验证通过的。比如某次的构建产物，在测试环境部署后经由测试人员和相关的自动化测试工具完成相关的测试验证，如果没有问题才会继续部署到后续环境中，应继续使用该产物部署后面的环境，不建议重新构建新的产物来做后续环境的部署，也不建议覆盖之前的构建产物标识。因为在现有流行的语言和框架中，普遍存在大量的第三方依赖，即便是同一份源代码，由于其依赖以及构建环境的不同，会有一定几率出现由于外部依赖的更新导致构建产物存在差异，从而产生非预期的情况出现。
对于如前端这类纯静态资源的应用，由于不同的环境需要连接不同的后端服务地址，因此无法直接使用唯一的构建产物。可以考虑在业务启动阶段，用一些额外的启动脚本或命令配合传入环境变量或参数来修改配置文件，从而达到所有环境使用同一个构建产物的目的。
下面例子展示了在使用nginx的容器镜像里，通过在CMD指令里面先执行一段脚本来对配置进行修改，来达到在容器运行时根据传入的环境变量WEB_ENV的值来访问对应环境的后端服务的目的。
FROM nginx:1.21.3-alpine
COPY dist /app/
CMD sed -i -e "s/VUE_APP_ENV/${WEB_ENV}/g" /app/env-config.js \
&& nginx -g 'daemon off;'对于移动端app，也存在与前端应用类似的问题，需要开发人员做额外设计和开发，在app启动时判断需要进入什么样的运行模式。
一般情况下，脚本都会或多或少的使用到一些外部工具。而我们的脚本很有可能会运行在不同的环境中，不同环境中提供的工具也会有版本和用法的差异。如果需要在环境中维护某一工具的多个版本的，工具本身的版本管理，以及多个工具之间的依赖冲突和升级更新也会产生较高的管理和维护成本。
我们建议尽可能的减少所使用的工具对环境的依赖，尤其是系统不会默认安装的工具。另外在编写脚本的时候，也尽量避免使用只有某些版本特有的语法特性。这些情况都会导致脚本有可能出现一些不可预期的结果。我们建议使用容器化工具或者容器化环境管理工具如Batect来替代对应的需求。
CI/CD agent中只需要安装容器运行时即可，可以减小agent的体积。
容器化的工具因为对环境的依赖非常低，所以不论是工具升级还是降级都非常简单，同时也解耦了对agent特性的依赖，提高agent利用率。
最大化的保证环境一致性，使用容器化的工具消除了环境差异可能导致的非预期异常。
新人友好，新加入的团队成员可以快速的配置好可运行的环境，无需过多的考虑具体工具的安装，配置等。
解耦对CI/CD工具的依赖，虽然在实际项目中很少会有更换CI/CD工具的情况，但是如果需要迁移，我们也只需在新的工具环境中构建出容器运行环境即可，大大减少了切换工具工作量，提高迁移的速度。
因为没有预装构建所需要的各种软件，如果本地没有镜像缓存，在运行容器化的工具时都需要去容器仓库中获取对应的工具镜像，会有额外的带宽压力。
因为需要获取工具镜像，容器启动也比二进制的程序要慢，所以整个任务运行过程需要的时间会更长。
理论上来讲，容器化技术性能损耗很小，工具的性能和二进制程序的差别不会很大，但是在实际的使用中，我们发现因为容器引擎配置不当等原因会导致一些工具性能变差甚至无响应的情况出现。
在使用 terraform 时，不同版本之间的 terraform 并不兼容，那么如何保证所有人与 CI 都使用相同的 terraform 版本就是一个非常麻烦的事情。那么如果我们无论在 CI 还是本地都基于 docker 去运行 terraform 就可以解决这个问题。
#!/usr/bin/env bash
function terraform() {
docker run --rm -it \
-v $(pwd):/app -w /app \
hashicorp/terraform:1.1.4 -c "$@"
}
terraform init
terraform plan && terraform apply auto/ACTION是我们在项目实践中总结并希望可以广泛推广的一个经验总结，在和客户合作过程中，尤其是有很多团队的大型项目上，我们从这个模式中受益匪浅。auto/ACTION模式的核心是使用统一语义能表明脚本目的的ACTION来命名管理脚本，如应用的测试(test)，验证(validate)，打包(build)，发布(deploy)等相关任务，统一把这些管理脚本归放在auto目录下来维护。
因为类unix系统在运行的时候并不真正使用文件后缀来识别文件的类型，我们建议脚本名字不要加后缀。这个建议是基于管理脚本有可能会在多个地方被使用，而不同的开发和维护人员对于语言的偏好不同，如果在需要使用另外一种语言重写脚本的时候，使用这个脚本的地方就不需要做更新，消除了因为文件名变化可能导致的自动化任务的错误和中断。虽然没有后缀可能会带来一些不便，比如编辑器的语言类型识别错误等，但是相对于它带来的优点，还是非常值得的。
管理代码和业务代码放在同一代码库，使用版本控制，便于进行更新，回退。
每个脚本只做一件事，职责单一，同时便于理解和管理。
可以方便的知道所有可用的脚本。如：
$ ls -l auto/
auto/validate
auto/test
auto/build
auto/release
auto/deploy如果跨团队合作，或者团队成员有轮换的时候，可以更快速的掌握业务管理的上下文。
脚本满足既可在本地执行，又能在CI流水线上执行，便于验证。
脚本中的变量内容尽可能从环境变量中读取，避免向脚本中传入参数，方便运行。
专属于CI/CD平台的脚本不要放在auto根目录下，建议创建一个对应的子目录，例如 .buildkite, .github, .travis来做管理。
可根据团队的需求适当的扩展脚本的名字使之更容易理解，建议使用-而非_ 来分隔单词， 如auto/upload-image-to-ecr。
我们的应用中一般都会有一些脚本来做一些辅助性的工作。这些脚本通常会和业务代码放在同一个代码仓库，使用版本控制来进行管理。这些脚本大致分为两种：管理脚本和业务脚本。
管理脚本是用来做应用打包，部署等管理相关工作工作，这种类型的脚本是无需打包进业务运行所需的产出物中的；业务脚本是辅助业务运行，比如说初始化环境和配置，结束时的清理工作等，这些脚本需要打包到业务运行的产出物中。
我们建议除了一些有特殊要求的脚本外，不要把脚本放在根目录。并且把这两种不同类型的脚本存放在不同的目录中。
基础镜像是业务镜像的地基，其包含了我们业务和应用所必需的基础库、二进制文件和配置文件等。一个良好维护的基础镜像通常会根据需要做更新，这些更新通常包含安全补丁，新功能或对操作系统或框架的改进等，我们建议及时的更新容器的基础镜像来保障业务的安全性。除非有特定原因需要继续使用旧版本镜像，否则应及时跟进使用经过充分评估和测试的最新版本镜像。
在Dockerfile和compose等文件中，可以通过指定镜像中的标识和sha256值组合来指定基础镜像的版本。当镜像有了更新之后，及时沿用了如latest或大版本号这类通用性比较高的标签时，其sha256的值也会发生变化，通过更新这个组合可以更新使用最新版本的基础镜像。
可以使用 dfresh或者类似的工具来检查和更新基础镜像。
检查基础镜像是否有更新
$ dfresh check Dockerfile
Dockerfile:1: mysql
old sha256:5e515d337402579571c19a2a34a9b733d26788805429b5b3bdca12b76e7cc208
new sha256:fbe848f5738001063a89367adb747e7f283f9c87b20e74ccb6db3b13ec6e35cd更新基础镜像
$ dfresh update Dockerfile
Dockerfile:1: mysql
old sha256:5e515d337402579571c19a2a34a9b733d26788805429b5b3bdca12b76e7cc208
new sha256:fbe848f5738001063a89367adb747e7f283f9c87b20e74ccb6db3b13ec6e35cd回退方法 在需要回退基础镜像版本时，可从代码库的提交找到上一个可用版本的相应信息。
随着 Bug 修复、新功能的开发或者其他更新，我们应用的依赖包可能会过时。此时应用的依赖项越多，就越难跟上这些更新。过时的依赖包可能对安全构成威胁，并对性能产生负面影响。最新的软件包可防止漏洞，这意味着定期的依赖性检查和更新很重要。我们建议定期的对应用的依赖包做更新和安全检查，并升级到一个合适的版本。并且我们建议在应用的 pipeline 中加入这些检查任务，并在常规的开发过程中及时发现和升级。如果应用已经处于维护阶段，我们也建议定期执行这些检查并在需要的时候加以升级。
npm-check-updates: 是一种更高级的检查工具
npm-check-updates 与 Buildkite Pipeline 的集成
由于 buildkite 没有官方插件支持 dependency-check。所以对于buildkite 推荐两种方式：
## Dockerfile
FROM node:18.7.0
WORKDIR app
COPY ["package.json", "package-lock.json*", "./"]
RUN npm install -g npm-check-updates ## docker-compose
version: "2"
services:
node-version-check:
build: .
command: sh -c "ncu" ## auto/dependency-check.sh
#!/usr/bin/env bash
set -ex
docker-compose run --rm node-version-check ## buildkite script
steps
- label: 'node version dependency-check'
command: auto/dependency-check.sh
agents:
queue: 'xxxx'
- block: 'Please check node-version-check' jenkins pipeline 的集成：需要安装 dependency-check Plugin。步骤如下：
如果项目 code 托管在 Github，我们可以使用 Dependabot 和 Renovate 工具和 Github 集成来做依赖检查。这两个工具都会做定期扫描，创建依赖版本升级的 PR。
示例 dependabot.yml
version: 2 updates: # Enable version updates for npm - package-ecosystem: "npm" # Look forpackage.jsonandlockfiles in therootdirectory directory: "/" # Check the npm registry for updates every day (weekdays) schedule: interval: "daily"
在应用处于维护阶段，如果业务不再会增加新的功能，抑或因为某些原因无法做定期的应用依赖升级，我们也建议你定期的重新部署这个应用，以应对平台等更底层的变化带来的部署失败的风险。定期部署可以确保你的应用在新的平台环境中也可以正常的部署，如果在周期性的部署过程中发现应用无法在新的环境部署，你也会有一个缓冲期来制订应对策略，而不是在平台完成升级之后的某一天，应用发生了问题才发现已经无法部署。
定期部署应用是对部署工具和流程的有效验证，CI/CD Agent的一些升级有可能会导致我们在部署流程中使用工具发生兼容性问题，定期部署可以及早的发现这些问题。
定期部署应用也能够有效缩短我们的依赖获取未验证的窗口期。虽然我们的应用依赖可以锁定版本，也可以将依赖保存到私有仓库，但长时间没有运行相关部署流程，我们无法保证应用的依赖能够在需要的时候可正常获取且可用。
现在的应用的基础设施很多都基于各类云平台，服务提供商会定期的对自己的基础设施做升级和换代，定期部署应用可以让我们及早的获知基础设施变化带来的兼容性风险。
定期部署会对系统的稳定运行造成一些影响，变化本身就会带来一定的未知风险。
自动化的发布一般情况下都需要配有完善的回归测试流程来确保业务的可用性，会带来成本的增加
蓝皮书在编撰的过程中，有很多热心的小伙伴加入贡献了自己的力量和知识，在这里非常感谢他们。
常卉、冯炜、甘霖静、高语越、何水平、何蔚、毛灵、毛远鑫、钱文涛、乔伟星、石昆、孙瑞、许乐、杨伟健、赵浩、赵佩、周瑞丰、朱翔
