近期做的稳定性建设总结

背景

近期业界频繁出现较大的稳定性事故，引发社会舆情。湖北十堰也发生了安全的大事故。海因里希法则告诉我们：一件重大事故的背后总是有29件轻微事故+300件潜在隐患。我们要把这些事件当做镜子做好自身的稳定性建设。

我们的项目目前平稳运行，架构设计上也能满足现阶段的需求。所以近期做的稳定性建设并非轰轰烈烈的大事件，却对未来的长远稳定性至关重要。如果一个工程或者项目需要做大手术了，甚至派上了公司级的专家一起来建设，那直接说明之前做的太烂了，遇到了大问题，估计要走马换将了。

很多朋友听到这里就会很无奈，在上一篇《社招面试的架构分析》里，我也提到社招面试中很大一部分比重是要介绍自己实际做的项目业绩。做这些小事能有业绩吗？以后有什么值得说的吗？我的回答是：太有了。

一个好的项目从功能演进方面大体经历：支撑业务、快速支撑业务、引领业务三个阶段。从稳定性建设来说，大体经历从0-1的基本稳定阶段和1到无限的稳定性加固阶段。“稳定性是第一性”，一旦稳定性出现问题，我们的功能演进就会回退到疲于奔命的支撑业务阶段。由于本篇文章功能演进不是重心，所以只告诉大家可以在面试中这么跟面试官讲：

我们的项目稳定性不错，日交易量十几个亿的情况下，SLA5个9以上。假设我们的系统连续5分钟系统成功率低于50%，就需要上报科技司、国务院了，所以我们有严格的事故定级标准，从最高的s0到最低的s9。s9定级要求影响总交易在5笔以下。实际上我在任的三年没有出过s9及以上的事故。(这里只是举个例子，大家还是要照自己的实际情况描述，要点是我们的系统很重要，对稳定性要求很高，这个场景下还做的不错。做的都是交易量不大的项目也不用担心，面试官关心的是从表述中体现出来的：格局、站位、层面和视野)

总体思路

1、独立出运维工程，将保障逻辑和业务逻辑分离，保障逻辑频繁迭代更新不影响业务逻辑稳定性

2、制定日志规范，新增集中采集日志，并据此新增监控告警，比外部先发现问题，并可以方便的进行问题排查和统计

3、规范和梳理现有监控告警，查缺补漏，合理设定告警阈值和级别，提高告警敏感度

4、告警治理，现有隐患各个击破，将平时告警数降为0

5、合理根据业务增长情况进行扩容

细节FAQ

这里举几个在方案评审时被问到的问题和回复以及具体实施过程中遇到问题的排查的解决思路用问答的形式表述如下：

Q1：在日志规范中规定在请求的开始和结束都需要打印日志，结束日志的内容包含了开始日志的内容，打印开始日志的意义是什么？

A：快速排查定位问题的需要

在需要对问题进行排查定位的场景，可以快速清晰的看到整个请求的过程。包括什么时间点接收到请求、什么时间点处理请求。

针对这个问题同学发起了连环问，问我结束时间-cost不就是开始时间吗？

是的，但是在实际排查问题的场景，需要尽量减少人工转换，快速定位，牺牲一点存储降低排查难度是值得的。同时，针对处理中间出现了问题，没有达到请求结束的场景，也可以定位到出现问题的环节。

连环问继续：如果是请求没有达到结束，直接try catch finally来处理，或者是通过请求成功率就可以定位了呀？

我们的try catch建议是catch exception，但是实际情况中有可能发生error级别的异常，这时候未必可以走到finally。我们没有必要在所有的场景都加上try catch还是要根据实际需要。如果请求出现成功率下降，那么影响的不是一笔交易，在需要针对具体一笔进行排查的时候，我们怎么知道请求成功率影响的是哪一笔呢？当然，通过复杂的排查和计算是可以最终实现定位的，但是我们要快速定位，尽量减少对开发人员的技术要求。同时，从容灾容错上考虑，我们需要对监控机制进行容灾，万一一个监控机制发生了问题，也可以最终定位到问题。这就是为什么系统有zabbix监控、Prometheus监控等多项监控共存，指标上和角度上有区别也有重复，区别是为了根据具体场景快速定位，重复是为了容灾一个监控组件出现了问题也能定位。

Q2：收到一个可用内存不足10%的告警，经过了两个小时才自动恢复到87%，所在的机器出现一笔请求超时

A：

现象

1>对业务进行了解发现开始出现问题的时间点，有收到外部MQ发过来的大报文，虽然报文做了分片但是每个分片还是有几M大并且下发条数多，集中下发。

2>分别在问题机器和其他相同应用的不同机器上执行top命令，观察到问题机器和其他机器上jvm内存占用差不多并且稳定。

3>执行free -h命令观察到cache/buffer下降到1G以下，内存使用率的计算规则是(1-available)/total。available虽然大家都说是大体上等于free+buffer/cache。因为buffe/cache可以快速被释放。但是实际上当cache/buffer下降到一定数值，available的值远远小于free+buffer/cache。本次问题发生的时间点，机器可用内存7.6G，free+buffer/cache下降了200M，但是available却下降了500M多。

4>收到外部MQ发过来的大报文时间段网卡占用情况从平时0.5M以下飙升到20M TPS

5>出现一笔请求超时正在下发大报文的高峰期，请求方发请求到机器接收到请求时间间隔是几毫秒。收到请求后机器会将请求转发给MQ，用了3秒多。而请求方设置了5秒超时。

6>所有环节cpu使用率都很低

7>20天前在另外一台机器上也发生了内存升高到90%以上的现象

分析

此问题的根本原因是外部短时间内下发大量大报文(受节假日影响当天的报文略高于其他天)，从根本上治理需要和外部(大佬级别，我们完全没有主动权)一起进行架构方面的调整，不现实也没有必要用此牛刀。

表现为虚机层面内存资源不足，影响了IO速率。因为高峰IO TPS20M，针对现在的千兆网卡、万兆网卡来说，并不大。问题并不在网络通道上，而在机器本身。而IO需要大量内存：内核态和用户态之间数据传输等环节的数据拷贝。研究过NIO、netty、linux内核等技术的应该都知道：IO无非就是分配内存、操作fd文件描述符和调用中断等命令的过程。因为现象中可以看到jvm内存是没有问题的，这里的瓶颈就在系统内存不足上。

所以短期我们制定SOP/EOP，应对临时问题。中期提申请进行纵向扩容。纵向扩容说白了就是增加物理内存。有人就要问了是不是扩机器数量也能解决问题。这种处理方式大概是能治病但是不一定对症。意思可以理解为吃广谱抗菌药来治疗感冒，有一定帮助但不是针对性的处理。因为扩机器是减少了请求数从而减少了内存占用量。但是万一有个大请求就是把内存飚高了呢？linux的设计如果内存高到一定程度自身的很多功能会受到影响，导致不符合预期。需要从根本上升高内存。并且扩内存实施成本更低，不需要程序的发布。就是低峰期暂停程序，插个内存条。当然，长期上业务量在上涨，但是我们还没有进行水平扩容。需要我们计算业务增长量进行合理扩机器。

有的朋友会觉得这个处理方式并不高大上。牛逼的处理方式是调整个linux参数啥的。现在也算比较流行的一个词叫做：不可变服务器。“传统”的部署方式中，对系统的改动都会呈现在服务器上，从而增加了风险。采用不可变部署方式，服务器都是公司统一标准化的，那么变更只要考虑应用程序的发布，而应用程序一旦发布也不允许改变，就成了不可变服务。不可变性可以增加系统的稳定性。在一个规模比较大的公司，就算可以通过技术解决资源的问题，从整体角度，还是通用方案更加可取。

Q3：有个MQ服务偶尔会在并发量高的情况下有响应耗时高的问题，这个MQ是闭源的收费服务。怀疑是内部实现用的是短连接造成的。

A：排查人员review代码发现每次发送消息都调用了close方法，怀疑是短连接造成的。首先来说close方法有没有直接把连接关闭不能从名称上来判断，还是需要看实现。比如连接池方式的close实现实际上是把连接归还了连接池。

可以使用netstat命令观察连接的状态，如果状态一直是established，应该是长连接。具体建立了几个长连接就看对应的established的数量。具体原理就是常见的一个面试考题了：TCP三次握手：

TCP四次挥手：

看netstat的状态就可以了解处于TCP的哪个阶段了。