展开

关键词

事故启示录

近期热议的系统故障事件,想必大部分人都已经有所关注。截止2月26日中午,官网仍然挂着公告,表示数据还在修复过程中。? 跑路,近几年偶有发生,甚至经常成为技术圈中调侃的话题。而作为国内最大的信生态服务商,在中国香港上市已近七年,员工规模也超过3000人。 「跑路」造成如此深远影响的,属实不多见的。 官方对于事件发生经过,并没有太多细节:犯罪嫌疑人乃研发中心运维部核心运维人员贺某,贺某于 2 月 23 日晚 18 点 56 分通过个人 V** 登入公司内网跳板机,因个人精神、生活等原因对线上生产环境进行了恶意的破坏 安全娱乐圈,也提供了很多idea,如跑路不留痕迹,也不乏调侃之人,建议从黑市上买一份被脱的数据来进行数据恢复等。在这次疫情期间,对企业带来了极大的挑战,需要上下齐心协力克服困难。

1.5K10

事件,看安全的本质

2月23日,国内领先的SaaS服务商遭遇了恶性的事件,直到3月1号才将数据全面找回,各项业务逐步恢复正常。 事件很多,是影响最大的一次从2月23号晚6:58分发生操作,到3月1日晚间发布公告宣布数据全面找回,整个过程历时1周。 这次事件对公司、的300万客户及管理团队个人都造成了严重的损失,是今年来最严重的事件,而这次的事件也带来了巨大的影响。 ? 其实在IT行业事件频繁发生,大多数属于工程师在运维工作时的误操作,也有类似这次主动的恶意攻击行为。 ?此次事件本质上是一个网络安全事件事件本质上是一个网络安全事件。 事件给国内所有的IT服务商,尤其是往SaaS和企业服务转型的这些服务商敲响了一个警钟,一定会大幅提高他们的安全意识。

10820
  • 广告
    关闭

    腾讯云前端性能优化大赛

    首屏耗时优化比拼,赢千元大奖

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    ,谈谈身边跑路的大神

    今天互联网圈子最火的一件事就是‘被恶意’...? 公告当然,该类事件在圈子内屡见不鲜,只是36小时恢复期比较长了...运维人员恶意除核心数据这种操作确实是有可能发生,但是在正常情况下又不应该发生。 下面盘点一下在我身边发生过的‘跑路’事件:核心研发 应用服务器 4小时恢复工作以来第一次接触的‘跑路’事件,当时公司的权限设置还是比较好的。 核心研发 除数据 3小时恢复后来又发生一次事件,确实是,不存在争议!研发收到leader的通知要某个数据,相关数据已经迁移至其他平台存储。所以数据要进行物理除。 除的数据名称为 X_DATA,但是该研发其实本身没有该的权限。他的权限列表里可见的只有XX_DATA。收到命令后一直很纠结,很奇怪为啥要了。但是还是忠实的执行了命令除XX_DATA。 ?

    59630

    ”事件来谈谈企业的信息安全伪壁垒

    就在前天晚上的晚餐时间,出了一件大事,一个心情剧烈波动的运维同学除了数据,哗然一片,幸运的是,在和腾讯云的努力下,相关的数据都在有条不紊的恢复当中。 回溯这两年的事件,可以说层出不穷,有误的,有介质损坏的,有人为的,单从这件事来说,非常严重,始作俑者被拘留,企业受到很大的损失。 而在此次事故中,我们发现恢复时间是最亮的电,不亚于顺丰事件中的恢复时间,十分的漫长。 对于来说,事故发生后,腾讯云技术团队就第一时间与对齐,研究制定修复方案,协助将损失降到最低。事件是不幸的,但选择腾讯云又是幸运的,不难想象,如果没有腾讯云的协助,后果可以想象。 观点五:请给予更多理解 在安全管理方面,确实做了很多工作,对服务和数据的权限都有非常严格的限制。但是,在特殊情况下的远程办公期间,遇到这样的意外,实在是令人同情。

    50122

    大家如何看待这两天在跑路的那个员工?

    最近被的员工除数据这事情刷屏了,这种事情发生过不止一回,未来很可能还会再发生,作为一个工作十几年的程序员在工作中还真遇见过这种事情,而且刚刚不久发生的事情,只不过事情的性质和这个有区别,但造成的结果是一样主要有个程序员在操作数据的时候直接把数据给清空了 ,好在服务器数据有2个月前的备份,但是也把公司给折腾的够呛,最终通过查询之前的交易记录以及个人导出的一些数据才勉强找回90%,这种事情一旦发生对于企业都是灾难性的结果,特别是数据量众多的数据,所以在这里还是提醒类似的厂家要做好数据的备份工作 为什么程序员除数据的现象一直在出现? 除数据这件事主要发生在外包公司的比较多,因为外包公司主要涉及到回款的问题,很多外包公司拿不到尾款当然也不排除有些外包公司想多要点钱,做一些手脚根本原因还是在利益关系,在当前的社会中有人的地方就存在江湖 特别是在思维非常灵活的时候,虽然大部分的企业在追求华为公司的这种铁血精神,但是忽略了华为背后强大的资金支持,不是所有的企业都有这种条件达成,但是让员工工作起来更加舒畅肯定能提升工作效率,而且还能避免类似的除数据事件的发生

    31120

    谈数据灾难的灾后重建

    近日,官方发布:研发中心运维部核心运维人员贺某,“由于个人生活等方面压力” 于2020年2月23日晚7点,利用V**登录公司内网的管理机,然后对线上生产环境进行了恶意破坏,导致业务停摆。 属于电商平台,大凡电商平台的数据数据量都非常庞大,繁枝末节的业务和数据关系,如果是留有备份,则基本步骤就是拷贝文件和redo log,然后执行log重放。 作为这类二三线电商平台,核心数据应该不至于这么大的容量,所以怀疑这次连备份都被,而只能从其他途径将数据从其他或者数据源进行导入,重新生成数据,这种方式非常缓慢。大范围但没备份。 入驻的是腾讯云,但通过数据恢复的进度判断,很可能没有充分用到云上的备份功能。目前各家云厂商均提供了备份功能,比如虚拟机的镜像备份,硬盘快照备份,数据备份等等。以各家云硬盘的快照备份为例: ? 不管如何,还是希望能够尽快恢复数据上线业务,也希望所有人引以为戒,更加重视数据安全。END

    30520

    传AMD、英特尔已获得华为供货许可;美地方法院紧急叫停特朗普信禁令;”主角被判6年有期徒刑

    01地方法院紧急叫停特朗普信禁令9月20日消息,在美国“信联合会”等努力抗争下,美国地方法院已签发临时禁令,紧急叫停了美国商务部周五发布的对信限制。 这样意味着,8月6日的特朗普总统令和周五的商务部交易禁令中关于信的部分,将不会生效。信可以照常使用、也不会被下架。 2016年,软在北京成立了技术透明中心,中国技术专家可以查看软产品和服务的源代码,检测其安全性。 (央视财经)13”主角贺某被判6年有期徒刑”主角贺某获6年有期徒刑,贺某透露,是酒后因生活不如意、无力偿还网贷等个人原因导致作出“”行为。 上海市宝山区人民法院认为,贺某违反国家规定,除计算机信息系统中存储的数据,造成特别严重的后果,其行为已构成破坏计算机信息系统罪,应当依法追究刑事责任。

    13230

    BUF大事件丨员工事件;迪卡侬数据泄露波及1.23亿员工

    本周BUF大事件还是为大家带来了新鲜有趣的安全新闻,员工事件,公司市值暴跌10亿;迪卡侬数据泄露了1.23亿员工的数据;RSAC 2020于旧金山举行,大会主题:Human Elements; 观看视频内容梗概员工跑路,公司市值暴跌10亿2月23日晚,公司的SaaS业务突然崩溃,基于的商家小程序都处于宕机状态。 随后官方发布公告称:本次故障是由核心运维人员的恶意破坏导致。受事件影响,股价24日出现下跌,仅在这一天时间内,蒸发的市值超过10亿港元。 2月27日,创始人孙涛勇回应员工表:企业都有至暗时刻,不落井下石是道德。? 该数据漏洞于2月12日被发现,迪卡侬于2月16日得到通知,随后数据于2月17日下线。 ?

    60620

    程序员“跑路”的锅,该怎么补?

    (图摄于浙江茶山) 2月23日,称公司生产数据严重受损,故障需持续一段时间,最晚在28日24点前恢复。上百亿市值的,在后,居然需5个工作日恢复。即发布消息起,股价下挫8%,10个亿跌没了。 2018年登陆港交所的被称为“新经济SaaS第一股”主要扎根信生态,主要为中小企业提供SaaS(软件即服务)和精准营销服务,但收入中7成来自精准营销,而包括信在内是其最重要的投放平台,仅有3 备份策略,告警机制在杜绝“不小心”时候,特别有用。第二种就是“恶意”。这次事件中就是。据称,这名运维员工个人精神、生活压力过大,导致做出过激行为。日防夜防,家贼是最难防的。 在本案中,估计是连备份都干净了。但仔细看的技术架构,都在云上,为何还能丢掉备份。在大家的概念里,云上数不尽的磁盘资源,为什么不多备份几份儿? 如何将“跑路”的影响减到最小?据说这次事件发生后,有赞已经杀进来了。这个996被老板挂嘴上的黑马,已经开始攻城略地,一个不小心就走到前面去。

    42810

    跑路!一行代码蒸发10亿人民币!

    年后复工大戏,又增加一出:跑路! 此举直接给公司带来数10亿的市值蒸发损失!这次不是别人,正是信生态的第三方服务商,在这个远程办公”的节骨眼出事了。 3)后果:直接蒸发10亿!预计,老用户数据将在2月28日晚上24点前方可完成数据修复。这意味着,的老用户将面临超过5天的系统宕机。 受事件影响,股价24日出现下跌,市值一日之内蒸发约12.53亿港元。之后,随着生产环境和数据的修复,今日收盘,股价涨4.22%至6.18港元,总市值138.3亿港元。? 6)从技术角度解读这次互联网技术专家赵成针对此事件在其个人公号《成哥的世界》分析称,此次故障被破坏最严重的就是生产系统的数据,且一定是核心。 从这次恢复这么长时间推算,这次故障一定是这个操作者做了非常极端的操作,而且还没有可快速恢复的备份,耗时超长就不难想象了。

    33520

    史上最贵“跑路”,市值缩水21.5亿!抢救7天恢复数据,商家不满1.5亿赔付

    尽管业务已经恢复,但是的这次已持续发酵一周的“跑路”事件远没有结束。 也就是说,这次的数据事故,缘于一位内部程序员的恶意。? 截至2月27日周五收盘,经历了事件的集团股价连续下挫,与25日相比较,市值已缩水约24亿港币(约合21.5亿人民币),堪称史上最昂贵的“跑路”事件。 而本次的“人为”,数据清除更为彻底。根据发布的公告来看,显然对数据恢复的时间过于乐观,也因此持续推迟数据恢复时间。 由此看来,此次的“”事件远未结束。

    35010

    程序员“跑路”,一己之力蒸发公司市值超10亿,300万商铺遭瘫痪

    而且就发生在中国,这家公司叫,是一家从事智能商业生态的互联网企业,也是信头部服务提供商。 至于程序员跑路的背后原因,还被扯出了多个狗血版本。再脑洞的职场剧,估计都不敢这么拍。 员工跑路,公司市值暴跌10亿事情从2月23日晚说起。当时公司的SaaS业务突然崩溃,而基于的商家小程序都处于宕机状态,300万家商户生意基本停摆。 那么这个惨遭,到底是干啥的?为啥影响这么大?代价这么惨? 员工为哪般?此外,这次跑路的员工,究竟是为何这样做,也引发了各种猜测。目前主要有三种原因传闻。第一种,公司管理问题。 然而归根到底,在这个事情中,可能也防不住“心生怨怼”的员工。所以防火防盗防病毒之余,公司老板们也多关心下员工生活和心理,打造一个愉快、顺遂的环境,不要让类似跑路的事情上演。

    28420

    就在昨天,又发生一起跑路事件!

    来自官网的消息,的业务系统数据(包括主备)遭遇其公司运维人员的除。目前技术团队正在努力恢复数据,但数据恢复较慢。 最后,集团表示,公司正在拟定相关赔付方案,来补偿因本次SaaS生产环境和数据破坏事故而遭受损失的商家。是一家什么样的企业?是一家从事智能商业生态的互联网多元化集团企业。 早期主要业务是上海企业发展有限公司推出的一个针对信公众账号提供营销推广服务的第三方平台。 经过5年的高速发展,业务扩展至软件开发、广告营销,电子商务、金融、投资和大数据等。 也有网友提出:直接原因在于员工泄愤,核心问题是公司管理问题混乱。 ??还有网友调侃:,赶紧跑路:?? 近年来,类似的员工跑路事件并不稀奇,比如,浙江某互联网企业的技术总监邱某在2018年因不满被裁,报复性跑路,但容易跑路难,最后邱某自愿认罪并赔偿公司8万元,并被判处有期徒刑二年六个月,缓刑三年

    48320

    sudo rm -rf *这代码写好了,跑吗?

    别惹程序员,小心他跑路,一句IT界老梗了。不过调侃归调侃,毕竟谁也不想把牢底坐穿。 老板,招程序员不,rm -rf *那种 ???但是没想到的是,这两天还是真实地发生了事件。 上海这家公司的一运维人员,直接远程登陆公司内网了…… 在经历了 36 个小时的浴血奋战之后,发了个关于系统故障的通告,然而数据至今依然没法恢复。公告在此: ? 场主带大家简单回顾下此“骇人听闻”的事件: • 2020年2月23日,18:56分,研发中心运维部核心运维人员通过V**登入服务器,并对线上生产环境进行了恶意破坏; • 2月23日 19 时,内部系统监控报警 而在36小时后才公告事件始末,慢得匪夷所思。有大佬分析认为,的商家数据迟迟未能恢复可能是因为没有一个“兜底的备份、还原方案”。 数据永远只放在内网。 周密的备份,即使管理员跑路也不怕~场主也去咨询了业内资深人士,大佬表示,对付公司跑路的方法也不复杂,就两点: 对员工好点,让他们别冲动!对自己好点,备份!备份!备份!

    3.7K20

    成天说要跑路,这次真的有人干了

    说句玩笑,乍一看到这条新闻时,还以为是软系统被员工了,吓了我一跳。“跑路”,一直是程序员们的口头禅,但很少有人敢做这样的事情,毕竟容易牢底坐穿了。? 之前发生过某科技公司技术总监,因被离职不满报复,除数据索引和部分表导致 SaaS 服务瘫痪。结局就是被判处有期徒刑两年半,缓刑三年,与公司两败俱伤。究竟发生了什么?我们可以先看下的公告。? 这次“落难”,它的友商们自然也没闲着:??作为最大的SaaS服务竞争对手,有赞发布公告称,将给商家提供2周免费开店的服务,帮商家重建小程序和店铺,恢复生意。 真是乐于助人呀...操作太骚啦,哈哈哈 后续通过公告得知,这名员工不是误操作,而是故意的。在目前造成了巨大损失的情况下,违法判刑是妥妥跑不了了。 作为一个港股上市公司,被一个人直接干掉了整个数据,流程和管理上的问题实在是太大了。另外,希望这次事件能带给各位技术管理者和企业主们一些启示。

    831130

    跑路只用1秒,数据恢复7天7夜,如何避免历史重演?

    一周前,部署在自建MySQL数据上的核心业务数据,被某运维人员用一种让程序员闻风丧胆的Linux系统下文件除命令,整体进行了不可逆的除。更残酷的是,备份数据也一起除了。 所有平台上的用户和商家业务因此被迫停滞了一周,而服务没有恢复的每一分每一秒都是收入和用户的损失,这次造成的后果也超出了外界想象。 要想快速恢复业务正常运转,摆在面前的难题是如何在数据连同备份文件被全部除,且数据体量达到数百T的情况下,进行100%的数据恢复。而专业的数据恢复公司,也只敢谨慎评估20%左右的修复预期。 立刻启动紧急响应机制,并向腾讯云紧急求援。 备份服务器上文件类型单一,数据集中,且数据被后,硬盘没有被二次写入,理论上里面可能存在相对完整的备份数据,于是技术团队决定从备份服务器入手恢复数据。

    48020

    数据被后胆颤心惊的七天七夜

    很快,溯源到部署在自建MySQL数据上的核心业务数据,被某运维人员用一种让程序员闻风丧胆的Linux系统下文件除命令,整体进行了不可逆的除。 业内经常调侃的程序员的事件,就如黑天鹅,毫无征兆地发生在身上,业务瞬间全线崩溃,数百万商家无法开展业务。 事后外界的各种技术解读,大多会提到“有没有备份数据?为什么不用备份数据快速还原?” 外界并不清楚的是,备份数据也被一起除了。事情的严重程度远超外界想象。 立刻启动紧急响应机制。由于内部相关技术能力缺乏,也向腾讯云紧急求援。 数据连同备份文件被全部除,且数据体量达到数百T。这种情况,哪怕是专业的数据恢复公司,也只敢谨慎评估20%左右的修复预期。难度可想而知。 “这好像就是重症病人进了手术室”。 技术团队很快对修复方案达成一致:鉴于数据服务器上文件数量多,类型复杂,文件的提取和确认难度很大,而备份服务器上文件类型单一,数据集中,且数据被后,硬盘没有被二次写入,理论上里面可能存在相对完整的备份数据

    1.4K30

    七天七夜找回数据,决定赔付商家1.5亿,痛定思痛全面上云

    十三 发自 凹非寺量子位 报道 | 公众号 QbitAI“七天七夜,除的数据全面找回!” 而造成此次严重事故的,竟然是的一名员工——凭一己之力,除自家公司数据,累计市值蒸发超30亿港元。 而此次数据,在腾讯云的协作下,为何还要耗时7天7夜之久?对此,业界知名实战派软件质量和研发工程效能专家茹炳晟,发表了一些看法,主要原因归结于技术过于复杂。 从之前腾讯云对外的回应中,可以大概看到的数据不在腾讯云上,再结合目前数据恢复的速度来看,几乎可以判定很大概率没有采用“全上云”的架构,或者是只有部分数据在云端。 除此之外,像如此庞大的系统,各个垂直事业部可能都有各自的业务数据,这些数据甚至可能采用了不同的方案,这种架构上的异构性也会给恢复过程带来极大的挑战。

    28720

    36小时故障,谈谈数据安全这点事

    早上爆出一条数据安全的大新闻,了.......大家先来看看新闻: ?很震惊!很震撼!吓得我赶紧召集全公司服务端小伙伴Review了我们所有的安全部署!!! 02防指南除了这次安全事故,关于跑路,一直是互联网的黑传说。 虽然不是大厂,也算有一定规模了,备份肯定是做了。根据公告的信息,恢复需要这么久,我推断要么是全量是很久前做的,增量数据丢失了,要么是除者做了极端操作都给干掉了! 如果用的是云数据,云数据一般都会保留binlog日志,先全量恢复再重放增量。这个恢复速度非常快,不会需要36小时还没弄完,产生这么大损失! 当然也是受害者,说实话中国互联网发展太快,往往即便很努力也没法在很多方面考虑周全。好的是,有了云方案让一些中小公司的确会更高速的发展。看看公告:云厂商也在积极的帮助做数据恢复!

    24330

    谈谈跑路这点儿事

    早上爆出一条数据安全的大新闻,了.......大家先来看看新闻: ?很震惊!很震撼!吓得我赶紧召集全公司服务端小伙伴Review了我们所有的安全部署!!! (公众号回复 666,带你入圈) 02防指南除了这次安全事故,关于跑路,一直是互联网的黑传说。 虽然不是大厂,也算有一定规模了,备份肯定是做了。根据公告的信息,恢复需要这么久,我推断要么是全量是很久前做的,增量数据丢失了,要么是除者做了极端操作都给干掉了! 如果用的是云数据,云数据一般都会保留binlog日志,先全量恢复再重放增量。这个恢复速度非常快,不会需要36小时还没弄完,产生这么大损失! 当然也是受害者,说实话中国互联网发展太快,往往即便很努力也没法在很多方面考虑周全。好的是,有了云方案让一些中小公司的确会更高速的发展。看看公告:云厂商也在积极的帮助做数据恢复!

    39110

    扫码关注云+社区

    领取腾讯云代金券