请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 121|回复: 0

运维人心声-SRE是未来

[复制链接]
发表于 2020-11-19 17:07:02 | 显示全部楼层 |阅读模式
《SRE》读后感  
  

% @& g( D/ R1 w. h/ v* j
                        xindoo    评论    SRE            5    2016-10-02 10:57:41                                                  原文来自:http://blog.csdn.net/xindoo/article/details/52723114
0 Q# J0 n$ Y* c0 E《SRE》这本书英文版已面世半年后,中文版终于面世。从4月、5月的时候,我就一直在尝试看英文版,由于自己英文水平有限,阅读进度和深度实在有限,看到中文版,对很多章节的内容才算是有了较深入的理解,一句话评价此书,这是一本运维转型的指导性书。 / G7 D2 ]- L& O) D6 B8 L1 t

$ u" G% j: U# J) ~# f, T2 S# ?  f' u看过原版,再对照中文版,从内容上,并不比原版少什么,所以各位读者不必担心内容相对原版是否缺失,如果各位英语不好、但又想了解Google的SRE,放心大胆的买中文版吧,因为译者也是Google的前SRE,翻译的不能说原汁原味,但也八九不离十。  5 i% L6 w! o9 e- O8 q

8 \" o. ^2 c, g% g; l我自己本身也在国内某大厂做运维,我们也面临着传统运维向DevOps的转型,接下来我就结合自己实际工作的经历,谈谈我对这本说的理解。   ' ~5 g+ N  [, _2 T  N; X% Y
& g( j& n8 [2 X& O
这本书基本上可以分成几个大部分。3 c) t2 W, _: r; [2 m$ L

0 `1 q( l4 ]3 I% l, O. V( p; @* SRE的诞生  
% U$ ?7 d* i! U. g8 E; Y* Google内部软硬件环境  5 [8 V" A. j# Z) v3 w
* SRE和Dev的协作
' N1 G- [- X9 i  F* SRE自己是如何做事的  
4 L8 j% T$ I0 D/ l/ F& Y5 k: B  Q4 _* @2 j$ Q
) A' f+ o, Y  [) ~1 u1 A+ s2 T
SRE是为了解决op和dev相互之间的矛盾和割裂的问题,用一些工程和规范来让op和dev之间有个平衡,并且最优化系统的发展。书中举出大量dev和sre系统的方法和规范,比如错误预算、部分运维工作交还dev、SRE协助dev团队健康发展等……   - L$ {4 E8 v( R9 h( N; \
- G% U. O; H) F* {
从我自己的经验来看,其实作为一个op,一天到晚有一堆乱七八糟的事,曾经因为这些事,搞的我情绪都不太好。不同于国内一些公司,google考虑到了这些,制定了一系列的标准来平衡SRE工作上的问题,比如最多50%运维工作、完善的轮值机制、完善的SRE培训体系……,前两天还看过google的《重新定义公司》,从他们内部各种福利政策来看,google是一个非常人性化的公司。  
$ w/ [2 z2 T3 u6 t/ R* a/ f- _1 `/ S: O6 N( O. x
运维工作中,有些是管理层需要做的事,但也有些内容能让你自己提升自己运维的效率。这么多年,SRE总结出了一套完善的方法论,比如和Dev团队的协作沟通,SRE在风险管理、on-call、故障排查、问题处理、故障后总结……,google都总结出了想当好的经验。  ( C2 T7 m9 D% e) X+ B2 ]+ W0 M% e

. o; B1 l. b8 b书中也介绍了google的一些软硬件环境,比如数据中心、网络、borg、Chubby(zookeeper)、监控系统、负载均衡、cron等。书中介绍了一些这类软硬件设计的思路,可以给那些想自己设计软硬件系统的公司一些方向。
8 T4 G* n: O: U5 ~> We want our systems that are automatic, not just automated.
+ H6 P& O6 ]! ]0 J7 g>
+ r$ l+ s) Q- X; J
' O7 E! g+ b# v上面这句话是英文版原文,如何理解这句话?我们想让要系统是自治的,而不仅仅是自动的。这是一个设计系统先进的理念,想想我们往常是怎么设计系统的,是不是专注于解决一个问题,流程在这里卡了,需要人为干预,甚至是再做一个新的系统来解决某些问题。  9 e3 M# F% r! r& W5 n# M$ T
( O  ?9 O  T3 {
举个例子,一个应用有数十台服务器,服务器会宕机,然后需要把服务器下线,再扩容一台。然后就会有一个监控系统发现问题,再弄个服务器下线的系统,自动化扩容的系统,然后都需要手工提单。这个时候,有人嫌提单麻烦,又写了个自动调其他三个系统解决问题的系统。就因为服务不是自治的,而我们一味强调自动化,导致系统越来越复杂,越来越难以自动化。其实我举的这个例子,google的borg已经很好的解决了,我认为borg基本上就是一个自治的系统。   % g& N  C- b( m) }9 p7 ^

$ I" _. h" A4 \6 L: X. K总结一把,我觉得这本书并不是直接告诉你应该怎么做,因为不同的公司在不同的阶段关注的重点是不一样的,做的事也不可能和google相同,盲从某些方法论可能会得到相反的结果,所以我的建议是把这本书当成一种方向性的指导。 ' r5 k' J8 i* x/ h3 g
2 K% F# T6 I8 Q+ T; s$ X
2017年7月29日补充:在我即将离开运维这个岗位之即,说下我的体会,目前国内许多大公司都鼓吹运维向devops(也就是sre)转型,其实大多数人都在转型过程中被干掉了,我觉得其实是因为运维缺乏研发能力。SRE骨子里是研发,而不是运维,就像这本书里说的,SRE其实是研发团队构建运维团队的产物。

+ A* y/ g  @# b3 H( ~5 U) y8 O9 |2 L, i: E: X
有人回复了楼主:/ s/ R4 u* ^5 x: h6 F% w
还是不建议做运维,说下我们运维团队的变化,15年我实习的时候团队有30多人,我16年写这篇书评的时候团队拆分后运维还有将近20人,19年初团队彻底解散。。。再说下转行难不难的问题,我算是18年中真正从运维转到java开发,但在此之前我自己就有大量的编码练习,而且还刷脸去旁边的开发团队过渡了半年的时间蹭了个项目经验。我能从运维转开发是有大量的前期准备和很多机遇在里面的,并不是所有人都能走我这条路的,所以我还是觉得直接运维转开发门槛还是很高的。    但是所有事情都得辩证去看,运维的经历也不是说完全不好,运维的经历让我学到了好多普通开发不懂的知识,就比如我现在很多命令行工具玩的贼溜,关键时刻节省大量时间;再比如比较虚的有对架构的理解、对流程的把控也是超过普通开发。运维也算是让我修炼了一些内功,学起其他的东西也比较快。注意:这一切都得建立在你有学习的主动性上,我觉得很少有leader能在运维方向上给你指明未来的发展道路(可能他们自己也不知道),也很少有人会愿意这么做。

9 G+ p( t+ A1 V4 W5 V
$ H6 q2 J; H/ t1 Y" r

; g) J% G+ c/ P- @* d2 w% ?+ M, l+ F+ c6 ^

% e3 b+ Q2 \2 x0 L$ T5 a; W
/ ~2 s$ z& k9 B/ W- p" F0 y9 p3 i




上一篇:从谷歌不Dang机说起,SRE
下一篇:如何朝着谷歌的SRE方向迈进

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2020-11-28 04:05 , Processed in 0.154442 second(s), 27 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表