近日微盟出现了大规模系统故障，根据官方通告:微盟研发中心运维部核心运维人员贺某，于2月23日晚18点56分通过个人VPN登入公司内 跳转机，因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏；这是一起运维部门核心员工在生产环境的“删库”操作引发的。
本次删库事件引发了IT技术圈的广泛关注；小编整理了 友们比较好奇的几个问题：运维产生的危害为何这么大？修复期为何这么久？微盟是否存在管理漏洞？类似事件如何预防？为此，小编对沃顿在线负责人朱磊和业界知名软件研发工程效能专家茹炳晟进行了专访，内容整理如下。
单个运维人员产生的危害为何这么大？
信息化时代，没有孤立的个体
信息化时代，系统集成变得度越来越高，作为单个个体是完全可以摧毁一个系统的。但是在信息时代以前，这是难以想象的。
人类历史上，一个个体决定一个民族，一个朝代历史走向的事情，也不是没有发生过，但必须是那些位高权重的大人物。此次事件的主角作为公司的核心运维人员，显然在这种事情拥有天然的便利。
云上服务，运维权限过大
谈到运维和DevOps，我们会发现，很多IT运维人员的权限过大，甚至会大到可以摧毁一个系统/产品，这种在一些创业公司中比较常见。微盟公司现提供的服务是部署在服务器上的。
为了便于工作，运维工程师手里掌握着高权限的账 ，可以对服务器进行任何操作。例如，这次删库事件运维工程师使用高权限账 把服务器上的文件删除，直接导致服务器崩溃，进而造成公司业务中断。
难以避免的人为因素
抛开运维人员是否会出于恶意去破坏自己的系统，但作为人的操控来讲，忙中出错的概率还是不小的。所以，这个问题带给我们的启示是，要充分重视个人在系统中可能产生的作用，必须对个人的行为进行严格的监管，避免由个人引发的系统性故障。
恢复时间为何这么长？
据介绍，一般来说数据备份要对最近的数据至少在30分钟内可以恢复。既然微盟已经在全力抢修，腾讯云也表示在给予技术协助，那全面恢复的时间为什么还要这么久呢？
影响因素一：灾备出现问题
运维人员对生产服务器进行了文件删除，并没有提到对备份服务器进行破坏。如果微盟有着高性能灾备，那么恢复服务在技术层面是没有太大难度的。
但是根据目前官方的信息推测，数据库应该是在生产环境的本地库发生了不可逆的删除，否则不会需要这么长时间。
假定本地生产库没了，那唯一的方法就是借助远程灾备的全量备份库来恢复，但这也会引发出一系列的问题，比如远程库容量大，需要大量的 络传输时间。
影响因素二：恢复流程复杂
就数据恢复来讲，受到的影响因素较多，这其中包括了应急团队响应速度、技术能力、被删文件体积、文件被删后继续频繁读写硬盘等等，这些任何一个出现问题都影响恢复时间。
影响因素三：技术实现难度大
不熟悉运维的人可能会觉得恢复是比较简单：不就是重装一下系统或者恢复下数据库备份吗，其实这其中的涉及技术比我们想的要更复杂。
1.业务架构复杂，现在常用的软件的架构及部署是极其复杂的，在微服务大行其道的今天，每个微服务本身就是一个集群，微服务和微服务之间还有各种依赖关系，同时每个微服务都有可能会和数据库打交道，光理清楚这些服务之间的依赖和配置就够大家受的了。
2.时间紧，任务重，此次事件涉及到几乎是整体架构的梳理，难度不亚于从0到1搭建一个新系统，再加上客户压力和舆论压力，难度可想而知。
3.数据库问题，有可能是增量备份的完整性欠缺，此外，还会出现由于近期的数据Scheme变更引发的备份数据兼容性问题等。这些都需要研发人员和运维人员的共同推进，这些都会导致工作量加大和时间的推迟。
微盟的问题：技术管理和数据灾备不能忽视
成本是影响公司数据管理投入的直接因素
微盟删库事件，暴露了部分互联 公司内部数据管理的混乱。按理像微盟这种体量的公司对于数据安全和保护的投入和重视程度理应是非常大的。
但是此次事件背后隐藏的是利益问题，对以微盟为代表的企业来说，数据安全和保护对于是比较大的成本支出，并不能直接创造营收，所以往往有些还在成长阶段的企业不会重视投入，很多制度保护也往往流于表面。
对大公司来说，如果忽视数据安全会有可能带来更大的损失，所以一般来讲大公司对数据安全对投入和措施比较规范，类似微盟这样对删库问题基本不会出现。
互联 公司管理内功欠缺
21世纪是属于互联 等新产业的时代，但是管理问题一直是新兴互联 企业前行的最大阻碍，企业管理的意义，估计每个公司的高管都懂，任何一个企业的领导掌舵者都不会忽略的问题，但是能够真正做到真的很难。
互联 发展迅速的同时也埋下了隐患，浮躁的行业使得互联 公司高层管理没有时间学习管理，没有时间苦炼内功，这次微盟事件，给互联 公司上了重要的一课，也希望更多公司能吸取教训。
如何避免此类事件？
此次事件给微盟和微盟客户造成了巨额损失，对于整个事件背后暴露的管理与技术漏洞等问 题，其他公司甚至整个行业需要如何避免类似问题再次发生呢？小编总结了茹炳晟和朱磊的建议，来从运维和公司两个角度聊一下。
对于运维技术人员：
1.避免任何形式的人肉运维
如今随着软件架构复杂性的不断提升，从早期的“人肉”运维，到现在的DevOps，再到目前初绽头角的AIOps，运维的理念和技术手段也一直都在不停地演进。但这其中人的影响一直存在。
这也是为什么大型企业都会建立比较完善的分级和分层发布流程，层层监管和审批，避免个人单点故障的无限放大。当然，这些监管和审批必须要纳入到由技术驱动的DevOps流水线中来完成，而不是靠传统的领导签字来完成。
所有对生产环境的变更，像系统参数、安全策略、 络配置、应用参数、环境参数、文件更新和数据库更新都应该是通过DevOps的流水线走正式的发布上线流程，所有的操作必须是由脚本或者自动化代码来完成，任何个人都不应具有直接在生产环境上执行命令操作的场景。
因此应该避免任何形式的人肉运维，倡导“人管代码，代码管机器”，而不是“人直接管机器”。
2.未雨绸缪，做好灾备演练
一般来讲待办事项分为两类，分别是既重要又紧急的事和非常重要但是不紧急的事，也就是运维同学经常面对的各种救火型任务（生产环境Bug fix、Hotfix发布等）和未雨绸缪型任务（自动化运维、监控数据分析统计、模型获取与优化等）。
理想情况下，应该将更多的时间放在未雨绸缪型任务上，而只将少量的时间放在救火型任务上。当把未雨绸缪型任务做好了，那么救火的概率就下降了。
但是现实情况正好相反，运维同学天天忙于各种发布、各种线上救火，根本没有精力去偿还各个时期欠下的技术债，这种模式就难逃成本中心的宿命。
因此运维部门在平时定期开展一些故障演练的实践是很必要的，结合混沌工程（Chaos Engineering）的思想，来确保系统的鲁棒性和可维护性，以此来应对各类突如其来的“黑天鹅”事件。
“纸上得来终觉浅，绝知此事要躬行”，只有在实际故障演练的过程中，我们才有可能得到很多宝贵的一手实战经验，光靠想是不行的。
对于整个公司：
1.运维是成本中心的谬论
在很多人的眼中，运维部门都被归在成本中心，简单来讲就是花钱的部门。运维是成本中心的宿命论对于运维的发展其实是很不利的，如果运维部门长期处于机械性的发布执行和生产环境救火的状态，那么就会陷入无止境的恶性循环。
很多时候，我们总是解决了看得见的问题，但是看不见的问题往往会在看不见的地方聚集，这类问题一旦出现就都是大问题。所以我们需要转变运维是成本中心的思维定式，让运维的同学能够更积极地去思考和解决系统性的问题。
2.做好危机公关
微盟的这次删库事件，对很多行业用户造成了很大的影响，但是面对危机，微盟所表现出来的 会责任感是值得我们借鉴和学习的。
面对突如其来的故障，微盟并没有试图掩盖真相，而是第一时间在其官 发表声明，解释事情的背后原因，并且明确告知了后阶段的恢复计划以及明确的时间节点。
多一些真诚，少一些套路，有问题一起扛，是面对此类危机最好的方法。如果你试图掩盖，盖不住了就撒谎，接着就像张宇唱的那样“用一个谎言圆一个谎言”，必然会让自己陷入更深层次的危机。
采访对象：
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！