“SRE 需要非常了解某个新发布中包含的所有具体改动，以便在发布出现问题时可以更快地进行在线调试”——发布出现问题还是应该先回退版本，恢复服务吧，调试定位问题感觉应该业务开发来做，SRE通常也无能为力，如果是devops就没什么可推脱了

在配置管理中老师提到:‘’将配置管理与物理硬件环境彻底进行解耦，这也是数据中心操作系统（DCOS）在做的事情。本质上，你也把它理解成是将高频的配置变更支持做到应用逻辑中，只不过这由一个基础平台来实现罢了。‘’对于这一点不太理解，配置中心已经将服务的配置管理做的很好了，为啥还会有‘‘将配置管理与物理硬件环境彻底进行解耦’’的需求呢？这么做的优势是什么？

这篇比较简单，事务性介绍

七牛云项目发布是sre还是软件开发工程师自己发布呢

变更是故障之源，变更要做到可监控，可应急，可灰度。这个里面有很大的挑战，每个批次变更完之后，要确保对应的监控是精确的，实时的，有问题能及时发现，最好是自动检测的（系统性的比较简单，业务层的监控比较难），确认没问题后继续。

将配置管理与物理硬件环境彻底进行解耦，这也是数据中心操作系统（DCOS）在做的事情。本质上，你也把它理解成是将高频的配置变更支持做到应用逻辑中，只不过这由一个基础平台来实现罢了。

讲的是将配置打包到douker镜像中吗？

对配置管理中的数据配置操作系统不太熟悉，希望作者能在后面深入展开讲一下。

看了上一节和这一节内容对于“事务性工作”还是不太理解，老师可以详解一下吗？

收获满满😬