谷歌SRE精髓思想浅析

admin

: |4 O+ h2 L1 C# ~" P7 B$ _1 o

       

       

       

' k5 ^# f. U4 y0 p0 \

                                          

       
Google SRE：起源
一、世界上第一个SRE专注于参与阿波罗登月计划的MIT教授Margaret Hamilton
二、Apollos计划中的SRE
. |7 g5 `# P6 u+ H; R- x5 D Apollo 7 飞船研发事故的启发：
1、类似的情况不断发生
' u2 @8 n% N; J6 A1 }  T 2、对于细节的不懈关注
/ {3 P) |( {1 k 3、做好充足的灾难预案和准备工作
4、时刻警惕
/ _1 J. ]! H4 q$ H 5、不放弃一切机会去避免灾难发生
以上是SRE最重要的理念！
% z' I: l0 z2 b$ E- Y  O0 Y 三、SRE：站点可靠性工程师（Google负责7*24小时运维的VP命名）
1、SRE是工程师：使用计算机和软件工程手段设计和研发大型、分布式计算机软件系统；
+ d& A8 g: S3 a" ` 2、SRE关注：焦点是可靠性，包括架构设计、运维流程优化->“足够可靠”；
3、SRE主要工作：运维分布式集群系统上的具体业务服务（Service）
) l0 M7 Q* ]8 V9 j5 H, f  F% D 四、SRE是一种职业：专注于整个软件系统的生命周期管理

" D5 x) t, C3 y Google SRE：基本概念
% N8 W5 X+ r* c 一、SRE：Service，google搜索引擎服务，S 最初指 Google.com
      软件系统40%-90%的花销是在开发建设完成后的不断维护过程中；
二、SRE 作为一个职业迟早诞生；
$ F# A& x) |, U6 c& M5 m$ y        Apollo 7 飞船研发的事故（一场的软件执行失败案例）
1、小朋友意外触发，导致整个模拟过程失败；
7 @: U( v6 X0 y$ x- n. z3 | 2、基于SRE的直觉， Margaret提交软件改进建议；
7 Z4 w) P% e9 f 3、所有人（NASA管理层、工程师团队）认为错误低级，不值得修改，否决建议；
3 {  V' ~: D2 r4 @ 4、几天后，飞船运行中操作失误导致故障真的触发，不是演习；
, l" C) c3 L6 M1 [* ?8 j 5、航天员参考Margaret之前更新的手册，有限时间内解决问题。
/ l/ K! F" L" V! e0 v& L1 W 三、站点可靠性工程（SRE）和系统管理员（sysadmin）的区别
1、运维对象不同：分布式集群管理系统VS小型机、X86管理系统
2、存在时间不同：于Google，前十年 VS 近十年
                            于中国，15年之后  VS 15年之前
/ ^/ z9 Q7 c  W: v 3、技能要求不同：计算机科学+软件工程 VS 计算机科学
. s$ S# ^! g9 I8 b+ D 4、关注焦点不同：产品可靠性 VS 只负责将现成的软件组件部署到生产系统
5、成员来源不同：研发工程师 VS 从第三方工具厂商或系统集成商招聘

' W' \3 E- ]7 n7 Y: g' \0 J
, s* e) C" A- l- c+ |" C
Google SRE 实践总结
0 w6 L8 H& }7 T& b
传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
1、直接成本相对清晰；
$ Z/ r5 ?6 V+ h0 G: t/ c 2、间接成本差异较大（背景、技术能力、工具习惯、工作目标）；
* C" [8 t1 K. n  F' ] 初步演变为目标与方向上的分歧以及内部沟通严重问题，上升到部门之间的信任与尊重传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
3 x; a* O( G7 K5 w+ f6 A
传统运维模式（Dev/Ops分离的团队模式）冲突的焦点
1、传统研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。
8 `- v& X# f6 D7 H( f4 K: X& R3 R 2、开发团队宣称不再进行大规模的程序更新，改为功能开关调整、增量更新和补丁化（大变更→小变更），为了绕开运维团队设立的各种流程，从而更快地上线新功能。
  A# X$ E5 Y" ?6 F$ ]. R1 m; L
: b# Y0 ^: H$ A+ {/ \
1 p, [8 D5 h/ O