我认为SRE的协作机制主要有2种，一种是对外，另一种是对内。对外的协作机制更多的是依托业务场景制订的、双方达成一致的协作规范规范，比如发布规范，配置管理规范，服务变更规范，容量规划规范等。对内的话，业务运维，工具开发，稳定性开发需有一套可正常流转的SOP，确保团队成员的协作规范和需求跟踪全流程，内外兼修，方可游刃有余。😄

学习经常搞的模拟考试就是“以赛带练”的思路吧

我目前就职的公司是电商类企业，以赛带练最符合的场景就是每年的大促了。我自己本身是性能测试，但通过几次生产全链路压测，发现我的工作内容和老师本节课程的中所提到的PE角色很类似。无论是前期准备阶段的链路梳理强弱依赖，数据预埋模型分析，还是整个压测节奏的把控，全局进度跟进和风险分析，压测复盘，以及大促当天的值班指挥，甚至是某部分预案的决策，都会参与其中。通过很多的压测和复盘，自己也模糊看到了性能测试工程师的职场发展方向，是向稳定性保障的角色靠拢，通过学习老师的课程，也买了《Google sre运维解密》书来看，发现PE或者说类似SRE的角色，是很适合的前进方向。

日常运维中发现有一个问题，特别是微服务化后，每次变更发布，开发如果有调整了接口的调用，而又没有及时更新相关资料的话，会直接影响运维的效率。在现在的敏捷开发中，代码迭代很快的，这样的话，实际中是怎么处理的呢

PE和业务开发分工并没这么明确

"以赛代练"个人觉得这种方式应当是源自体育：尤其是一些主要的比赛，我们会发现有各种各样的比赛；真正的比赛可能就是联赛，不同情况下还会有各种舍取。 电商平台中不少典型的可能会在双11之类的大型促销出现的策略，我们已经能够在平时的小型促销中去看到；合适的策略就是在生产环境的某些场景中可以利用平时业务量不大降低资源投入，非真正核心交易环节，平时降低资源投入测试一下其实风险并不大，只要随时能跟上就行。例如：快递有时我们会无法知道中间到哪儿了，不过发货方或收件方对于途中到哪儿其实并不关心，确定发出以及到了收获城市会有提醒就好。 记得之前听DevOps课程中就有提及过，"用重要而非绝对核心的业务去测试，循序渐进。"谢谢老师今天的分享，期待后续课程的分享。

赵老师，你好 技术中台 到 业务中台 之间的运维岗位被称为 应用运维，业务运维，技术运营；为会会有这三种不同称谓的岗位呢？他们应该是有不同侧重点的吧？能否详细介绍下差异