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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 177|回复: 0

谷歌SRE运维解密前言

[复制链接]
发表于 2020-11-25 15:51:11 | 显示全部楼层 |阅读模式
如果用一个词语来描述 Google 的历史,那就是不断地"扩大规模"(scaling up)。Google的成长经历,是计算机行业中数一数二的成功故事,标志着整个社会向 IT 为中心的商业模式的转变。Google 很早就开始实践 IT 与商业模式的结合,也是向社区推广DevOps 理念的先行者。本书就是由来自公司各个部门,切身参与甚至主导了整个行业转型实践的人写成的。1 ]4 G" e" g% B. X0 X# A6 n+ C
- @+ L4 }0 s& \* U# a
Google 是在一个系统运维工程师行业转型的阶段发展壮大的。Google 的发展史就像是对传统的系统运维理念发出的革命宣言∶我们无法按照传统方式运维 Google 系统,必须要思考一种新的模式,但是同时我们也没有时间等待其他人验证和支持我们的理论。在Principles of Network and System Administration(参见文献【bur99】)一书的介绍中,我提出了一种观点∶系统运维本质上是人与计算机共同参与的一项系统性工程。当时的一些评论者对这种观点表示了强烈的反对∶"这个行业还远远没有成熟到可以称为一项工程"。在那时,我甚至对整个运维行业产生了怀疑,认为这个行业在个人英雄主义与神秘色彩中已经永久地迷失了自己,无法前进。但是,这时 Google 诞生了,Google 的高速发展将我的预言变成了现实。我之前的定义变成了一个具体的词语∶SRE,站点可靠性工程师。我的几个朋友切身参与了这个新职业的创立,用软件工程理念和自动化工具定义了这个行业。一开始,他们显得很神秘,Google 公司内的体验和整个行业也格格不入,Google 太特殊了! 随着时间的推移,公司内外交流逐渐增多。这本书的目标就是将 SRE 的一些思考和实践带给整个行业,以促进交流。( J1 X4 T+ a. {( j3 K

. K8 A+ I7 n$ u" G) j5 D在本书中,我们不仅仅展示了 Google 是如何建设维护其富有传奇色彩的大型计算集群的。更重要的是,我们展示了在建设过程中,Google 工程师团队是如何学习、成长、反复修改,最后定义出一套完整的工具和科技体系的过程。IT 行业大多自我封闭,交流过少,很多从业人员都或多或少地受教条主义的限制。如果Google 工程师团队能克服这个惯性,保持开放的精神,那么我们也能够一起和他们面对 IT 行业内最尖端的挑战。; W( r3 o/ }& J% s

/ X4 D( D% j. Z# O) h! h  S5 d这本书由一群有共同目标的 Google 工程师写就的短文组成。本书的作者们聚集在同一个公司旗下,为了同一个目标努力,本身就是一件很特别的事情。在本书的各个章节之间经常能看到软件系统的共同点,以及工作模式上的共通之处。我们经常可以从多个角度分析不同的决策选择,了解他们是如何一起解决公司内部多种利益冲突的。这些文章并不是严谨的学术研究论文,而是这些人的切身经历。虽然本书的作者们有着不同的工作目标、写作风格,以及技术背景,但是他们都尝试着去真诚地描述自己遇到的问题和解决的经历。这和 IT 行业内的普遍文风截然不同,风格迥异。有些作者会宣称∶"不要做A,只有做B才是正确的。"另一些作者会更谨慎,行文更富有哲学性。这其实恰恰代表了整个 IT 行业内不同个性融合的现状。而我们作为读者,作为观察者,并不了解整个Google 的历史,也没有参与到具体的决策过程中,无法全面了解当事人所面临的纠缠不清的挑战,只能带着谦逊的态度远远旁观。在阅读本书的过程中,相信读者一定会产生出许多疑问∶"他们当时为什么没有选择X?""如果他们选择了Y,结果会是怎样?""如果多年之后回头再看,这个选择会是正确的吗?"这些问题,恰恰是阅读本书的最大收获,│因为我们第一次有机会将自己的经历、选择和本书陈列的决策逻辑相互对应,从中发现不足和缺陷。2 ?1 A, u4 x# ~
7 @' V% ], c: f* e3 A1 k+ ]) \
这本书的成书过程也堪称奇迹。今天,我们能感受到整个行业都在鼓吹厚颜无耻的"代码拿来主义"(just show me the code)。开源软件社区内部正在形成一种"不要问我问题"的风气,过于强调平等却忽略领域专家的意见。Google 是行业内为数不多的,愿意投入精英力量钻研本质问题的公司,而且这些公司精英很多都有工学博士学位。工具永远只是解决方案中的一个小小组件,用来链接日益庞杂的软件、人和海量的数据。这本书中没有万能药,没有什么东西能解决一切问题,但是这恰恰是本书的宗旨∶相比最后的软件结果、架构设计而言,真实的设计过程、作者本身的思考经历更有价值。实现细节永远只是短暂存在的,但是文档化的设计过程却是无价之宝。有机会了解到这些设计的内幕真是太难得了!
' c' Q& T  X/ N% ^
$ x5 f9 p. |- w9 y2 T( Y! W5 W这本书,归根到底,记录了 Google 这个公司的成长经历。书中的很多故事都是由相互重叠的故事组成的,这恰恰说明了扩展一个计算机系统,要比简单按照书本上的标准架构放大困难得多。一个公司的成长,意味着整个公司商业模式和工作模式的扩展,而不是简单的资源扩张。仅此一点,这本书就物超所值了。5 Z; x$ S: [5 f5 ]% \( a
/ x2 Q2 z0 r2 C+ O: y
自省,是一个在 IT 行业内部并不流行的词语。我们不断重复发明各种系统。很多年以来,只有 USENIXLISA大会论坛以及其他几个专注于操作系统的会议会讨论一些 IT 基础设施的设计和实现。很多年后的今天,IT行业已经天翻地覆,但是本书仍然弥足珍贵∶它详细记录了Google 迈过分水岭时期的全过程。很显然,这些经历没有办法完全复制,也许只能被模仿,但是却可以启发读者,指引未来。本书作者们表现出了极大的真诚,显示了谦逊的风格,以及极强的凝聚力、领导力。这些文章记录了作者们的希望、担忧、成功与失败的经历。我向这些作者们和编者们的勇气致敬,正是这种坦率,让我们能够作为旁观者和后来人,从前人的经历中学习到最宝贵的知识。
( T1 ^. S, S+ d, {! L  b7 W  R1 l. ]0 D  @! z
Mark Burgess
  V! E6 M3 l: _& U7 G* ^In Search of Certainty 一书作者
6 E# _. [1 {& p: ~Oslo,2016年3月
5 O: X2 T  c8 j8 K




上一篇:谷歌SRE运维解密译者序
下一篇:谷歌SRE运维解密序言

本版积分规则

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

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

Baidu

GMT+8, 2021-1-20 09:16 , Processed in 0.165927 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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