本文次要是讲如何建设无效的环境、程序、配置、SQL变更和治理平台。

几天前和一个敌人聊到环境、程序的配置变更，SQL变更和整个上线流程。之前咱们在这块也做了很多，有做的好的也有做的个别的，借机都总结下来，心愿对你有用。

通常状况下，咱们最关注的也是最重要的局部是利用的变更，就是程序的部署上线公布这块，因为这部分最高频，每天上线很屡次的状况都能够产生，所以咱们在平台建设的时候也是优先做好这部分，然而对于环境、程序配置和SQL变更局部，通常状况下会优先级低一些，不是这些不重要，只是临时通过手工操作或者人力顶一下这部分的工作，最终这些问题是要通过平台自动化来解决的。

底层物理环境配置

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

当初随着计算资源价格下降、云计算疾速遍及，尤其是 k8s 的呈现，大大降低了放弃「开发-测试-预发-生产」环境一致性的老本，同时操作起来简便易行。所以工作中，咱们要「尽量」放弃这些底层基础设施的对立，这是做好下层很多工作的根底。

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

    1. 应用代码治理基础设施,大大提高效率。
    1. 缩小手工操作谬误。
    1. 代码能够版本控制,具备残缺的跟踪性。
    1. 自动化能够保障环境一致性。
    1. 代码即文档,有利于团队合作。

之前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 都应该整合到利用上线流程中去，而不是独自有一个平台来承载。这样数据买通、角色和权限买通、流程买通，对立的体验和流程，解决了各种零碎间跳转带来的问题，进步了产研运各方的整体效力和工作体感，尤其是对于中小公司来说。