谨慎， 是一个运维人员必备的态度， 每一个命令，每一个操作都要稍微有个停顿，以便于让自己在最后时刻能及时发现自己的失误，不至于造成无法挽救的后果。所以，一个优秀的运维不在于做事有多快，而是他可以在上千个日日夜夜中，谨慎、无误，不急不躁的的完成每一件事。泰山崩于前而面不改色，任你世界再繁华我亦无动于衷。
你不是运维，所以你以为删库跑路只是个让人发笑的梗，而我是个运维，虽历尽刀山火海，但仍不免会有失误；我给你说服务出了故障，停个服，有可能是在默默恢复数据；所以你不要嘲笑别家公司删了库，有可能只是自家同事备份做的好；不是你遇不到，而是你不知道；
带了一个满意的新人，真是一件令人幸福的事情
带新人就像带徒弟，当你的徒弟基础知识扎实，思维又灵活的时候，你应该知道这是一件多么幸福的事情。就像得到了一个人生知己，虽不说心意相通，但当你说一件事，教一个知识点，他便能瞬间领悟，不用费太多口舌去解释，这是一个多么兴奋的事啊，又可以有更多的时间偷个懒了。
待时机成熟，我便把一个普通的小游戏交给了他，让其算是练个手。 有疑问的地方也会很主动的请教我，有什么想法也会先告诉我，然后再实施，也算是慢慢步入正规。
删库跑路？他真的把数据库删了
“哥， 我好像把数据库删了”， 当他铁青着脸，一脸惊恐，而又磕磕绊绊的告诉我的时候， 我甚至没有听到他说什么， 声音细若蚊声，惊恐的看着我。 等我意识过来他说的意思的时候，我也是愣了片刻，随后便赶忙登录服务器查看状况。果不其然，实例里面除了默认库，应用库已经没了。“闯大祸了”。我缓了缓神，强迫自己淡定安静下来，心里已经飞速思考解决方案，埋怨已经没有用了，并且只会引起更多的人注意，需要想一个三全其美的方法：如何把这么严重的事情变成一次普通的故障？如何让更少的人知道这件事？如何将数据全部恢复？
拯救新人，蒙骗项目组，恢复数据
最主要是恢复数据，然后为了保护新人，不能让项目组知道我们把数据库删了。 我假装淡定，走到项目组PM身边，撒谎告诉他们：“刚刚接到告警，显示我们的MySQL实例无法连接，让他们测试下游戏是不是正常的”。当然得到的游戏异常的结果，数据库都没了，正常了都是怪事。我随即说： “我这边需要调试一下，你持续的刷新游戏， 我们微信交流”。然后就回到自己的工位。让他持续刷新游戏就是为了防止他跑来看我操作，恢复数据他应该还是能看懂的，要是被他猜到了怎么办，还是不让他看到比较好。
数据安全一向是重中之重， 机器可停，服务可断，但是数据不能丢失，这是做为一个运维的底线。在运维的理念中，做一件事情，我们需要提前考虑好最坏的情况，制定出如何在最坏的情况下亦能将损失降到最低。
数据恢复其实对于我们来说是一个简单的事情， 通过调整备份周期，备份程序自动启动，将每个实例的数据和bin log日志都进行相应的备份，然后恢复时再将备份导入实例， 另外如果服务器存在，则将服务器内的bin log进行操作回放，如果服务器也销毁了，就使用备份的bin log进行恢复。
数据恢复成功之后， 查看了服务日志，也没有任何报错之后，便告诉项目组多刷新几次。项目组回馈游戏已经正常了，我这边也终于可以长长的呼了一口气。
秋后算帐，关起门来批评
毕竟是一次故障， 项目组多次询问此次故障的原因，我均以实例莫名故障为由搪塞过去，并表示自己也还在继续查原因，等原因查明，必然会再次告知。
外部因素已消除，自己内部还是要进行批评总结的，我将此事告知了经理，并告知了处理结果，经理脸色也是由阴转晴，并对其进行了严厉的批评，并告知我以后他操作数据时，由我全程观察。
而删库原因也是很简单，项目组准备开放葡萄牙区域，需要单独创建葡萄牙服务专属的数据库，所以操作时，本应该创建game_pr库，但是字母拼错，写成了game_br，所以就想着删除重建，但是，不知为何，却删除了game数据库，也就是目前线上的数据库，所以才造成此次故障。
身为一个一线运维人员， 谨慎、小心 一向是我们的第一要则，哪怕前方有刀山向你袭来，有火海向你扑来，你都要保持淡定，头脑清醒。你的一行命令足以造成难以恢复的灾难。当你感觉自己累了，大脑不清醒了，请你闭上眼睛，适当的休息。开弓没有回头箭，谨慎的对待你所写下的每行代码。
閱讀更多 感悟運維 的文章
