【51CTO原创稿件】
上周微盟出现了大规模系统故障，根据官方通告:微盟研发中心运维部核心运维人员贺某，于2月23日晚18点56分通过个人VPN登入公司内网跳转机，因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏；这是一起运维部门核心员工在生产环境的“删库”操作引发的。
本次删库事件引发了IT技术圈的广泛关注；小编整理了网友们比较好奇的几个问题：运维产生的危害为何这么大？修复期为何这么久？微盟是否存在管理漏洞？类似事件如何预防？为此，小编对沃顿在线负责人朱磊、阿里云OLAP产品团队高级产品专家韩锋和业界知名软件研发工程效能专家茹炳晟进行了专访，内容整理如下。
单个运维人员产生的危害为何这么大？
信息化时代，没有孤立的个体
信息化时代，系统集成变得度越来越高，作为单个个体是完全可以摧毁一个系统的。但是在信息时代以前，这是难以想象的。人类历史上，一个个体决定一个民族，一个朝代历史走向的事情，也不是没有发生过，但必须是那些位高权重的大人物。此次事件的主角作为公司的核心运维人员，显然在这种事情拥有天然的便利。
云上服务，运维权限过大
谈到运维和DevOps，我们会发现，很多IT运维人员的权限过大，甚至会大到可以摧毁一个系统/产品，这种在一些创业公司中比较常见。微盟公司现提供的服务是部署在服务器上的。为了便于工作，运维工程师手里掌握着高权限的账号，可以对服务器进行任何操作。例如，这次删库事件运维工程师使用高权限账号把服务器上的文件删除，直接导致服务器崩溃，进而造成公司业务中断。
难以避免的人为因素
抛开运维人员是否会出于恶意去破坏自己的系统，但作为人的操控来讲，忙中出错的概率还是不小的。所以，这个问题带给我们的启示是，要充分重视个人在系统中可能产生的作用，必须对个人的行为进行严格的监管，避免由个人引发的系统性故障。
恢复时间为何这么长？
据介绍，一般来说数据备份要对最近的数据至少在30分钟内可以恢复。既然微盟已经在全力抢修，腾讯云也表示在给予技术协助，那全面恢复的时间为什么还要这么久呢？
影响因素一：灾备出现问题
运维人员对生产服务器进行了文件删除，并没有提到对备份服务器进行破坏。如果微盟有着高性能灾备，那么恢复服务在技术层面是没有太大难度的。但是根据目前官方的信息推测，数据库应该是在生产环境的本地库发生了不可逆的删除，否则不会需要这么长时间。假定本地生产库没了，那唯一的方法就是借助远程灾备的全量备份库来恢复，但这也会引发出一系列的问题，比如远程库容量大，需要大量的网络传输时间。
影响因素二：恢复流程复杂
就数据恢复来讲，受到的影响因素较多，这其中包括了应急团队响应速度、技术能力、被删文件体积、文件被删后继续频繁读写硬盘等等，这些任何一个出现问题都影响恢复时间。
影响因素三：恢复预案不完备
当企业遭受到如此重大的破坏时，是否有完整的恢复预案并真实演练过，将变得非常重要。如果之前没有相关准备，很难在出现问题时快速响应，并将问题涉及范围、恢复手段、相关风险、所需资源等一一考虑清楚。仓促应战的话，难免顾此失彼，且对可恢复的程度、时间等，也很难预估。
影响因素四：技术实现难度大
不熟悉运维的人可能会觉得恢复是比较简单：不就是重装一下系统或者恢复下数据库备份吗，其实这其中的涉及技术比我们想的要更复杂。
1.业务架构复杂，现在常用的软件的架构及部署是极其复杂的，在微服务大行其道的今天，每个微服务本身就是一个集群，微服务和微服务之间还有各种依赖关系，同时每个微服务都有可能会和数据库打交道，光理清楚这些服务之间的依赖和配置就够大家受的了。
2.时间紧，任务重，此次事件涉及到几乎是整体架构的梳理，难度不亚于从0到1搭建一个新系统，再加上客户压力和舆论压力，难度可想而知。
3.数据库问题，有可能是增量备份的完整性欠缺，此外，还会出现由于近期的数据Scheme变更引发的备份数据兼容性问题等。这些都需要研发人员和运维人员的共同推进，这些都会导致工作量加大和时间的推迟。
微盟的问题：技术管理和数据灾备不能忽视
成本是影响公司数据管理投入的直接因素
微盟删库事件，暴露了部分互联网公司内部数据管理的混乱。按理像微盟这种体量的公司对于数据安全和保护的投入和重视程度理应是非常大的。但是此次事件背后隐藏的是利益问题，对以微盟为代表的企业来说，数据安全和保护对于是比较大的成本支出，并不能直接创造营收，所以往往有些还在成长阶段的企业不会重视投入，很多制度保护也往往流于表面。对大公司来说，如果忽视数据安全会有可能带来更大的损失，所以一般来讲大公司对数据安全对投入和措施比较规范，类似微盟这样对删库问题基本不会出现。
互联网公司管理内功欠缺
21世纪是属于互联网等新产业的时代，但是管理问题一直是新兴互联网企业前行的最大阻碍，企业管理的意义，估计每个公司的高管都懂，任何一个企业的领导掌舵者都不会忽略的问题，但是能够真正做到真的很难。
互联网发展迅速的同时也埋下了隐患，浮躁的行业使得互联网公司高层管理没有时间学习管理，没有时间苦炼内功，这次微盟事件，给互联网公司上了重要的一课，也希望更多公司能吸取教训。
如何避免此类事件？
此次事件给微盟和微盟客户造成了巨额损失，对于整个事件背后暴露的管理与技术漏洞等问 题，其他公司甚至整个行业需要如何避免类似问题再次发生呢？小编总结了茹炳晟和朱磊的建议，来从运维和公司两个角度聊一下。
对于运维技术人员：
1.避免任何形式的人肉运维
如今随着软件架构复杂性的不断提升，从早期的“人肉”运维，到现在的DevOps，再到目前初绽头角的AIOps，运维的理念和技术手段也一直都在不停地演进。但这其中人的影响一直存在。
这也是为什么大型企业都会建立比较完善的分级和分层发布流程，层层监管和审批，避免个人单点故障的无限放大。当然，这些监管和审批必须要纳入到由技术驱动的DevOps流水线中来完成，而不是靠传统的领导签字来完成。
所有对生产环境的变更，像系统参数、安全策略、网络配置、应用参数、环境参数、文件更新和数据库更新都应该是通过DevOps的流水线走正式的发布上线流程，所有的操作必须是由脚本或者自动化代码来完成，任何个人都不应具有直接在生产环境上执行命令操作的场景。
因此应该避免任何形式的人肉运维，倡导“人管代码，代码管机器”，而不是“人直接管机器”。
2.未雨绸缪，做好灾备演练
一般来讲待办事项分为两类，分别是既重要又紧急的事和非常重要但是不紧急的事，也就是运维同学经常面对的各种救火型任务（生产环境Bug fix、Hotfix发布等）和未雨绸缪型任务（自动化运维、监控数据分析统计、模型获取与优化等）。
理想情况下，应该将更多的时间放在未雨绸缪型任务上，而只将少量的时间放在救火型任务上。当把未雨绸缪型任务做好了，那么救火的概率就下降了。但是现实情况正好相反，运维同学天天忙于各种发布、各种线上救火，根本没有精力去偿还各个时期欠下的技术债，这种模式就难逃成本中心的宿命。
因此运维部门在平时定期开展一些故障演练的实践是很必要的，结合混沌工程（Chaos Engineering）的思想，来确保系统的鲁棒性和可维护性，以此来应对各类突如其来的“黑天鹅”事件。“纸上得来终觉浅，绝知此事要躬行”，只有在实际故障演练的过程中，我们才有可能得到很多宝贵的一手实战经验，光靠想是不行的。
对于整个公司：
1.运维是成本中心的谬论
在很多人的眼中，运维部门都被归在成本中心，简单来讲就是花钱的部门。运维是成本中心的宿命论对于运维的发展其实是很不利的，如果运维部门长期处于机械性的发布执行和生产环境救火的状态，那么就会陷入无止境的恶性循环。
很多时候，我们总是解决了看得见的问题，但是看不见的问题往往会在看不见的地方聚集，这类问题一旦出现就都是大问题。所以我们需要转变运维是成本中心的思维定式，让运维的同学能够更积极地去思考和解决系统性的问题。
2.做好危机公关
微盟的这次删库事件，对很多行业用户造成了很大的影响，但是面对危机，微盟所表现出来的社会责任感是值得我们借鉴和学习的。面对突如其来的故障，微盟并没有试图掩盖真相，而是第一时间在其官网发表声明，解释事情的背后原因，并且明确告知了后阶段的恢复计划以及明确的时间节点。
多一些真诚，少一些套路，有问题一起扛，是面对此类危机最好的方法。如果你试图掩盖，盖不住了就撒谎，接着就像张宇唱的那样“用一个谎言圆一个谎言”，必然会让自己陷入更深层次的危机。危机之下，我们要的是公开的信息，这样才能减少公众的猜测，抵制黑公关，并获得大家的理解和支持。
3. 练好“内功”
面对类似疫情这类突发事件，首先让员工知悉真实情况，并做好必要的宣导工作。从员工角度来讲，一般能够理解此类情况，并愿意付出。其次是要做好工作量评估及必要的人员安排，包括值班、轮休等。最为重要的一点，是负责人到岗，与员工一起承担；一方面便于快速响应、快速决策；一方面减少员工压力，有利于公司业务的快速开展。
还有对于管理层来讲，应重视技术工作（包括基础运维）的重要性。从团队构建上予以倾斜，建立起一支有战斗力的技术团队。从人才角度上，在“选育用留”多个环节，把握公司价值观，将真正认同公司价值、愿意付出的同学选到、用好；淘汰不合格人员。
最新消息
2020 年 2 月 25 日，微盟发布公告称，公司线上生产环境及数据遭到员工恶意破坏，导致公司系统服务不可用。经过几天的“抢救”，3 月 1 日，微盟再次发布公告称，数据已全部找回，将于 3 月 2 日进行系统上线演练，于 3 月 3 日上午 9 点恢复数据正式上线，同时针对受到影响的商家也给出了赔付计划。
赔付计划
根据公开资料显示，微盟目前的渠道代理商超 1600 家，注册商户超 300 万。此次微盟宕机或导致 300 万商家生意停摆，损失巨大。因此，微盟也公布了商家赔付计划，整体准备了 1.5 亿元人民币赔付拨备金，其中微盟公司承担 1 亿元，管理层承担 5000 万元。
针对商家因系统不可以而造成的不同损失，微盟也制定了不同的赔付方案：
现金赔付计划
针对因系统不可用而造成利润损失的商户，微盟将按照商家边际贡献利润额进行赔付，具体公式计算如下：边际贡献利润额 = 日均收入×行业平均边际贡献利润率×系统故障时间
流量赔付计划
针对因系统不可用而造成流量损失的商户，微盟将给予腾讯广告 50000 曝光次数的流量补偿，并且提供账户运营服务，同时再延长 SaaS 服务有效期两个月。
放弃自建数据库，基础设施全力上云
以上是经济方面的赔偿，在技术方面，此次核心运维对微盟生产环境和数据造成破坏，使得商家对微盟系统安全和稳定性产生了质疑，同时也给微盟自己敲响了警钟。
微盟在 3 月 1 日发布的公告中称，微盟将会支持基础设施全力上云，逐步放弃自建数据库服务 ，迁移到腾讯云数据库（CDB），增加数据库跨可用区和异地灾备的能力，同时将黑石 1.0 物理机全面升级黑石 2.0，全面使用云主机。
除了之外，微盟还宣布将加强数据安全管理机制和安全灾备体系建设。
采访对象：
1.茹炳晟：业界知名实战派软件质量和研发工程效能专家，腾讯云最具价值专家，中国商业联合会互联网应用技术委员会智库专家，畅销书《测试工程师全栈技术进阶与实践》的作者，“软件测试52讲-从小工到专家的实战心法”的专栏作者。现任Dell EMC中国研发集团资深架构师，历任eBay中国研发中心测试基础架构技术负责人，HP软件中国研发中心资深架构师、性能测试专家，Alcatel-Lucent高级技术主管，Cisco中国研发中心资深工程师等职位，具有超过16年的软件研发和技术管理经验。
2.朱磊：专注运维安全的北京沃顿在线信息技术有限公司创始人，《暗战：数字世界之战》一书作者。他曾任京东研发系统安全经理，具有多年的互联网信息安全管理经验，丰富的信息安全理念和多个安全系统架构经验。
3.韩锋：花名：群峰，阿里云数据库产品团队高级产品专家，CCIA（中国计算机行业协会）常务理事，Oracle ACE，dbaplus社群联合创始人，ACMUG主席团成员、专家组成员，《SQL优化最佳实践》作者。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
