大家好，关于提货系统网站源码分享在哪很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于提货系统有哪些的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
互联网从业者都知道这么一句话，别惹程序员，小心他删库跑路。
但从前大部分都是当个自嘲的笑话来看，比如类似这种：
但是没想到的是，这两天还真实的发生了删库事件。
此举可能给公司带来数10亿的市值蒸发损失！
这次不是别人，正是微信生态的第三方服务商微盟，在这个”远程办公”的节骨眼出事了。
2月25日，微盟集团（SEHK：02013）发布公告称，Saas生产环境及数据遭到员工“人为破坏”导致公司当前暂时无法向客户提供SaaS产品。
犯罪嫌疑人是微盟研发中心运维部核心运维人员贺某，于2月23日晚18点56分通过个人VPN登入公司内网跳板机，因个人精神、生活等原因对微盟线上生产环境进行了恶意破坏。
目前，贺某已被刑事拘留，并承认犯罪事实。
从这个公告可以看到如下几点：
1.该员工删库不是误操作，而是人为的，可以想象这跟公司是多大仇，想必积怨已深；
2.微盟是腾讯投资的，所以用的腾讯云服务，在和腾讯云团队浴血奋战36小时之后，数据依然没法恢复，这说明问题非常大，备份环节一定出问题了，可以说是致命的。
3.数据丢失对一家公司的打击有多致命呢？如果后续依然无法恢复，说导致公司倒闭也一点不夸张。
以下为该事故的完成时间线：
2月23日：系统崩溃
2020年2月23日19：00左右，微盟集团监控系统发出警报，获悉SaaS业务服务出现故障，随后微盟集团召集相关技术人员进行排查。
此时有商家反馈微盟于19:15前后崩溃，基于微盟的商家小程序几乎全部宕机，无法打开。
随后微盟开展调查，最终发现运维贺某，于2月23日晚18点56分，通过个人VPN登入公司内网跳板机，对微盟线上生产环境进行恶意破坏，直接导致这场事故的发生。
2月24日：官方回应商家，并选择报警
2月24日，微盟在官方发布公告称，由于技术故障，导致当前服务不可用，服务恢复预计需要24~48小时。随后把证据梳理向宝山区公安局报案。
删库后果：直接蒸发10亿！
微盟预计，老用户数据将在2月28日晚上24点前方可完成数据修复。这意味着，微盟的老用户将面临超过5天的系统宕机。对疫情期间本来正在经受门店歇业重创的商家来说，可以说是致命性的打击。
一位商家表示：微盟系统崩溃后，已售出的几百万元提货卡无法提货，“客户说我是骗子，微盟销售说是腾讯出问题，腾讯修复又不可能这么慢。店铺数据如果都没了，我的损失该怎么办？”
微盟集团公告称，目前预计SaaS生产环境和数据破坏将会对本集团SaaS业务营运带来一定的负面影响，但不预计会影响本集团其他板块的业务。可以预见的是，此次突发事件将对微盟集团利润与收入造成直接影响。
受删库事件影响，微盟股价24日出现下跌，市值一日之内蒸发约12.53亿港元。之后，随着生产环境和数据的修复，今日收盘，微盟股价涨4.22%至6.18港元，总市值138.3亿港元。
互联网技术专家赵成针对此事件在其个人公号《成哥的世界》分析称，微盟此次故障被破坏最严重的就是生产系统的数据库，且一定是核心库。很大可能是该员工直接做了rm-rf或fdisk这样基本不可逆转的文件删除操作，更极端的可能是将主备一起删除了。
从事故爆发到现在，微盟事件已经发生了超过36个小时仍未得到解决，赵成分析称，有几个可能：
第一，微盟方面没有备份，只能从磁盘文件系统维度恢复，那一定会非常慢；
第二，有备份，但备份恢复不了，也就是备份文件不可用，那只能从磁盘文件恢复；
第三，有全量备份，但无增量备份，全量可能是一个月、一周，三天等，差几天的数据一样会给客户造成极大损失。
从微盟这次恢复这么长时间推算，这次故障一定是这个操作者做了非常极端的删库操作，而且还没有可快速恢复的备份，耗时超长就不难想象了。
微盟集团在最新2月25日的公告中表示，其生产环境和数据修复在有序进行，预计2月25日24时前生产环境将修复完成，微盟所有新用户将可恢复服务，老用户由于数据修复时间问题，将提供临时过渡方案，预计老用户数据修复可在2月28日24时前完成。
微盟集团还称，在此之前本公司将提供临时过渡方案。同时，正在拟定相关赔付方案来补偿此次事故而遭受损失的商家。微盟称，“对此次因人为造成的事故灾难无比愧疚，今后将一定吸取这个惨痛的教训，加强对线上运维的治理。”
资料显示，微盟的主体为上海微盟企业发展有限公司（即“上海微盟科技股份有限公司”）（以下统称“微盟”），成立于2013年，注册资本约9.29亿元，法定代表人为刘志平，2019年1月15日在港交所上市。
招股书披露，2015至2017年三年间，微盟营收分别为1.14亿元、1.89亿元和5.34亿元。2015年和2016年间，微盟分别净亏损8860万元、8090万元。2017年，微盟扭亏为盈，净利润为260万元。
柒财经旗下互联网金融新闻中心了解到，根据微盟此前发布的财报，其2018年营业收入8.65亿元，较2017年同期增长62%；经营亏损4189.2万元，净亏损10.9亿元；经调整后的净利润5083.8万元，而2017年这一数字为1100万元。
微盟方面表示，亏损主要是由于香港财务报告准则下与优先股有关的并非自身信贷风险产生的金融负债公平值变动引起的10.4亿元亏损、上市及其他一次性开支6000万元及以股份为基础的补偿3300万元。
在精准营销方面，2018年，微盟集团精准营销实现总营收5.18亿元，同比增长90.9%；每广告主平均开支由2017年的52767元提升至87185元；全年广告主数量增长60%以上，达28589名。
2019年8月，微盟集团公布的2019年上半年财报显示，其报告期内营收6.57亿元，较2018年同期增长97.8%；净利润为2.88亿元；经调整利润为6830万元，同比增长79.2%。
开发多个贷款软件
据互联网金融新闻中心了解，在相关消息公布后，微盟集团的股价呈现了断崖式下跌。截至2020年2月25日上午午盘，微盟集团报5.66港元，跌幅为4.553%，市值约蒸发了约9.63亿港元。
不过，截至2020年2月25日收盘，微盟集团的股价有所回调。当前，微盟集团的股价报收6.18港元，单日涨幅4.22%。以收盘价计算，微盟集团总市值为138.33亿港元。
在业务拓展方面，根据微盟2019年半年度报告，SaaS产品、精准营销是微盟两大业务核心。其中，SaaS业务在2019年上半年为微盟带来了2.19亿元的收入，同比增长31.1%。
数据显示，微盟集团称，其SaaS产品及精准营销服务拥有300万注册商户。其中，SaaS产品的付费商户数增长24.3%至7万名，每用户平均收益3129元。精准营销的广告主数量增长37.7%至1.95万名，每广告主平均开支9.2万元。
互联网金融新闻中心发现，除了核心业务，微盟还打起了金融变现的主意。2019年6月，微盟还携手汇付天下（01806.HK）推出“微盟慧付”解决方案，打通微盟SaaS服务与汇付天下支付服务的合作。
微盟集团董事会主席兼首席执行官孙涛勇表示，对SaaS商户来说，支付场景是商业活动的关键环节，商家的资金管理灵活便捷，才能最大化的提高效率，进一步实现数字化升级。
此外，微盟集团还“亲自”开发了现金贷产品，并上线了贷款超市，提供导流等服务，相关业务的承载主体主要为上海萌店金融信息服务有限公司、上海萌店信息科技有限公司、上海小萌投资管理有限公司（以下统称“萌店金融”）。
据了解，萌店金融系公司的法定代表人均为刘志平，同时刘志平也是微盟集团的法定代表人。在攒够了流量后，微盟上线了萌小贷、易贷款、微盟贷款王等产品。其中，微盟贷款王为一款贷款超市。
经微盟客服确认，微盟贷款王属于微盟集团开发的一款金融产品，由“上海萌店信息科技有限公司”开发运营。不过，萌小贷、易贷款、微盟贷款王的官网均已无法打开。
根据天眼查信息，萌店金融开发了多个金融类软件，包括贷款王小额版软件、萌店金融51保险管家软件、萌店金融51保单软件、萌店金融征信萌助手软件、萌小贷app软件与易贷款软件等，登记注册时间从2017年6月至2019年6月不等。
根据微盟2019年上半年的财报数据，微盟的SaaS产品及精准营销服务拥有300万注册商户，SaaS产品的付费商户数有70006名，精准营销的广告主数量有19537名。许多商户已经直接受到影响。
如客户数据不能找回，将对商家带来毁灭性打击
钛媒体就此事联系到一位微盟某海鲜从业商户，该商户向钛媒体坦言，他店铺的业务一半以上都在微盟成交，特别是疫情期间店铺销量大部分通过线上，但目前由于微盟服务不可用，导致很多顾客都无法正常下单。但他最担心的还是数据恢复问题。
“耽误几天生意，这问题还不大。主要是我们客户几万人的信息全在微盟服务器上。现在他说他主服务器和备用服务器全都崩了，我们几个商家都最担心的是数据丢失，如果客户数据不能找回，对我们是毁灭性的。”
对于微盟在《关于微盟系统故障的通告》中提及的“预计2月25日晚上24点前，微盟所有新用户可恢复服务，老用户由于数据修复时间问题，预计2月28日晚上24点前完成”，这位商户告诉钛媒体，他不知道自己是新用户还是老用户，他认为微盟现在对新老客户没有一个明确的定义标准。
与这位商户遭遇相同，一位名为“卖提货卡”的商家也对钛媒体表示，自己主要针对大客户团购经营提货卡，每年在微盟上的销售额有500万，今年1月已经在微盟卖掉了200万的提货卡，但是现在由于微盟数据丢失，客户无法提货，他正在面临被客户当诈骗报警的风险。
受访商户告诉钛媒体，他们不愿透漏具体商户名称，“我不要实名。我们也是做生意的，都希望他尽快解决，希望微盟能够把每天的恢复进度跟我们商家交代一下。他现在什么都不说，我们都没办法安排后续的工作。按照他的说法，28号恢复得了恢复不了，还不一定。无止境的让我们商家等下去全都是成本。”
同行开始“拉客”
微盟遭遇不幸之后，微盟的同行们也被推到了风口浪尖。
他们有的推出了专门的扶持政策，有的把微盟的客户直接拉到微信群游说，仿佛迎来了新一轮跑马圈地。
2月25日，针对微盟服务器宕机事件，有赞方面称接下来将针对商家实行以下措施：1.有赞提供2周免费开店的服务，帮商家重建小程序和店铺；2.如果商家想长期用有赞，但顾虑微盟的软件服务尚未到期，有赞可以适当补贴对应服务期来减少大家的损失。此前，微盟集团公告称其SAAS业务数据遭一员工“人为破坏”，已报案处理，预计此次故障还会持续一段时间，2月25日晚上24点前将生产环境修复。
但此时也有人力挺微盟。微博用户@新农人和平发布微博表示：
找到一家靠谱的SaaS服务商非常重要，个人更看好微盟的不忘初心，自由创业理念。所以请那些借微盟崩了来说事的代理商不要再吹了，本人实事求是很客观的阐述事实，我只是以一个农村电商创业者的角度把自己的真实经历说出来，希望一切顺利，2020真够难了，小微创业企业今年不容易，一切都得继续，我们只想活下去！有些人走着走着就迷失了……
对于会不会考虑临时在其他平台搭建业务，一位商户向钛媒体表示，其实也在考虑，但是远水解不了近火，“有些服务商在蹭热度，微盟数据都还没恢复呢，没办法做数据迁移，要迁移只能迁移商品。所有的客户资料包括积分商城充值都是不能迁移的。”
从投资者的角度来看，据智通财经网报道，截至2月25日午盘，瑞士信贷、极讯亚太、汇丰证券、摩根香港均为微盟集团的前十大买入联席券商。其中，联席券商瑞士信贷净买入1499万港元，占其总成交的3.6%，成为买入主力。截止钛媒体发稿，微盟集团（港股代码：02013）股价已有小幅反弹。
嫌疑人应该受到什么惩罚？
这不是第一次有公司遭遇内部员工“删库跑路”事件，此前的几次类似事件，嫌疑人都受到了应有的惩罚。
微博备注信息为“北京云纵信息技术有限公司CTO”的用户@郑昀发微博表示，按《刑法》第286条和相关司法解释，“删库跑路”如果造成10台以上系统不能正常运行就可以判刑，如果影响50台以上则至少判5年。即“删库跑路”具体判不判，判几年，和有多少台系统用这个库有关。
郑昀提供了两个历史上的判例：
1）北京一软件工程师徐某离职后因公司未能如期结清工资，便利用其在所设计的网站中安插的后门文件将网站源代码全部删除。2017年8月20日记者从北京市丰台区人民法院获悉，徐某破坏计算机信息系统罪成立，获刑五年。
2）邱某是某某科技公司的技术总监，2014年入职到杭州的一家科技公司。因老板逼其离职，2018年6月23日就在自己家里面远程登录上了公司在阿里云的数据库，当然为了不是很明显，他选择删除了数据库上的一些关键索引和部分表格，但仍造成公司经济损失。因邱某自愿认罪并赔偿了公司8万元，杭州市余杭区人民法院酌情予以从轻处罚，并对被告人邱某判处有期徒刑二年六个月，缓刑三年。
微盟的危机应对值得我们借鉴
面对微盟的这次删库事件，对很多行业用户造成了很大的影响，但是面对危机，微盟所表现出来的社会责任感是值得我们借鉴和学习的。面对突如其来的故障，微盟并没有试图掩盖真相，而是第一时间在其官方发表声明，解释事情的背后原因，并且明确告知了后阶段的恢复计划已经明确的时间节点。
要知道，微盟也是此次事件的最大受害者，在幕后，我们可以想象会有多少个我们运维人的不眠之夜。在这期间，腾讯云给予了极大的支持和帮助，派驻了很多一流的技术专家，不计成本来支持微盟和微盟的客户。
多一些真诚，少一些套路，有问题一起扛，是面对此类危机最好的方法。如果你试图掩盖，盖不住了就撒谎，接着就像张宇唱的那样“用一个谎言圆一个谎言”，必然会让自己陷入更深层次的危机。危机之下，我们要的是公开的信息，这样才能减少公众的猜测，抵制黑公关，并获得大家的理解和支持。
为什么恢复时间这么长？
那接下来的问题就是，既然微盟已经在全力抢修，同时腾讯云也给予了极大的技术协助，那全面恢复的时间为什么还要这么久呢？
圈子外的同学可能觉得这个不应该很复杂，感觉不就是重装一下系统吗，数据库不是都应该有备份吗，直接恢复一下不就行了吗。其实事情远远要比你想的要复杂得多。很多时候，人常常会有一个认知上的偏差，对于一个自己没有切身参与过的领域，我们会不自觉地对难度产生错误的判断。这种所谓的迷之自信，是很难克服的。
这样的例子很多，比如在看球赛的时候，有人就恨不得把电视砸了，总觉得某些球员怎么这么挫，但是真要是轮到你上场，你就能比他好吗。再比如兰州拉面，看起来也没什么难度吗，来回几下子面就拉出来了，但要是换你上，你能拉出那碗面吗。
其实，熟悉现代软件架构和运维的同学一定知道，现在软件的架构以及部署是及其复杂的，尤其在微服务大行其道的今天，每个微服务本身一个集群，微服务和微服务之间还有各种依赖关系，同时每个微服务都有可能会和数据库打交道，光理清楚这些服务之间的依赖和配置就够大家受得了。更何况这次的微盟事件不是一次局部的更新和发布，而是几乎整体架构的全局梳理，从这个意义上说，难度不亚于从头搭建整个系统，更何况是在如此巨大的业务压力和舆论压力之下。
再来看看数据库，根据目前官方的信息推测，这次的数据库应该是在生产环境的本地库发生了不可逆的删除，否则不可能会需要这么长的时间。假定本地生产库没了，那唯一的方法就是借助远程灾备的全量备份库来恢复，但这也会引发出一系列的问题，比如远程库容量大，需要大量的网络传输时间，再比如，增量备份的完整性欠缺，另外，还会出现由于近期的数据Scheme变更引发的备份数据兼容性问题等等。这些都需要研发人员和运维人员的共同推进，这就会需要更多的时间。
运维进化的冷思考
通过这次的事件，站在运维的全局视角来看，对我们又有哪些启发呢。这里我提出了4个问题作为我们讨论的主线。
问题1：一个普通个体，能在多大程度上破坏系统？
先说我的观点：在信息时代，一个普通人完全可以摧毁一个系统。是的，你没有听错。这种事情在信息时代以前，是很难想象的。在人类历史上，一个个体决定一个民族，一个朝代历史走向的事情，也不是没有发生过，但必须是那些位高权重的大人物，你有没有听过，两个普通人聊着聊着，就把人类文明和外星文明都改写的事吧。
听起来很荒唐，但是这样的事情就发生在了刘慈欣的《三体》小说中，地球人叶文洁和三体人1379都是各自世界中的小人物，叶文洁处于对人类的失望，1379处于对生活的失望，在双方建立了联系后改变了人类世界与三体世界在接下来几百年中的命运。虽然这只是小说中所描绘的场景，但是所有的逻辑都是自洽的，就连霍金在接受采访时也表达了相同的观点。
回到运维和DevOps，你有没有发现，现在很多互联网产品运维人员的权限其实是很大的，有时候大到可以直接摧毁一个系统，这种现象在一些B轮或者C轮的企业中尤为普遍，我们先不谈运维人员是否会处于恶意故意破坏自己的系统，但是忙着中出错的概率还是不小的。Gitlab.com的删库其实就是运维人员的误操作导致的，由于过多的终端窗口反复切换，导致原本应该在staging上执行的删库操作实际发生在了生产环境，最终酿成大祸。
所以，这个问题带给我们的启示是，要充分重视个人在系统中可能产生的作用，必须对个人的行为进行严格的监管，避免由个人引发的系统性故障。这也就是为什么大型企业都会建立比较完善的分级和分层发布流程，层层监管和审批，避免个人单点故障的无限放大。当然，这些监管和审批必须要纳入到由技术驱动的DevOps流水线中来完成，而不是靠传统的领导签字来完成。
问题2：“人肉运维”还有多大的生存空间？
首先解释一下“人肉运维”，我认为那些在生产环境中直接敲命令来完成的各种运维操作都属于人肉运维的范畴。我记得左耳朵耗子就说过“一个公司的运维能力的强弱和你在生产环境敲命令的多少成正比”，运维能力越弱，在生产环境上直接执行各种命令的频次就越高，运维能力越强，人直接和生产环境打交道的机会就越少。
所有对生产环境的变更，无论是系统参数、安全策略、网络配置、应用参数、环境参数、文件更新、数据库更新都应该是通过DevOps的流水线走正式的发布上线流程，所有的操作必须是由脚本或者自动化代码来完成，任何个人都不应具有直接在生产环境上执行命名操作的场景。这样做的好处有一下几点：
发布流程的详细过程可以被记录和回溯；
发布流程可以被重复，避免操作步骤的遗漏或错误，保证集群中节点状态的一致性，这点对于集群扩容场景非常重要；
避免生产环境中有人为产生的随机错误；
所以，这个问题的结论显而易见，我们应该尽可能避免任何形式的人肉运维，我们的行为准则是“人管代码，代码管机器”，而不是“人直接管机器”。
问题3：运维已经积累了大量实践，为什么依旧举步维艰？
随着软件架构复杂性的不断提升，运维的理念和技术手段也在一直都在不停的演进，从早期的运维，到现在的DevOps，再到日渐完善的AIOps，我们已经积累了大量的经验和最佳实践，但是为什么似乎我们运维人依旧感觉举步维艰。
我认为其中的原因有两个，一个是现在软件架构的发展速度在某种程度上超越了运维自身的发展。你如果回头看一下，运维的技术体系一直在进步，各种CI/CD的工具链，容器技术，自动化部署工具，系统监控方案都在日趋成熟，我们的运维能力的确在不断增强。但是，与此同时，运维的对象也随之变得越来越复杂，无论是依赖关系，还是集群规模都比以往任何时候都复杂，可以说“水涨船高”是现代运维所面临的主要矛盾。
另一个原因是，很多运维的最佳实践在实际工作中被“教条化”了，没有达到这些实践设计的初衷。比如为了防止人为的出错，在做一些关键操作的时候，我们往往会有Peer机制（两个人配对相互检查），也会有Checklist机制（自己检查），但是在实际执行过程中，往往是形式主义占了上风，这一点不用我解释你也能心领神会，所以这些机制并没有发挥出应该有的效果。因此我的建议是把这类方法完整嵌入到流水线的执行步骤中去，而不是靠人为的方式来实施。我常说一句话“凡是靠人完成的东西都是不靠谱的，要靠技术手段才靠谱”。
另外，还有一个我认为不太好的实践，在实际工作中为了引起运维工程师的注意，我们会把系统设计成“危机敏感型”的，也就是说有事没事都输出很多告警信息，或者很多一般的操作都让你反复确认是否要执行。比如，你发起某个命令执行某个操作，系统就会先给出告警，然后让你再次输入“Y”来确定是否继续执行，看起来这是一种风险更低和更稳妥的设计，但是实际上这会造成一定的困扰。我们一定都听过“狼来了”的故事，当你每次都觉得这些信息是无关紧要的话，你就会下意识忽略这些信息，那么当真的狼来的时候，你就惨了。这个问题在以前的波音飞机的设计上也遇到过，因此我的建议是只在那些最有必要的操作上才启用这种双重确认的机制。
问题4：运维部门是成本中心吗？
在很多人的眼中，运维部门都被归在成本中心，简单来讲就是花钱的部门。运维是成本中心的宿命论对于运维的发展其实是很不利的。如果运维部门长期处于机械性的发布执行和生产环境救火的状态，那么就会陷入无止境的恶性循环。
很多时候，我们总是解决了看得见的问题，但是看不见的问题往往会在看不见的地方聚集，这类问题一旦出现就都是大问题。所以我们需要转变运维是成本中心的思维定式，让运维的同学能够更积极去思考和解决系统性的问题。
我们一直说有两种类型的待办事项，一种是既重要又紧急的事，也就是运维同学经常面对的各种救火型任务（生产环境Bugfix、Hotfix发布等），另一种是非常重要但是不紧急的事，也就是我常说的未雨绸缪型任务（自动化运维、监控数据分析统计、模型获取与优化等）。理想情况下，应该将更多的时间放在未雨绸缪型任务上，而只将少量的时间放在救火型任务。当把未雨绸缪型任务做好了，那么救火的概率就下降了。但是现实情况正好相反，运维同学天天忙于各种发布，各种线上救火，根本没有精力去偿还各个时期欠下的技术债，这种模式就难逃成本中心的宿命。
关于未雨绸缪型任务，我还想多说两点。
首先，运维部门有必要在平时定期开展一些故障演练的实践，结合混沌工程（ChaosEngineering）的思想，来确保系统的鲁棒性和可维护性，以此来应对各类突如其来的“黑天鹅”事件。这里我想强调“纸上得来终觉浅，绝知此事要躬行”，只有在实际故障演练的过程中，我们才有可能得到很多一手的宝贵实战经验，光靠想是不行的。
其次，对于日常运维中遇到的各类看得见的问题，不能只是关注表面上的解决，而是要有“刨根问底”的精神。这里我强烈推荐《丰田模式：精益制造的14项管理原则》一书中的方法：问N个为什么。
举个书中的例子，“工厂地上发现一大片油渍。通常的处理方式就是先清理地上的油，最多再检查一下，机器哪个部位漏油，换掉有问题的零件就好了。但是按照丰田的思路，会引导员工继续追问：为什么地上会有油？因为机器漏油了。为什么机器会漏油？因为一个零件老化，磨损严重，导致漏油。为什么零件会磨损严重？因为质量不好。为什么要用质量不好的零件？因为采购成本低。为什么要控制采购成本？因为节省短期成本，是采购部门的绩效考核标准“。当你连续问了N个为什么之后，漏油的根本原因才找到。所以对漏油事件的根本解决方案，其实是改变对采购部门的绩效考核标准，这样才能防止以后发生类似问题。
对于日常的运维工作也是如此，只有这样才能发现和定位那些未雨绸缪型的任务。
来源：stormzhang、CSDN企业招聘、互联网金融新闻中心、钛媒体、Java架构师日记
提货系统网站源码分享在哪和提货系统有哪些的问题分享结束啦，以上的文章解决了您的问题吗？欢迎您下次再来哦！