谷歌SRE理论读书札记: Release Engineering & Simplicity

Release Engineering

构建与分发软件（building and delivering softwares）
相关从业人员需要一个坚实(solid)的知识基础，包括：源代码管理（GIT SVN等）、编译器（）、创建配置语言（makefile dockerfile）、自动化构建工具（gitlab pipeline、jenkins）、包管理工具（）、安装器（installer）
技能需要囊括：开发、配置管理、测试整合（test intergration）、系统管理与客户服务

1，Changes to any aspect of release process should be intentional, rahter than accidental
任何变更都已是有计划的，而不是突发的

2，SRE工程师要关心这个release engineering中从源代码到部署的过程(source code to deployment)

具体的职责划分是这样的：在google，发布工程师是独立的job function（大概就是独立title的意思），和软件工程师（SWE）一起负责软件的开发而SRE则定义软件发布的每一步（如：代码以怎样的方式存储在仓库中，编译规则，该项目代码该如何测试、打包、部署）

Release engineers define best practices for using our tools in order to make sure projects are released using consistent and repeatable methodologies.
这里提到的tools，需要说明一下，google对自己的定义是一家数据驱动的公司（data-driven company），所有有大量的工具可以汇报主机上各种metrics，比如某项目代码一次部署到生产环境花费了多久，同时可以看到相关配置文件的简要报告（如这次变更的features是什么，在书籍前面，一直强调了配置文件的重要性）
那么发布工程师需要利用好这些工具，让发布的实践经验，是持续并且可以被复用的。
这里也提一点自己的看法：搭建一个数据平台，并不是结束，而如何利用数据平台上的数据才是真正的关键。真正的工程师，需要把时间（每次practice）得到的metrics，statistic转化成可以复用的工程方法论

同时为何解释了发布工程师（Release）和SRE要一起协同工作，因为SRE需要对服务的可用性负责，所以需要确保发布是能满足需求的（就是说SRE必须知道你这次发布到底是为了做什么，即便SRE本身并不直接负责软件的开发），同时发布还不能中断整体的服务（到谷歌这个体量，所有服务都必须是724可用的）

Release Engineering 哲学

Self-Service Model

这里有一句话非常重要：in order to work at scale, teams must be self-sufficient
虽然前面说到如发布工程师和SRE之间有协同工作的部分，但为了达到scale这个目的，每个小组必须能完全完成自己的process
当我读到这里的时候，才意识到，所谓scalable或 scalability，不仅仅是软件层面的概念，说我这个系统是可扩展的，而是要延申到具体的职责上。
如果多个组的workflow几乎全部是交错的，那一起合作的系统也很难称得上是完全可扩展的。

High Velocity

谷歌已经习惯了“小步快跑”式的迭代（比如chrome的版本就是一个例子），每次变更内容不会很多（但不会是“仅仅修改某些bug”这样的更新），但是会增加更新的频率。这样对于test与troubleshooting很有帮助。

Hermetic Builds

构建不会受机器环境的影响，并且还能确保，当我需要build某个老版本来debug时，所获得的build结果和之前是完全一致的（这其实是一个难点）

Enforcement of Policies and Procedures

有若干层安全、权限管控来决定在发布项目时大家能进行的操作
所有对代码的变更都需要review，并且已整合到开发者的workflow中
发布系统会生成所有改变相关的报告

持续构建与部署

谷歌目前使用的自动发布系统名为Rapid

building

branching

testing

packaging

rapid

deployment

配置管理

Simplicity

软件系统天生是动态、不稳定的，处于完美稳定的软件系统仅存在于虚空之中。如果你完全不改代码，不添加功能，那么肯定不会引入bug（换言之，只要迭代软件系统就有出问题的可能）
所以对SRE工作的最好总结是，我们每天所作的就是保证系统敏捷性和稳定性的平衡（keep agility and stability in balance）