转载

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

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

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

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

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

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

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

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

Geekbang：“能不能说一下白盒运维？”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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