DevOps ｜研发效能之环境、程序、配置、SQL变更管理

devops,研发,效能,环境,程序,配置,sql,变更,管理 · 浏览次数 : 274

小编点评

**环境配置** * 使用代码管理基础设施，例如 IaC，自动化基础设施配置和管理。 * 将基础环境的固化到 Dockerfile 中。 * 研发效能平台引用基础镜像，实现编译和运行时受控。 **SQL 变更和管理** * 优化 SQL 语句，确保正确性、执行效率和安全性。 * 使用配置中心，将项目中所有配置集中管理。 * 在上线应用时伴随 SQL 变更，确保数据一致性。 **其他** * 考虑将运行时配置也纳入代码仓库，方便修改和维护。 * 使用配置中心，进行配置更新和同步。 * 整合数据库变更管理流程，确保数据一致性。 * 优化应用程序配置，以降低配置管理的复杂性。

正文

本文主要是讲如何建立有效的环境、程序、配置、SQL变更和管理平台。

几天前和一个朋友聊到环境、程序的配置变更，SQL变更和整个上线流程。之前我们在这块也做了很多，有做的好的也有做的一般的，借机都总结下来，希望对你有用。

通常情况下，我们最关注的也是最重要的部分是应用的变更，就是程序的部署上线发布这块，因为这部分最高频，每天上线很多次的情况都可以发生，所以我们在平台建设的时候也是优先做好这部分，但是对于环境、程序配置和SQL变更部分，通常情况下会优先级低一些，不是这些不重要，只是暂时通过手工操作或者人力顶一下这部分的任务，最终这些问题是要通过平台自动化来解决的。

底层物理环境配置

很久以前，计算资源成本高昂，导致机器匮乏，很难做到「开发-测试-预发-生产」物理环境配置的统一。线上用高配的物理机，线下用低配的过保机器，甚至用虚拟机，这都是很常见的做法。不同环境之间物理资源的不同加大了环境配置的管理难度。比如一个Java 程序需要 4G 的内存，这在线上没问题，但是线下的虚拟机可能 1G 的内存都没有。同样的配置在两个环境中需要小心维护否则程序就崩了，所以经常有很多文档记录这些「魔法」骚操作，然后在操作环境时拿出来翻一翻。

现在随着计算资源价格下降、云计算快速普及，尤其是 k8s 的出现，大大降低了保持「开发-测试-预发-生产」环境一致性的成本，同时操作起来简便易行。所以工作中，我们要「尽量」保持这些底层基础设施的统一，这是做好上层很多工作的基础。

基础设施即代码(Infrastructure as Code, IaC)的出现把环境配置的问题变得更简单。IaC解决的最大问题是基础设施配置和管理的自动化。之前通过手工操作来配置和管理的服务器、网络等基础设施通过 IaC 把基础设施配置和管理自动化，大幅提升效率和可靠性。

1. 使用代码管理基础设施,大大提高效率。
2. 减少手工操作错误。
3. 代码可以版本控制,具备完整的跟踪性。
4. 自动化可以保证环境一致性。
5. 代码即文档,有利于团队协作。

之前Google是把 IaC 放到代码仓库中，SRE管共性的配置，研发小伙伴来管理每个服务独特的配置部分，这也是一种方法。但是鉴于国情，我还是觉得让 SRE 或者 Ops 来管更合适，这样也有利于划清职责边界。

我建议 1）梳理全公司的编译和运行时环境需求 2）把基础环境的固化到有版本控制的 Dockerfile中，3）然后研发效能平台引用这些基础镜像，最终达到编译和运行时受控。

编译时配置

在编译源代码前,我们通常会有一些编译时配置，要么写到配置文件中，要么通过传参的方式传进去，然后在编译时打到二进制程序里面。通常情况下编译时配置信息放到编译脚本中固化下来是个不错的最佳实践。比如我们经常遇到的 build.xml, pom.xml, build.gradle等。通常这些构建脚本是研发小伙伴会开发调试时会用到，研发管理平台通常也会用到这些构建脚本，但是有时也会传入一些其它的参数。此时研发效能管理平台就会自己记录一份当时运行的命令，以便后面排查之需，比如保障制品的可重现。

所以在这里，我们可以看到研发小伙伴会把大部分编译时配置放到构建脚本中，存在于代码仓库(repo)中和源代码一起进行版本管理；研发效能平台部署环境时，会从平台上传入参数进行「干净的」编译，此时平台会记录一份编译时的配置。这两处的编译时配置信息都很重要。

运行时配置

一旦我们的程序或者软件部署完成，通常在启动时还需要读取配置文件或者读取数据库加载一些动态的配置信息，这就是运行时配置。运行时配置是可以动态调整的，无需重新打包和部署。

有的公司会把运行时配置也放到代码仓库中一起管理，尤其当配置信息比较少，修改比较容易时。但是一旦部署上去想要修改，就要把运行的实例(机器/容器)中的运行时配置都需要修改一遍，虽然有ansible，saltstack，puppet，但操作也会麻烦、容易出错且会导致安全问题。通常情况下研发小伙伴是没有手动修改生产环境配置的权限。如果想一次更改多个服务多个实例的配置，这就会是个大问题。随着服务的增多，配置的复杂，我们就会遇到如下的问题：

配置文件分散：每个服务在自己仓库下维护一套配置，无法统一配置和管理
多环境配置文件难维护：通常「开发-测试-预发-生产」每个环境都有自己的一套环境配置，有的配置项需要统一，有的配置项需要区分。
配置文件无法实时更新：配置文件修改后，必须重启服务才能生效配置，无法实时更新，对用户不友好。

为了解决以上问题，通常公司会引入配置中心来解决，比如apollo，disconf，nacos，SpringCloud Config等。这些都是市面上比较常见的配置中心选型。

首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。
当各个服务需要获取配置时，就来配置中心接口拉取自己的配置。
当配置中心中的各种参数有更新的时候，也能通知到各个服务实时同步最新的信息，使之动态更新

数据库配置，数据库变更管理

我们在上线应用的时候，通常也伴随SQL变更，主要的需求

SQL上线审批流：做某些关键变更要有人审批，比如上级、DBA等
SQL语句检查、审核和执行等：SQL语句要正确，执行没有问题
角色和权限：只能查询和变更自己有权限的 DB

可以试试Yearning/Themis/inceptior这三个工具，我们也是在开源工具的基础上进行了二次开发，主要是打通了用户、权限和应用部分。之前申请个DB 还需要在数百个DB中去寻找，现在只要登录就会列出自己有权限的 DB。但这部分还没有完全整合到我们的流水线/发布单/上线单体系中去，这是一个需要继续发力的点。

统一变更流程和平台

「生产->测试」环境之间的配置变更，通常由QA小伙伴来负责，比如把生产环境的表结构应用到测试环境。

「开发->测试->预发->生产」这样的配置晋级流程通常由研发的小伙伴来完成。具体的情况说明，可以参考我《研发效能之环境管理》的这篇文章。做好变更风险管控就好。

我个人觉得SQL 上线，配置文件上线，前端 CDN 都应该整合到应用上线流程中去，而不是单独有一个平台来承载。这样数据打通、角色和权限打通、流程打通，统一的体验和流程，解决了各种系统间跳转带来的问题，提高了产研运各方的整体效能和工作体感，尤其是对于中小公司来说。