「这种感觉你应该有过」
做技术最害怕的是，可能正在路上、可能正在吃饭、可能还在睡觉，突然线上服务炸了，顿时着急忙慌浑身发热。 当然这个线上问题，肯定是影响面大的情况，不然也不会突然拉群打电话，甚至于老板都开始关注，@你询问问题情况了。
「面对突发事件如何应对」
互联网和生活是相通的，先看下现实生活中的case。平时遇到房间突然着火，第一时间一定是想办法灭火，拿水盆、或是被子捂住。 基于已有的应急方案认知，做快速的反应，而不是去现场追“为什么突然起火”。面对突发事件，第一反应应该是「止损」，不让火势蔓延造成更大的影响。
如果火灭不下去了，应该尽快逃离房间，保住生命安全也是止损的一种。小时候记得住在木房子很容器着火，当时一边下楼一边大人还要大喊着火了，这个时候邻居都会过来帮忙想办法。 「周知」也是很重要的一环，让更多的知晓，借助于他人的力量来解决，尽可能减小损失。发生事件时客户投诉一般比较多，让前线知晓大致的情况，给予一些安抚客户策略也是止损的一环，避免舆情扩大。
「如何止损」
面对突发事件，止损、止损、止损，服务问题一般如何止损：
首先，关注有没有正在灰度发版，或刚发布不久的情况，这个是最容易感知的，如果有先立马回滚（粗估回滚带来的影响和线上事件比较，往往是线上已有服务来的重要）。 当然这个发版不止是代码服务的发布，也可能是线上配置的更新。
如果没有人为操作的情况，马上看下监控日志，这个时候首先可以看下报错的容器，如果集中在一台或2台，本着止损的原则，先摘流。大概率是容器物理机出了问题，摘流后可以细追下什么原因。 容器没有问题，细看下日志内容，找几条 trace 看下，情况一般就比较明显了：
- 依赖服务出错、限流
- DB 超时，可能慢查、连接数不够
- 队列堆积，处理慢了
- 服务有OOM，内存资源耗尽
等等，欢迎评论分享下你遇到过的线上问题。
「如何避免」
保持对线上服务的敬畏，像是在高速上开的车，需要时刻关注留心。 大的事件往往有小的前兆，例如在预发环境验收时可能就有问题疏忽了，或是在单实例灰度的时候就有错误日志，然而没有观察到。往往觉得应该没有问题的时候却更容易出问题。 平时需要做到日常的巡检，依赖服务的裂化，DB的慢查询等等，把问题掐死在苗头。
流程建设来保障，迭代的测试验收，迭代的code-review，必上预发产品验收等等，适公司情况而定。发布的流程规范，发布单的创建 & review、单实例的灰度时间、线上监控日志观察等。 通过约定的流程规则来避免可能的事件发生。
「在问题中学习」
不出问题的服务是不完整的，没遇到过问题的职业生涯也是不完整的，有波澜才有意思。在问题中看到更深的问题，在问题中学习，不断进步。 出了问题后的「复盘」是很有必要的，避免问题的二次出现，提高现有服务、流程、人员的能力。 这样才能在突发事件前越来越有定力。
「黑话」
当然不是什么突发事件，第一时间就该找自己的原因，得分清楚是否真的是技术问题，不甩锅也不主动接锅。
