1. **SRE是否需要从项目开始就参与系统架构设计？如果只是在项目上线运行后才接触，遇到架构不合理的地方如何处理？**
SRE是不是要在项目开始的时候就参与到系统架构设计中，答案是肯定的。即使不是在项目开始时介入，也要在做技术方案和架构设计阶段就要参与进来，这个时候不一定参与架构本身的设计，但是要**给架构提出明确的稳定性要求**，比如哪些是核心部件？它们的稳定性要求应该是怎么样的，也就是SLO要达到多少？承诺的容量水平是多少？如果要做到高可用，是需要集群模式，还是主备模式？故障时的应急切换机制应该怎么设定？等等。这些要求决定了高可用的架构应该怎么设计。
如果是上线后才接触，还是先从SLO入手，建立SLO的稳定性衡量标准，然后看哪里不达标，就推进解决。SRE更多的要成为稳定性的监督者和推进者，而不是各种问题的救火队员。
1. **国内传统行业的SRE组织架构是什么样的，有必要设置SRE岗位吗？**
国内传统行业的SRE组织架构基本也是我在[09讲](https://time.geekbang.org/column/article/219387)中提到的组织架构。其实最开始我也很好奇传统行业会不会特别不一样，后来走访了一些企业后，我发现其实是殊途同归的，因为不论是传统行业还是互联网行业，大家**选择了相似的架构演进方向，就需要有配套的组织架构**，无论是实线的组织架构，还是虚线的协作模式，形式上大致相似。
至于是否有必要设置SRE岗位，我觉得真的不能把SRE只当成一个岗位来看，它实际传递的是一种稳定性的理念。遵循这种理念去做，这个岗位是不是叫SRE其实都已经不重要了，比如在阿里和蘑菇街，甚至是国外的Facebook，都叫做PE，在这些公司里PE在职责上跟SRE是一样的。
讲到这里呢，就多说一下PE（Production Engineer）这个角色，翻译成中文是生产系统工程师，最早是由雅虎定义出来的一个岗位，注意，这个岗位不是运维。这个角色的职责其实是由软件架构师承担的，也就是架构师负责设计架构，参与核心功能研发，对于产品了解得也最全面，所以系统上线后，维护的工作自然由他来承担，同时，随着线上问题的解决和处理，以及对线上问题的反思和总结，他又会不断完善架构设计和改造，是一个不断正循环的过程。
所以，你看，PE这个角色从一开始就是有非常高的要求的，并不是普通角色能承担的。阿里也是在收购了雅虎中国后，将PE的角色和先进机制引入到了阿里的技术体系中，国外很多公司也沿用了PE这样的角色，可以说从根本上，PE跟SRE的要求和作用是一样的。
1. **DevOps和SRE有什么区别？**
这个问题，是我在[第01讲](https://time.geekbang.org/column/article/212728)中留的作业题，我发现很多同学的回答已经非常深入了，我分享两位同学的理解。
来自于加硕同学：
>
DevOps核心是做全栈交付，SRE的核心是稳定性保障，关注业务所有活动，两者的共性是都使用软件工程解决问题。
>
DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频地迭代来满足市场需求，抢占市场（产品的迭代是关乎一整条交付链的事），高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，运维必须开启DevOps来实现全栈交付。因为不断的迭代交付（也就是俗称的变更）是触发故障、非稳定性的根源，而对于互联网产品来说，服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生。
来自无聊的上帝：
>
DevOps主要是以驱动价值交付为主，搭建企业内部的功效平台。SRE主要需要协调多团队合作来提高稳定性。
例如：
与开发和业务团队落实降级；
与开发和测试团队推动混沌工程落地；
与开发团队定制可用性衡量标准；
与开发、测试、DevOps、产品团队，共同解决代码质量和需求之间的平衡问题。
关于这三本书的阅读循序，建议你先读兼具普适性和参考性的第二本，然后再看第一本，最后读第三本。
好了，今天的答疑就到这里了。学习的过程中，如果你还有什么疑惑或者心得体会，欢迎继续写在留言区，和大家一起交流。