本系列内容是我们在不同项目的维护过程中总结的关于DevOps/SRE方面的最佳实践，我们将致力于在项目上尽最大的努力来推行这些最佳实践。我们希望这些最佳实践能对项目的稳定运营提供帮助，也希望刚接触DevOps/SRE的新人能通过学习这些最佳实践来提升自己在这方面的水平。
因为DevOps/SRE涉及到的方方面面比较多，一次性完成的工作量太大，所以我们决定分阶段来完成，这一次发布的是“应用开发和部署”这个部分的内容，后续我们将逐步发布“云平台与网络”，“操作系统和服务”，“用户与权限”，“监控与可视化”，“数据与备份”，“敏感数据”，“故障与应急响应”这几部分的内容。
所谓“最佳实践”应该是最适合自己的实践，而不一定是最先进的，而且每一种实践本身也存在一定的局限性，所以我们在描述了对应实践的优点的同时，也把可能存在的缺点写了出来，就是希望大家在看到它的好处的时候，也能知道可能存在的风险在那里，理性地去评估到底是不是要采用相应的实践，所以这里总结的最佳实践请适度取用，不要为了“最佳”而实践。
我们深知自己在诸多方面存在一定的局限性，相关的内容可能存在一些不足，而且最佳实践本身会随着技术更新等因素不停地变化，我们将会把蓝皮书内容同步发布在Github上（https://github.com/toc-lib/DevOps-SRE-best-practice） ，希望引发更广范围的传播和讨论。也请使用PR或Issue的方式来提出你的不同的观点和更好的建议，谢谢。
在传统的运维环境中，由于条件的限制无法快速的提供新的基础设施和环境，所以通常在业务的依赖环境如操作系统内核，服务，类库，运行时版本等需要变化时，我们会根据需要在现有的环境上做持续性变更。而且我们还可能会在机器上运行一些临时任务，做调试和排错等，很多的时候，这些操作对应的变化并不具有可追溯性，甚至不可以恢复到之前的状态。这样，刚开始统一配置的无差别的一批机器随着时间的推移慢慢的就会变得各自具有一些独有的特性。另外还有一些类型的服务，比如数据库，存储等，其业务本质就导致了集群中的每一台机器具有独特的属性。当我们在维护这些服务的时候，需要根据每台机器的特性来做不同的管理和配置，而且一旦机器出现故障的时候，也很难去创建出一样的机器来替代。因为这种情形和养宠物类似，比如我们会给宠物起一个名字，它也需要悉心照料，生病的时候要带去看病，所以我们称这种服务模式为宠物模式。
而在具有云原生能力的平台上，我们可以按需定制基础镜像，也能快速的从这个基础镜像中创建出运行环境，我们的变更就可以基于基础镜像来做更新和版本迭代。这样当某一台机器发生了故障，我们可以快速的复制出一台一模一样的机器来替代。如果需要做一些临行性的操作和变化，在任务结束之后，也可以销毁这台已经发生了变化的机器，使用一台新的机器来替代，使整个集群恢复到一个最初的收敛状态。这个场景和我们现实生活中的规模化牲口养殖类似，对应的我们称这种服务模式为牲口模式。
大家所熟知的无状态应用，就是牲口模式的最常用的一种实现方式。在业务的设计和实施过程中，我们建议把逻辑和数据分离，在逻辑运行环境不要兼顾数据存储工作，比如请求的session相关的数据，不要保存在本地，而是把它放在一个共享数据服务中，从而达到无状态的目的，这样就可以对逻辑运行环境进行牲口化的管理方式。
向前兼容指低版本的系统、程序或技术能优雅处理（例如：忽略其不理解的部分）高版本的系统、程序或技术。向前兼容技术的目标是让旧系统能够识别为新系统生成的数据，简单的说就是旧版本的系统可以接受新版本的数据，是旧版本对新版本的兼容。
我们建议在做业务升级时候，设计你的业务具有向前兼容的能力，以应对升级失败时某一功能模块或者依赖无法随之回滚的风险。比如说在有数据库字段变化的升级中，在正式对数据库做变动之前，基于旧的业务流程做代码层面更新，使其可以兼容数据库将要发生的改动并加以部署。在数据库升级完成之后，如果新的业务流程上线后不幸出现重大的问题等情况需要回滚时，回滚之后的代码仍然可以兼容数据库的变化，而不用对数据库也进行回滚，毕竟数据库的回滚成本非常高。