，网友@JM 认为，微盟架构在安全制度落实上有根本问题；即便做了异地备份，理论上恢复也不需要这么久，他的另一个猜测是上海微盟这家香港上市公司，度过了艰难的三天，只因一个运维人员对微盟线上生产环境进行了恶意破坏，导致整个SAAS系统瘫痪。

　　2月23日晚7点，微盟收到系统监控警报，经排查后获悉是微盟研发中心运维部核心运维人员贺某，因个人精神、生活等原因，在2月23日晚6点56分通过个人VPN登入公司内网跳板机，对微盟线上生产环境进行了恶意的破坏。

　　1、该员工不是误操作，而是恶意破坏，可以想象他跟公司有多大的仇恨。官方说的“远程办公期间忽略了对该员工个人精神、生活的关心”，这有点扯了。

　　2、微盟作为腾讯投资的公司，使用的是腾讯云服务，在亲兄弟腾讯云的帮助下，奋战了48小时，仍未恢复数据，说明操作的是主库，数据库遭到了致命的破坏。

　　3、一名运维人员拥有那么高级别的权限，并且成功执行了巨大破坏力的操作，这种事情发生在一家上市公司，让人觉得不可思议。

　　老K跟微盟技术团队的架构总监相熟，之前也是沪上知名电商公司的同事，并且一起在CSDN举办的技术沙龙上做过分享，所以对他们的技术实力是比较了解，也比较敬佩的。

　　下面我们结合微盟的技术架构图，来理解一名运维人员为何有如此大的破坏力。以下是微盟的运维架构图，那名运维人员对这张图再熟悉不过了，现在你和他站在同样的视角。

　　最底层的是运维架构，这是我们整个监控体系，在互联网公司待过的小伙伴都比较清楚，有基础的体系，有管理体系做支撑。底层有很多网络管理相关的东西，我们上万台模型在里面做，你怎么去管理，这个也是很大的运维管理。这里有不同的数据存储层，我们引入到虚拟化与容器层，上层还有流量控制、服务注册等等支持整个运维管理层体系。顶层有安全相关的软件，如 DDOS、WAF等等，还有相关的堡垒机模型。

　　从架构上看没什么毛病，注意到运维监控系统中，有数据库监控这个模块。在监控模块正常工作的情况下，删库后一分钟内应该会触发报警，当时是周日晚上6点，周末的吃饭时间，想必值班的运维人员也在吃饭吧。

　　以一名工程师应有的职业素养，10分钟内发现异常告警，半小时内陆续上线查看问题，这时候库早已删干净了。选择这个时间点来做案，显然是经过思考的，这把操作，快狠准！

　　。再来看微盟的基础架构图，从架构分层上看，采用了时下流行的微服务架构，服务治理框架采用dubbo，全链路监控系统用的CAT，作为一个大型SAAS电商系统，其架构设计是做到位了。

　　上面提到的全链路监控，技术细节如下图，参数定义都非常清晰的，工程师的职业素养，可以打高分。

　　再看微盟电商整体架构图，最下面的是业务中台架构层，原来大家吹得热火朝天的中台架构，人家微盟技术团队早就玩得很溜了，真是低调奢华有内涵啊。

　　最后再看看，微盟SAAS系统整体架构，领域建模边界清晰，架构层次划分合理，再给架构团队点个赞。

　　一个误入歧途的运维工程师，一时冲动，酿成大祸。其结果是，公司和个人两败俱伤。无论如何删库总是不对的，已经触犯法律了，法律意识淡薄，这里还是要提醒一下。

　　最后，愿每个公司都能引以为戒，重视数据备份，权限管控。对个人来说，遇到跟公司之间的矛盾，不要一时冲动做傻事，寻求合理合法的方式来解决，万一不行，还可以通过舆论曝光嘛。

　　：K，知名电商公司技术老K级人物。武做过CTO，文出过畅销书，带你一起洞见技术新时代。