[关闭]
@gaoxiaoyunwei2017 2018-04-19T03:55:23.000000Z 字数 4465 阅读 396

纵观全球:运维的过去、现在与未来

luna
作者: 梁胜


作者介绍:耶鲁大学计算机博士,Rancher创始人——梁胜

很高兴有这个机会在高效运维社区跟大家有一个交流,我们Rancher也很有幸成为这个活动的一个赞助商,我觉得这也是非常有意义的事情。我们公司做的也是跟运维有关的事情,每个人进入DevOps的领域,都有自己的着重点,我就跟各位讲讲我对这方面的认识。其实最主要的还是通过我们帮了非常多的企业客户、非常多的互联网客户,帮他们实现DevOps。

image.png-34.8kB


运维在很早的时候跟现在是完全不一样的,我记得十几年前大家说起运维,那就是没有几家大公司是真正自己开放软件的,你找IBM、Oracle、SAP买现成的ERP软件部署出去,那时候的运维基本上就是基础设施运维,并没有应用开发、连续部署,所以那时候最重要的事情就是你部署好了以后最好不要动,软件升级的周期也非常长,常常是半年以上,有的时候甚至是三年做一个升级,这是完全另外一个时代的事情。

image.png-574.3kB

到了今天这个时代,DevOps成了一个大家都关心的课题,但是DevOps本身并不是一种做法,比如做DevOps有名的公司Netflix,还有一个公司是Coinbase,这两个公司在DevOps的两端,Netflix公司对开发速度的要求非常高,大家知道网络视频是一个非常有竞争的产业,它的竞争对手非常多。Coinbase因为在亚马逊上,它是做虚拟货币的,所以对安全性的要求非常高,Coinbase要做一个连续部署不是一两天可以做完的,它做连续部署的速度可能比在座的传统企业能想象的最慢的部署都要慢很多,因为对它来讲如果出一个错误的话,那就是一个非常大的问题。另外就是推特这样的公司,它的安全性要求比Netflix要高一点,推特要做得可靠,它哪天如果不可靠了,我们可能听不到川普每天讲什么,这个可能也不是什么大的问题,但是你要做运维,现在碰到更严重的问题是另外一个角度,就是安全性。你试想如果他的帐号被人攻进去了,他发一条信息说我要攻打北朝鲜,这对整个国家、社会的安定就会有非常大的影响。

image.png-89.3kB

所以在这里我要强调的一点就是DevOps做到一定程度之后,从风险的角度来讲,风险是两方面的,一方面是可靠性,另一方面是安全性。前几年大家吹得很凶的就是SRE这个词,这是谷歌前几年发明的,就是完全雇工程师放在DevOps应用里面,集中解决一些可靠性的问题。但是以今天的观点来看,我觉得哪怕是SRE这个词可能也未必能完全解释运维这个词,在另外一个角度,可能是安全更重要。随着行业的发展,在今天可靠性只是运维风险的一小部分,因为可靠性说到底还是被一些随机的因素控制,而人为因素引起的系统不稳定,这实际上更加可怕,所以现在我们看到越来越多的安全团队,成为DevOps和AIOps中间很重要的一部分。

image.png-31.2kB

AIOps是今天这个会议的重点,但是在做AIOps的时候,大家每次一想到AI,总觉得AI有可能要替代人,但是大家放心,AI在今天这个程度还远远没有做到替代在座很多工程师的程度。

image.png-207.4kB

而现在我们碰到的问题是工程师不够,不光是研发工程师不够,而且运维工程师也很缺。我们开运维大会、DevOps大会,常常有一些一流的互联网公司的架构师上来分享自己公司是怎么做的,但是其它的公司可能自己没有这样的团队,比如说在谷歌他们雇那些做运维的人员的时候,他们的标准和研发人员的标准是一模一样的。到今天为止我不知道他们是不是还坚持这个观点,早年刚建立SRE的时候,他是必须做到SRE工程师跟研发工程师是互相可以替换的。这里说有多少个公司能做到这样的水平呢?对两边的要求都要这么高。

image.png-432.1kB

所以又碰到了一个问题,早年我们做DevOps的时候,碰到最大的阻力就是Ops对DevOps比较敌视,这也是很有意思的,因为你知道解释这个词DevOps好像是一个词,但是Dev好像是修饰Ops,好像是研发的人进了Ops,原来Ops搞得好好的,我就管管机器,过段时间就给机器升级,突然来了个DevOps,很多人就说现在研发人员是上帝了,你卖东西也好,你要实现什么东西,你只要把研发人员那边想通了,最后部署研发人员就全部干掉了,Ops就没有了,现在大家都上云了,机器也不用你管了,你要部署应用的话,研发人员直接部署就好了,所以很多人看DevOps,觉得Dev是形容词,Ops是名词,是放Dev的人进来把Ops做掉。我一开始也是这么想的,但是和我个人的经历是恰恰相反的,我刚才说了运维最重要的是人,我看到自从有了DevOps之后,我发现越来越多的ops的人进了Dev,以前你学计算机可能学了本科还不够,你还要学研究生,还要实习,还要学算法。

image.png-58.6kB

但是今天这个程度,你看这个人的背景,他就是一个系统管理员,他非常年轻,他读的也不是什么好的学校,但是他可以把整个Docker做出来,他就是一个做运维的人,不是做研发的人。

image.png-349.6kB

现在我们公司也有好多个非常厉害的研发的人,但是我看有一大半真正厉害的研发人员都是从运维过来的。以前我对他们也是有偏见的,因为我问他们一个算法复杂的问题他们也搞不清楚,但是他们编程也做得挺好的,所以我觉得也挺好的。在座如果做运维的人,大可不比妄自菲薄,不要觉得是DevOps威胁了Ops。

假设哪一天AI把Ops全部统治了,我觉得有些人可以做Dev,为什么Ops的人做Dev可以做得好,因为他们懂得需求。现在的Dev不是原来的Dev,现在不是从零做起,而是站在巨人的肩膀上。

我下面几页PPT要用飞机做例子,所以有很多张用飞机做例子的,我先讲一下。你要讲起DevOps,实际上跟航空业有非常相像的地方,比如说大家知道飞机是要很安全的,否则大家都不敢坐,所以你看到有修飞机的人,同时还得需要有安检的环节,这实际上是两种工程师都要有的,不光是有工程师负责飞机本身的可靠性,也得有工程师负责安全性。
image.png-581.2kB

有时候你看看DevOps必须朝哪个方向走,我们有时候看看这些行业往哪个方向走,对我们也是非常有启发的,这一点非常了不起。在1960年的时候,那时候飞机已经非常可靠了,而且很高级,但是从1960年到现在,飞机的可靠性又提高了100。

image.png-502.2kB

你如果从软件可靠性的角度来讲,如果软件哪一天也能走那条路,那是非常了不起的。飞机是怎么达到这个东西的呢?我小时候在中国,大家说中国飞机不安全,也有人说苏联飞机不安全,有一次我就看到一篇文章说为什么不安全,后来我自己做软件了,我们在美国做的软件拿到中国这边的公司部署,我发现中国人对这个软件的态度跟美国人对这个软件的态度也不一样,我不知道在座的有多少人有这个态度,那时候我们做云平台软件、容器平台软件,我们把软件部署之后,有的时候出了问题,我们就叫人去修,客户就跟我说,不要来了,问题解决了。我说怎么解决的?我们系统重启了一下,这个问题就没有了。我觉得非常不好理解,在我看来,那就相当于是飞机坠毁了,他们又造了一架飞机,等着下次再坠毁。如果在国外,我们出一点点小事情,你不要说互联网公司,哪怕是传统的企业,它对这个事情的态度都是非常严谨的,真的就像调查飞机坠毁事件一样。我们搞软件,有时候也是叫我们公司的工程师查问题,查了一个星期也没查出来,我说你要接着查。

有时候我们看看飞机上做的事情,也是一个启示,这是一架从中国到伦敦的飞机,在降落的时候距离跑道不远的地方就降落了,好在没有一个人死伤,但是也不知道这是怎么回事,这个波音777飞了十几年,从来没出过一次事故,没死过一个人,这是第一次出事故,当然也没死人,大家不知道是怎么回事,怎么快降落了发动机就没力气了,那个飞机就掉下来了,大家也不知道是怎么回事,他们就去调查,你说波音777再飞一架绝对不会有这个问题,但是他们调查发现有一个地方高压油进来,这个油是冷的,因为空气在空中飞,油在零下,它必须把油加热,下面才能烧。

image.png-572.2kB

这边油进来的时候,它的管子有点露出来,最后发现什么问题呢?你知道汽油里面总是会有水的,再纯的汽油里面也是有水的,这是正常的,飞机在空中飞的时候汽油是很冷的,在非常冷的时候水是不会结冰的,到零下30度、50度它是不结冰的,但是在飞机降落的时候,油又热起来了,热到一定程度的时候,油里面的水就结冰了,结冰了之后,这个小冰块就会到这里来把它堵住,它设计的时候已经考虑到了这一点,这个管子有一个热交换器。如果冰进来,冰会化掉。

image.png-229kB

他们在调查的时候就有一个假设,是不是这个管子突出去太多了,冰就搁在上面化得不是太快,他们有这个假设,然后就造了一个巨大的机器放在冰箱里,把这个温度慢慢提高,最后把这个错误就能重现出来。重现出来之后再修就简单了。

image.png-231.1kB

后来进行改善,把这个管子打平,这样冰块就不会被卡住,即使有冰块生成,马上就会化掉,从那以后波音777就没出现过这样的问题。

image.png-817.3kB


他们修好了之后,有很多飞行员就说,怪不得777在降落的时候常常莫名其妙地这个发动机就会没有力气,但是很快会回来,因为冰化掉了,但是很多时候发现这个事情之后,可能这个飞机距离地面还有几百米甚至几千米,但是在伦敦那架飞机正好离地面只有几十米的高度掉下来了。因此我跟我们的研发人员讲,你们不管是做研发还是做运维,如果出现了一次事故,你总不能对它置之不理,你至少要从这次事故中学到一点东西。所以现在这个年代,很多真正质量的改进都是需要通过一个过程,然后不断地学习,将来运维就可以做得跟今天的飞机一样可靠。

image.png-523.4kB

最后我再讲一点自动化的话题。我也是拿飞机做例子,这是同样的飞机不同的型号,左边是新型号,右边是老型号,老的这个就是明显的Ops,新的这个就是AIOps。当年要登月的时候,地面上控制室有很多的屏幕,有很多的按钮,这是六十年代造的,非常复杂的系统,这个系统现在在佛罗里达的博物馆里还可以看到,它假装火箭飞起来,地板震一震。

image.png-1208.7kB

但是在今天,我去Netflix看它的运维中心,这里面的人不是很多,大家也不是很紧张,我当时觉得它至少应该有几个大屏幕、有几个曲线,像我们这里很多人喜欢搞一个大屏幕,搞一个指挥中心,但是他们那里什么都没有,所有的东西就在静静地发生,如果偶尔发生什么事情,大家就去处理,这也是挺有意思的。

image.png-1106.4kB

我有一个朋友那时候在一个公司刚升到运维中心的负责人,他去搞了一堆的屏幕挂起来,结果挂上去之后也没什么好显示的,后来把用户量挂上去,结果发现用户量上涨也不太快,过了几天就把这个屏幕拿掉了。

我在这次过来的飞机上看了一部前两年拍的电影,那个画质非常差,这里我找到了一部1996年拍的电影,那时候的画面还是很震撼的,我记得里面有一个情景是外星人进来了,所有的飞船都在打地球,但是有一个总飞船控制那个飞船,有一个勇敢的人上去把那个总飞船炸掉了,所以外星人全死掉了。

image.png-1349.4kB

其实说到底,你要可靠性和安全性,从运维可以解决,像开飞机、建飞机场这样去做。但是我们做技术的,我们也应该从架构上去考虑考虑,最近比较受大家注意的,比如说去中心化,我个人对区块链的很多技术是非常感兴趣的,你真正可以做到去中心化,不会因为一点被别人打掉了,整个系统就毁掉了,这样才能做到真正的可靠。

image.png-371.6kB

image.png-9.7kB

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注