Q1: 是一个结合研发和运维的团队吗？
A1: SRE的核心思想跟一样的，在开发和运维一体化这个旗帜下面，但是两个方向的东西。我的理解：SRE是从运维角度出发的，在运维下面，我要整合研发能力、整合研发团队，原有的运维人员要转型做50%的研发，这样转型后的团队就叫运维研发团队，转型后的工程师就叫运维研发工程师。DevOps从开发角度出发的，是强调应用的研发和运维一体化。
这两者是开发和运维一体化这面旗帜下的两个大方向，最终目标是一致的，所以叫殊途同归。即开发具有运维的职责和能力，运维具有相当程度的研发的职责和能力，这样一来，原有的部门墙、冲突和矛盾就消除了。
Q2: SRE其主要职责是通过研发能力提升运维能力？
A2：可以这样说，原来的运维团队可以认为是不具备研发能力的，倒不是说一开始不具备，回到十几年前二十年前的IT人员是不分运维、研发的，运维和研发是在一起的，是具备这个能力的。但是后来在金融行业，特别是银行需要满足监管、合规的，大约是在06、07年刘明康时期，由银监会颁布的“风险管理指引”明确指出开发和运维一定要分开，当时引发了开发向运维交钥匙、账号、权限和口令的事情。当时银监会的强烈要求之下，就真的分开了，但是效率就低了，而且出现了很大的部门的协作、沟通等问题。
那么，SRE的主要职责是做好运维做好服务，其次是大量引入研发能力，不管是通过招聘、培训、学习或转型，具备了研发能力后，来更高效的做好运维研发工作，不像以前界定的那么清楚了，强调能力的融合，最终可能是两个团队走到一起。
Q3: 运维的研发指责和开发团队的研发有没有明显的区分？
A3：这个区分是有的，运维的研发职责是基于运维研发的对象的，就是说运维的对象，比如运维的监控、网络、计算资源池等等，也就是我的运维对象里有什么，以后新的管理对象会有什么，但是纯面向业务的可能不由这个团队来单独解决，这一点我也要问一下孙宇聪老师，我们SRE这本书的翻译者，思想引入的人。他们是具备研发能力但不是替代开发，因为最适合的需求是IT管理的需求，以及IT管理需求延伸的软件和工具。
Q4: 有没有图解SRE核心管理理念？
A4：我们是通过书友会的形式来陆陆续续安排讲师、志愿者团队，大概控制在社群规模的10%，有兴趣的朋友可以加入这个志愿者团队，志愿者团队可以轮值做讲师，或者画一些图解SRE，也有利于SRE理论的进一步推广和宣传，另外实际场景也是计划结合实际案例，国内目前还是痛点，如果第一批解决了，我们也会出图解和大家交流。
Q5: 传统运维岗位，不会开发，以后如何发展？
A5：前几年还好，如果是15、16年您问我这个问题，我会说传统运维岗位不会做开发就去做管理好了，比如安全管理、运维管理和IT治理，是很好的方向。但是这两年，金融行业受互联网冲击下，很多金融机构都在学Python了，前两天书友会群里还分享一个帖子，就是“某股份制银行要求三个月内学会Python”，已经到了行政命令的程度，我这里理解，很多时候人是要有压力的，要有转化成的动力的，IT行业本来就是三到五年更新一遍，不如趁这个机会，运维也学一学研发，学一学Python、各种应用架构TOGAF、我们原来接触比较少的东西，整个运维团队会变得更有价值，国内IT人士还年轻嘛，四五十以上的IT人士还是比较少，大部分还年富力强，四十岁也年富力强啊，我觉得都可以学习啊，没有什么不能学习的，早年国内做IT的有几个没有学过C语言和VB，至少是有一定基础的，现在捡起来，做一些相关的需求或者脚本，甚至参与一些研发，我认为是很有意义的事情，希望大家正确面对时代的呼唤和挑战，我们不见得要做领先的人，但至少不要落后。
Q6: SRE团队内部是如何进行职责分工的？
A6：这个在我们后面分享是有的，第一章只是提纲挈领的、从整个战略高度来看SRE，对组织和原有运维、研发矛盾的解决，如何从整体上认识可靠性，真正的从源头上提高效率，执行一个更好的结果，提高我们的服务，从这个角度来看的。
