运维系统性能优化后思考，除了避免懒惰的麻木，还需要了解系统的“脾性”

做了一些优化之后，发现系统和人其实蛮像，当然人要高级的多。

很多业务系统在发生问题的时候感觉是突然发生的，但是按照分析问题的思路查下去却发现是这样那样的原因，毫无疑问大多是一些很小的问题逐步放大之后看到的。

近期我们的运维系统的小问题不少，在这个过程中大家有点感觉到了运维系统的老态龙钟，初期关注功能实现，后期关注性能，其实这种方式会让你不断的走一些重复的老路。

近期运维系统常见的问题有：

1）有时候和外部系统进行接口数据推送的时候，会因为API层的异常导致数据通信失败，报错信息类似Broken Pipe,IOError这种，但是没有明细的错误信息。

2）运维系统有时候会突然奔溃，等发现的时候基本是被动的处理方式

3）在某一天做一条简单的DML操作的时候，数据库竟然给我返回执行了5秒

4）近期的业务变更需求比较多，时不时会拆东墙补西墙的发布一些补丁

而这个问题在近期达到了一种常态，那就是每天都会出点问题，这个问题引起了我的关注，我们做出了一些改变。

1）对于系统的服务可用性，我们加入了系统层的monitor模块，这样在服务自动宕机之后，会自动拉起服务。

2）排查了近期的业务需求变更，暂未发现一些明显的性能隐患

3）从磁盘空间增长情况来看，也没有产生一些异常的日志。

从问题的反馈频度来看，大家会逐步对于系统失去信心，同时也会无形中加大各方的业务处理压力。

在经过排查，我定位到问题的瓶颈主要在API层，所以在API层入手来查看是否有一些超时处理的流程。

有一个流程引起了我的注意，我抓取了这个逻辑的SQL情况。

这是一个慢日志进行稽核回写的逻辑，会把收集到慢日志信息进行慢日志个数统计后回写到一个新的表中。

数据库层面进行排查和分析，发现都指向了这个逻辑处理。

也就意味着这条SQL如果进行了完善的优化，那么整个性能问题的90%以上的瓶颈都能够解决。

在这种情况下我进行了进一步的优化，而优化思路其实就是采用增量变更而非全量变更，采用这种方式之后，优化的效果从原来的分钟级下降到了0.2秒左右。

整个过程涉及几个索引的重构和SQL逻辑的优化，难度其实不大。

我在思考这样两个问题

1）为什么这个问题到了现在才被重视？

2）为什么这个问题到了现在才能够被优化？

说到底，里面涉及的主要就是懒惰，就是对于问题的忽视，导致问题由小变大，从一个小的设计问题变成一个大的问题甚至故障，而另外一个层面就是我们需要了解一个系统的“脾性”，正如我在开头说到，系统和人有些类似，有时候我们能够容忍一些，但是如果容忍不了就会爆发，对于系统也是如此。

如下是这条SQL的执行时长的趋势图。

可以看到在近几个月里的执行时长是逐步增长。但是每隔一段时间就会有一些明显的下降，从我的记忆来看，那是我对一些历史数据做了清理，对一些索引进行了构建，但是解决的是一些表面问题，如果我忘记了清理历史数据或者索引的重构效果不佳，那么问题就依然存在，而等到了爆发的一个点，这个问题就是以点带面的影响方式，所以初步来看，这个系统的容忍时间是60秒，但是我们能够优化到0.3秒，听起来确实是很讽刺。

什么样的方式能够解决这个问题，一种行之有效的方式就是能够提出更高的要求和标准，比如现在执行10秒钟，业务逻辑是完全可以接受的，所以我们选择了默认接受，而等到了不得不改的时候，才会去重新审视这个逻辑。

而进一步思考，如何进行问题的规范和完善，我觉得：设定相关的标准和规范流程，同时在这个过程中进行问题跟踪和回溯。