关于在金融业运维项目注意1，2，3事之生产事故处理流程

       自从来到当前的公司，前期一直处于运维项目中，有已经跑了一两年的，有已经跑了6，7年的项目，在各个项目上兜兜转转，也是积累了一些在运维项目中的做迭代开发的经验，当前做一个总结，大概和大家讲讲，互相交流吧，因为一直做金融项目，眼界，思维方式限制，所以很多的东西可能不那么具有普适性，欢迎大家做一补充。

      生产事故处理，一般要包括一下几个方面：影响范围，终止方式，损失处理，缺陷修复，事故预防；其实这些不仅仅在运维项目，其实很多事情上都可以作为借鉴，很多事情的的教训也可以反哺我们在运维项目中。废话有点多，进入正题。

       对于一个生产事故，做的第一件事请应该就是止损，暂停服务提供，下面会提供详细的说明，损失其实包括我们直接看的见的损失，请求异常，数据处理异常，在金融行业，第一关注的是就是账务异常，即银行资产损失和  客户账户资金损失。在事故发生的第一时间，需要根据缺陷发生的现象，对当前的出现异常的范围做基础评估，在尽量合理的前提下对相关服务进行分流，或者停止，或者白，黑，灰名单的处理方式来保证银行资金的安全。

        一般在账务发生异常的时候，第一时间是判断当前资金到底在哪里，如果还在银行内部流转，客户的账户没有收到对应的资金，这种情况一般叫银行长款的情况，因为主动权掌握在银行手里，还是可以从容应付，但是资金如果已经流入客户账户，银行多支付或者少收到资金，对于银行来说，保证客户资金十分重要，基本上如果未经客户授权的情况下绝对禁止直接操作客户的账户。所以这个时候需要做个和蔼有礼貌的服务机构，求“上帝”们还钱，当前不排除一些法律途径， 毕竟并不是所有时候都能相互理解的。业务的操作一般有账户冻结或者限制，但是问题是技术问题引起的，对于相关问题做定位，如果只影响一小部分用户的服务，可以做黑白灰名单，如果是直接是服务级问题，直接会暂时停止相关服务，这时候就是发布紧急版本升级补丁。

       对于直接阻碍当前的业务的运营的，必须当前给出紧急版本做升级补丁，所以在银行开发的过程中会有一个开发分支叫紧急生产问题开发分支，和当前的在线运行版本分支一致。

        在生产事件处理完成之后会对相关问题进行归档复盘，更多的作用是发现问题，对与开发测试的过程做补充说明，还有准备预备方案，防止后续再次遇到此类问题，也不排除有些人在此过程中需要对问题负责，毕竟如果是在前面已经有借鉴的情况下再次发生，就不是无心之失可以解释的了。