讲师介绍
欧阳辰,超过15年的软件开发和设计经验,目前就职于小米公司,负责小米广告平台的架构研发。曾为微软公司工作10年,担任高级软件开发主管。热爱架构设计和高可用性系统,特别对于大规模互联网软件的开发,具有丰富的理论知识和实践经验。个人公众号:互联居。
大家好,我是来自小米公司的欧阳辰。早先我有幸进入微软公司,在那工作了10年,做了两个项目,一个是搜索,一个是广告平台。去年我又加入了本土的小米公司,做一些大数据平台的工作。此次大会的主题是“Gdevops”,其中的“G”代表了Global,而我正好在微软、小米积累了一些全球化的经验,今天就自身所得给大家分享一下。
本次演讲包括以下内容:
2011年在印度召开的谷歌测试大会上,作为谷歌工程非常重要的一个人物——Alberto Savoia在会上发表了一个开题演讲,这个演讲的题目就叫“Test is Dead”(测试已死)。他的观点很明确,在互联网世界,如果你发布一个产品没有任何质量问题,这样的产品是失败的,而且也发布得太晚了。他认为,很多测试的质量问题实际上在测试实验室里是发现不了的。Alberto Savoia还有很多有趣的观点,有空大家可以找来看看。
但是,我今天不是来宣布“测试已死”或者“运维已死”,我主要想和大家分享一个观点。
这个观点其实也不是很新鲜了,毕竟最近有很多这样的热门讨论,包括 “DBA已死”、“Ops已死”等类似的观点。在我看来,这些角色可能会慢慢地减少,但不意味着他们的任务就消失了,代表的职责就消失了,他们只是变成另外一种工具和形式。
先来谈谈什么是质量,有很多定义。以前我们的定义是怎么找Bug,后来软件大了,我们会定义怎么去找matches,怎么去度量每千行软件代码的Bug数,或者说满足这些需求输出的规范程度。这是早先的定义,但在最近几年,很多定义在慢慢淡化,我们更加强调软件的质量就是它满足客户需求、提供用户体验的一种感觉。质量相当于一种经济竞争性,如果你做得快,迭代得快,很多时候会占优势。
其实做DevOps的核心问题就是提高工作效率,提高工作效率算是个老生常谈的话题了。大家可以读一下德鲁克写的这本《21世纪的管理挑战》,俗话说“文无第一,武无第二”,简单来说就是无论哪个领域,你很难找到一个大师级的人物是排名世界第一的,但是在管理领域中有个例外,就是德鲁克,他的排名永远是第一的。他的这本著作中写了很多关于IT信息技术公司应该怎么去管理的思考。
他讲到,在一个好的公司或者以生产效率为初衷的公司,其实他们更多的是在营造一种气氛,让大家提高运维效率、工作效率,而不是去做各种角色,把角色做得细,把人变得像流水线上的一个工人。他更多地强调一种跨界的角色,要不断学习和教导,强调质量优于数量。
因此,我所理解的DevOps很简单,就是一种产品的责任心,提升生产力,碰到问题、解决问题的一个过程。
接下来讲一下我在微软的研发过程,以及微软DevOps是怎么转型的。
以前,微软可以说是一个非常强大的测试公司。在微软里,测试工程师的招聘跟开发工程师是完全一样的,需要写代码,写很多的测试,待遇也是一样的。当时比尔·盖茨说,微软是世界上最大的测试公司,这是毫无疑问的。因为它当年有12000名的测试工程师,覆盖了各种产品的测试,有大概7、8个vp for test,就是测试可以直接做到vpm。这是2009年之前的情况。
比尔·盖茨也说,微软不光是个软件公司,更多的是个测试公司,因为微软早年的软件就是靠质量支撑的。在2009年以前,微软有三个非常重要的角色,我们称之为铁三角,一个叫产品经理PM,另外两个是开发和测试。当时这三个角色都非常强大,而且每个角色都有自己的行为目标。
不知道大家有没有想过产品经理的核心价值是什么,在我看来,他的核心价值就是发布产品,不管用什么手段什么方法,只要搞定产品发布就OK了。而开发的核心价值在于实现代码。那么,测试的角色是什么呢?很多时候在不同人眼中,会有不同的答案。但在当时,微软把测试的核心价值定义为提供质量反馈,也就是Quality Feedback。意思就是测试团队要不断提供测试的反馈,包括代码、Bug、生产效率的低下、运行效率的提高、用户体验等等。
总的来说,当时微软的模型就是这样,但这种模式有很大问题:
后来在2009年,微软提出了一个思想:Combine the engineer,基本想法就是把开发和测试合成一个角色,而名称还是沿用了“开发”这个名字。也就是说,在转化后,测试和开发全部合在一块了,测试工程师变成了开发工程师,而测试经理变成了开发经理。
微软整个DevOps转化过程分为三个阶段,碰到过很多问题。比如说,转化后整个团队更扁平了,可能以前有些主管就不再带人了,也可能以前有的人在测试领域是非常擅长的,可产品的部分他不太熟悉。还有包括运维,以前运维是个非常大的独立团队,但现在也全部转化到Combine the engineer去。
微软的第二阶段大概花了四年的时间,这时总体来看,开发和测试合在一起了,而运维还相对独立些。以前只有运维可以上线,但在第二阶段开发和测试也能上线了,不过数据库的一些部署主要还是由运维来上线。
到了第三阶段,也就是2013年之后,微软的运维角色已经非常少了,后来主要就集中在一些机房里。因为机房里有成千上万台机器,每天都有大量的硬盘坏掉,所以他门的工作就是换硬盘,每天推着一个手推车在机房里窜来窜去。
所以微软在融合的过程,把开发、测试、运维都变成一个角色。这样简化角色有一个好处,就是责任比较清楚,产品出问题了就是找你。以前产品出问题,经常要打电话给运维,但运维需要一个很长的路径才能接到电话,所以后来就改成所有线上问题都打给开发。反正你做了开发、做了测试、做了部署,都是你的事,那你也把这个事情搞定就好了。而开发人员也可以在整个过程中体会到怎么做产品,学到很多很重要的东西。
这是微软以前一些角色和任务的转移:
在工作方式上,也从以前的服从计划变成一种主动的探索。
以前,微软都是产品经理定好了工作方向,然后大家一起努力,加班加点,往这个方向去做。因为觉得方向肯定是对的,所以只要用最好的算法、最努力的态度去搞定就好了。但后来发现,其实你做出来的东西在市面上不一定受欢迎,而且竞争压力也很大。
在微软改成DevOps模式以后,工作方式转变成主动探索,我们会去尝试不同的方向,也不会认为哪个方向就一定是对的,我们还会做一些取舍,找到最终需要用到的方向。这也显示了一个极客文化,包括我们有很多黑客,大家找两天一起编程,实现一些好的idea。同时,这也强调了微软的一种代码文化,就是少说话,有什么想法show me code。
微软的Combined Engineering从效果上来看,使得产品发布节奏明显加快,以前我们讨论“做和不做”,现在是讨论“如何做得更快”。大家都会去交流生产力问题的焦点,体现了一种线上产品的主人翁精神。转型之后,我们内部还做了一个调查,发现开发者的工作效率、工作热情都有正面的上升。
微软在实现整个转型的过程中有几个原则:
微软大概是做了这么一个DevOps转型,而很多互联网公司其实也是这么做的。
比如说Facebook,Facebook是没有测试的,强调“NO Testers”这种文化,也是做单元测试、灰度测试为主,都有开发人员来做,但没有测试人员。
再比如谷歌,以前一个微软同事去了谷歌,写了一本介绍谷歌测试的书。书的内容其实很简单,就是说谷歌测试团队归于开发效率团队,职责是指导开发人员怎么去写测试用例之类的,他们开发和测试的比例大约是10:1,即10个开发对1个测试。
亚马逊还有一些测试功能,主要是集中在一些业务场景。
大家可能都知道,Facebook每周有一个灰度发布的过程。每周日晚上它会发布一个完整的build,星期一早上可能会推大概1%-2%到线上,然后星期二下午看看效果,没有问题的话星期三把它推到全线。每周都有这样一个节奏,并通过反馈的指标来看效果好不好。
谷歌的测试也没有什么神秘的,就是有单元测试、集成测试、Staging测试等。
在互联网公司中,可能有一个传统,就是我们可能更愿意把一些测试从发布前挪到发布后,换句话说,就是发布后再测试。发布前可以做一些单元测试、功能测试、探索性测试,发布之后可以边做集成测试边做系统测试。
比如我在微软时有一个项目就是做性能测试,很多时候我会利用微软晚上机房里一些流量比较低的机器。我会启动这些机器,模拟一些流量,直接打到线上产品的服务器上,再看它的效果。这时就可以充分利用线上的一些服务器来帮助你做一些测试,看很多指标,你还可以邀请用户去帮你做一些测试,比如β测试,可以邀请少量的用户使用3%或5%的流量enable the feature,然后观察这些用户的关键指标有没有变,比如用户时长、返回的响应时间等。
大家应该知道小米手机的软件是一个深度定制的Android系统,叫做MIUI。以前很难想象一个手机操作系统可以做到每个星期更新一次,甚至在列目板块,操作系统每天都有新的版本,包括我的手机使用的就是MIUI的内部版本。每天都是最新的版本,但基本上没有影响过我打电话、玩一些常用的软件。所以小米MIUI也有几个版本,体验版是每天发行,开发版是每周五下午发行,稳定版是每一两个月发行一次。能把操作系统做得这么快,这是我们非常重要的一个目标。
包括应用也是。以前应用都是跟MIUI ROM操作系统一起发布,但这样太慢了,后来就改成单发,每个应用自己发版,不需要走系统ROM的发版。后来还是觉得慢,就开始用Hybrid的H5做了。大概就是主要页面有一些用H5的,这样调整更方便,可有些体验相关页面还是要用native code来写。整个过程围绕如何做得更快更好来写,这就是DevOps的核心问题。
在部署方面,小米自己开发了一套自动部署系统。没有什么神秘的地方,基本上每台机上有些后台进程帮你去从代码拉服务器,拉完代码帮你做build,build完之后一台一台机器上线,上完一台会给你发一些消息,做一些测试,没问题继续上。这个系统叫AESIR。
小米也有自己的监控系统,叫Open-Falco,是我们去年11月开源的一个系统。大概也是在每个机器上装些agent,agent把performance counter收集起来,包括机器性能打到中间服务器里面,后面有HBase和MySQL,提供一些界面帮你去查询这些图表、趋势,大家有空可以看一下。Opensource也有很多解决方案,例如OpenTSDB等类似的解决方案。Open-Falco是我们开源的内部使用得不错的一款系统,它可以定义很多查询条件,做些定义的图片,报警了就发到你手机上。
传统的质量评判,是在测试环节结束后,测试机体会跳出来说质量已经满足了我的要求,OK,按绿灯,发出去。这感觉是一种好像没有人阻止你上线,但是后果由你自己承担责任的模式。出于这一考虑,开发人员就会有很大的动力去增加更多产品的指标,进而达到质量提升,这是一个比较健康的模式。
那么,产品质量到底能不能度量呢?这是一个很有趣的问题。有本书叫《数据化决策》,里面认为所有的事情都是可以度量的,可以用数字化去表示。比如他说可口可乐的口味是可以度量的,他通过邀请20万人去做可口可乐新口味的调查,最终得出结论。再比如说,他设定一种方法,推断出幸福的婚姻相当于你年收入增加2万美元。总之,它运用了很多方法和指标。
小米在这里会强调几个事情:
那么,不同性质的应用程序,它们的发布节奏分别是怎样的呢?我们在这一块有很多想法,也做了很多事情。
DevOps有很多工具,然而我觉得在每个团队里,核心问题并不在于你比我用了更好的库的工具,而是在于在适当的时候解决适当的问题,用简单的方法解决团队的大问题。不是用很重的工具去解决,而是把大问题分解成几个小问题去突破。
整个自动化基本架构包括持续集成、持续部署、shell、Service等,持续集成和持续部署就不说了。Service非常重要,就是需要把一些好的服务变成一个共享的服务去使用,包括DNS、申请虚拟机等。以前我们申请虚拟机都要去找运维,后来我们就跟运维强调,所有申请的机器直接让开发人员去做,不用找运维等运维再同意,让整个过程的效益再快一点。
DevOps有很多开源工具,相信大家都比较熟悉了,这里就不一一介绍。这些都可以在网上搜到,基本上一个工具可以解决一个小问题。主要还是要看自己的团队具体需要解决什么问题。
三大核心问题:
两个非核心问题:
DevOps实际上是一个关于适应的文化。动物学家达尔文曾说过:“世界上进化下来的动物,并不是最强大的动物,也不是最聪明的动物,而是那些最能适应变化(Responsive to change)的动物”,比如说老鼠、蚊子、蚂蚁等等。软件系统也一样,能够传承发扬的软件,必定能够快速适应变化。所以很多时候公司需要有一个适应力非常强的工程师,才能帮助公司、团队解决业务问题。
最后,DevOps转型不是一蹴而就的,这个过程可能是漫长的、持久的,但也是必须的,与时俱进的!走在DevOps转型路上的每一位前行者,唯有坚持不懈地去探索,才能不忘初心,方得始终。
峰会官网:www.gdevops.com
原文来自:DBAplus社群
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com
涉农贷款地址识别,支持对私和对公两种方式。输入地址的行政区划越完整,识别准确度越高。
根据给定的手机号、姓名、身份证、人像图片核验是否一致
通过企业关键词查询企业涉讼详情,如裁判文书、开庭公告、执行公告、失信公告、案件流程等等。
IP反查域名是通过IP查询相关联的域名信息的功能,它提供IP地址历史上绑定过的域名信息。
结合权威身份认证的精准人脸风险查询服务,提升人脸应用及身份认证生态的安全性。人脸风险情报库,覆盖范围广、准确性高,数据权威可靠。