美团外卖系统架构演进与稳定性的探索

“相信大部分人都用过美团外卖，尤为是在天天的两个吃饭的高峰期。美团外卖从创业到如今经历了数次的迭代，不断的适应需求，提供更好的体验。本文是美团外卖架构师曹振团在ArchSummit 2016 深圳站上的分享。老司机简介

曹振团，美团外卖技术专家/架构师，目前负责美团外卖业务系统的架构设计及优化工做。2013年加入美团，早期参与了多个创新业务的探索。经历了美团外卖从无到有的创业过程，以及业务快速发展的高增加期，积累了丰富的从0到1业务系统的架构设计和优化经验。加入美团以前，在网易网站部工做，负 责后台服务的设计和开发工做，拥有丰富的高并发系统的架构设计和实战经验。

本视频时长39分，建议在Wifi环境下观看。

技术体系架构演进

简单介绍一下外卖如今的状况：咱们从2013年10月份作外卖的事情，是从餐饮外卖开始的。通过两年多的发展，咱们不光能够提供餐饮外卖，也能够提供水果、鲜花、蛋糕、下午茶甚至是超市和便利店一些外送的服务。咱们作外卖过程当中，咱们发现用户对外送的体验有两个关注点：

1. 第一个是品质，用户对品质要求很是高，送过来的饭不能凉了，不能很差看，送餐员身上脏兮兮也不行会影响食欲的；

2. 另一个关注点要准时，必定要按时间送到，好比我要求按12点送到就必定要按12点送到，不能早也不能晚，若是早为何很差呢？11点40送到不行，咱们正在跟老板开会，一会一个电话太烦了；12点20送来也不行，太饿了，我都饿晕了，中午也有不少的安排，吃完饭可能要睡一会，中午不睡下午崩溃呀。

咱们发现若是要把用户体验作到极致的话，作得足够好能保证用户获得足够好的体验，咱们就要作专送的服务。因此咱们正在作的是美团外卖的平台和咱们本身的配送服务。

咱们从2013年10月份确立作这个事情，到11月份正式上线，到14年末11月份时突破日订单一百万单，15年的5月份大概突破了天天两百万单，而后大概15年12月份作到天天三百万单，今年5月份的时候咱们作到了四百万单天天。咱们但愿在响应国家大的号召下，咱们作供给侧改革。咱们但愿给你们提供更多的、优质的、可选的外送服务，但愿将来的某一天作到天天1000万单。

介绍一下咱们的业务，也介绍一下在作这个业务过程当中技术架构的演进的历程。咱们在开始作外卖的时候发现，那时候都是经过电话来点外卖的，小餐馆的老板发传单，咱们用传单上的电话给老板打电话下单。咱们在思考咱们是否是能够把电话点餐的事情变成网络点餐，让用户只须要在网络上点点点就好了，不用打电话。

因而咱们在公司周围的商家摸索这个事情，咱们早上下了地铁在地铁口发传单。咱们怎么可以最快地去验证这个事情是否可行？

咱们提供了一个很是简单的Web版本和Android的App，对于商家那一边咱们没有提供任何软件的服务，用户在咱们平台里下单之后，咱们再打电话给商家下单，有时候咱们是发传单的，有时候咱们是接线员，用户在咱们平台上下单，咱们再打电话给商家下单，而后再去写代码。那时候基本上没有太多架构考虑，就是怎么快怎么来，以最快的速度去把咱们的功能给变上去。

这个事情咱们验证以后发现确实可行，咱们发现“懒”是极大的需求。由于懒得去换台，因此发明了遥控器，懒得爬楼梯就发明了电梯，人都是很懒的，由于懒得打电话订餐，因此在网上点点点就行了。

咱们发现这是极强的需求，因而咱们就考虑规模化，由于只有规模化以后边际的成本才能够变低，这套软件在一个区域能够用，在一个城市能够用、在全国也能够用，咱们的开发成本就是这么多，因此咱们在尝试在作规模化。

这个过程爆发性产生了很是多系统，咱们在用户这边提供各类APP，商家这一边咱们也开始提供服务。咱们给商家提供PC的版本、App版本，还给商家提供打印机。

打印机是跟咱们后台是联网的，若是用户在咱们平台上下单，咱们会直接推送到这个打印机上，这个打印机能够直接打出单子，同时能够用林志玲或者郭德纲的声音告诉你：“你有美团外卖的订单请及时处理”，这是对商家很是好的效率提高；同时咱们给自身运营的系统加了不少功能，咱们有上单、审核等各类各样的系统等爆发性地产生了。

在这个阶段咱们业务发展特别快致使咱们堆了特别多的系统，这个时候也并无作很是清晰的架构，就是想把这个系统尽快地提供上线。这时候全部的表都在一个数据库里，你们都对这件事情很是熟悉，我能够作订单，也能够作管理系统。

可是这个事情在规模化、用户量迅速上升以后给咱们带来很是大的困扰，由于以前咱们是有不少技术欠债的，在这个阶段里面咱们就作了重大的架构调整，在这个调整里主要说两点：

1. 第一点就是拆

   咱们把不少耦合在一块儿的服务作服务化拆分，服务与服务之间经过接口来调用和访问，服务本身保护本身的库：不能访问别人的库，不然叫出轨；你的数据库也不能被别人访问，不然叫绿帽子。

2. 第二点是中间件

   咱们在这个阶段引进了不少中间件，包括了在开源基础上自研的KV系统，咱们也引用了搜索Elasticsearch，咱们经过Databus抓取数据库的变动，把数据库的实时变动刷到缓存和索引里，让这个中间件作到稳定可靠的服务。

总结一下的话，咱们的演进大概分了这样一个阶段：总体上有一个多逻辑耦合在一块儿的状况按服务化拆分出来，每个服务独立专一地作一个事情，而后咱们再作应用级的容错，到如今咱们在作多机房的容错。

在缓存上，咱们早期使用了Redis，在Redis Cluster还没发布以前咱们用了他们的Alpha版本，固然也踩了不少坑。后来咱们用了自研的KV系统，最先的时候咱们把全部业务的KV都是共用的，这个也有很大的问题：若是全部的业务共用的KV集群，其中某一个业务致使这个KV集群有问题的话，全部的业务都受影响。后来咱们也作了每个业务拆分本身专用的KV集群。

在数据库这一层上，基本上是把一些大表的查询、对数据库有较大伤害的查询变成了高级的搜索，在数据库和应用层之间加了中间件。

在360开源的Atlas基础上作了咱们本身的定制，这个中间件有个好处：咱们对数据库的变动对于业务层是透明的，好比说以为能力不够要扩容，咱们加几台从库，业务方是无感知的，并且咱们会作SQL的分组，即数据库的分组，哪些SQL到哪一个数据库上，到主库仍是从库上去，咱们业务是不用关心的。

遇到的挑战

下面介绍一下作外卖这个事情上遇到的挑战：

1. 第一个挑战，外卖这个事情具备一个典型的特色，就是汇集在中午和晚上两个吃饭的高峰期，这自然就是很是集中的秒杀的场景，由于你们会集中在11点10分到11点半去下单。咱们在高峰期的时候，有一分钟接进2万单的巨大流量；

2. 第二个挑战，你们理解送外卖是一个很简单的事情，我点了餐，送过来，我愉快的把它吃掉就结束了，可是作外卖的事情上咱们发现确实蛮复杂的，由于咱们发现用户要下单，要支付，咱们还要调度一个配送员，咱们找一个最快最合理的骑手，让他到时间取餐送过去，同时还要给这个骑手最好的路径规划，告诉他走这条路是最快的。因此整个是一个很是复杂的过程，有很是很是多的服务；

3. 另外，外卖仍是快速发展的阶段，对咱们的挑战是迭代太快了，你可能要频繁的发版，就有稳定性的风险，可能有Bug，可能有测试不全的状况。另外是项目周期短，业务发展很快有不少业务需求正在排队，架构优化的工做可能排不上去，甚至作技术架构设计的时候可能有一些折中，这是极大的隐患，咱们把它叫技术欠债。

   咱们有一个列表记录下来这些技术欠债，会记清楚说这是一个什么样的条件下作的方案，它在什么状况下可能会有哪些问题，须要在何时必须去作哪些事情；另一块在监控的压力也很大，由于业务变化很是快，你今天是这样设置监控规则，明天业务又变了。

如何保持稳定性

介绍一下咱们对于稳定性的定义，咱们也是拿四个“9”来衡量稳定性，可是咱们分别用于两个指标：系统可用性和订单的可用性。

1. 系统可用性四个"9"意味着整年的宕机时间不超过52分钟，咱们是按季度考核的，至关于一个季度系统宕机时间不超过13分钟；

2. 另一个维度订单可用性也是四个"9"，意味着咱们一个季度是一亿单的话，这个季度的订单损失不能超过1万单，而咱们高峰期一分钟就接近两万单，所以只要这个系统有问题，咱们这个KPI就没法完成。

咱们仍是要保证四个"9"的可靠性，而咱们怎么去作：咱们从四个阶段来扎实地作这些事情：一个是平常运行，二是事前预警，三是事故处理，四是过后总结，我会详细地介绍这四个环节：

1、平常运行

首先在平常运行里面，咱们要作好稳定性的架构设计，这里有几个原则：

第一个是大系统小作

咱们不但愿作一个很是大的系统，它什么都能作，咱们但愿作小的系统，很是专一，功能相对独立。咱们先把功能相对独立的系统拆开，在早期发展过程当中，大家看咱们有一个系统它什么都能干，它实际上是一个Web项目，还提供了Web的服务，同时还提供了App的API服务，它还消费消息队列，仍是Job的执行者，这就带来一个问题：你消费消息的逻辑发生变化了，你就要去发版，其实别的功能是没有变化的，发版就会影响到其余的功能。当咱们把几个系统拆开，它就是四个独立的系统；

第二个原则是依赖稳定性原则，你提供的服务必定是稳定可靠的

这里但愿是将易变的和不变的地方拆开。举个例子，对于商家的服务，对于C端的用户和服务来讲，用到最大的场景就是GetById，就是知道这个商家的信息就行了，可是咱们还有不少对商家管理的服务需求，好比说商家符合什么条件才能上线，须要什么过程才能改他的菜品，这些管理的功能是常常变化的，对于读取的信息是不变的，因而咱们把这它拆开，把它变为读的服务和管理的服务。管理的服务能够随时发版，没有关系，读的服务是很是稳定的，基本不发版；

最后一个原则是设计这个稳定性的时候须要考虑用户的体验

须要考虑在系统出现问题的时候用户怎么办？相信不少同窗都有这个体验：可能APP上忽然有提示失败、服务器异常、空，不知道什么状况。我相信用户遇到这种状况必定会不停刷新的，这时候若是后台已经有问题的话实际上是糟糕的事情，因此设计的时候要考虑到在异常状况下用户的体验和用户如何引导。

平常运行里面，另一个工做是作例行的稳定性巡检

一、好比说咱们作专项的巡检

对DB来说，咱们每月要作DB容量的Review，咱们看哪些表是大表、读写的QPS以及它的容量，以及将来某一天它能不能支持业务的发展；

二、咱们会作静态的梳理

咱们按场景梳理，例如首页、Banner、列表页，这些场景用到哪些服务，这些服务又用到了哪些服务，这些过程当中，它们对下游的调用是否存在放大的状况。有一些状况是假的高并发。

好比说有一个服务是说告诉商家今天有几个新订单，这个功能很简单，就是在前端页面去作轮询，这个过程其实80%-90%的查询是无效的，由于一旦有新订单咱们就会推送到商家，商家就会及时地处理掉，查这个请求实际上是无效的，这么多无效的请求去查订单的服务，最终还要落到数据库上，这是假的高并发，这里咱们在前面加一层缓存，把到数据库的这一层假的高并发给干掉；

三、另一个例行的工做是对指标的巡检

咱们有许多的监控指标，尤为是关注它的尖刺，这些尖刺也不会放过。

对于平时来说，给咱们加强稳定性最可靠的信心就是在线压测，咱们和其余大厂差很少，咱们也在作在线压测这个东西，咱们有一个在线压测的平台。咱们但愿经过压测来发现什么呢？首先发现系统里面的性能瓶颈，到底哪一个系统是里面最弱的，以及咱们要知道系统服务的上限和能力。

另外更关键的是，咱们须要经过压测来验证咱们的监控和报警机制是否生效的，可能不少时候你们都说咱们配置了很是完整的监控方案，可是它可能不生效，一旦不生效就惨了。另外，咱们要经过压测指导咱们报警的警惕线是怎么设置，到底CPU是设置是30%仍是70%，何时该报警，咱们就经过压测来确立。

这个压测告诉咱们指导意见，警惕线设置到哪一个位置是给你留有充足时间的，若是你的报警发生以后立刻挂了，其实报警是没有用的。咱们能够经过压测来要设置警惕行动线，到这个时候咱们要考虑和关注这个问题，留给稳定性处理有足够的时间。

咱们怎么作呢？咱们把线上的流量通过日志录取下来，把录取的流量放到咱们的压测平台里，这是对于读请求的。对于写请求的，咱们作一些事务的模拟，咱们有一些模拟的脚本伪造一些根据咱们场景作的数据。

这些数据再通过一次染色，把真实数据和测试数据隔离开，通过咱们异步阶梯加压的模块，咱们先经过异步的方式把它迅速打起来，咱们能够把量打地很是高；另外咱们是经过阶梯性地打，咱们不是一次打到2万，咱们可能先到5000，而后再到9000，而后打到15000，而后再持续10分钟。

咱们对这个监控的流量施压过程和跟咱们监控指标关联起来，咱们作压测以前先看和哪几个指标关联，哪几个指标到了什么阈值就自动停止压测，毕竟咱们是在线上作这些事情，不能对真实线上的状况产生影响。对于其余依赖的服务，好比说支付，这些真的不能压到银行去，外部的服务咱们作了一些Mock。

2、事前预警

对于事前预警阶段，若是真的有事故发生咱们但愿更早曝露出来，触发报警，而后有充足的时间去应对这些事情，咱们在这个地方在事前预警阶段咱们有一些监控心得：

首先是有分层的监控：有系统级的监控，例如性能指标的监控，还有业务监控，咱们还有平时健康度的分析，咱们的应用是否是健康的。

咱们分享一下在业务监控的想法，业务监控实际上是最让你放心的，你有一个业务大盘，这个大盘若是有一个波动你就立马发现了，说明如今可能会有影响，你可能会收到报警，例如什么CPU的报警，你去看大盘，大盘可能说没有什么影响，这样你不会那么慌。

另外，咱们系统里面把订单相关的全部信息和重要节点作了日志的输出，日志经过flume收集到Kafka再到Storm里，咱们在Storm里对这些日志进行汇聚，汇聚的结果放在HBase里，在这些结果里咱们有几个很是好的应用：

1. 例如首先只要告诉我一个订单号或者手机号，我能够查到这个订单走到了哪一个环节，到了哪一个服务的哪一个服务器挂掉了，解决这类问题很是的方便；

2. 另外咱们还能够把这些指标作成监控曲线，好比说你要下单，下单量是这么高，到了接单的环节它出现了降低，接单这个服务可能关联的ABC三个服务：可能有商家、PC、打印机的接单，究竟是哪一个服务出了问题致使了大盘的降低，咱们的曲线能够很是方便地看出来。

3、事故处理

还有可能有一些意想不到的事情发生，真的出现了事故怎么办？第一原则就是及时止损。咱们知道发版是致使稳定性变化的第一因素，若是立马肯定是由发版引发的此次事故，最快速最有效的方法就是回滚。另外可能还有一些流量异常，对于流量异常咱们有限流的模块，咱们提供了三种限流的策略：

1. 第一种是防刷的，防止用户频繁刷新致使后台的流量继续放大；

2. 另一个策略是等待+限时的服务，用户其实在用咱们平台的时候，用户确实是须要选的，可能要选来选去才能下单，对于这些服务，咱们但愿说你愿意等一段时间咱们能够提供，好比说你愿意等10秒钟，我给你提供20分钟的服务，这段时间应该是能够下完单的；

3. 还有一种策略是对单机的QPS保护：咱们压测验证的时候这个服务单机能达到500QPS是稳定可靠的，再往高有问题的话，我能够启动这样一个保护，确保你可以以最大的服务能力提供服务而不至于挂掉。另外在单机QPS保护中咱们须要把关键的路径去放过，你真的不但愿用户在下单、支付的这些路径把它干掉或流空掉，这些服务咱们就用白名单的方式放过。

4、事故总结

事故发生以后，咱们须要对事故作一个很是深入的总结。这里面有几个很是强的要求，第一是必须找到根源，根源咱们采用5whys的分析方法，必定要追踪到最根本的缘由，从现象开始追踪。另外要去核算清楚此次形成多少损失，由于咱们要算咱们的稳定性。还有一个方面，你要对此次系统出现问题的过程、你处理的过程和中间的流程进行总结，看哪些地方能够优化。

我建议的作法是：咱们须要把此次事故处理的过程详细记录下来，它多是须要精确到分钟的，好比说某一分钟谁跟谁作了什么动做，这对咱们总结颇有帮助。由于有可能事故处理过程自己是有问题的，好比说你去扩容花了30分钟时间，这是有问题的；比说你在处理过程当中作了错误的决定也是有问题的，因此咱们把过程当中作了详细的记录。

咱们对于这个事故的总结和Review，咱们但愿能看到什么？在这个总结里面，咱们但愿看到到底哪里出了问题，咱们能不能更快的发现它，未来若是再发现，能不能比如今处理的更快一点。

讲完这些处理原则，再介绍一下咱们作这个事情的实践。咱们对稳定性的要求是极高的，每个订单的损失咱们很是敏感，咱们就有一个实践的动做：就是力保关键路径不挂，咱们要保住订单，那要保住和订单交易相关的全部路径不能挂。

因此平时咱们就梳理出了和订单交易的关键路径，从用户下单、从用户开始选门店，而后开始选菜，而后下单，而后到配送完成，这个过程里边每个环节关联了哪些服务，这些服务都应该具有有降级的功能。

好比说Rank服务，用户首先打开咱们App的时候，咱们就会给他最附近的、能够配送到的一些商家，这些服务会给用户以前的购买记录来作推荐，咱们会给他更好的排序。

若是咱们Rank的服务出现问题了，咱们能够迅速地将这个Rank的服务给降级掉，改为默认按销量去排序，这样用户也是能够选餐的。因此这个环节里面的每一步咱们均可以降级的，从而保证在下单这个关键路径上服务都OK，其余服务能够接受它的挂掉。

另外，预案的建设，你永远须要想一下你未来可能发生什么，若是发生这些事情的话，咱们该怎么办？因此你在作这个事情以前就要去考虑，咱们认为性能是功能的一部分，稳定也是功能的一部分，而不是你们作这一次技术方案设计，作完以后再来优化性能和稳定性。

咱们须要在作这个架构设计的时候考虑到性能和稳定，它们是产品功能的一部分，同时也要考虑到若是性能稳定性出现问题，用户体验是怎样的，用户不但愿看到很傻的提示。

因此咱们在功能设计的时候，就考虑到了出现这样的状况咱们可能要降级，这个降级的方案多是一个开关，就会有很是多降级开关，有些状况下是更复杂的场景：若是这个状况发生了，咱们可能把这个开关和那个开关给关掉，这是咱们的降级管理平台，咱们真的把一个降级开关给作成了一个开关，就是开启和关闭，同时我告诉你开启意味着什么、影响着什么。

再介绍一下这个平台里面咱们有对灰度的管理，有对压测的管理，有对健康度的分析。另外有一块咱们称为核按钮，即若是事情发生以后你要保住的底线，若是咱们的系统出现问题，商家不能接单或者配送没法送出的话，用户下的这些单子都会被取消掉，这个体验是很糟的。

我下了单，而后5分钟你告诉我商家不能接单这个订单被取消掉了，我忍了我换了一家，结果又被取消了，这会骂人的。若是商家不能接单，就不要让用户下单，若是这些状况发生，咱们就迅速启动核按钮，把咱们筛选的这些不能接单的商家迅速变为休息，能够保证用户向能够服务的商家去下单。

在整个实践的过程当中，与稳定性斗智斗勇的过程当中，咱们总结了很是多的流程，咱们叫作标准操做流程SOP，这些流程涵盖了从需求、开发、测试、上线、监控、故障处理的每一个环节，每个环节都是标准的、很是严格的、通过认真思考的流程来供你们参考的，必定要按照流程来操做。为何这样作？

给你们举个例子，按照这个步骤走是值得信赖的，每一步都有很是好的预案与系统的配合。好比说出现事故，你们是很慌的，由于那么多人在投诉、那么多人在等着说不能点餐了，为何，美团外卖怎么了？而后咱们处理事故的同窗说：你不要慌。怎么可能呢？那么多用户在投诉，老板还在后面问你怎么样了，何时才能处理好，怎么可能不慌呢，臣妾作不到呀。

这个时候你确定很慌的，这个时候你还要把不少问题考虑清楚几乎是不可能的，有些同窗说我这里须要这么作、我须要写条SQL，结果忘了Where的语句，因此你在很是紧张的状况下根本想不全这件事情的，那怎么办？咱们只能提早想好，若是会出现这种状况咱们就执行这条SQL，而后放在那里通过无数人的Review和实验，它是可靠和能够被执行的。因此，咱们在整个过程里面收集了很是很是多的操做流程，每一步都有很是严格的要求。

咱们梳理完了这些流程，但愿把这些流程变成自动化的，不然人工操做的话，咱们是能够要求你们严格执行，可是毕竟也是效率低下的，咱们须要把不少的操做变成自动化。

举个例子，下图是咱们发版的流程，看上去还蛮复杂的，一共有10步，咱们有很是多的要求，你在发版以前须要验证哪些事情，发完版以后要验证哪些功能，最重要的是你要去评估，你要去评估有什么影响，你对下游有什么影响。

更重要的是，咱们对每次发版都必定要有回滚措施，就是应急预案，你要回滚到哪一个版本，若是是一个大的项目，你们一块儿联合发布的，是怎样的回滚过程，谁先操做谁后操做。对于每一次发版，没有预案是不容许发布的。

你们可能会说，我要改库、我要改表，我已经把表结构变了，还要写数据，这时候没法回滚，回不去了。那不行，那是不可能的，你必定有办法把它回退过去。另外，咱们有每一次的降级方案和灰度的策略，若是是这一次发版引起的故障的，发版以后整个过程作一次很是详细的整理，到底哪些地方出了什么问题。

在处理的过程当中有几句总结的话跟你们分享：

第一句话：你要想稳定性作的很是可靠，灰度、灰度、仍是灰度，没有别的方法 ；你不要把全部的量去验证这个事情。咱们对于灰度，能够作到按照城市、按某个功能、按URL某个参数来进行灰度，也能够按照必定流量的比例，好比说先灰度1%，而后到50%，而后到100%。

另外咱们对于发版是有很强要求的，咱们有一个发版的时间窗，周一到周四的下午两点到四点，其余时间是不容许发版的，若是你要发版你要提申请和审批。

为何这么作呢？由于咱们外卖特色就是中午流量很是高，晚上流量偏低。咱们以前发现其实兄弟们很辛苦，很是辛苦的写代码，写到晚上八点，终于写完了开始发版，而后测试，到十点多又有十几台服务器要发布上去，还要回归这些功能，到11点终于发完了，一身疲惫终于能够回家了，而后回去休息。次日早上十点钟一个电话打过来，出问题了，怎么办？到底去公司仍是不去呢？别去了，赶忙在家看吧。

由于次日中午是很是高的高峰，咱们不但愿用中午这么大的量来验证，咱们但愿晚上来验证，晚高峰虽然比中午的高峰低不少，可是也是一个很是大的高峰，咱们用这个流量来验证，因此咱们把发版的时间调到下午，不要在晚上发版，这样很累可能想不清楚，和你关联的其余同事都不在，不少事情也没法处理。

因此咱们下午来发版，这样会很稳妥，你们都在，经过晚上的高峰来验证，若是没有问题，次日也很稳妥很安心的，若是有问题则晚上进行压测；

第二句话：慢查询每每闯大祸。慢查询是很是讨厌的事情，并且它的出现可能会有很是大的危害，慢查询把一个库打挂的话，咱们负载均衡会跑到其余库也继续打挂，而后全部都挂了，解决数据库挂了的问题是很是耗时的，因此对SQL有极高的要求，在咱们的实践里面咱们不容许写join，不容许写like，每一次SQL都有Review，上线的流程里面会记录此次上线此次SQL是谁Review的；

第三句话：防护式编程，不要相信任何人和服务。别相信你的下游说，我就调你三次，你放心吧，没事的。别信，确定有鬼，你要作好对自身的保护，也不要相信下游说别人的提供的服务放心地使，哥向你保证五个9的可靠性，没有一个服务能作到100%的可靠的，这是必然的，即便是5个9，也有损失的时候，别相信他，要作好对下游的依赖和熔断；

第四句话：SOP保平安。咱们把全部的流程都变成标准化流程，这比拜大仙还管用，有时候开玩笑说发版以前没有拜一拜因此挂了，其实不是，而是由于你没有按照标准流程来操做因此挂了，若是每一步都严格按照标准流程来作，它是可信赖的，是不遗不漏的，保证作到方方面面；

最后一句话：你所担忧的事必定会发生，并且可能立刻会发生。最近上了一些功能，你说好像这个地方可能会有问题，你最好赶忙看，也许立刻就会有问题。因此咱们建议作例行的巡检，按期地对你的服务、服务的指标、依赖的状况，有一天你去看发现忽然多了一个服务，可能你还不知道。另外对DB、KV这样一些中间件作例行的巡检，及时的发现这些里面可能存在的问题。