运维服务进化论

发布时间：2016-07-10 01:17:36

本文作者苗辉先生负责白山第一个产品线CDN-X的相关研发工作，带领团队在3个月内实现CDN-X系统从无到有，依靠独特的SHAQUE、MANTA、TUNA、DOLFIN技术和质量化运维体系取得平台4个月上量500G，90%以上客户PK第一名的成绩。

作为网络传输优化专家，苗辉先生在运营支撑与性能优化方面积累了丰富经验。2007年至2011年，就职于网宿，带领团队创建网宿科技CDN运营监控体系；2011年至2014年任百度架构师，负责百度自建CDN架构和服务质量的优化改进，自建CDN稳定性业内首达4个9，并成功承载百度搜索等80%的百度核心业务。

下文是苗辉先生对于质量化运维思考与实践的分享：

自动化运维的话题大家都已经很熟悉了。不过，正如世间万物一样，运维服务也处于不断进化之中。在白山云科技有限公司（简称“白山”）的团队看来，在如今云服务时代，相对于自动化运维，我们更需要质量化运维。

1. 再问运维的本质

作为从事运维工作的一员，大家可能深都有体会：运维同学很苦逼。

图片中天台上运维同学的压力并非来自于老板与同事，而是来自于图中没有画出来的客户！因为服务没做好，全公司都处在被动的境地，客户通过老板与同事把压力传达给了运维。

楼下的同事哪一个不苦逼，哪一个无压力？今天之所以站在天台上的是运维而不是别的角色，恰恰说明运维与服务质量关系最为重大。

要在这样的环境中做好运维，必须要明白运维的本质—— 做好服务才是运维的本质。

众所周知，服务是互联网行业的立足之本，云服务时代的到来，更是一切皆服务。在这个时代运维的方式也发生了改变。此时的运维与服务的关系更为直接，与最终用户的距离也前所未有的近。

有人说做好自动化运维，矛盾不就解决了吗。可是真的是这样吗？

举个例子，面对不可规避的宕机和网络问题，你开发了一个高水平的智能调度系统，它能够及时辨别各个IP的服务质量高低，并且你设立了一个阈值，如果低于客户要求，就会立即自动切走。这算是高级而精密的运维自动化系统了，可是这样一个运维自动化平台真的能让服务质量达到客户要求吗？很可能最终你发现调来调去你的服务质量就是达不到客户的要求，因为你的每个节点的服务质量就是这样了。

这个皮球可能被你暂时踢给了研发和产品，但这个球终究还是会回到你这里，并且会使你更加痛苦。因为整个平台的服务质量并没有提高。

2. 何为质量化运维

我们不仅需要能够提高效率、减少出错、消除故障的自动化运维，我们更需要以提高服务质量为核心的，涉及自动化、服务质量检测、快速的持续服务能力、客户有效沟通等诸多环节的质量化运维。

2. 何为质量化运维？

其实就是尽一切努力为客户提供更好的、符合要求的服务。这不仅是概念上的改变，更是平台架构和服务理念的革新。

运维。

当然，质量化的基础在于自动化。

自动化

自动化必须要做，没有自动化，保证服务质量就无从谈起。一家配置全部需要人肉登录服务器进行修改的公司，客户能放心使用它的服务吗？

快速定位与质量敏感体系

只有自动化远远不够，面对诸多用户反馈的各种质量问题，很多自动化工具无能为力。你还需要进行细节分析才能找到问题的根本。因此我们需要一个快速定位功能和质量敏感体系，让我们能够先于客户发现质量问题，并且快速找到问题所在。

透明化

很多时候客户对服务质量的评判手段跟你的并不相同。作为服务提供方，我们最了解服务质量内部的细微变动，而很多客户则会在若干小时之后才能用其自己的判断手段感受到。所以我们还需要一个透明化的机制，让客户和我们同步看到服务质量的细微变化。

3. 白山质量化运维实践

同其他互联网公司一样，在运维自动化方面，我们也投入了大量的精力。

上图是白山的运维自动化体系，大体分为三层：

1.内容管理数据库

以CMDB为核心，用以记录资源信息、资源状态、应用类型、客户信息、客户配置信息等核心基础数据；

2.资源层面

构建了自动扫描、自动监控、自动部署、自动配置和故障自动处理等小粒度自动化操作；

3.业务层面

在内部两层的基础上，结合流程引擎来实现业务层面自动化上包括：

1>资源管理自动化：节点的自动上下架、自动割接等；

2>服务管理自动化：服务开通自动化、服务终止自动化等；

3>服务质量调度自动化：根据每个IP当前服务质量来动态调度覆盖，持续保证稳定可用和高服务质量；

4>计费账单自动化：按不同客户要求自动统计出账单，并发送给客户。

我们在做自动化的过程中，有一个贯穿始终的原则

就是：适合的才是最好的。我们不怕重复造轮子，就怕轮子拿来用不上。

接下来我们通过举例来进一步介绍我们的运维自动化体系。

上图是我们的节点建设自动化流程图。

我们集成了设备自动扫描、软件自动部署、配置自动安装等业务层的自动化过程。

节点建设自动化是每家公司都在做的，并且许多公司已经做得比较完善，思路通常就是将节点建设过程中复杂的部分剥离给供应商，让供应商按要求装好系统，甚至把软件部署在服务器上，运维只需要下发配置就可启动。

但这对于创业公司来讲，是根本不可能的，原因很简单，供应商不愿陪你这样玩。以白山为例，我们单次采购量也就上百台服务器，我们采购的核心标准就两个：一是设备必须满足我们的要求；二是在入围供应商中选相对便宜的，这样对方自然不愿提供额外的自动化支持；另一方面，我们目前合作的供应商有数十家之多，在自动化方面分别管理协调供应商的成本远远高于自己实现的成本。于是我们设计了这个适用的节点建设的自动化流程，但是就解放运维生产力的角度来说已经足够。

启用该自动化流程之前，我们面对的是一堆零散的自动化脚本，需要一个运维同学用两个小时跟踪执行这些脚本。现在运维同学被解放出来了，只需要在平台规划好每台服务器的用途即可全自动完成，这个过程只需运维同学几分钟。

这样，我们就可以将运维人员的精力释放出来，转移到提高服务质量上。

白山第三版配置自动化架构可以分为如下部分：

以CMDB为核心，通过消息队列来进行配置文件生成与配置文件分发大交互。之所以演化三个版本最终这样设计，是为了解决实际运营中的痛点：

1. 高并发：平台要支持每分钟上百次的配置变更需求，而每次配置变更都将涉及上千台服务器上配置文件发布和生效；

2. 支持事务：对于客户提交的配置，发布途中客户发现语义错误需要撤回，平台要能立即回退所有已发布的配置；

3. 灰度发布：分批次灰度部署，配置自动化测试和监控将风险控制在最低。

目前我们所有客户通过portal自助修改的配置和运维同学通过后台修改的配置，其后台都是使用上述架构在支撑。

上图是我们全球智能调度系统DOLFIN的原理图。智能调度是服务质量的生命和大脑，目前我们是国内唯一一家将解析系统做到全球边缘化的公司。利用DOLFIN系统，实现了基于服务质量的调度，切换从原来的分钟级提升到秒级。（此架构去年我们的架构师符立佳已经进行了一次分享，大家可以关注白山官方微信baishancloud获取）

不过自动化运维还远远不够。做完自动化，质量化运维才刚刚开始。

自动化实现后，我们会发现客户的不满确实有所减少，但你还是无法完全避免。那我们是怎么解决的呢？

通常做法是查看监控系统找异常，审查日志找线索，复盘整个操作过程。在一个三层网络架构中，复盘过程可能会横跨3-4台服务器。这个过程少则30分钟，多则需要3-4天，有时可能更长。所以我们需要一个快速定位来解决这个痛苦的过程。

所谓天下武功唯快不破。客户并非不允许出问题，而是怕出现问题后解决速度慢。所以我们需要快速定位的功能来找到根本问题。

上图是快速定位的实现过程。

我们将以往的运维手工操作升级到了自动化。IDO打通了运营支撑的各个平台，将监控系统跟CMDB以及配置管理系统、日志系统、流程引擎等数据结合，针对不同场景快速在各平台中搜索匹配的监控数据或变更行为，在3分钟内定位问题。

这样已经很自动化了，定位质量问题也够快了，可这样还是一种被动响应，因为这样依然是“救火”的思维。

服务变差那客服损失的可是真金白银。有没有办法提前于客户发现质量问题呢？

因此，我们还建立了质量敏感体系。质量敏感体系建设的目标是先于客户发现服务质量问题。

如上图所示，我们进行了两个层面的建设。

首先，我们通过日志和网络层数据分析，结合外部平台监控，匹配客户对服务质量要求的算法，时时分析服务质量，一旦发现异常立即报警。

其次，我们梳理了与服务质量相关的高风险操作和基础故障，并以风险预警的方式发送给运维。

最开始，我们通过分析日志建模，模拟与用户同样的算法匹配服务质量的变化。但在分析过程中，我们发现日志其实是一个黑盒子。通过日志可以统计用户访问的状态码比例、成功率，但日志实际记录的只是用户请求到达及内容写入网卡缓冲的时间，而数据包则需要经历两个甚至更长的网络传输，以及至少五个缓冲区。

所以日志纪录了零毫秒，但客户实际感受到的可能是1s，内核偷走了你的时间。因此，对于小文件来说，发送计时永远不准确。

另外，以流媒体服务来说，用户非常关心首次缓冲时间，而日志记录的是用户访问播放流媒体的完整时间，无法获取首次缓冲时间。

为解决日志问题，我们实现了一个内核模块在四层进行完整的访问过程监控。从开始收到SYN包到整个TCP连接过程结束，可以实时监控到整个连接上的每一刻的丢包率、传输速率。基于此，我们可以得到小文件的传输所用时间。另外，对于流媒体的首次缓冲时间，同样可以通过近似的算法计算得出（例如计算第一个500K字节传输完毕的时间）。同时我们可以实时计算视频的播放码流，评判客户播放的服务质量。