RE演进之路展示

RE演进之路展示

RE演进之路

手工时代

云基础设施

跑在云上的一个好处是把底层主机和网络抽象化，相当于云平台将主机创建、网络策略修改等封装到相应的系统内，对用户提供统一的平台接口。我们在做维护的时候，就能把之前很复杂的流程串连起来。也是在此时，SRE团队初步成立，我们对整个运维相关的工作做了拆分。云计算部分（由美团云负责）主要负责主机、网络，还有系统相关的；SRE对接业务侧，负责机器的环境、业务侧的架构优化以及业务侧相关问题的处理。

问题＆解决方案

接下来介绍一下我们在做云基础建设的过程中，遇到的问题和一些解决方案。

针对这个问题，我们做了两点，一个是对所有的网络资源都做了隔离，针对每个VM作相应的配额，另外一个是针对业务特性将宿主集群做了拆分。离线业务，它不考虑CPU的竞争，各个业务对于所部署服务的具体响应时间不是很关注，只要能在一个允许的时间段内把业务跑完就可以了，我们把这些服务单独的放在了一个离线集群。在线业务，根据不同业务的重要程度，又划分成了多个小集群。

第二个问题就是VM打散，这个问题初期的时候暴露得并不是很明显，当时整个线上的业务还没有做细致的服务化拆分，服务都部署在一个大集群内，这种情况下即使VM没有打散（同一个服务的多个VM在同一个宿主），某一个宿主挂掉，影响也不是很大。但是随着业务的变化发展，再做服务化拆分之后，线上的服务基本上没有几百台做成一个大集群的情况，都是十几台，或者几十台这种小集群。

如果我们有一个10台VM的服务，其中5台在一个宿主上，那么这个宿主一旦挂掉，服务整体的承载能力就砍掉了一半，风险很高，高峰期如果掉一半，这个业务就瘫痪不可用了。针对这个问题，SRE团队跟云计算的同学做了一个持续了半年多的优化，将VM打散率控制到了90%以上，最终在同一个宿主上，同一个服务，不会多于两台VM。

第三个问题，完善调度成功率。经过SRE和云计算同学的合作努力，现在的成功率已经达到了3个9左右。

c基础设施架构

上图是我们云计算基础设施网络相关的架构图，可以看到上面是公网的入口，流量接入大部分都是走的BGP链路。往下是多机房间的高速专线，专线的稳定性经历了线上大规模业务的校验，像外卖、团购、酒旅等，都是做多机房部署的。

另外就是高冗余的网络架构，基本上每个节点都有一个冗余设备，能保证在其中一台设备出现问题的时候，整个流量不受影响。入口和出口接入了一些自研的组件，像MGW、NAT等，使我们对流量的管控变的更灵活。

运维自动化

随着订单量和机器数的高速增长，为了更高效的运维，我们不得不往自动化的方向发展。

在自动化演进的过程中，我们总结出了自己的一套方法论。

复杂的事情简单化。比如引入云平台，基础设备管理都通过云平台的系统来做，把底层相关的东西全部封装，最终暴露给我们的就是接口或Web界面。

简单的事情标准化。如果你想做流程或者自动化，没有一个统一标准的话，你要考虑的点就会很多。所以我们在主机、域名等资源的命名、系统基础环境、上下线操作等方面，出了很多的标准，这些标准经历线上的实践打磨最终形成统一的规范。等标准都成型之后，我们再引入流程，比如创建一些机器，我会列出需要的操作，然后根据标准来做SOP，先流程化再自动化。我们通过代码把手工的工作释放掉，最终达到了一个自动化的水准。

上图是我们创建机器的一个简单流程，首先由技术人员发起流程，然后到流程中心，流程中心从服务树获取服务的基础信息，然后将信息发送到运维平台，运维平台根据这些信息去云平台创建机器。

之后云平台会返回到运维平台，运维平台将创建好的机器加到流程中心提供的服务节点下，同时调用配置管理系统对机器进行环境初始化，初始化完成后会自动添加基础监控信息。之后调用部署系统，对服务进行部署。部署之后，服务根据它的服务的标签，最终注册到服务治理平台，然后就能提供线上服务了。相当于只要技术人员发起，整个流程都是能自动完成的。

自动化这块就简单介绍这些，下面介绍一下目前的现状。

数据运营

如上图所示，现如今公司规模变得很大，我们对此做了一些相应的拆分，图中红色的部分全部由云平台来负责，从最初的接入层到底层的一些基础设施，比如机房、网络、主机，全部由云平台来封装。中间又拆封了一层，这一层是由SRE来负责。

现在流程系统已经做得比较完善了，接下来我们新的探索目标就是数据运营这块。首先是故障管理，针对线上故障做一个统一管理，包括故障发生的时间、起因、负责人，根据它的严重程度，分为不同的故障等级。我们也会针对故障的后续改进持续跟进优化，保证每一个TODO都能落实。

另外一点，通过故障平台我们对所有的故障进行汇总，系统能根据汇总的信息对不同的故障进行分类，也能总结出我们线上不同故障类型的占比，进而做一些定点的突破。

在故障管理之后，我们又做了一些数据挖掘相关的工作，在初期，我们运维的数据主要来自于监控平台或者是业务主动上报，而在现在这个阶段，我们会主动挖掘一些信息，比如线上服务的请求量、响应时间等来做一些定向的分析。

职责&使命

如上图所示，我们的使命从最开始的变更与救火，到现在已经逐渐转变为防火与驱动变革。通过数据运营，我们能反向的驱动业务。工作核心是稳定性，这一点一直没变。

我们可以把运维理解为运营维护，运营是指通过经验积累、数据分析，推动整体服务质量的改进；维护是针对线上的服务，还有业务的需求，我们能够用专业的技术来满足他们。

下面讲一下在稳定性保障方面的实践。

业务稳定性保障实践

故障起因&实例

首先，我们来总结下故障的起因，同时举一些例子来说明具体的情况。

① 变更。美团点评线上服务的日常发版超过300次，另外还有一些运维的基础变更，包括网络、服务组件等。举个例子，线下做变更的时候，我们写一个简单的Nginx配置，如下图所示。

不过业务层在设计架构之初，应该考虑到网络不稳定的情况。针对上面的隐患，大概有三个方法。

第一个就是做全链路的演习，模拟一个真实的场景，经过模拟演习，还是多多少少能暴露出来一些问题。我们可以针对这些问题，去完善我们的故障预案、修复线上漏洞，做演习的时候也能验证我们的报警系统是否正常运转。

第二个是SLA，对于服务定一个比较严格的稳定性指标，并针对这个指标持续不断的优化。比如我们线上HTTP接入的服务，针对accesslog中的状态码和响应时间提炼出一个稳定性指标，这对于服务本身的稳定性情况，就多了一个可参考数值了。稳定性指标波动服务必然有问题，这时候我们就要针对它波动的点进行相应的分析，根据分析，最终能找到一些隐患。指标这块，要做到用真正的数据来反馈出线上的稳定性。

第三个就是做故障的管理，每个故障都能找到问题，TODO能落实，各个故障的经验总结，也能共享到多个业务线。

经验总结

事故之前（比如标准SOP、容量评估、流量压测）的核心就是要防范于未然。

事故之中的核心是快速止损，查找问题是一个相对来说难度比较大，也比较漫长的过程，因为这个时间是不可控的。但是如果我们提前有好的应急预案，就能达到快速的止损。此外，还要有服务的自我保护，还有一点，沟通也是很重要的。最开始出现问题的时候，其实是比较乱的，因为大家发现问题都很急，很多人都在问原因，这时候你问原因是没有用的，因为大家大部分是不知道，知道的话就能给出解决方案了。所以这时候需要一个完善的沟通机制，正确的时间反馈正确的消息，反馈的原则是少说表面现象，尽量说一些对于问题定位或者是对于止损方面能够有帮助的信息。

事故之后，像TODO落实、完善预案之类的，核心点就是吃一堑长一智，相同的问题不能发生第二次。

用户体验优化

首先从用户端开始，用户在访问我们线上业务的时候，流量是从公网到私有云，再到Server。公网问题主要有网络劫持、多运营商环境、不可控的公网链路等。对于Server的话，主要就是一些传输层的协议，或者应用层的协议的问题，目前大部分业务交互还是用的HTTP 1.0/1.1，其实HTTP这个协议也是需要改进的，它不太适合做频繁的业务交互。

针对这些问题，我们都做了一些尝试：

首先在公网接入这块启用BGP，我们现在已经做了自建的BGP网络，不用再关心多运营商接入的问题。只需要采用BGP网络，数据包在公网传输寻址的时候，就可以进行最优的选路了。

针对业务交互的协议，上线了SPDY协议，对于频繁交互的业务提升还是很明显的。目前正在测试HTTP 2.0，Server端对于HTTP 2.0的支持还存在少量bug，努力修复中，希望能早日用上。

未来展望

产品方面，我们现在做的所有工具，经过线上业务大规模的校验，正在往产品化的方向发展，希望能把它做成成型的产品，放在美团云上，能给美团云的用户提供服务。不只服务于我们自己，也服务于他人。

最后是技术架构，美团点评发展过程中一些疑难问题的解决方案，或者针对挑战的经验积累，经过线上大规模业务的校验，最终能形成一些成熟的方案，它能为美团云上的用户提供最前沿的技术参考。

云是大势所趋，它能把很多底层的问题封装起来，让我们有更多精力去做更重要的事情。