话题1：Gartner 2019 年「基础设施和运维」十大趋势
1.        “I&O变得比以往任何时候都更深入地参与到现代企业前所未有的领域。I&O领导者关注的重点不再仅仅是交付工程和运维，而是交付支持和实现企业组织业务战略的产品和服务。问题已经变成‘我们如何利用AI、网络自动化或边缘计算等能力，支持快速增长的基础设施并满足业务需求？”——基础设施运维越来越重要，SRE大有可为。
2.        Serverless计算 是硬件无感知（体现了老外对基础环境研发的追求，并不是没有服务器）；数据中心死亡 是抽象概念，其实没有死亡，而是越来越多无处不在，立地成佛了。
3.        数据中心等IT基础设施和大量运维对象不会凭空消失，在边缘计算、物联网等新技术条件下，更加需要持续的研发工作来解决运维的深层次问题，因此SRE的核心思想可以适用于I&O等新型态和新场景。

话题2：对于SRE等运维研发人员，您建议掌握哪些开发语言？掌握Java以及Python，在新的开发运维一体化大环境下重要吗？
1.        其实和语言无关的。python只不过是比较简单，上手比较快。不过，必须要掌握一门语言，这个是未来的大的趋势。很早以前要求的熟悉  PHP/Perl/Python 其中一种语言优先。现在是必须掌握 PHP/Perl/Python其中一种开发语言用于日常运维。
2.          Google的SRE并不是将运维⼯程师转为开发⼈员，⽽是直接招聘合格的开发⼈员。SRE团队本质上是⼀个开发团队，⼯作内容是⼀个系统⼯程，包含做项⽬的⽅⽅⾯⾯，项⽬管理、产品、架构、开发、测试、 CI/CD等，只不过建设内容是⾯向⽣产环境可⽤性。

⽬前国内的现状，很多开发⼈员都⽆法做出良好的软件，何谈让运维⼈员转开发，做⼀套可⽤的软件；⼀个开发⼈员的培养是需要系统化的、持续的训练，是不断在项⽬中历练出来的，让⼀个0开发基础的运维做开发：如果把这个⼈放在⼀个成熟的开发团队，需要3-5年的时间，如果是⾃学，成功的希望渺茫，就像⼀直在岸上⾃学游泳⼀个道理。
SRE应该掌握哪⻔语⾔：是整个公司的技术栈和现有⼈员的技术背景决定的。运维⼈员应该学习python，⽬的是⾃动化运维，提⾼效率，减少重复劳动；如果只是让现有的运维⼈员写⼏个python脚本，不能称为SRE⼯程师；如果企业的技术栈是JAVA，运维⼈员也应该了解JAVA,⽬的是理解运维的内容，以更好地运维。

话题3：DevOps与SRE的交互
SRE和DevOps同属开发运维一体化时代的产物，有交集很正常，个人以为是“殊途同归”。

话题4：Keys to SRE
1.        网址链接conference/srecon14/technical-sessions/presentation/keys-sre
2.        SRE是谷歌的中流砥柱（对一切负责），从谷歌内部软件架构到用户服务以至于云平台。SRE is responsible for everything；

话题5：在成本分析的角度解读风险

1.        可靠性（蓝色）越高成本越高，指数级增长趋势。创新，比如自动化会降低维护成本，鼓励做些有收益的应用会带来额外的收入，比如gmail，adwords等等，所以趋势是绿色线表示。
2.        赞成SRE提出的Error budget（错误预算），确实很好揭示出运维风险的一个侧面，即风险不仅仅意味着负面损失，如果加以深入分析、积极利用的话，完全可以带来正向收益，实质上是很接近于机会成本与商业回报的概念。
3.         运维的发展路线是标准化—自动化—智能化，其中每一步都意味着对于服务风险的认识深化和能力提升；Google的精彩实践再次证明，国内的差距不仅仅是技术上的，更大程度的上是认识上的差距。

       

       

       

                                        话题1：Gartner 2019 年「基础设施和运维」十大趋势
1.        “I&O变得比以往任何时候都更深入地参与到现代企业前所未有的领域。I&O领导者关注的重点不再仅仅是交付工程和运维，而是交付支持和实现企业组织业务战略的产品和服务。问题已经变成‘我们如何利用AI、网络自动化或边缘计算等能力，支持快速增长的基础设施并满足业务需求？”——基础设施运维越来越重要，SRE大有可为。
2.        Serverless计算 是硬件无感知（体现了老外对基础环境研发的追求，并不是没有服务器）；数据中心死亡 是抽象概念，其实没有死亡，而是越来越多无处不在，立地成佛了。
3.        数据中心等IT基础设施和大量运维对象不会凭空消失，在边缘计算、物联网等新技术条件下，更加需要持续的研发工作来解决运维的深层次问题，因此SRE的核心思想可以适用于I&O等新型态和新场景。

话题2：对于SRE等运维研发人员，您建议掌握哪些开发语言？掌握Java以及Python，在新的开发运维一体化大环境下重要吗？
1.        其实和语言无关的。python只不过是比较简单，上手比较快。不过，必须要掌握一门语言，这个是未来的大的趋势。很早以前要求的熟悉  PHP/Perl/Python 其中一种语言优先。现在是必须掌握 PHP/Perl/Python其中一种开发语言用于日常运维。
2.          Google的SRE并不是将运维⼯程师转为开发⼈员，⽽是直接招聘合格的开发⼈员。SRE团队本质上是⼀个开发团队，⼯作内容是⼀个系统⼯程，包含做项⽬的⽅⽅⾯⾯，项⽬管理、产品、架构、开发、测试、 CI/CD等，只不过建设内容是⾯向⽣产环境可⽤性。

⽬前国内的现状，很多开发⼈员都⽆法做出良好的软件，何谈让运维⼈员转开发，做⼀套可⽤的软件；⼀个开发⼈员的培养是需要系统化的、持续的训练，是不断在项⽬中历练出来的，让⼀个0开发基础的运维做开发：如果把这个⼈放在⼀个成熟的开发团队，需要3-5年的时间，如果是⾃学，成功的希望渺茫，就像⼀直在岸上⾃学游泳⼀个道理。
SRE应该掌握哪⻔语⾔：是整个公司的技术栈和现有⼈员的技术背景决定的。运维⼈员应该学习python，⽬的是⾃动化运维，提⾼效率，减少重复劳动；如果只是让现有的运维⼈员写⼏个python脚本，不能称为SRE⼯程师；如果企业的技术栈是JAVA，运维⼈员也应该了解JAVA,⽬的是理解运维的内容，以更好地运维。

话题3：DevOps与SRE的交互
SRE和DevOps同属开发运维一体化时代的产物，有交集很正常，个人以为是“殊途同归”。

话题4：Keys to SRE
1.        网址链接conference/srecon14/technical-sessions/presentation/keys-sre
2.        SRE是谷歌的中流砥柱（对一切负责），从谷歌内部软件架构到用户服务以至于云平台。SRE is responsible for everything；

话题5：在成本分析的角度解读风险

1.        可靠性（蓝色）越高成本越高，指数级增长趋势。创新，比如自动化会降低维护成本，鼓励做些有收益的应用会带来额外的收入，比如gmail，adwords等等，所以趋势是绿色线表示。
2.        赞成SRE提出的Error budget（错误预算），确实很好揭示出运维风险的一个侧面，即风险不仅仅意味着负面损失，如果加以深入分析、积极利用的话，完全可以带来正向收益，实质上是很接近于机会成本与商业回报的概念。
3.         运维的发展路线是标准化—自动化—智能化，其中每一步都意味着对于服务风险的认识深化和能力提升；Google的精彩实践再次证明，国内的差距不仅仅是技术上的，更大程度的上是认识上的差距。