应急演练会议的心得体会

应急演练会议的心得体会

　　最近一周都要抽点时间去搞应急演练，本来只写了个方案，后来市场部还有中心的非技术领导觉得写成演练脚本会更让他们明白（有点像演戏的脚本）。这两天都是领导在调改应急演练脚本，毕竟，组织语言方面领导还是比较在行的。今天下午就去“演戏”了，一人一个角色。未去之前我觉得是不会让我们从头念到尾的，因为，从头演下来，还真的挺无聊的~~虽然说是走走过场，果不其然。整个会下来，有点失策了，会议后半场才想起录音的，因为怕丢了信息，虽然最后还是录了半小时，前面只能靠人脑去记了。还有一个自己都想把自己给埋了的状况，我竟然没带笔！！！之前以为洗完书包把笔放回去了（特殊时期，果然脑子不太好使）

　　这个会议主要是给中心业务部负责人说明白演练流程的。我们都没开始念对白，仅仅念完开场白及主持人（都是我们经理演）一些套话，他就打断了，因为，听不懂，说应该结合方案给他说，得浅显易懂！！！外行人，非技术人员都要能听懂的！！！

　　幸好借了旁边妹子的笔，不然回来估计全忘光了，虽然可以听最后半小时的录音。

　　简单说下，演练的系统在网站分类里面属于一个内容管理方面的网站，意味着内容如果遭到恶意篡改，比如跳转到反动暴力信息页面，会造成很大的社会影响：导致糟糕的用户体验及降低企业信誉。所以对于应急演练方案上面的定级中，最应该考虑的是网站被篡改的情况！！！遭遇DDOS攻击或者各种原因导致网站访问不了，这些都是不及前者危害大的。

　　所以他们反复说的一点，我是挺同意他们的：网站要是被篡改，比如链接到赌博网站，或者有些内容链接到别的不良信息网站，第一件事是下线被篡改的内容，上替换页面（先摆个友好提示：系统维护升级中，请稍候再访问。。。【他们说的是统一对外口径】，然后同步告知给他们（业务部+技术部，我之前只汇报给技术部，以后也要注意下），不能让他们完全不知情，最后再是技术人员去找出原因。因为技术人员的通病就是（包括我自己在内），一遇到问题就会埋头苦干，想查出问题的原因，一般极少会考虑外面的情况，如果你把应急事件升级了（他们说的升级是超过30分钟，事件就会从一般事件升级到较大事件，随着时间的推移，甚至会变成特大影响事件），后续会有很多麻烦事要跟进的，甚至最糟糕的情况是可能你会被革职（当然这个是我想的）。我知道，技术人员肯定不是故意的啦，一般都是比较单纯滴，就是技术情结作祟，以为自己可以在短时间内解决，但有时候问题没你想的那么简单，可能短时间内都会没有任何处理进展的。所以这个处理顺序要调整下，出问题时不能是技术人员一直自己查查查，也要关心周边情况。

　　这个内容管理网站在我入职以来，出现的都是一般故障。一般就是30分钟内能处理好的，出现问题最多的是WAF中断导致网站访问不了的情况，这个时候一般就是切断这个大门先咯，因为WAF是天翼云那边搞的，我们能做的是把域名解析回源站IP，不要指到有问题的WAF地址，直到他们通知已经解决好再开回这个大门。

　　另外他们提到这个应急演练事件的定性问题，主要要从3个方面着手：

　　（1）内容是否受到篡改/损坏，丢数据，被删了数据？    

——》 有：肯定不能是一般事件了

　　（2）造成的影响？

——》对社会有影响：也肯定不能算是一般事件

　　（3）预计什么时候恢复好？

——》30分钟内：定性为一般事件

　　我提下，对于特别重大事件，比如云服务商被劫持，整个广东省光纤坏了，他们说要补个异地灾备的预防措施的写法（虽然这种情况非常极端，估计10年都不会出现一次），机房不能放在同一个地方，两者之间距离越长越好；或者

　　所以整个会议下来，传达给我们的意思就是 ——》尽量将事件控制在30分钟内，把事件降低为一般事件来进行解决！（反正入职以来，基本都能处理好【故障报告写的极少，上家公司写故障报告写到怕= =】），

　　我先粗略讲下这些突发事件，我是如何比较有信心在30分钟内恢复网站访问的。天翼云WAF那个问题我已经讲过就不说了。

　　（1）对于首页搜索框失效搜索不了的情况，我做了两手准备。因为这个搜索框（线上的一个服务）实质上是去查内网数据库获取搜索内容的，内网的数据库端口要映射到公网，给线上服务器去访问。现在是通过ngrok反向代理内网数据库端口给线上连的，线上跑的服务器能以域名的形式连接内网数据库来获得数据；之前一直用开的是autossh的反向代理，它的代理原理是要开线上服务器的ssh端口，而且因为公司出口ip一直会改变，所以不好限制ssh端口开放的ip网段，不限制ip去连的话相当于把服务器的ssh端口暴露在公网下，有些家伙扫到这个端口就一直ssh暴力尝试破解服务器登录密码，搞到很多报警（/var/log/secure有很多错误失败登录日志）。但作为候选方案去恢复服务还是可以顶替着先的，所以这就是我的第二手准备了，毕竟出问题时，恢复网站正常访问才是最重要的。即出问题的时候我会切回到这种方法去保证这个搜索框能用，不至于说搜索框搜索内容是返回空白的。然后剩下的时间，就是慢慢排查为什么ngrok代理的方法，域名连接的形式为访问不了内网数据库，譬如是因为ngrok服务端服务停止了，或者ngrok客户端服务停了，甚至是因为ngrok证书过期了，都会导致连不上的。

　　

 

　　（2）第二个举例故障事件，网站访问不了，页面空白，主服务器远程登录都登不上了，天翼云的控制台也连不了，完全处于失联状态（我记得那会7点的时候领导就打电话叫醒我了），最后是通过天翼工程师去帮忙搞的，说是networkmanager服务关了，服务器dhcp获取不了内网ip，相当于服务器自己跑着，跟外界完全失去通信，那时候幸好有个备机，nginx入口转发我转过去了，不然真的会成特大故障的。入口服务器（也就是nginx）我后来也做了双机热备，谁知道下次会不会遇到攻击入口服务器的情况呢。

　　所以凡事得做好两手准备，不然随着时间推移，就会酿成大祸~~~~

　　再说下预防网站可用性和内容的监控提醒，这个也做了。网站可用性直接用阿里云监控就可以了，目前设置的是：网站在5分钟内连续3次平均响应时间大于400毫秒，即钉钉群上报警；内容监控用的是md5指纹校对（关注我下一篇文章）。

　　心得文就写到这里了，以后要是有新增了别的措施去预防，也会补上去哒  ^__^