关注ITValue，看企业级最新鲜、最具价值报道！
图片来源@视觉中国 ｜
文章来源@技术领导力 ｜
ITVlue注：
除了本文作者分析的微盟没有做数据双活，网友@JM 认为，微盟架构在安全制度落实上有根本问题；即便做了异地备份，理论上恢复也不需要这么久，他的另一个猜测是：微盟使用了便宜好用的MySQL，没有用商业级别Oracle或DB2。
上海微盟这家香港上市公司，度过了艰难的三天，只因一个运维人员对微盟线上生产环境进行了恶意破坏，导致整个SAAS系统瘫痪。
2 月 25 日，微盟官方通报了一则系统故障通告：
2月23日晚7点，微盟收到系统监控警报，经排查后获悉是微盟研发中心运维部核心运维人员贺某，因个人精神、生活等原因，在2月23日晚6点56分通过个人VPN登入公司内网跳板机，对微盟线上生产环境进行了恶意的破坏。
随后微盟向上海市宝山区公安局报案，贺某已被刑事拘留。
从这个通告当中，我们得到以下信息：
1、该员工不是误操作，而是恶意破坏，可以想象他跟公司有多大的仇恨。官方说的“远程办公期间忽略了对该员工个人精神、生活的关心”，这有点扯了。
2、微盟作为腾讯投资的公司，使用的是腾讯云服务，在亲兄弟腾讯云的帮助下，奋战了48小时，仍未恢复数据，说明操作的是主库，数据库遭到了致命的破坏。
3、一名运维人员拥有那么高级别的权限，并且成功执行了巨大破坏力的操作，这种事情发生在一家上市公司，让人觉得不可思议。
老K跟微盟技术团队的架构总监相熟，之前也是沪上知名电商公司的同事，并且一起在CSDN举办的技术沙龙上做过分享，所以对他们的技术实力是比较了解，也比较敬佩的。
下面我们结合微盟的技术架构图，来理解一名运维人员为何有如此大的破坏力。以下是微盟的运维架构图，那名运维人员对这张图再熟悉不过了，现在你和他站在同样的视角。
（图片来源 @微盟技术中心 版权归原作者）
微盟架构师在那次分享中提到：
最底层的是运维架构，这是我们整个监控体系，在互联网公司待过的小伙伴都比较清楚，有基础的体系，有管理体系做支撑。底层有很多网络管理相关的东西，我们上万台模型在里面做，你怎么去管理，这个也是很大的运维管理。这里有不同的数据存储层，我们引入到虚拟化与容器层，上层还有流量控制、服务注册等等支持整个运维管理层体系。顶层有安全相关的软件，如 DDOS、WAF等等，还有相关的堡垒机模型。
从架构上看没什么毛病，注意到运维监控系统中，有数据库监控这个模块。在监控模块正常工作的情况下，删库后一分钟内应该会触发报警，当时是周日晚上6点，周末的吃饭时间，想必值班的运维人员也在吃饭吧。
以一名工程师应有的职业素养，10分钟内发现异常告警，半小时内陆续上线查看问题，这时候库早已删干净了。选择这个时间点来做案，显然是经过思考的，这把操作，快狠准！
但是，从这张架构图里看不出数据库是双机房部署，还是单机房。从结果来看应该没有做数据双活方案，才导致删了一个主库，多天无法恢复。
再来看微盟的基础架构图，从架构分层上看，采用了时下流行的微服务架构，服务治理框架采用dubbo，全链路监控系统用的CAT，作为一个大型SAAS电商系统，其架构设计是做到位了。
（图片来源 @微盟技术中心 版权归原作者）
上面提到的全链路监控，技术细节如下图，参数定义都非常清晰的，工程师的职业素养，可以打高分。
（图片来源 @微盟技术中心 版权归原作者）
再看微盟电商整体架构图，最下面的是业务中台架构层，原来大家吹得热火朝天的中台架构，人家微盟技术团队早就玩得很溜了，真是低调奢华有内涵啊。
（图片来源 @微盟技术中心 版权归原作者）
最后再看看，微盟SAAS系统整体架构，领域建模边界清晰，架构层次划分合理，再给架构团队点个赞。
（图片来源 @微盟技术中心 版权归原作者）
看完微盟整个系统架构，不禁想起那句话：功能再高，也怕菜刀。
一个误入歧途的运维工程师，一时冲动，酿成大祸。其结果是，公司和个人两败俱伤。无论如何删库总是不对的，已经触犯法律了，法律意识淡薄，这里还是要提醒一下。
最后，愿每个公司都能引以为戒，重视数据备份，权限管控。对个人来说，遇到跟公司之间的矛盾，不要一时冲动做傻事，寻求合理合法的方式来解决，万一不行，还可以通过舆论曝光嘛。
愿微盟早日恢复数据，同行也别在这个时候落井下石，商家们再多点耐心。
本文参考：
1、《微盟SAAS新零售电商业务系统的架构演进实践》， 微盟技术中心
作者简介：K，知名电商公司技术老K级人物。武做过CTO，文出过畅销书，带你一起洞见技术新时代。
往期精彩内容
行业▽
微盟遭员工“删库跑路”：SaaS服务暂停，或涉及300万商户
观察▽
趋势▽
2020年服务器的七个发展趋势：数据为王、特定领域的CPU将崛起、机架密度新增一倍以上……
