欧卡2中文社区

 找回密码
 立即注册

QQ登录

只需一步,快速开始

需要三步,才能开始

只需两步,慢速开始

欧卡2入门方向盘选莱仕达V9莱仕达折叠便携游戏方向盘支架欢迎地图Mod入驻
查看: 8300|回复: 0
收起左侧

[互联网] 技术人攻略访谈二十五:运维人的野蛮生长

[复制链接]
知行 发表于 2015-8-11 01:07 | 显示全部楼层 |阅读模式

技术人攻略访谈二十五:运维人的野蛮生长

请输入图片描述
文:Gracia(本文为原创内容,部分或全文转载均需经过作者授权,并保留完整的作者信息和技术人攻略介绍。)

导语:本期采访对象邵海杨@海洋之心-悟空UPYUN运维总监。第一波互联网潮流兴起以来,Web运维作为一份职业已经存在了十几年。在普遍的印象里,运维人总是和“辛苦”这个词划上了等号。飞增的流量带来网站规模和复杂性的提升,在高压环境下生存的运维人,谁不曾为服务上线彻夜坚守?谁未曾被半夜报警紧急叫醒?谁不是问题出现后第一个知道,问题解决后最后一个离开?O'Reilly出版的《网站运维:保持数据实时的秘密》这本书的第一章,对运维职业做了这样的描述:Web运维没有定义好的职业路径,也没有教育能够造就懂得运维Web基础结构的人才。追求Web运维这个职业,你将成为一名拓荒者。

想征服这块荆棘丛生的领地,成功的拓荒者不仅需要掌握坚实的基础,更少不了长期的坚持和探索的勇气。从毫无章法到游刃有余,邵海杨用了差不多10年时间,当他可以把Linux玩得如同庖丁解牛(把Linux裁剪到12M),自然也能轻松玩转运维。于是我们看到了一个快乐的运维人,在UPYUN这家以云服务为核心业务的公司,3人的运维团队用高度自动化的方式管理着500台服务器,不仅能保证系统的可扩展性,还能实现平滑的升级和问题的快速定位。在荒地上辟出新路,和邵海杨对Linux的热爱密不可分。见面那天,我们不幸选择了一家非常吵的餐馆。为保证录音效果,他扯着嗓子、眉飞色舞地吼了两个多小时,说他怎么看几百台Linux在他的控制下跳舞,我眼前也瞬间浮现出几百只小企鹅跳舞的奇妙画面。他希望能传递运维的正能量,就和攻略君一起来看这段运维人的拓荒历程吧!

  • 技术人攻略:能否介绍一下你是如何把嵌入式Linux的思想应用到了运维领域?

我98年进大学开始接触Linux,到04年加入台湾威盛之前,已经玩了6年Linux。包括各种服务器配置,IDC机房的网络,LAMP组合都驾轻就熟,自认为玩得还不错。可接触了嵌入式Linux之后,才发现原来Linux还有很多奇妙的玩法和专用领域。之前只了解上层应用,对Linux本身的印象还停留在几百兆的一张光盘和一堆服务配置,其实根本没有入道。

在威盛的工作是做车载嵌入式系统,属于定制化的Linux系统,去掉了不需要的硬件模块和驱动,封装出一个很小的、精干稳定的操作系统。做完这个系统之后,我对Linux的每一部分都了解得很清楚,像庖丁解牛一样,能把Linux做到12M(2005年用16MB的DOM盘)。

加入UPYUN以后,发现业务和硬件都是自由、自有且可控的,很适合为它打造一个专有系统。于是我把嵌入式的思想用到了运维中,打造了一个86M的专有Linux系统。这个系统可以灌到4G或8G的U盘里,当上架新机器时,只需插上U盘,配合执行一些脚本,机器就摇身变成存储或CDN服务器。UPYUN的500台机器都采用这种方式管理,现在哪怕一天部署300台也不成问题,极大提升了运维效率。

采用U盘系统的好处不仅在于快速安装,更重要是实现系统的平滑升级。有了U盘以后,可以把系统镜像写到U盘里,升级之后,再把镜像写回到磁盘,通过两种媒介的切换,可以保证3分钟内整个系统焕然一新。采用光盘网络安装的方式虽然也能提升效率,但只有硬盘一个载体,无法及时给正在运行的操作系统升级。我们的CDN分布在全国,数量多又分散,光盘网络安装的方式更适合集中式机房。

更酷的是,由于系统和安装的标准化程度非常高,系统又很基础,没有敏感数据,我们规范化和简化了上架流程。后续采购新机器,只需将定制好的U盘快递给经销商,经销商用程序生成一个硬件检测报告,截图发给我们确认,证明这台机器OK,直接就可以发到机房上架。这省却了原来经销商先检查一遍硬件,打包快递给我们,我们拆封检查、灌系统,再打包发给机房的中间环节。运维做到连机器都不碰,把人解放了出来。

  • 技术人攻略:运维工作普遍很辛苦,你却能做得如此快乐,有哪些经验可以分享?

流程比补位更重要,方法比拼命更重要。UPYUN运维团队只有3个人,但很早就做了流程规范和脚本处理,从最初几台到现在的五百台机器,再到将来的五千台、五万台也都是用同样的方式管理。国内很多公司对运维的认知度不高,导致业务量上去之后,用堆机器的方式快速抢占市场,运维也只能靠人力堆,24小时待命,事后救火,自然会觉得辛苦。

运维想做得轻松,首先要做到自动化,其次是监控常态化,然后是性能可视化。服务器不会无缘无故出问题,犯病之前肯定有征兆。用监控系统做连续的健康检查,会很容易发现故障触发原因。新出现的问题要及时增加监控数据,例如一台机器上发现CPU过热报警,处理后会监控所有的机器是否有CPU过热的情况。

自动化做好之后,再也不怕频繁部署,而且排查问题变得非常轻松。批量上架10台机器,其中9台没问题,1台有问题,那肯定是硬件问题,因为都是跑的同一个脚本,通过人海战术部署就无法这么快定位。还有个例子,有段时间我们发现某两个机房的表现不一样,因为程序是统一的,把正常运作的机房的程序拷过来,在表现有问题的那个机房机器上重新配置生成一下,如果问题仍然存在,那么一定是机房的原因。自动化的工具和流程可以最大程度地把人和机器隔离开,减少犯错误的机会,快速定位问题。

运维自动化不只是为了帮运维工程师节省精力,更重要是实现整个系统的可扩展性,这也是BOSS最关心的。如果某个节点随时可以摘掉,运维工程师就没必要24小时待命,要是不能摘,一旦出问题,哪怕是三更半夜也得爬起来。要做到良好的可扩展性,需要运维工程师从架构上去设计它。eBay的工程师曾说过,做任何架构都要考虑一个问题:如果负载扩大10倍怎么办?架构的扩展性一定要从系统设计之初开始做。当然,不是说一开始就要考虑架构扩到100倍怎么办,要用进化的思想去看架构,分阶段进行容量规划。运维工程师虽然不怎么写程序,但是他们接触了许多非常优秀的软件,如Apache、Nginx、LVS等,好的运维工程师一定有好的分布式理念。

所有这一切想实现,前提是要做好时间管理。当你忙得像狗一样,没有留下时间思考,就没有机会去深入细节。有时间以后,就可以去做工作上的优化,包括工具的使用、流程的优化、执行结果的监控等,还可以考虑人员的互备和管理。这一切都是环环相扣的,只有把细节封装好了才能在时间、资源、和人员上做到衔接。

  • 技术人攻略:运维做得这么好,一定和你过去的经历有很大关系吧?

我运维能做得这么High的前提是对Linux真的很了解。大学时机缘巧合,同学的表哥从美国回来,告诉我们Linux很火。当时对未来没有明确方向,没有别的选择,就对准Linux这个方向努力。四年里看了大量UNIX的书,做了大量实验,包括编译内核尝鲜。在大学里已经把系统管理员、网络管理员的基础打扎实了。

2002年毕业后找的第一份工作是在广州一家数据中心做系统管理员,主要做基础运维,帮助客户调试机器和上架。那时候服务器很少,就算在数据中心,一个月才会有一、二十台机器进来。03年回了杭州,做过计算机老师兼网管,但心里还是割舍不下对Linux的这一份热爱,于是加入浙大网络,接触到应用运维,并认识了现在UPYUN的创始人。

04年我去了台湾威盛,开始做嵌入式Linux系统。在这家公司待了5年多,不仅让我重新认识了Linux,并且拓宽了职业生涯。做到第3年的时候我感觉遇到了瓶颈,一方面不想放弃技术,另一方面又想了解客户和外面的世界。迷茫的我当时向公司总裁请教人生的规划,他曾是3COM前30位员工,在他的建议下我转做售前技术支持。原以为工程师比技术支持牛,但后来才发现技术支持很锻炼人,不仅要懂技术,还要懂表达,考验现场发挥和感染力。通过写大量的方案,还锻炼了写作能力。

做了两年技术支持后,被公司提升到技术管理岗。一开始不懂管理,工作分不下去,我自己也做得很累。于是又去找总裁聊天,才发现我保护下属的做法其实是害了别人不能成长,而自己也成了公司的天花板。好的管理者应该做托板,把下面的人托上来。明白了这个道理之后,我改变了策略,把手头的工作整理成WiKi文档,交给下面的人去执行。多出来的时间用来跟踪新技术,做前瞻性的研究,并且把学到的东西分享给大家,帮助下面的人快速进步。

常有人问我,你把知识都分享出去了,会不会担心被取代。我个人认为这种担心大可不必,丰富的经验和阅历是偷不走的。纸上得来终觉浅,绝知此事要躬行,我分享自己思考后的结果,别人想倒推我思考的过程仍然需要经验。就像大家每天都在吃饭,可为什么只有一小部分人成为美食家呢?因为这些人会用心去思考,深入进去,方能总结一些门道出来。一个真正的强者,不是摆平了多少人,而是看他能够帮助多少人。我的从业经历也证明,如果把事情做得漂亮,不让自己成为公司的瓶颈,反而会获得更多信任,就算离开依然互相尊重和感激,甚至在以后的人生路上,遇到困难别人也会帮助你。

  • 技术人攻略:你过去一直在嵌入式领域发展,为什么会选择进入互联网行业?

互联网蓬勃发展起来以后,围绕Linux出现了很多创新的技术,我骨子里对互联网很憧憬。嵌入式Linux做的往往是实体产品,对性能、并发性没有考量,所以体会不到Linux在互联网如火如荼情况下的那种威力。我很向往操纵成百上千台机器的感觉。2010年加入了国内较大的一家在线客服系统,对实时性,大并发要求很高。那时的工作是重新设计架构,提升性能,最后用原来一半的机器实现了同样的业务负载,但却离我最初想操控成百上千台机器的梦想有点偏差。公司的业务规模无法让我完全施展自己的才华,于是重新做了选择。

那时在凤凰古镇待了两个礼拜,想自己未来的方向。98年选择Linux,是听了前辈的建议,这条路是选对了。工作多年以后,有了自己的阅历,就要结合自己的思考,去想未来在哪里。思考的出发点其一是兴趣爱好,其二是找到自己的自豪感来自哪里。我一直认为运维工程师就是让Linux跳舞的人,当我操纵几百台机器,整齐划一地做一件事情,那种感觉特别棒。

我想清楚了自己未来的方向是做云上的运维,选择加入UPYUN有几个原因,一是可以实现我操纵几百、几千台机器的梦想;二是我过去帮别人做架构的项目,都转向了阿里云,我意识到云的发展一定会给传统运维带来打击;三是我比较擅长做业务的抽象和自动化,对DevOps有自己的想法;再加上UPYUN几位创始人都是浙大网络的同事,在正式加入UPYUN之前,我就以顾问的角色帮他们解决运维和架构上的问题,彼此之间很信任。如果凭个人能力,可能要等到四五十岁才能出来创业,但寻找到志同道合的人,大家能力互补,就可以在年轻的时候去追寻自己的梦想。

  • 技术人攻略:云计算领域竞争激烈,你怎么看待UPYUN专注的云存储市场?

UPYUN提供静态文件的存储和CDN加速服务。单从CDN来说,有老牌的网宿和蓝汛;单从后端存储来说,网盘大战早已白热化了。为什么UPYUN能在夹缝中生存,因为我们走了一条服务路线。网宿、蓝讯只做CDN,不做后端存储;网盘只做存储,但目标是做用户的大数据分析,不会为网站做加速。UPYUN将存储和加速结合起来,企业不需要利用多套架构,把东西放在网盘上,再找网宿和蓝讯去加速。单从CDN角度来说,网宿和蓝讯的带宽是混合模式,包括了视频点播、流媒体等服务,导致高峰期带宽特别拥堵。而UPYUN是针对网站和移动应用的静态资源做存储、处理和分发加速,目标人群高度统一,应用类型有很多共通性,高峰期不会出现严重的带宽冲突。

UPYUN早期的创业方向是做图床网站又拍网,在图片领域有着7、8年技术积累。比起大而全,我们更擅长做小而美的事,同时也和专业的第三方公司合作,例如DNSPod,Takling
Data等。我们的理念是,行业之间要抱团,专业的事交给专业的人做,不然大家都在浪费时间和精力,还要提防被BAT干掉。

  • 技术人攻略:你怎么看待DevOps,运维和开发的关系应该怎样平衡?

DevOps国内大家提得多,用得少。难度在于思路上的转换,运维自动化是一个结果,要做到这一点,首先需要抽象业务模型。以业务软件性能监控为例,如果软件工程师在程序中插入很多的钩子或探针,就可以统计出数据来,不需要运维费心监控;软件工程师在设计程序的时候,考虑到了分库分表,考虑到了大并发和分布式的设计,运维就可以水平扩展机器。开源软件但凡名气大的,程序日志信息非常详尽,可以通过标准的syslog或者日志去监控。但根据我接触的大多公司和工程师的情况,大家都忙于实现业务功能,连个文档甚至注释都不愿意写,更别提能够考虑这么周全了(UPYUN团队这方面做得不错),所以才需要做运维的去补位、去优化流程。运维苦逼的公司,软件工程师也幸福不到哪里去,这种负能量是相互传递的。

至于是开发人员学会运维,还是运维人员学会开发,在我看来是殊途同归。高级软件工程师会测试自己的程序,知道性能指标是什么情况,但如果正好遇上一个三流的运维工程师,程序性能上不去,那么这个软件工程师可能会自己去找原因,这样他就做了运维工程师的工作。另一种情况,一个三流软件工程师的程序到了我手里,因为已经做了性能监控,第一时间就知道程序跑得好不好,如果程序出现死循环或者内存泄露,我会告诉这位工程师程序有bug。但如果软件工程师很忙,那么我就要去把这个bug查出来。自己的修炼功底很重要,其次是要去寻找小伙伴,发现问题的时候如果能坐下来互相学习和探索,就能学到更多知识。

我们现在运维做得很好,可以倒逼开发,让他们加快新业务模型的开发,让公司加快业务增长速度,因为再上一百台、一千台机器都是分分钟的事情。运维人员的强势,是要通情达理,站在全局的角度上,才能说程序员想听的话,说老板听得懂的话。我加入UPYUN之后,一方面做了很多内部分享,把我的理念毫无保留地告诉大家,帮助大家提升工作的效率。另外用实际行动把运维自动化、标准化做出来,去年花了三个月做嵌入式Linux原型,一个半月测试稳定性,然后用一台新机器放到集群里,性能监控发现新架构的机器响应、负载都有很大提升,然后就开始逐渐推广更新。

  • 技术人攻略:运维领域有什么新趋势?

虚拟化会越来越大行其道。现在运维能够让几百台机器跳舞,但还不能让几百个应用跳舞。举个例子,做日志分析的Hadoop集群晚上启动,而音频处理或Python服务器白天会吃紧。要平衡物理机器上的资源利用率,只有依靠虚拟化,让同样的机器在白天变成Python服务器,晚上变成Hadoop服务器。我们打算采用Docker做虚拟化,这个技术去年才诞生,但业界已有相当多公司对它抱有很大兴趣。

运维工程师有必要学一门能打通前后端的语言,如Node.js加Python。未来的应用会越来越轻,后端放在云里,前端是个浏览器。要从两个角度去思考这个问题,首先JavaScript是唯一的浏览器原生语言,世界上几十亿的设备都在运行浏览器的时候,想想看它有多么重要。其次,前端用浏览器这样轻巧的东西,后端必须有云的支持,这决定了运维人的职业生涯应该往云端靠。往云端靠有几个途径,作为开发者要了解BAT之类的开发平台,或者是加入做云的公司,去做云上的运维和云上的开发。JavaScript会越来越大行其道,学一门能打通前后端的语言,能获得最高的学习效率。

  • 技术人攻略:能不能给新人一些学习Linux的建议?

任何技术都是竞技活,一定要多做、多练。我自己学Linux的时候是什么都玩,一开始的时候装系统、装Apache环境、装MySQL,也用PHP写论坛,聊天室程序,踏踏实实做个完整的项目就是最好的锻炼。印象最深的就是2001年那会,编译内核加入了对reiserfs和ext3文件系统的支持,那时的2.4内核可以裁剪到500KB,太有趣了。到了大四那年出来个Soft
Raid,我们又开始编译,硬盘不够就从同学的机器上拆出来一个硬盘,用两块硬盘组成阵列做实验。

学习过程中不能老是跟着别人的脚步走,要有自己的思考,才能发明新东西。所谓的技术难题就是对未知的茫然,任何你不知道的东西都觉得是天大的东西,捅破了就明白了,但关键是这个捅的过程,是自己捅、还是别人捅。如果遇到问题就搜索,对别人总结出来的方法不加思考地应用,很可能会影响自己的思考和成长。我们那时没有这么发达的网络,也没有那么多的教材,很多东西都是要自己反复做实验,调参数,然后走在路上、吃饭时、睡觉时思考琢磨才能整明白。现在条件这么好,我不反对凡事上网搜索,但一定要做好笔记,整理心得,要真正转化成自己理解的内在的东西。这跟古人的“学而不思则罔,思而不学则殆”是一个道理。

多看书,看好书,如何看书也很重要,要学会查漏补缺,细品慢琢磨,我个人建议不光技术书,还有情商、管理、哲学的书都要看,做人一定要文艺(我喜欢读《泰戈尔诗选》《明朝的那些事》)。少抱怨,要懂得感恩和回馈,这样人生才是精彩的。有机会尽多参加甚至组织开源活动,锻炼自己的口才和交际能力,“教”是最好的”学”。经营好自己的影响力,可以交到更多的朋友。推荐看《禅》道和《了凡四训》

《UNIX编程艺术》这本书要重点推荐,我做了很多年总结出来的东西,人家30年前就总结出来了。里面提到的“模块原则”、“分离原则”、“吝啬原则”、“生成原则”、“扩展原则”,还有很多先进的理念都让人叹为观止。如果想要对Linux本质有深入理解,推荐去打造一个自己的Linux版本。有个开源项目叫LFS(厨房里的Linux),给你一本菜谱,告诉你打造Linux需要哪些软件,可以照着这本菜谱把Linux从头到尾编译一下。此外,我们还要学会时间管理(不要告诉我你都会利用好时间),推荐《暗时间》和《把时间当作朋友》。

一定要找到自己学习的动力是什么,我招聘新人的时候对个人技能看得不重,更关心他的动力和热情来自于什么地方。在威盛的时候曾招聘过一个高中生,他之前因为贪玩没考上大学,知道生活的艰辛后开始学Linux。公司原来从没招聘过高中生,他进来之后非常努力,成长非常快。我在他身上看到一点自己的影子,高中一开始我成绩不错,以为凭着聪明就可以轻松学得不错,直到高三才明白,原来那些表面上的天才背后都下了功夫。那个黑色的七月给了我很多教训,我再也不认为自己是天才,而明白了要靠脚踏实地努力才能得到自己想要的东西。人在历过挫折以后,能够爆发出的能量是很惊人的。

人生就是一场修行,我们都是半杯水,这才有了人生存在的意义。不自卑,不骄傲,寻找互补,越努力,越幸运,做最好的自己!


技术人攻略访谈是关于技术人生活和成长的系列访问,欢迎和我们有共同价值观的你关注“技术人攻略”,邮箱
devlevelup@gmail.com,新浪微博
@devlevelup,希望能成为技术人成长的精神家园。
欢迎通过微信公众账号关注技术人攻略
请输入图片描述

感谢:  

感谢SegmentFault提供博客专栏及推广支持。
感谢迅达云成提供云主机及技术支持。

原文

http://segmentfault.com/a/1190000000464916

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

联系我们|手机版|欧卡2中国 ( 湘ICP备11020288号-1 )

GMT+8, 2024-11-25 11:57 , Processed in 0.051025 second(s), 13 queries , Redis On.

Powered by Discuz! X3.4

Copyright © 2001-2023, Tencent Cloud.

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