前段时间公司线上环境的游戏服务器出现了严重的运维事故，之前一直没有抽时间总结下来，最近过完年相对比较空，总结一下以防后患。事情的起因是，程序员测试时误删除了数据库大部分的表文件，恢复数据库时又发现备份机制存在问题，根本无法恢复数据。值得庆幸的是用户和角色表没有删除，而且大部分游戏行为都有相应的log记录，最后通过log记录使用大数据分析恢复了玩家的大部分数据。整个过程耗时3天，3天基本没有怎么睡觉。最终的结果还算是好的，停服3天，虽然玩家还是有部分数据丢失，但是我们给予了大幅度的补偿，基本玩家反馈还是正面的，比我们开服前的预期要好。
这个事故的起因，现在总结主要是一下几个方面。
程序员长时间的工作，出事的时间已经是凌晨一点多了，整个身体状态已经不是很好。
使用工具连接多个数据库进行操作，其中包括测试服务器、本地服务器和线上服务器，操作时来回切换，长时间的多窗口操作，以至于后面自己都搞混了。
因为使用了工具（navicat），并没有通过命令去更新数据库，为了方便直接在可视界面里选择删除了表，虽然结果其实一样，但是界面操作确实会容易产生误操作的可能。
虽然有从备份数据库，但是删除操作很快同步到了从数据库上，没有办法在有效时间里使用从数据库恢复主数据库。
备份机制存在问题，在数据出现问题后，没有办法通过备份来恢复数据库。
所有的这些问题凑到一起，就出现了前面说的严重事故，有多严重，如果不是运气好没有删除用户和角色表，游戏的所有数据就都没有办法恢复了，相当于给所有用户删档。
这个事情已经过一段时间了，这段时间里大家都在反思我们到底存在什么问题，下面先总结一下。
线上环境不应该给程序员权限直接操作，应该由专职的运维人员操作。
线上环境直接使用工具连接，包括服务器、数据库，然后多窗口混合工作，本地服、测试服、线上服不停切换，难免会出问题。
不应该使用工具直接操作服务器和数据库，包括在服务器上使用shell命令、在数据用sql语句修改数据库。
备份机制存在问题，并且没有对备份进行校验和定时检查。直到用时才发现不能用。
这些问题，只要又一个环节是好的，其实都可以避免事故的发生。
正好这段时间出来gitlab数据库删除事故，也有人进行了分析，我觉得还是很有道理的，里面提到了一个就是关于反思问题的。
反思问题，就是不停的问为什么，直到找到问题的根源为止。我们来看看Wikipedia上关于5 Whys的操作原则。
需要在公司层面管理提问过程，分析本身要找正确的团队来进行，对困难的问题考虑安排一个领导者。
使用纸或白板而不是用电脑。
写下问题，并且保证所有人都能看懂。
区分原因和症状。
注意因果关系。
确保根本原因导致了错误发生，通过“因此”来反推出结论。
努力使你的答案更加精确。
一步步的寻找问题根源，而不是直接跳到结论。
基于客观的事实和知识。
评估过程而不是人。
绝不要把“人为失误”和“工作疏忽”当成问题的根源。
营造信任和真诚的氛围。
不断的问“为什么”直到找到问题的根源。找到原因才能防止问题再次发生。
当你追寻“为什么”的答案时，应该从用户的角度出发。
基于上面的“5 whys”原则，一定可以准确的分析出问题的根源所在。
事情发生后，经过一段时间的反思，公司层面也做了一系列的调整。找了专门的运维人员负责运维相关工作，并让运维人员制订了更加规范的运维操作流程，数据库也换成能提供更好备份支持的云数据库。同时更加规范了运维的制度与流程。
但是我个人觉得，运维方面的失误并不是光靠规范制度、优化流程就能从根本上解决的，一定还是要从技术层面着手才能更好的解决。
首先，所有的运维操作，尽量做到自动化，只有自动化的工具脚本才能从根本上避免人为失误。
另外，通过技术手段设计更高可用性的系统来更好的避免问题。
- 本文固定链接: http://www.wy182000.com/2017/02/07/线上环境运维随想/
- 转载请注明: wy182000 于 Studio 发表
