Google SRE：起源
一、世界上第一个SRE专注于参与阿波罗登月计划的MIT教授Margaret Hamilton
二、Apollos计划中的SRE
Apollo 7 飞船研发事故的启发：
1、类似的情况不断发生
2、对于细节的不懈关注
3、做好充足的灾难预案和准备工作
4、时刻警惕
5、不放弃一切机会去避免灾难发生
以上是SRE最重要的理念！
三、SRE：站点可靠性工程师（Google负责7*24小时运维的VP命名）
1、SRE是工程师：使用计算机和软件工程手段设计和研发大型、分布式计算机软件系统；
2、SRE关注：焦点是可靠性，包括架构设计、运维流程优化->“足够可靠”；
3、SRE主要工作：运维分布式集群系统上的具体业务服务（Service）
四、SRE是一种职业：专注于整个软件系统的生命周期管理

Google SRE：基本概念
一、SRE：Service，google搜索引擎服务，S 最初指  
      软件系统40%-90%的花销是在开发建设完成后的不断维护过程中；
二、SRE 作为一个职业迟早诞生；
        Apollo 7 飞船研发的事故（一场的软件执行失败案例）
1、小朋友意外触发，导致整个模拟过程失败；
2、基于SRE的直觉， Margaret提交软件改进建议；
3、所有人（NASA管理层、工程师团队）认为错误低级，不值得修改，否决建议；
4、几天后，飞船运行中操作失误导致故障真的触发，不是演习；
5、航天员参考Margaret之前更新的手册，有限时间内解决问题。
三、站点可靠性工程（SRE）和系统管理员（sysadmin）的区别
1、运维对象不同：分布式集群管理系统VS小型机、X86管理系统
2、存在时间不同：于Google，前十年 VS 近十年
                            于中国，15年之后  VS 15年之前
3、技能要求不同：计算机科学+软件工程 VS 计算机科学
4、关注焦点不同：产品可靠性 VS 只负责将现成的软件组件部署到生产系统
5、成员来源不同：研发工程师 VS 从第三方工具厂商或系统集成商招聘



Google SRE 实践总结

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
1、直接成本相对清晰；
2、间接成本差异较大（背景、技术能力、工具习惯、工作目标）；
初步演变为目标与方向上的分歧以及内部沟通严重问题，上升到部门之间的信任与尊重传统运维模式（Dev/Ops分离的团队模式）冲突的焦点

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
1、传统研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。
2、开发团队宣称不再进行大规模的程序更新，改为功能开关调整、增量更新和补丁化（大变更→小变更），为了绕开运维团队设立的各种流程，从而更快地上线新功能。

       

       

       

                                          

       
Google SRE：起源
一、世界上第一个SRE专注于参与阿波罗登月计划的MIT教授Margaret Hamilton
二、Apollos计划中的SRE
Apollo 7 飞船研发事故的启发：
1、类似的情况不断发生
2、对于细节的不懈关注
3、做好充足的灾难预案和准备工作
4、时刻警惕
5、不放弃一切机会去避免灾难发生
以上是SRE最重要的理念！
三、SRE：站点可靠性工程师（Google负责7*24小时运维的VP命名）
1、SRE是工程师：使用计算机和软件工程手段设计和研发大型、分布式计算机软件系统；
2、SRE关注：焦点是可靠性，包括架构设计、运维流程优化->“足够可靠”；
3、SRE主要工作：运维分布式集群系统上的具体业务服务（Service）
四、SRE是一种职业：专注于整个软件系统的生命周期管理

Google SRE：基本概念
一、SRE：Service，google搜索引擎服务，S 最初指  
      软件系统40%-90%的花销是在开发建设完成后的不断维护过程中；
二、SRE 作为一个职业迟早诞生；
        Apollo 7 飞船研发的事故（一场的软件执行失败案例）
1、小朋友意外触发，导致整个模拟过程失败；
2、基于SRE的直觉， Margaret提交软件改进建议；
3、所有人（NASA管理层、工程师团队）认为错误低级，不值得修改，否决建议；
4、几天后，飞船运行中操作失误导致故障真的触发，不是演习；
5、航天员参考Margaret之前更新的手册，有限时间内解决问题。
三、站点可靠性工程（SRE）和系统管理员（sysadmin）的区别
1、运维对象不同：分布式集群管理系统VS小型机、X86管理系统
2、存在时间不同：于Google，前十年 VS 近十年
                            于中国，15年之后  VS 15年之前
3、技能要求不同：计算机科学+软件工程 VS 计算机科学
4、关注焦点不同：产品可靠性 VS 只负责将现成的软件组件部署到生产系统
5、成员来源不同：研发工程师 VS 从第三方工具厂商或系统集成商招聘



Google SRE 实践总结

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
1、直接成本相对清晰；
2、间接成本差异较大（背景、技术能力、工具习惯、工作目标）；
初步演变为目标与方向上的分歧以及内部沟通严重问题，上升到部门之间的信任与尊重传统运维模式（Dev/Ops分离的团队模式）冲突的焦点

传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
1、传统研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。
2、开发团队宣称不再进行大规模的程序更新，改为功能开关调整、增量更新和补丁化（大变更→小变更），为了绕开运维团队设立的各种流程，从而更快地上线新功能。