包含系统运维事故事件的词条

本篇文章给大家谈谈系统运维事故事件，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享系统运维事故事件的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、微盟事件真相是什么？
• 2、出现运维事故后，你会怎么办？
• 3、如果微信被运维删库、跑路，会造成什么恐怖的后果？你怎么看？
• 4、如何正确面对信息系统的故障、事故和问题

微盟事件真相是什么？

事情经过

2020年2月23日18时56分许，微盟核心运维贺某酒后因生活不如意、无力偿还网贷等个人原因，在其暂住地上海市宝山区逸仙路XXX弄XXX号XXX室，通过电脑连接公司VPN、登录公司服务器后执行删除任务，将微盟服务器内数据全部删除，导致微盟自2020年2月23日19时起瘫痪，300余万用户(其中付费用户7万余户)无法正常使用该公司 SaaS 产品。(上述来源系统运维事故事件：中国裁判文书网)

2月25日，我们紧急恢复系统运维事故事件了核心业务的线上生产环境，新用户使用不受影响，并提供老用户临时过渡方案，确保商家在数据暂时没有恢复的情况下可以正常经营。

2月28日，我们恢复了所有业务的线上生产环境，并且开放了老用户登录，以及恢复了微站产品的所有数据。

截止到3月1日晚8点，在腾讯云团队协助下，经过7*24小时的努力，我们数据已经全面找回，由于此次数据量规模非常大，为了保证数据一致性和线上体验，我们将于3月2日凌晨2点进行系统上线演练，将于3月3日上午9点数据恢复正式上线。

此次事故给商家经营造成了严重的影响，公司管理层对此深感自责和愧疚，我们准备了1.5亿元人民币赔付拨备金，其中公司承担1亿元，管理层承担5000万元。在紧抓数据恢复的同时，也在同步研究商家赔付方案，我们拟定了现金赔付计划和流量赔付计划供商家选择。

同时此次事故也暴露出公司在数据安全方面出现了管理漏洞。事故发生后，我们加强了内部流程控制管理，同时邀请外部数据安全专家一起来评估数据安全保障方案，并迅速制定了一份数据安全保障计划，以杜绝此类事故的再次发生。

赔付计划

此次事故给商家经营造成了严重的影响，公司管理层对此深感自责和愧疚。事故发生后，公司管理层在紧抓数据恢复的同时，也在同步研究商家赔付方案。

首先针对此次赔付计划，我们准备了1.5亿元人民币赔付拨备金，其中公司承担1亿元，管理层承担5000万元。其中公司董事会主席兼首席执行官孙涛勇承担3500万元，公司执行董事兼首席技术官黄骏伟承担500万元，公司执行董事兼智慧商业事业群总裁方桐舒承担500万元，公司执行董事兼智慧营销事业群总裁游凤椿承担500万元。

其次整个赔付方案中，我们既要考虑商家因系统不可用而造成的利润损失，同时也要考虑系统不可用而带来的流量损失，因此我们的赔付计划做了两个不同的方案供商家任选其一。

01

现金赔付计划

我们会针对因系统不可用期间商家边际贡献利润额进行赔付，具体公式计算如下：

边际贡献利润额=日均收入×行业平均边际贡献利润率×系统故障时间

(其中日均收入等于该商家在2020年2月17日晚7点至2020年2月23日晚7点在微盟系统中产生的实际成交额除税后的平均值;边际贡献利润率是指在收入(不含税)基础上扣除商品成本、仓储及物流费及推广费、销售佣金等与商品服务销售及交付过程直接相关的费用之后的边际贡献利润占收入的比例;行业边际贡献利润率最终参考值将以研究机构公开报告为准;系统故障时间自2月23日晚7点至3月3日上午9点)

02

流量赔付计划

我们会针对因系统不可用期间的商家给予腾讯广告50000曝光次数进行流量补偿，并且提供账户运营服务，同时再延长SaaS服务有效期两个月。

(其中腾讯广告包括微信朋友圈广告、微信公众号广告、小程序广告等;曝光次数是指该广告被用户看到的次数;运营服务包含广告的创意策划、素材制作、投放执行、数据分析、账户优化、数据报表等运营服务)

最后我们所有的赔付将通过线上赔付系统完成，公司将在接下来一个月左右开发完成线上赔付系统，届时商家可通过登录微盟商户后台，点击申请赔付即可完成。

数据安全保障计划

此次事故暴露出公司在数据安全方面出现了管理漏洞。事故发生后，我们内部在系统自查的同时邀请外部数据安全专家一起来评估数据安全保障方案，现公布措施如下：

措施一：数据安全管理机制全面加固与整改，加强运维平台治理

1、完善数据安全管理制度(涵盖权限、监控、审计方面)，严格执行授权审批制度;

2、使用腾讯云CAM权限系统进行云资源管理，严格执行分级授权和最小集权限制度，对高危险动作执行二次授权制度;

3、建立科学、高效、安全的网络策略，对开发环境、测试环境和生产环境进行严格隔离;使用腾讯云堡垒机替换自建堡垒机，进行细粒度权限分级和授权管理，同时严格审计堡垒机操作日志，发送安全审计报表;

4、加强运维安全流程学习，职业道德学习，法律学习等。

措施二：加强灾备体系的建设，做到多云异地冷备1、建立多云灾备体系，在北京、上海、南京等地区建立全备份的冷备系统架构;2、借助腾讯云的IAAS的底层服务能力，建立高可用的同城双活架构;3、云上所有的云主机，启用每天的快照策略，保证全量和增量备份;4、所有非结构化数据，使用腾讯COS对象存储系统进行归档保存，启用COS的多异地复制功能，数据存放多地，并且COS冷存储，确保数据只增不减;5、建立月、季度级别的定期演练机制和制度
。

措施三：基础设施全力上云1、借助腾讯云数据库MySQL的数据高可用和安全体系，逐步放弃自建数据库服务，迁移到腾讯云数据库(CDB)，快速具备数据库跨可用区和异地灾备的能力;2、黑石1.0物理机全面升级黑石2.0，全面使用云主机。

法院判决

2020年9月，上海市宝山区人民法院认为，贺某行为违反国家规定，删除计算机信息系统中存储的数据，造成特别严重的后果，其行为已构成破坏计算机信息系统罪，应当依法追究刑事责任。公诉机关指控的犯罪事实清楚，证据确实充分，罪名成立。

贺某如实供述自己的罪行，认罪认罚，可依法从轻处罚。辩护人的相关意见本院予以采纳。依照《中华人民共和国刑法》第二百八十六条第二款、第六十七条第三款、第六十四条、《中华人民共和国刑事诉讼法》第十五条之规定，判决如下：

一、贺某犯破坏计算机信息系统罪，判处有期徒刑六年。(刑期从判决执行之日起计算。判决执行以前先行羁押的，羁押一日折抵刑期一日，即自2020年2月24日起至2026年2月23日止。)

二、作案工具笔记本电脑一台依法没收。

出现运维事故后，你会怎么办？

有一次和朋友聊天，他说他们有一次部署出事了，影响还挺大，那次事故后，他们公司对于部署流程增加了更多的审批。

当朋友说完前半句时，我已经猜到下半句，那是很多公司或个人会做出的反应。至于为什么会做出这样的反应，我也不知道。

我问：为什么那次部署会“出事”？

他说：当时部署的人忘记了那台机器上有一条 Iptable 规则，导致了事故。

我就在想，如果有人审批，那次事故就不会发生吗？审批的人就知道那台机器上有一条规则导致事故的发生？然后驳回这次部署吗？连一线的开发和运维都忘记了的 Iptable 规则，“高高在上的审批领导”就更不知道了。

题外话：增加审批流程并不能避免这次事故，只不过当出现事故时，可以更好的定责。然而我又好奇了，这种“审批”是为了解决问题，解决什么问题？，还是为了逃避责任？谁逃避了责任？谁又有责任？

对于这类问题，我心里已经有数了，但想知道这位朋友的回答，就接着问：那么怎么杜绝这类问题呢？

这位朋友说的做法，我之前待的一个团队的做法也差不多：会有一个页面专门记录下每次部署的步骤，步骤由开发人员写，然后由运维人员执行。只是我不知道他们会不会回顾之前所有针对这台机器的部署步骤。

这个团队里有某某大型互联网公司来的架构师和某财务软件公司来的运维，所以，我不负责地推测，我们这个行业很多公司对于配置的管理还没有达到足够的重视，也没有正确的看待。

我笑了，接着问朋友：那我要知道当前机器的“最终状态”，是不是要找出所有部署记录，还要过滤出对这次部署有影响的每一个细节？比如那条 Iptable 规则。

接下来的对话细节已经记不清，也不重要了。重要的是找出针对这类运维事故根本原因及解决办法。

我个人认为这类问题的根本原因在于：

以上只是我个人认为的，不一定正确，欢迎各位读者讨论。

那如何杜绝这类问题呢？

这两个原因可以看作一个，也可以看作两个。但方法都是一样的：

脚本式的配置管理是这样的：

而声明式的配置管理是这样的：

声明式的配置里写的是当前环境的“状态”，语意上，声明式的配置不论你执行多少次，你得到最终的“状态”就是你所声明的，这也就实现了《持续交付》里说的：

这样，你就不用在第1000次部署时，根据前999次部署脚本找出对这一次部署有影响的细节了。

具体实践时，我发现 Ansible 就能很好的做到这点。

将这些配置版本化的好处，就不需要重点说明了。

具体一点的说就是所有环境都使用相同的声明配置，具体到不同环境时，使用变量替换。这样就可以保证所有环境的一致性了。

具体实践方法，还需要根据所在团队调整。你也可以通过本文附录里链接，参考其他人是如何实践的。

关于配置管理

多环境配置管理

如果微信被运维删库、跑路，会造成什么恐怖的后果？你怎么看？

这个问题问的还是很有意思的系统运维事故事件，也是热点问题吧。如果微信被运维删库跑路的话，会造成什么样的结果呢，其它微信就简单的多了，它无这不微盟那么复杂，因为微盟是有更多客户数据的，结果也不太一样，因为它的服务对像并不多，也只是300万，但是数据量反而非常大，所以删库的影响反而更大了，微信被删库的话，结果会是这样的。

怎么系统运维事故事件我的微信登不上去？这是最为常见的。客户基本信息数据丢失了，微信会登不上去，使用手机号登录可能还会提升，没有注册过呢。这个影响是最大的，就是微信数据丢失了，啥啥都没有了。

再有的就是部分数据库的无法使用，比如有微信，可登录，但是好友没有了，朋友圈的数据没有了，备注的用户名没有了，等等，这个是一些相对影响小一点儿的。另外微信因为用户比较大，所以它的用户数据存储应该是分散式的，相对微盟这样的相对集中式管理还是不太一样的，个人认为了，具体的只有腾讯的工程师知道他们的数据存储方式了。

最后就是最恐怖了，那就是微信它有一个钱包账户，里面是有钱的，如果用户的账户信息缺失的话，可能会造成巨大的钱财无户主，想想看，你的钱是不是没有什么保障呢？所以钱最好还是不要放到微信里面好呀。

你好，很负责任的告诉你这种情况几乎不可能发生。

我们从如何删库的方式来分析下系统运维事故事件：

1.SQL清除数据库

企业一般情况下只有开发人员或DBA（数据库管理员）有权限通过SQL操作数据库。 基于数据的重要性，企业一般都有严格的权限限制及SQL审核机制，对操作人员的执行的SQL进行审查，粒度可以精确到执行时间长短、删除等危险性操作、数据查询结果量等，凡是匹配相应的策略，平台将会拒绝执行此类操作。 因此通过SQL达到删库是不可能的。

2.操作系统级别格式化或删除

操作系统级别的格式化或删除一般只有系统管理员有权限执行，但是以目前的自动化水平， 服务器的交付已经完全可以脱离系统管理员手动操作 ，从而有效的避免了人为操作引起的事故。另外， 系统管理员也都不是直接操作服务器，而是基于堡垒机操作，堡垒机已经对用户权限、目录、删除操作都做了限制，因此也无法做到删库的目的。

虽然，我们在网上偶尔听说某某公司程序员删库跑路，这其实都可以通过技术手段来避免，像腾讯、阿里、百度这样的大厂对删库这样的危险动作，肯定都是做了十足的防范，这种事情的发生的概率比中彩票还难。

最后， 企业的数据库都有高可用架构、异地容灾、完善的数据库备份计划，甚至还时长会对故障进行演练，因此即使发生数据库被删，也能够通过一些列手段将数据找回。

综上所述，微信被运维删库、跑路，用户感知的后果应该会是暂时登陆不了，不会有什么其他大的问题。不过，鉴于微信的流量，最终后果还得看吃瓜群众的反应。

刺激！！！

删库最直接的影响就是能会导致系统瞬间崩溃，所有相关功能瘫痪，然后就是公司无法估计的经济损失。业务停摆、股票暴跌、市值下降再到后续的信任危机、对家抢单等等等等。

反正就是，严重的就像是微盟的下场，可能他们也没想到，一个女人能引发这么大的“ 血案 ”。

删库被称为程序员最后的底裤！！！是程序员最后的倔强！！！

一般来说，程序员还都是比较讲理的，但总有一些“大老板”不断地挑战小哥哥的底线，不管是从精神上还是物质上，不断地压榨小哥哥们，最后导致了悲剧的发生...

毕竟，删库简单，跑路难，删库的程序员都是抱着同归于尽的想法来进行的删库，在现在进行跑路实在是太难了，所以你放心，你只要不过分的欺负你的宝贝程序员他是不会轻易做出这么危险的事情的。

要说最轰轰烈烈的删库事件应该就是微盟的删库事件了，瞬间将rm-rf的身价狂抬到30亿短短的五个字符价值竟达到了30亿。

事件的起末应该就不用我多说了！！！大家肯定都已经懂已经知道了！！！

要想生活过的去，头上必须带点绿。

我还是简单的叙述一下吧！

某某员工不管被自己的老板绿了，然后还被威胁要辞退他，他的女朋友去帮他说情，然后这个可怜的小哥哥又被绿了。

愤怒之下的他，打算像个男人一样！站起来！

然后他就删库了，但是他没能跑路...

所以说小哥哥们要多注意锻炼身体，要不然你删库完都跑不了，就做好同归于尽的准备！！！

一定会有人问，那微盟这么大的公司没备份吗？？？

不好意思嗷，备份也被删库了。

这说明了一个很大的问题，备份不要只有一个，多个备份要分到不同的人手中管。

也不排除团队删库跑路哈，那估计真的是仇恨值爆表了！

剩下的小事件还有...

思科前员工在2016年7月到2018年4月任职期间，恶意删除思科四百多台虚拟机，造成16000个WebEx Teams账户被异常关闭。思科因此被客户退款超过100万美元，其损失共计240万美元。

2018年9月，顺丰一位高级工程师在升级系统数据库时，不慎将RUSS数据库删除，导致了顺丰线上发车功能约10小时无法使用，负面影响严重。最后该程序员被辞退，也被“跑路”了。

2017年9月，广西某大型IT企业为客户进行扩容割接时，误操作将HSS设备里面的用户数据格式化删除，导致该运营商近80万用户数据丢失从而无法通话和上网，波及七八个地市，事故重大。

还有好多，类似的事件。

要想安安心心的杜绝此类事件，还是要有待员工，不要让他们铤而走险。

怕删库，先容灾，再备份！

有关容灾备份的解决方案可以去云掣官网看， https://www.dtstack.com/dtsmart/#tt

如果微信被运维删库、跑路，会造成什么恐怖的后果？你怎么看？ 最近微盟公司因为员工和公司之间的矛盾，于是员工怒删微盟公司数据库导致了公司SaaS业务崩溃、基于微盟的商家小程序处于不能运行状态，300万商家商家生意停摆。并且还导致了微盟集团在港市值蒸发10亿，搞得是沸沸扬扬。

这次数据被删造成了微盟公司信誉的重大损失，到目前微盟公司的数据库还没有恢复，最新的消息是要到2月28日24时才能完全恢复，也就是说这一下竟然有差不多四五天时间基于微盟数据库的300万商家小程序不能正常运行，会带来相当大的损失。本来现在生意就难做，再加上小程序还不能使用，更是雪上加霜。

微盟公司与腾讯相比可以说体量完全不一样，即使微信的用户数量就达到了10亿级别，与300万用户数相比完全不是一个级别。况且还有几亿商家基于微信开发的各种各样的应用等等。如果微信发生数据库删除的情况，可以说会对微信会造成几乎整个 社会 一片愤怒，而不是像微盟那样单单300万商家。

微信里面不但有个人、群之间的聊天这么简单，即使是基于微信作为营销阵地的各种团队、个人将会是哀嚎一片。有基于微信做得各种各样的应用、小程序、个人财富等等，给个人和商家财富的损失比如零钱、理财等，会给腾讯带来数不清的官司、几千上亿商家业务的崩毁，这给腾讯带来几乎毁灭性的打击。

如果微信不能保证安全，那么其对手必然会加大对微信用户的吸收，到后来微信也许就会逐渐凋零步入小众，也许人手一个微信的将会变成人手一个支付宝。没有了微信这个平台腾讯将会失掉收割的臂膀，腾讯的业务会随着微信的凋落，也将一步一步走向平庸。

不过这一切都是假设，像腾讯公司微信这么大体量的业务，已经做好了万全的备份策略，即使是删除掉某些内容，很快也会恢复回来。

一个运维就想把微信删库？那是不可能的！

只能说非专业人士，对微信这个规模的系统一无所知，对运维的概念还挺停留在小网站的层面。

用户数据是微信得以生存的基础，一旦微信用户数据被删除，可想而知，微信的发展到底会受到什么样的掣肘，甚至于微信可能会陷入到“生死存亡”的关键时刻，怎么样的信任危机呢？

但是，我们的担心有多多余呢？其实，我们得知道的是，腾讯的数据库——

腾讯贵安七星数据中心的表现出色，更兼具安全性。

除此之外，腾讯江宁数据中心，上海数据中心等等，以及腾讯贵安七星数据中心等等，都让腾讯的数据库分散四处，且进行多种备份。

除此之外，用户管理这种绝密的数据，是在腾讯中心进行管理的，并且大量删除数据权限需要多人授权，单个人删除腾讯数据几乎可能为0！

这还用想？阿里钉钉立马趁火打劫推出普适版啊~只要微信一黑，阿里内部给钉钉的预算绝对是“无上限”级别。

当然这都是后话，人家托尼马也不是吃素的，自家的社交命脉，没那么脆弱，对于用户数据那都是多套备份，无缝衔接，就和酒店停电，地下室的发电机会立马启动一个道理。而微信有这个权利把所有备份删光的除非托尼马暗示张小龙花一定的时间才能做到完全删库

首先要明确，删是删不动的，就算一时能删除，也很快能找出备份恢复，所以恐怖后果不太可能，短期出现一些波动震荡就正常。

因为造不出什么恶劣后果，所以跑路真没必要，除非他能够从中获取到重大的经济利益。

可能吗？

这种可能性极大。收到竞争对手重金贿赂违法反职业道德是一种，或者因为腾讯是上市公司，重金高杠杆期货做空也是一种。

用户数据是微信得以生存的基础。

区区一个两个运维对微信能造成的伤害极小，一时删档，迅速恢复，就如大河里的一朵浪花，起不到多大作用，但要预防有恶意者结合政治经济形势下做出的联动，那样有可能造成恐怖的后果。

比如结合前段时间国家对互联网超大企业“二选一”规则的限制，腾讯的股价本身就在暴跌中，那时的百上加斤就最可怕。

单纯的理工男的泄愤行为，对微信这颗大树的影响微乎其微，基本可以忽略不计。

运维能对微信造成的伤害极其有限，并且也有时间局限

微信的数据有一个严密、安全的保护方式，而且有非常稳妥有效的数据恢复方案。所以就算有运维把他所负责的微信数据库删除了，可能对微信整体也无法造成太大的影响。那种被运维删库后就找不回数据的情况，通常只会发生在不怎么规范的中小型企业身上。

以阿里巴巴为例，你要想全部删除，至少需要150个左右完全不同小组的最高权限。

由于微信的用户数量上10亿，涉及到的数据和备份也达到天量，因此微信的数据库也不是由一个运维人员来掌握的，而是分成几个甚至几百个部分，由不同的运维分开控制，每个运维的权限也不一样，互相不能访问，甚至每份数据都保存在不同的地点。

这样一来，就算其中一个运维删库跑路了，影响到微信的可能也是数据库中的一个很小的部分，不会影响到整体。比如某一个用户数据库被删掉了，可能就只会导致十几万或者上百万的微信用户无法正常登陆，但其余大部分用户可能压根感觉不到有什么影响。

而且一般来说，只要保存数据的服务器没有遭受物理损坏，通过普通方式删除掉的数据基本上都是可以恢复，即使数据库完全被清空了，备份也没有了，也可以通过恢复硬盘的方式来找回数据。只不过速度有些慢而已。

当然微信里面不但有个人、群之间的聊天这么简单，有基于微信做的各种各样的应用、小程序、个人财富等等，那些基于微信作为营销阵地的各种团队、个人将会是哀嚎一片。给个人和商家财富的损失比如零钱、理财等，会给腾讯带来数不清的官司、几千上亿商家业务的损失，以及无形商誉和品牌名声上的质疑。

这些都会给微信带来一定的纠纷和麻烦，但是只要恢复速度够快，微信的体量也大，还是能够轻易消化这些纠纷和损失的。

若是竞争对手打击必然配合有系统整套的计划

因此，就要预防在战争或者非常情况下竞争对手精密部署，做出恶意的系统性计划来。

近年的几个案例可以作为分析警醒。

微盟公司因为员工和公司之间的矛盾，于是员工怒删微盟公司数据库导致了公司SaaS业务崩溃、基于微盟的商家小程序处于不能运行状态，300万商家商家生意停摆。并且还导致了微盟集团在港市值蒸发10亿，搞得是沸沸扬扬。

这个是规模小，删除成功了，而且备份系统不够强大，恢复时间有点长，这种威胁对微信来说可以轻松应对。

2018年9月，顺丰一位高级工程师在升级系统数据库时，不慎将RUSS数据库删除，导致了顺丰线上发车功能约10小时无法使用，负面影响严重。最后该程序员被辞退。

顺丰数据库规模够大，这位高级工程师已经身处核心，也造成了严重后果，顺丰花了10小时恢复，可见运维这种行为能影响大型互联网企业的时间是很短的，关键是因之衍生出来的各种 社会 影响和负面影响才是要紧。

思科前员工在2016年7月到2018年4月任职期间，恶意删除思科四百多台虚拟机，造成16000个WebEx Teams账户被异常关闭。思科因此被客户退款超过100万美元，其损失共计240万美元。

这个案例造成的影响是由客户直接反应回来的，正如蚂蚁延缓上市，阿里巴巴美股投资者起诉阿里巴巴一样，配合上政策性因素以及市场放大反应，那才是真正致命的东西。

至于微信可能会出现无法登陆、不能发消息、不能打开公众号、小程序等故障，持续的时间则由运维人员恢复数据的速度来决定。这些只是事件的原点，能放大到多少倍要看市场的反应和当时的环境，以及有没有被恶意设计。

在疫情肆虐的如今，金融投资者的心态已经没有以前那样平和理智，这无疑也会提供一定的加成放大因素。

删库最直接的影响就是能会导致系统瞬间崩溃，所有相关功能瘫痪，然后就是公司无法估计的经济损失。业务停摆、股票暴跌、市值下降再到后续的信任危机、对家抢单等等等等。

另外出现这样重大的安全和管理漏洞，也会引发市场对腾讯管理经营水平的怀疑，从而大幅动摇投资者对上市公司高昂股价的信心。

单一因素并不可怕，要预防竞争对手甚至敌对国家组合所有因素的重磅一击。

若是个人行为必然伴随重大的经济利益

干什么事情都要讲经济利益的。

IT企业运营有一个重要的环节就是备份，正规的企业都会有多种备份方式，比如异地备份、云端备份等。而且正规企业的IT运维人员不止一个，每个运维都有不同的权限。能够访问数据的运维一般都没有操作备份数据的权限，为的就是避免一个运维“精神失常”，把数据和备份一锅端了。

作为一个无论清醒理智还是不理智的运维，基础的专业知识都是存在的，既然知道短期删除对微信造不成实质伤害，还是要做，必然有其深刻现实的原因。

他为什么要删掉跑路，定然牵涉到重大的经济利益，而且知道数据可以恢复，导致东窗事发，只有一走了之。

连续近期政策性因素影响的大跌后，阿里、腾讯、京东、美团互联网四巨头股价最终迎来回升。港股方面，阿里巴巴涨3.14%，腾讯控股涨5.44%，京东涨8%，美团涨7.9%。其中，腾讯最新市值55687.27亿港元继续超过阿里，位居港股市值第一的宝座。

这样巨大的五万亿市值，一个波动，就能造就无数个千万甚至亿万富翁。

因删档造成的短期腾讯的股价大幅下降，存在资本市场大幅做空获利的巨大空间，这应该是才是运维奋不顾身的原因。

不过说实话，世界早已过了单打独斗个人英雄的时代，个别运维如果不结合时势，只不过是蚂蚁撼树，终究无可奈何。

综上所述，理工男单纯的意气删除，对微信的伤害其实是微乎其微的，但是在国际环境、政策变化、竞争对手、甚至敌对国家组合各种因素，也抓住有利时机的情况下才有可能造成恐怖效果，这个值得微信运营警惕深思防范。

听说IT运维人员学的第一课就是“从删库到跑路”，虽然这是一句玩笑话，但是在一些不是很规范的IT企业，IT运维的很多操作都是在线的，一不小心就会给企业的数据库带来灾难性的后果，万一没有备份，客户的数据都找不回来了，那么企业多半也就黄了，有的甚至还要向客户赔偿经济损失。

所以IT企业运营有一个重要的环节就是备份，正规的企业都会有多种备份方式，比如异地备份、云端备份等。而且正规企业的IT运维人员不止一个，每个运维都有不同的权限。能够访问数据的运维一般都没有操作备份数据的权限，为的就是避免一个运维“精神失常”，把数据和备份一锅端了。

而腾讯是IT企业中的龙头老大，规章制度和备份机制肯定是最完善的。所以如果微信被运维删库、跑路了，那么肯定会有其他运维第一时间顶替对方的工作，然后通过备份来恢复数据。这种情况下，微信可能会出现无法登陆、不能发消息、不能打开公众号、小程序等故障，持续的时间则由运维人员恢复数据的速度来决定。

一般来说，只要保存数据的服务器没有遭受物理损坏，通过普通方式删除掉的数据基本上都是可以恢复，即使数据库完全被清空了，备份也没有了，也可以通过恢复硬盘的方式来找回数据。只不过速度有些慢而已。比如这次事件当中被删除的微盟就已经宣布：已经全面找回数据，并将于3月2日晚上10点到3月3日上午9点，正式进行恢复上线。

至于微信的用户数量上10亿，所以涉及到的数据和备份也达到了一个天量的数级，因此微信的数据库很有可能不是由一个运维人员来掌握的，而是分成几个甚至几百个部分，由不同的运维分开控制，每个运维的权限也不一样，互相不能访问。甚至每份数据都保存在不同的地点。这样一来，就算其中一个运维删库跑路了，影响到微信的可能也是数据库中的一个很小的部分，不会影响到整体。比如某一个用户数据库被删掉了，可能就只会导致十几万或者上百万的微信用户无法正常登陆，但其余大部分用户可能压根感觉不到有什么影响。

另外，微信的聊天数据并没有被保存在服务器上，而是保存在用户的手机里。所以就算微信被删库了，用户的聊天记录也不受影响，只要用户保证手机中的聊天记录不被删除就可以了。反过来如果手机中的聊天记录删除了，基本上就没有找回的方法了。

总而言之，微信的数据肯定有一个严密、安全的保护方式，而且有非常稳妥有效的数据恢复方案。所以就算有运维把他所负责的微信数据库删除了，可能对微信整体也无法造成太大的影响。那种被运维删库后就找不回数据的情况，通常只会发生在不怎么规范的中小型企业身上。

一帮子不审题就答题的人，题主问的是如果被删会怎么样，而不是微信会不会发生删库的事情。

如何正确面对信息系统的故障、事故和问题

1、工作中不出问题，是不可能系统运维事故事件的
我从1996年在营业部电脑部工作到2007年底不在中心机房现场办公，11年的证券信息系统一线运维经历，得出来的感触是系统运维事故事件：
（1）信息系统不出问题是不可能的；
（2）工作中间追求十全十美是不可能做到的；
（3）发现问题、解决问题如果只是头痛医头、脚痛医脚，不能从根本上解决产生问题的根本原因，下次遇到同类的问题，还会出现问题。对当事人自身来说不会有提高、团队也借鉴不到教训和经验，只是在原地打转，只是年复一年地做类似的工作。同时对信息系统运维来说，还是存在隐患，我们的工作质量也得不到提高。
信息系统不出问题是不可能的，并不代表这可以成为我们放任自流的理由。我们应积极地面对问题：
首先，发现问题后，积极地解决问题
信息系统出现的故障、事故和问题，多种多样。有些是我们自己能够掌控的，有些则是需要其系统运维事故事件他服务商，如网络服务商、软件系统服务商、专线提供商、银行等单位来解决的。
我们自己能够掌控的好办，我们自己积极地去解决，解除问题。关键是需要其他服务商解决的，需要我们动脑筋、总结方法，以求解决问题的效率。个人认为从以下几方面做起：
（1）主观上要有一个正确的态度。很多信息系统的问题需要其他服务商协助解决，我们的工作效率和工作结果取决于其他服务商的工作效率和工作结果。我们不能以此为借口，放任问题的拖延解决。不能说“是XX公司的问题，不是我们的问题，我催他们系统运维事故事件了，他们不解决，我也没办法”。因为我们是直接对公司负责的，其他服务商没有解决问题也是我们的责任，积极的态度是我们想尽一切办法，督促其他服务商解决问题。
（2）掌握进展。需要其他服务商解决的故障出现后，不是简单地向提供商通报故障，还要及时跟进，要掌握进展的动态。不是简单地一句话：对方在解决。如果我们不跟进，对方会认为我们不着急，认真负责的公司会积极地去解决，官僚的公司有可能拖拉，放在那儿不办。最终影响的是我们的工作，如果因为对方工作迟缓对公司造成影响或损失，对方工作不努力、经常找不到对方的人等等都不是我们的理由，现在这个社会，要想做好一件事是很难的。我们跟进与不跟进，绝大多数情况下效率是截然不一样的，这是我11年运维的体会。我们要尽最大可能知道：对方哪些人在解决？跟这些人能不能联系上？现场解决人员排除故障的进展情况？从对方获得的信息是不是第一手信息？
（4）对与其他服务商签订的合同条款细节了然于胸，这样做有两个好处，一是在出现问题的时候，了解自己的权益，利用合同规定的一些条款可以更加有效的督促乙方快速，认真的处理问题。二是在今后合同的签订时争取到更大的主动权。
（5）动用一切可以动用的资源，督促其他服务商解决问题。督促其他服务商解决问题需要讲究一下方式、方法。如果凭借技术人员的力量不能起到效果时，要向自己的上级报告、网点的电脑人员要向营业网点负责人报告，寻求帮助，大家集思广益，动用一切可以动用的资源，督促并最终解决问题。
其次，分析故障原因，以后是否可以避免
我们不是神仙，不可能预测各种可能的情况，我们的工作也不可能十全十美。但这不是我们推卸责任的理由。我们应建立和完善故障、事故和问题的分析总结机制。故障发现后，我们把故障原因分析清楚，尽可能地改进以后的工作，这样我们才能做到螺旋式上升。工作思路才能有长进。个人认为从以下几方面做起：
（1）分析故障、事故和问题的原因。信息系统运行中的故障、事故和问题的出现，都有其根本的原因，我们要分析清楚：是不是应急措施没有起到作用？是不是我们的一些操作没有按操作流程去做？是不是我们之前没有预料到？是不是其他服务商没有服务好？等等。只有我们把问题的原因分析清楚了，我们才能有针对性地改进我们的工作。
（2）如果是应急措施没有起到作用，我们下一步完善备份措施，加强应急演习。做到设备故障时有备份措施，需要启用备份措施时，备份措施是有效的。
（3）如果是我们的一些操作没有按操作流程去做，需要大家重新学习操作流程，反思主观上是否有松懈情绪，继续树立严格按操作流程操作的良好的职业习惯。
（5）如果是其他服务商没有服务好，那么我们总结一下，在今后的工作中，如何保持与其他服务商的良好的合作关系？如何加强沟通？如何掌握对方足够的联系人信息，在需要的时候能够找到人？等等。我们信息系统的外围服务商很多，有些经常联系、有些则不经常联系，如果要做到在需要的时候能够找到对方的人，需要我们的日常工作中，加强沟通，这一点至关重要。否则，也许对方的手机号换了，没有通知我们，在关键的时候，信息系统的故障得不到及时处理就可能影响业务的进行。
第三，触类旁通，查找类似工作的不足，不犯同类的错误。
发现问题、解决问题、想办法预防同样的问题，这是基本的要求。这也只能做到下一次不犯同样的错误。如果仅做到这个层次，一个人、一个部门的水平提高就太慢啦。我们要力争做到下次不犯同类的错误。出现一个问题，解决后触类旁通，查找类似工作的不足，针对性地改造自己的工作，这才是快速提高工作能力的最有效的方法。
第四，思想上高度重视是解决一切问题的根本
发现问题、解决问题、想办法预防同样的问题，并触类旁通预防同类问题。听起来工作量很大，是的，确实如此。按这种思路工作，会很累。会让一般的员工感到反感，不愿去坚持。这也是很多员工长进慢的根本原因。
我们作为一个职业人，职业追求是最根本的。只有从思想上愿意提高自己，在思想上高度重视所有工作，才不会觉得复杂，工作才能从根本上做好。我们作为证券信息技术工作者，既然选择了这个职业，我们就必须做好。
以上是我在工作中的一点体会，请部门人员参考。 关于系统运维事故事件和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 系统运维事故事件的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、系统运维事故事件的信息别忘了在本站进行查找喔。