你在地铁上修过bug吗？

作为技术人员，有没有遇到下班路上收到老板电话，系统故障，然后地铁上掏出电脑，修bug的场景。自己负责的业务线上出现问题，负责人心里是很慌的，在这种心理状态下做事很容易二次犯错，造成更大的问题。

但是线上业务在高速迭代的过程中，出现问题，又总是难免的。这个时候，对业务系统建立完备的监控体系是十分有必要的。

监控的目标是及时发现系统问题，并尽可能快地做出相应的动作，让系统处于一种健康状态。

监控，顾名思义就是监视和控制

监视：通过采集业务日志，系统运行指标等，观察系统运行状况，实现快速定位问题的目的。

控制：采用一定的技术手段，解决问题，使系统恢复正常状态。

定位问题是一件考验一个技术人员技术能力和对系统熟悉程度的事情，需要业务系统输出的日志等信息作为线索，顺藤摸瓜，细心排查，才能最终定位到问题。

解决问题是一个对技术人员工作经验要求比较高的事情，把问题解决是最基本的要求，同时还要考虑解决问题的效率，对业务的影响程度等。

解决问题的方式有很多，可能大部分技术人员都十分崇拜那种，直接在线上改bug，然后发布，告警消失，系统趋于稳定。但是这种解决问题方式对技术人员的技术能力、心理素质都有较高的要求，并不是所有技术人员都能做到的，这种解决问题的方案，很难普适。

这里小编介绍一种简单粗暴的解决问题的方案，对于大部分技术人来说操作起来都比较简单。

在讨论这种方案之前，我们先来讨论一下问题产生原因，问题的产生绝大部分的原因来自于“变化”，这里的变化怎么理解呢？

这里的变化分为两种：
1.业务系统功能迭代，发版。有没有同感，绝大部分情况下，产生线上问题，都是发版导致的。

2.业务流量变化：业务运营活动产生突发流量。

既然是变化导致的问题，那么消灭变化，让系统回归到变化前的状态，是不是就解决了问题了，如果没有解决，说明变化没有消灭彻底。

怎么消灭变化呢？

对于第一种：通常的做法是版本回退，业务功能回退，sql脚本回退等。

对于第二种：系统具有限流的功能，或者快速扩缩容的能力。

总结来说就是：流控和版本回退，简单，粗暴。但对于任何线上问题，都可以采用这种方案，这种方案可能没有直接在线上解决问题那么“酷”，但是，对技术人员的专业能力依赖不高，是一个标准化的流程，甚至可以做到自动化，二次出错概率很小。

而且作为一个技术人员，一定要转变一下思维方式：不解决bug，也可以解问题，并不一定要硬刚bug，要考虑解决方案对业务的影响。技术的价值是通过业务体现的，尤其是对于做业务的同学来说，技术nb，并不一定能给你带来成长，你支撑的业务nb，才能体现你的价值。