那天突然有人问我：问题解决和事件解决的区别。
今天刚好出了点问题，在解决完后，我突然对这二者有了更深入的体会。
举个例子：
如果由于网络中断，导致服务不可用，那么这就是一个时间，我们可以编号为2017-09-13号事件，那针对这一次的事件，我们可能通过重启设备，排查具体端口映射，或者更换新设备等方式解决，那么，在这次的事件中，我们解决问题的过程，既可以成称为是一次事件解决过程。
但是这里我们将面临两个问题：
1.在迅速判断出故障后，能否迅速修复问题？
2.整个故障恢复过程中耗费的时间对业务造成的损失？
--这就引出了一个核心店：运维的核心是保障业务的可用性
这就引出下面的问题解决方案。
仍以上例说明：
在这次的事件解决中，我们先是通过观察现场环境、并逐一的对硬件、链路连通性、系统、服务等进行排查，最后确认故障是由网络设备受损导致了服务不可用，然后我们又开始花大量的时间用于判断具体原因并修复该受损设备，最终恢复服务的可用性；
但是，围绕上面的一个核心店，我们再来思考这两个问题，就会发现，这样的突然事件处理方式必然是不可取的。那为了避免以后再出现这种情况，我们该怎么办?
我们是不是可以部署一套新环境，做一个高可用的方案呢？一旦故障发生，我们可以实现手动或者自动，但是保证最迅速的切换到备用环境，从而维持业务正常使用。当然，考虑到成本问题，很多公司并不愿做大动作。那我们可不可退而求其次，挑选整个环境中的几分关键或故障频发环节做有限度的冗余？本例中完全可以事先准备一台低端设备，但是预先配置好环境，这样，一旦出现未知故障，我们迅速的使用新设备直接替换；而待时间充分时再去研究具体原因，如此又完全不影响业务可用性，岂不两全？
以上就是我对问题解决与事件解决的一点思考，随笔记录以备日后回顾。