荷兰程序员删库跑路vnsc威尼斯城官网,笔者曾经对数十家企业的信息系统运维工作进行过审计

摘要2018年 9 月 19
日,微博网友“大佬坊间八卦”爆料,顺丰科技数据中心的一位高级工程师邓某因误删生产数据库,导致某项服务无法使用并持续
590 分钟。顺丰已辞退工程师邓某,并在顺丰内网通报。事件概述2018年 9 月 19
日,微博网友大佬坊间八卦爆料,顺丰科技数据中心的一位高级工程师(邓XX)误删生产数据库,导致某项服务无法使用并持续
590
分钟。顺丰根据公司相关规定,辞退工程师邓某,并在顺丰内网通报批评。其他渠道获悉该人任职顺丰科技
IT 数据中心应用交付技术部互联网产品运维组,职务 IT
运维开发高级工程师。据内部通报邓某错选了 RUSS 数据库,打算删除执行的
SQL。在选定删除时,因其操作不严谨,光标回跳到 RUSS
库的实例,在未看清所选内容的情况下,便通过 delete
执行删除,同时邓某忽略了弹窗提醒,直接回车,导致 RUSS
生产数据库被删掉。因运维工作人员不严谨的操作,导致 OMCS
运营监控管控系统发生故障,该系统上临时线上发车功能无法使用并持续了 590
分钟。……
此次故障导致业务产生了严重的负面影响。网友爆料的内部通报邮件截图来自网友的讨论

vnsc威尼斯城官网 1

vnsc威尼斯城官网 2

虽然运维这个行业从云计算概念出来那天就被唱衰,但运维却逐渐从IT行业默不出声的小角色走在了前台,技术沙龙里越来越多运维主题的技术分享,DevOps、Serverless、微服务、Docker等时髦的技术和技术理念都将运维纳入其中,从来没有哪个时候是如此的重视运维,其背后的逻辑就是企业对业务的可靠性、稳定性、扩展性的诉求越来越高。

程序员的最后威胁是删库,而跟在删库后面的一般就是跑路了,这是什么原因呢?先跟大家普及一下删库是什么意思,有什么后果?

就在两天前,《Gitlab误删300GB数据,备份失效后直播抢救》、《Gitlab不小心删除了数据库导致网站下线》霸屏了科技新闻的头条。

2014年7月1日,宁夏银行核心系统出现故障,故障时间长达长达37小时40分钟,影响全行业务存取款、转账支付、借记卡、网上银行、ATM和POS业务。

那些摆脱“人肉运维”,走在领域前沿的运维人,纷纷以运维作为切入点投身创业。今天,运维派就给大家盘点下国内运维领域的互联网初创企业。

数据库简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、截取、更新、删除等操作。也可以理解为按照数据结构来组织、存储和管理数据的仓库。是管理信息系统、办公自动化系统、决策支持系统等各类信息系统的核心部分,一旦数据被删除,后果十分严重。

整个事件的回顾,Gitlab第一时间放到了Google
Doc上,并在Twitter上对事件的处置状态进行实时更新,后来索性在Youtube上
开了频道直播恢复进程,目前网站已经恢复了正常,不幸的是,Gitlab还是丢掉了差不多6个小时的数据。

37小时40分钟是什么概念,《银行业重要信息系统突发事件应急管理规范(试行)》规定了3个级别的突发事件等级,业务终端超过6小时的为特别重大突发事件(Ⅰ级)、达到3小时的算重大突发事件(Ⅱ级)、达到半小时的算较大突发事件(Ⅲ级)。

一、优维科技

vnsc威尼斯城官网 3

对于事件的前因后果,Gitlab在Google Doc上面已经进行了详细说明,简单来说:

直接原因

在季末结算业务量较大的情况下,因备份系统异常导致备份存储磁盘读写处理严重延时,备份与主存储数据不一致,在采取中断数据备份录像操作后,造成生产数据库损坏并宕机。

优维科技,成立于2015年,初创团队主要来自腾讯、阿里,创始人王津银是国内“精益运维”的发起人,公司致力于提供一站式IT运维解决方案,包括全栈DevOps运维平台和互联网运维最佳实践。主要聚焦于互联网以及“互联网+”公司,为其提供如下服务内容:

我自己是一名高级python开发工程师,这里有我自己整理了一套最新的python系统学习教程,包括从基础的python脚本到web开发、爬虫、数据分析、数据可视化、机器学习等。送给正在学习python的小伙伴!这里是python学习者聚集地,欢迎初学和进阶中的小伙伴!

关注微信公众号:速学Python,后台回复:简书,即可拿Python学习资料

Gitlab遭受了恶意邮件发送者的DDoS攻击,导致数据库写入锁定,网站出现不稳定和宕机,在阻止了恶意邮件发送者之后,运维人员开始修复数据库不同步的问题,在修复过程中,错误的在生产环境上执行了数据库目录删除命令,导致300GB数据被删除,Gitlab被迫下线。

在试图进行数据恢复时,发现只有db1.staging的数据库可以用于恢复,其它五种备份机制均无效。db1.staging是6小时前的数据,而且传输速率有限,导致恢复进程缓慢。

根本原因

根本原因是在于核心系统数据库版本严重老化,且2007年至今未购买核心数据库的维保服务,核心系统长期缺乏维护,事故发生后,无法获得系统供应商及时技术支持。系统恢复过程中,缺乏应急预案和准备,长时间无法实施有效处置,导致业务恢复缓慢,对银行运营产生较为严重影响。

为什么IT系统会出问题?为什么影响范围这么广?为什么没有应急预案或者应急预案没有起作用?为什么要停几个小时这么久?

一句话系统太复杂了,大型系统就更复杂了。世界上从来就没有不出错的程序。所以我们在做架构设计的时候一定要考虑系统解耦,风险隔离,尽量保证核心业务系统的正常运转,即便系统出错只影响出错的部分业务而不至于影响全行全部业务。在这个案例中应急预案为什么没起作用,
要知道出故障是备份系统,备份系统都出故障了何谈紧急预案那。为什么停这么长时间,这次故障是数据库宕机,首要问题是数据库恢复,而宁夏银行恰恰没有购买数据库维保服务,得不到数据库厂商的技术支持,这就难办了。没有数据厂商的支持解决问题谈何容易,花这么长时间也是在所难免的了。

交付全栈DevOps运维平台,帮助客户提高服务质量,降低IT运行成本,提升IT组织效率。提供互联网运维最佳实践咨询服务,包括但不限于:组织及人员优化/流程再造/运维规范与标准化等。提供运维优化及技术架构优化服务,例如性能优化/微服务架构/服务化平台等。

vnsc威尼斯城官网 4

作为一个信息系统审计师和信息安全顾问,笔者曾经对数十家企业的信息系统运维工作进行过审计,类似的事件屡见不鲜,其中也不乏国际知名的IT巨头和国内顶尖的科技公司,只是传播范围、影响力、事件透明度都没有这个事件这么大。

GitLab 数据库误删事件

那么有没有使用备份系统的案例那? 2017 年 2 月 1 日 GitLab
发生了一起生产事故,数据库被误删了。最终会丢失一小部分线上数据(6个小时的issues、comments、merge
requests等,代码和wiki文档不受影响)。

一位同学在给gitlab的线上数据库做一些负载均衡的工作,在做这个工作时的时候突发了一个情况,Gitlab被DDoS攻击,数据库的使用飙高,在block完攻击者的IP后,此时已经加班到深夜了。因为遇到了种种常规脚本没能解决的问题,不得不进行大量人工操作,于是在精力不济后出现致命失误,准备从
db1 同步到 db2 时错误的删除了 db1 的数据。

在恢复的过程中,他们发现只有db1.staging的数据库可以用于恢复,而其它的5种备份机制都不可用,第一个是数据库的同步,没有同步webhook,第二个是对硬盘的快照,没有对数据库做,第三个是用pg_dump的备份,发现版本不对(用9.2的版本去dump
9.6的数据)导致没有dump出数据,第四个S3的备份,完全没有备份上,第五个是相关的备份流程是问题百出的,只有几个粗糙的人肉的脚本和糟糕的文档,也就是说,不但是是人肉的,而且还是完全不可执行的。

最终,gitlab从db1.staging上把6个小时前的数据copy回来,结果发现速度非常的慢,备份结点只有60Mbits/S,拷了很长时间

关于备份,Giblab事件中,就算所有的备份都可用,也不可避免的会有数据的丢失,理由如下:

  1. 备份通常是周期性的,即便从最近的备份回复,那也有部分数据会丢失。

  2. 备份的数据会有版本不兼容的问题。

3.
灾备中心的灾备数据没有一天live过。等真正灾难来临需要live的时候,你会发现各种问题让你live不起来。

所以最终的解决方案就是设计一个高可用性系统,AWS的S3就是一个高可用的号称11个9的持久性,AWS是这样定义的,如果你存了1万个对象,那么丢一个的时间是1000万年。

很不幸,亚马逊AWS服务也出了一次生产事故,2017年2月28日亚马逊S3数据中心无响应4个小时,墙外的半个互联网也跟着挂了。

2月28日晚间,亚马逊AWS服务出现了较高错误率,造成亚马逊S3在主要数据中心无响应,这是AWS历史上公共云服务出错最长且影响最大的一次。

S3 服务被近 15 万家网站使用
AWS S3 是项什么服务,为何会有如此多的企业采用?通俗讲,S3
是一项存储文件的服务,开发者可储存图片以及网页上的其他项目,保存备份,同时可在服务器和静态网站里共享文档。

简单来说,这天,工程师在调查Northern Virginia (US-EAST-1) Region 上 S3
的一个和账务系统相关的问题,想移除一个账务系统里的一个子系统下的一些少量的服务器,结果呢,有一条命令搞错了,导致了移除了大量的S3的控制系统。包括两个很重要的子系统:一个是S3的对象索引服务(Index),一个是S3的位置服务系统(Placement)。

虽然整个S3的是做过充分的故障设计的(注:AWS的七大Design Principle 之一
Design for Failure)——
就算是最核心的组件或服务出问题了,系统也能恢复。但是,AWS
在很长很长一段时间内都没有重启过 S3 的核心服务,所以S3
的数据对象存储级数级的成长。所以,这两个核心服务在启动时要重建并校验对象索引元数据的完整性,这个过程没想到花了这么长的时候。而Placement服务系统依赖于Index
服务,所以花了更长的时间。

后续改进

1)改进运维操作工具。对于此次故障的运维工具,有下面改进:

让删除服务这个操作变慢一些(陈皓注:这样错了也可以有时间反悔,相对于一个大规模的分布式系统,这招还是很不错的,至少在系统报警时有也可以挽救)

加上一个最小资源数限制的SafeGuard(陈皓注:就是说,任何服务在运行时都应该有一个最小资源数,分布式集群控制系统会强行维护服务正常运行的最小的一个资源数)

举一反三,Review所有和其它的运维工具,保证他们也相关的检查。

2)改进恢复过程。对于恢复时间过长的问题,有如下改进:

分解现有厚重的重要服务成更小的单元(在
AWS,Service是大服务,小服务被称之为 Cell),AWS
会把这几个重要的服务重构成
Cell服务。(陈皓注:这应该就是所谓的“微服务”了吧)。这样,服务粒度变小,重启也会快一些,而且还可以减少故障面(原文:blast
radius – 爆炸半径)

今年内完成对 Index 索引服务的分区计划

优维科技已于2016年11月获得3000万人民币A轮融资。

顺丰工程师误删库“被”跑路

这次事件,其实是一个非常典型的信息安全风险爆发、信息安全控制措施失效的案例,笔者将从IT审计的角度,进行一些简单分析和分享。

二、云霁科技

顺丰工程师删库:在接到改需求的消息后,按照操作流程登陆上了生产数据库跳转机,通过navicat-mysql客户端管理工具,连入SHIVA-OMCS的RUSS库进行操作。在操作过程中,该运维发现选错了RUSS
数据库,打算删除执行的sql。结果操作失误,鼠标跳回到了russ库,在未确认所选情况的时候,直接delete了。还忽视了弹窗的提示,直接一个回车,russ库被删除。导致系统故障,无法使用并持续约590分钟。该程序员也因为操作问题被“跑路”了。

1、IT审计的逻辑是什么

云霁科技,成立于2014年,是一家面向数据中心的IT运维服务提供商,创始人智锦,曾就职于支付宝运维团队,云霁科技目前的主要产品包括iDC
OS以及CloudBoot:

vnsc威尼斯城官网 5

IT审计是一种针对信息系统的审计方式,不同于财务审计对财务报告真实性、有效性、准确性的验证,IT审计关注于对信息系统本身的稳定性、准确性、安全性的检查以及围绕信息系统运维管理活动有效性的检查。

iDC
OS是一个数据中心操作系统,是面向数据中心和IT运维部门的PaaS平台,重点解决云计算数据中心在规模和效率上面临的挑战以及传统数据中心和用户转型云计算过程中遇到的困难,iDC
OS融合了数据中心运行所需要的技术工具、人员组织,流程制度,为传统企业向云计算和分布式提供了最佳实践。

荷兰程序员删库跑路

直白一点来说,除了要检查信息系统本身能否正确、稳定的进行信息处理,IT审计还关注是否针对信息系统运维风险的设计了有效的控制措施,并有效执行。

CloudBoot是一个开源X86服务器配置安装工具,目前主要提供开源版和企业版两种。其企业版产品是面向企业级用户提供的一套X86物理机自动化管理解决方案,围绕设备资源池、硬件监控、裸机安装、运行管理等功能模块构建的硬件统一管理平台,产品架构包括CMDB平台和BootOS系统。

荷兰海牙的一家云主机商
也遭遇过被删库的经历,一名前任管理员删光了该公司所有客户的数据,并且擦除了大多数服务器上面的内容,导致用户数据全部丢失,网络服务瘫痪一周,程序员跑的再快也没用。

在IT审计中,审计的出发点叫做WCGW(What Could Go
Wrong),说白了就是要识别出哪些场景可以导致信息系统的不稳定、不准确的情况发生。这是一个基于过程的分析方式,用Gitlab事件举个例子,其中的一个WCGW就可以是『错误的将对备库操作在生产库上执行』。

云霁科技已于2017年1月获得5000万人民币A轮融资。

阿里巴巴程序员差点删库

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注