BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Geekbang圆桌讨论:高效运维之路

| 作者 崔康 关注 1 他的粉丝 发布于 2015年6月19日. 估计阅读时间: 13 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

在最近举行的Geekbang科技日“高效运维”专场活动中,触控科技运维总监萧田国、腾讯互娱运营管理中心总监刘栖铜、环信首席架构师梁宇鹏、UnitedStack技术专家田双进行了圆桌讨论,就如何高效运维发表了自己的意见。

Geekbang:“我想知道在携程,知乎之类的事情发生以后,运维们在部署IDC机房的时候都会关注哪些参数或规格?”  

梁宇鹏:实际上来讲,在我们这边我们的技术改进是一直在持续进行的,并没有受到它事件的影响。我可以讲一下我们这边部署的话,你说的规格,我理解是云服务器底层的设施,因为我们使用的是云,也可能有基础设施这部分的工作,后面哪位聊一下就行了。我们正常的大部系统,今天我们讲运维成熟度模型,还没有服务,甚至工具化、自动化在完善的过程,这里没有太多跟大家分享的东西。 

刘栖铜:其实说实话,我到今天还不是很清楚说,咱们这次携程,知乎这个比较新还没有时间看,携程到底是什么原因,我今天还不是很清楚。但是就这个问题来看的话,我们以前可能有类似的例子,因为我们是自己的IDC,也是自己去部署,包括机器选型也是我们自己做,但是因为腾讯在底层这块专门有TEG这么一个团队专门去做底层的IDC包括网络这块。对于我们运维团队来讲,我们可能涉及到OS方面的参数的调整,可能以前我们也碰到过,因为系统参数造成我们的服务,比如进程数的瓶颈等等之类的,就是也碰到过这类的问题。

碰到这类问题,因为我们所有的环境设置都是服务器由TEG部署交付给我们,我们会把所有的环境设置做初始化,在那里面就会把问题的参数调整过来了,保证每一台拿过来的业务参数是最新的,都是吸取了之前的教训的。

当然回过头来,携程这次事件之后,其实我们也比较忐忑,我们也不知道原因,我们回过头查,包括我们的蓝鲸里面的发布系统里面的回馈机制,我们全部所有的业务都去核查了一遍,保证我们回退是有效的。因为携程这个事情我们之前听到很多传言,包括数据库的数据丢失,或者说因为发布系统造成所有的发布环境的数据全部被删除掉了,这种传言。我们针对这些传言在内部做了一些针对性的切合和梳理。        

萧田国:我们觉得本次5·27支付宝事件后,对大家而言会关注IDC上传目录,看看它是不是真的有这种可用的主备链路,而且我们这些在使用IDC,特别像网易,网易之前也出了一次很大的事故。同样我们最关注的,还是说是不是有两个或者三个机房互备的关键链路,而且保证机房链路是特别好的状态。这个可能是以后比以前更加关注的地方。

Geekbang:“能不能说一下白盒运维?”

田双:白盒运维我觉得从两方面入手:一个是首先开发人员会要求提供更多的监控参数,然后这样的话,会更早地发现这个问题。可能从运维角度讲的话,多去了解用户的需求,多去了解开发的需求,尽量把这个纽带建起来,尽量地加上更多可能的报警。        

Geekbang:做公有云的,云平台有很多告警机制,比如发现问题的时候,会发短信、打电话各种告警,但是发现问题了怎么处理? 

田双:首先看一下是什么问题,客户业务放在我们这边,我们能感觉到,只是说我们的主机问题,主要还是硬件方面的问题。因为我们是看不到用户到底在跑什么业务的,我们只能说是会给用户定一个级别,说什么样的级别会用什么样的响应速度,通过什么样的报警方式去通知用户。我们只能告诉他们说,这个服务现在大概到了什么样的状态,比如说存储用的已经达到报警预值了,或者内存跟历史来比的话不太正常,我们只能通过这种方式告知用户。        

萧田国:一般我们提出的都是黑盒测试,白盒测试,白盒运维反正我听的不太多。我觉得说明的白盒运维,应该是说开发人员,研发人员试图更多的要对运维进行了解。既然想更多运维的话你就去学呗。基本的Linux,特别是以后当很多部署是基于docker的时候,你自然也要去学各种东西。甚至有人建议,以后的系统的迁移,你从当前的虚拟机或者说物理机上迁上去,这个操作应该由开发部门去做的。 

Geekbang:是不是大多数生产环境都跑在云上,虚拟机上,docker上,而跑在物理机上相对越来越少,或者说你们公司的情况怎么样的?       

萧田国:对一般公司而言的话,它还是有大量的核心业务是跑在物理机上的,那些新的业务和以前的业务并没有耦合,这个时候会选择云,不管是私有云还是公有云也好。        

Geekbang:你们在运维这些问题的时候,比如说你们自己开发可能会有哪些测试,或者哪些手段?客户用你的服务的时候你们会有哪些建议,你们是怎么做的?  

刘栖铜:首先白盒运维是第一次听到。我想白盒测试是不是不止是从程序外部来看,而是通过程序内部逻辑持续监控和及时发现问题点,可能是这样的概念。如果是这样的概念的话,在腾讯可能有两种方式:第一种,腾讯自研的业务,像互联网社群,它们的框架里面就已经包含了很多监测点,比如说有模块建调用的成功率,还有响应速度这些指标。这种就比较好去监测内部的逻辑。

还有互娱遇到的情况,像有些是代理的,代理的对我们来说是没有源码的,我们也不清楚里面具体的逻辑,因为开发商不会有完善的文档告诉我们逻辑。所以这里我们有接入标准,这里面有一部分叫做可运维性的评估。这个可运维性评估包含了,我们会要求说开发商开发的这些程序里面,在关键点上一定要有日志输出,我们通过这个日志输出检查内部的逻辑,是不是有故障,有问题,通过这样的方式去及时发现腾讯的问题点。        

Geekbang:像游戏用户分布到全国各地,你们有没有遇到跨区域出现的问题,你们有没有运维的解决方案? 

梁宇鹏:还是先理解一下白盒运维的事情。我理解黑盒运维,可能是说运维不知道在干什么,它只知道是否在运行。白盒运维的时候,可能你需要知道这个程序到底在干什么,然后它的每一步对资源的消耗是怎么样的。这里都称运维了,为什么分白盒和黑盒呢?我觉得这是一个理念问题。在我们这里推行的理念是开发人员接触的服务器部署越多越好。

刚才说可运维性,这个是慢慢提高的过程,如果你发现这个问题要解决就把它完善,工具化,后面的运维就可以操作了。我们这边的原则,是只要开发能登上服务器,进行一些操作,操作完一遍之后,剩下的事情就是运维的了。不管我是去连到一台虚拟机上,写了几行代码也好,还是我直接通过一个Rest接口调一下这个服务,只要我开发能到机上去做,剩下的第二遍,第三遍就是运维的事情了。

从这个角度来讲,可能我们不要界定自己能做什么,不能做什么,或者非要说清楚,这个到底是白盒还是黑盒?我们还是回到我们最开始的,作为一个技术团队整体地来思考,只有这部分跟运维相关就做,跟开发相关的就开发做,我倒不太区分白盒还是黑盒。  

Geekbang:“什么情况下或者怎么才能避免出现像携程这样的,因为携程官方发布的是误操作。他说怎么避免这个误操作的发生?”

梁宇鹏:误操作,刚才举的例子,大家都会遇到很多,各种误操作。我这边觉得只要是人就会误操作,你能做的事情就是让它工具化,没必要的人不要上去。你要看日志,我日志搜集起来给你,剩下的事,正常来讲都不应该需要更多的人来参与,首先把人数降到最低。如果你真要上去,那就是工具的问题了。当然刘总上升到更高的高度了,工具的问题等会儿他会介绍,我就不说了。        

刘栖铜:梁总说的很对,对于误操作,我们尽量让少的人操作,这样风险就越少。就像梁总说的是人都会有误操作,即使有工具,就算工具简单到在里面填一个数字,比如填200,我不小心打成2000了,这个都可能出现比较严重的后果。对于这种情况怎么规避呢?

当我们已经工具化的时候,对于这种还可能出现的误操作,我们采取的措施是:刚才权限说了,这是最基础的,除了这个之外,第一,我们操作还有一些超限监测,当监测到是超限,非常不合理的时候可以拒绝这个指令,把问题反馈过来,这个就是避免非常严重的后果。当然这个超限还是会有一定的范围,比如我刚好打错了没有超限,这个时候怎么办呢?

我们想还是从人的层面解决问题,当然不是让人审批,像我们在蓝鲸里有一个防误操作,这里面说起来很简单,比如说我们要求所有的关键操作的输入,一定要有输入框的弹出确认的,而且这个输入框弹出确认是有时间限制的。而且输入框按纽的位置还会颠倒。就是当你输这些数字的时候,会要求你二次确认,大家知道二次确认很多时候都是一点就去了,都不会看看,我们是说通过系统的设置,强制操作人能看以下自己的这个操作是不是有效。    

当然,还有一种,就是两个人同时确认才能进行操作。这种我们用的非常少,这种除非是非常非常关键的那些我们才会用,因为这种会严重的增加我们的投入成本,降低我们的效率。这种双人确认的机制,在某些关键场景我们也会用。所以我们是这几种方式,减少误操作出现的几率的。    

当然我觉得误操作不能避免,这是系统性的事情,除了刚才说除了工具层面解决,还有刚才说的人员层面。所以我刚才在分享的时候有篇幅比较多的讲,说我们对人为失误的低容忍,这就是为了,首先做运维,至少我们自己要有一个比较强的意识,就是人为失误,我们尽量从意识上规避。当然我们也理解,每个人都有打瞌睡的时候,所以在系统上尽量减少措施。        

萧田国:这个观点在我刚才的演讲里都有,再讲一下,误操作有两类,一类是真的误操作,是无意的。像这些用刚刚说的,有一些权限,校验,或者两个人检查去做是可以的。但是还有一种误操作是有意的,或者说他就不爽了,有一个老大哥跟我说过,运维是需要关怀的群体。如果你有意误操作,让你整个系统都没有的话,你怎么办?你唯一的只能是多给这些员工一些关怀,不要让他走极端的事情。       

Geekbang:之前做程序开发,可能是为了防止误操作,会写很多类,很多库,和API,像青云上也放了很多API,这个规范的目的就是为了防止误操作,所以我想问一下,从原来田双你们的角度,因为你是做公有云的,对客户遇到这种问题的时候你们会有哪些建议?        

田双:误操作大家确实都遇到过,就像刚才几位老师讲到的,我们只能尽力去避免,然后我们这边能做的不多吧。     

Geekbang:就是说在云不上开发东西,像环信做的SAAS层的,像就开放一些API,能不能避免这种误操作?        

梁宇鹏:我举个例子,我们是用云服务的,但是我们的负载均衡也是服务,负载均衡的权重调整可能会有这样的问题,如果在你们实现负载均衡权重API时是不是有限制?还有不是怎么做呢?        

田双:负载均衡这方面,我觉得软件层面的限制,像配置方面限制的话,这个可能跟各个业务有关系吧,只是说我们如果要做的话,只是会提供一个模板,具体到底怎么限制,包括权重要做一个人为限制的话,我们应该只能提供的是一个模板。    

Geekbang的微信号是geekbang01,读者也可以扫描下方二维码来关注。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT