不只是运维，更要“运筹帷幄”

引言：

运维是一个比较专业的领域，需要有专业的技术人员来负责。企业应该通过加强对运维的规范和管理，从而来防范和规避事故发生的可能性与风险。

2017年11月23日下午16点22分，维金的员工都在有条不紊地忙着手头的工作。突然售后部门的工作人员接到某客户发来的邮件说由于失误执行了数据库初始化脚本，导致生产数据丢失，需要维金协助进行数据恢复。由于数据丢失，整个生产环境已经完全停止运作，客户方面非常着急。维金的售后人员也意识到问题的严重性和紧迫性，立即向领导进行了汇报并把此问题的严重程度定义为P1等级，同时协调实施、运维等部门的相关工作人员成立应急处理小组，展开了紧急支援工作。

1

事故分析与处理

经了解，事故的起因是客户的技术人员同时开了多个客户端窗口去连接线上生产环境数据库和线下测试环境数据库。由于窗口众多，再加上工作比较忙碌，技术人员一时没有分清楚操作所在的环境，就错误地把应当在测试环境下执行的系统初始化建库建表的脚本在生产环境下进行了执行。系统建库建表的脚本为了能够重复执行，会在执行前先把已存在的库和表会删除再重建，因此导致了生产数据丢失。由于客户方面没有资深专业的MySQL DBA，所以在事故发生后就立即求助于维金，希望维金专业的运维团队能够给予援助。

针对该事故状况，维金的应急处理小组凭借多年来服务众多客户所积累的丰富经验，果断地制定并实施了解决方案：让客户暂时停掉前端所有应用，防止系统内部一些定时任务在数据库产里面产生数据；同时拿客户前一天晚上0点的全备加上当天的Binlog在一台临时的数据库上把数据恢复，启动所有前端应用验证业务流程，待确保一切业务流程和数据没有问题后，再把临时库做一个全备，用临时库的全备在生产环境的主库上进行数据恢复

维金团队一直忙碌到当天晚上10点多，完成了对生产数据库的数据恢复工作。经过验证，系统运行正常，数据也恢复到了故障发生之前的时间点，客户对维金专业的技术支援和高效的服务表达了由衷的肯定与感谢。

2

回看过往，无独有偶

近年来类似的事故其实并不少见，而事故的“始作俑者”也基本都和企业的系统运维有关。早在2015年5月，携程网就发生过严重的网站瘫痪事件，而且瘫痪时间长达数小时之久，在当时曾引起广泛关注和议论。对于事故原因，社交网站和微信群中都有不同猜测，包括数据库被物理删除、业务代码被删除、安全漏洞、黑客攻击、员工认为破坏等。携程官方给出的回应是，因为携程部分服务器遭不明攻击，从而导致官方网站及APP无法正常使用。但根据业内人士分析，最大的事故起因可能还是运维人员在正常的批量操作时出现了误操作。而之后持续数小时的未恢复成功更是让外界对携程的系统运维能力和管理机制产生了诸多猜测和质疑。

最近一次引起关注的则是发生在今年初的GitLab误删数据库事件。2017年1月31日晚上，GitLab通过Twitter发文承认300G生产数据因为UNIX运维的误操作已经被彻底删除。与携程不同的是，在事故发生后，GitLab没有采取回避或极力掩盖事实真相的做法，而是选择在YouTube上直播整个修复过程，并把整个事件的回顾在第一时间就放到了GoogleDoc上。事后，又发了一篇Blog来说明整个事情经过。原本可能会对企业形象产生负面影响的事故因为这一开诚布公的处理方式反而赢得了一片好评。

3

把专业的事交给最专业的人来做

通过以上几个案例我们可以看到，系统数据丢失或被删除都跟企业内部的系统运维能力和管理有着直接的关联。从表面上看，事故主要是由技术人员的人为误操作导致的，但究其根本，还是因为企业本身的运维不够规范和健全，没有从技术和管理上去防范和规避事故发生的可能性与风险。

在本次针对客户事故的应急处理中，维金在运维方面所表现出来的技术能力和经验是毋庸置疑的。事实上，近期就有客户把技术开发、项目交付、售后支持、系统运维等统统交由维金来负责。维金结合客户的情况和业务特点，为其量身定做了一体化全方位的服务。经过一段时间内的几次重大活动测试验证，维金专业的服务已经赢得了客户的好评。

尤其值得一提的是，维金系统自设计之初就特别注重稳定性和易维护性，避免了客户使用时发生重大故障，并且减轻了客户的运维难度。

当然，运维是一个比较专业的领域，需要有专业的技术人员来负责。如果企业自身没有专业的技术人员可以进行操作和管理，则完全可以考虑把运维工作交给像维金这样的专业团队来负责，然后可以集中精力专注在自身业务的发展上，从而获得更大的成功。对于企业而言，如果可以“运筹帷幄之中，而决胜千里之外”，那么又何乐而不为呢？