Q1：SRE和全栈有什么区别？
SRE本质上说是由运维侧发起的运维与研发一体化的岗位，它有一些接近于全栈的要求，但并没有说任何技能都需要掌握，比如说，SRE提到了运维的能力、研发的能力，而测试能力并没有特别强调。SRE关注的是整个系统的可靠性，是从结果导向的分析出需要什么样的能力，这与全栈工程师可能是两个维度的概念，就是说你是不是全栈不要紧，但要满足系统可靠运行，高可靠性就好。

Q2：重点知识有推荐的线上学习论坛或者app吗？
我们有SRE书友会微信群，以及定期通过腾讯课堂定期线上分享，包括专家讲师专业技能的分享。知识沉淀是通过“知识星球”app，记录大家的问题以及讨论的话题。

Q3：SRE是不是更强调可靠性，而全栈更强调技术的全面性？
个人比较赞同这个说法，SRE是从系统的可靠性和运维研发一体化来实践的，并不要求非常全面的能力，比如运维能力、研发能力、测试能力等，掌握其中两个方向我认为就可以胜任SRE这个岗位了。

Q4：SRE如果参加CI/CD的流程，它的角色如何定义？工作职责有哪些？
CI/CD是DevOps里面提到的持续集成/持续交付的概念。个人理解，SRE会参与发布、参与集成，但是SRE更强调是作为运维研发的技术专家，尽量降低重复性工作。比如说CI/CD是不是全部自动化了，如果里面需要人员参与的特别是重复性的操作，SRE更希望是更加自动化，减少重复性的工作。

Q5：操作系统要了解到什么样的深度？
个人认为要了解到professional的程度还是有必要的，professional是指能够独当一面的来构建linux操作系统，满足栈点可靠性的要求，能够完成故障诊断、故障排查解决以及知识库沉淀的程度。具体点可能要满足一线工程师+的能力，还要看自己所属的方向，是偏研发还是偏云计算或者其他方向，每个方向具体要求都不太一样，偏云计算方向可能要求更高一点，偏运维研发可能要求稍微低一点。

Q6：Band5~Band8有哪些推荐的网站或者书籍可以提前学习？
Band5~Band8其实基本上涵盖了一个青年从他入行2~3年到入行10年左右，甚至15年一个成长经历。网站推荐，自己个人还是推荐类似Google亚马逊这些巨头的网站，我们的专家讲师也看过国内巨头BAT的网站，普遍认为国外的互联网公司还是比国内的领先5~10年左右，不管从概念、技术还是管理上来说。书籍的话个人推荐孙宇聪老师得这本书《Google运维解密》，还有就是这一系列动物封面得书籍，希望结合自己的方向去精读一本书而不是泛读。

Q7：目前很多企业还没有SRE岗位，那么SRE工种会不会快速在非互联网行业普及？
互联网行业目前已经有SRE岗位了，而且相关金融科技的企业包括银行，对SRE岗位也比较感兴趣。目前互联网以及金融科技行业在中国高速经济发展的背景下还是引领者，大概有半年到1年的领先性。SRE岗位如果已经是社会普遍的岗位或者岗位人员已经饱和的话，那么SRE岗位高薪就不会存在了。

Q8：Googel模式是让运维和开发相互配合实现DevOps，现在很多公司让开发去做运维，哪种模式更加可取？
SRE和DevOps是有点差异的。DevOps是开发拥抱运维，开发人员需要学习运维的相关知识能够承担运维的工作。Googel的SRE是运维侧发起的，运维去拥抱开发，运维的人员需要具备一定的开发能力，并且Googel空降了一批开发人员去做SRE，是比较激进的变革。Googel在做了5~10年的时间后比较成功，现在将他们的SRE实践对外输出。
个人认为这两种方法是殊途同归，即运维开发一体化。采取哪种模式是从运维侧发起还是开发侧发起，更多要看企业的实际情况，包括企业的管理层CEO、CIO如何考虑。个人观点，如果企业资产系统较多，可能开发一下难以接盘运维的工作，这种情况从运维侧发起更加好，因为运维人员非常了解这些系统，只要具备了一定的开发能力，运维人员做运维开发一体化可能会更顺畅一些；如果企业存量资产较少/大量系统在研发过程中，这种情况从开发侧发起更好，开发人员更了解更熟悉系统，开发人员做运维开发一体化可能会更顺畅一些。
个人观点，选择哪种模式跟企业的存量资产多少有关系，否则就变成突变了。一般中国人讲改革是渐变，就是说在原有的基础之上进行改变。两种模式是殊途同归的，采用哪种模式具体看企业的实际情况以及管理层的选择，这是一个战略/战术问题没有对错之分，具体看企业的改革路线。

Q9：Google公司内部管理SRE的是什么岗位？组织架构可以分享吗？
我了解情况是Google内部SRE是一个扁平的组织，原有的一线/二线的运维以及支撑的研发人员都转成Google的SRE了，规模有近千人，有三类的SRE分别是产品SRE、运维平台SRE、业务SRE。三种SRE都有各自分工，但是组织结构是相同的扁平管理，更多的强调个人的专业技能以及人的能动性，效率非常高。具体的组织架构我可以向孙宇聪老师问问看是否可以提供，不知道是否有保密条款的限制。