最近看到一个关于SRE与Dev如何协作的PPT，而且还是新鲜出炉的，这里分享给大家。对里面几页我觉得比较有启发性的内容做一下注解，或者说分享下我的理解。（分享部分在每张截图上面）
全部的PPT内容，可以关注我的公众号之后下载。
下面具体分享：
题目是SRE和开发如何一起工作，其实后面具体内容更多的是讲SRE在不同的项目或产品中的参与度应该怎样的。
接下来会有个Engagement Model的概念，参与度模式，或者叫投入模式，隐含着如何与开发配合协作，其实更准确理解应该是参与或投入的程度。
SRE与Dev组织架构的对应组织，这里有两个关键点，一个是funding，一个就是SRE和Dev必须是紧密合作共同达成稳定性的目标。
近几年，业内有点把SRE当成稳定性领域的银弹的趋势，好像有了SRE这样的组织、角色和人，稳定性就不是问题了，其实这里是有很大的理解偏差的。
再就是，通过这张图想表达背后隐含的一个关键点：
实践中，很多SRE的需求，根本上是需要Dev在产品中落地实现的，比如限流降级，甚至双活多活的架构，本质上是要产品能力和架构支持才可以。
所以，从这个角度，为什么说Dev对SRE有funding的义务，就不难理解了，最终是需要有HC支持的，这些都是成本，而且这个成本只能开发出。
这一页主要讲了SRE的投入阶段，其实就是整个服务生命周期，但是更重要的是在尽量靠前的阶段就投入，比如在design设计、implementation实施等阶段。
这里一个概念叫shift left，国内叫左移，现在听到比较多的是测试左移，其实就是靠前投入，而不是停在自己的环节被动接受。
这个在PPT中叫做throw it over the wall，其实现实中更多情况就是上游不管下游，自己搞完直接丢给下游。
当然，这里是不是可以在先期投入或者靠前参与，这个也不是SRE单方面介入就可以达成的，还是需要有机制和约束保障。
比如，没有SRE参与评审的架构或方案不允许通过，甚至上线后，SRE可以不参与保障。这一点在后面的Engagement环节有介绍。
三种参与和投入模式：
Baseline, Assisted Engagement, Full Support
其实选择哪种投入模式，是取决于项目和产品的运作方式，以及关键程度，下面会具体讲到。
Baseline模式，两页ppt一起分享。
主要针对短期临时性的项目，这类项目的特点就是短平快，有可能还有很多技术性的创新和尝试，并不一定完全遵守SRE的标准和规范，所以怎么部署、怎么运行、怎么玩，里面的弯弯绕是啥，只有开发清楚。
所以，这种就定个规则，开发自己玩，开发是Owner，负责系统的维护和稳定，SRE仅做必要的指导和咨询，或者有故障时，SRE介入应急。
所以这里Baseline Example来了一句，SRE Love.
Assisted Engagemet，这种模式就是针对highly critical project，也就是比较关键的项目了。
但是多用于在项目早期，这时候就需要SRE充分shift left，要主动地参与到项目中，形成联合项目。要严格地提出SRE的稳定性要求，比如SLO、关键接口的稳定性策略，甚至是共同设计跟稳定性相关的架构能力。
但是这个阶段，项目或产品的Owner职责仍然是开发，而不是SRE，不过上线后，SRE要开始参与Oncall和问题处理了。
其实再结合下面第三种full support模式，这里就感觉有点像我们国内传统行业的业务上线转维阶段的支撑模式，比如上线后的2-3周，开发为主现场处理问题，等系统稳定一个阶段之后，且各方面运行指标、工具支持和经验传递达到标准后，就开始由SRE主导。
Full Support模式，这里就是指关键业务系统，并且能够按照SRE的标准相对稳定运行的系统，英文的准确描述：
Best suited for mature and business critical systems
到这里，其实Speaker要强调的是，系统的维护职责，并不是SRE自己担了，其实这个阶段是需要开发更加重度投入的一个环节，所以他再次提到了headcount和funding.
因为这个阶段要解决的问题，就都是关键业务系统运行时，实实在在遇到的状况了，优先级和紧迫度会更高。
比如维护是不是繁琐，是不是需要SRE人工介入，运营复杂度以及SRE的认知难度是不是很高，导致问题处理效率低下，过程中使用的工具是不是足够高效，运营过程中发现的严重隐患问题应该怎么规划处理，故障要更加及时响应甚至参与Oncall等等。
还是回到我们前面表达的一个观点:
SRE遇到和发现的很多问题，根本上是要在产品层面落地解决才可以。
当然，我们不能仅仅从问题角度来驱动，根本上还是要从产品和系统稳定性的角度，通过这样的方式，通过这样的机制，让SRE和Dev联合起来，发挥更大的作用。
