深入解析和反思携程宕机事件

2020-11-25 11:44:16

携程网络的停机时间持续到晚上8点。28日,携程主页仍然指向静态页面,无法访问所有动态页面。在互联网上,人们对事故的根本原因有不同的看法。作为互联网运营和维护的老手,试着分析原因,谈谈自己的观点。

首先,分析停机的原因。

互联网上有各种各样的声明,有人说数据库数据和备份数据已经被物理删除了。据说,每个节点的业务代码都已被删除,目前正在重新部署。有人说这是操作不当,导致企业不可用,以及黑客攻击,甚至内部员工的恶意破坏。

首先,我想谈一谈最早的“实体删除数据库”。事实上,这个提法是很不专业的,应该是第一个沟通者,要强调问题的严重性和恢复的困难,所以我用了“物理删除”的概念,这是普通电脑使用者较为熟悉的。实际上,任何网站的数据库都分为三条防线:本地高可用备份、远程热备份和磁带冷备份。将相应的数据库管理员、操作系统管理员和存储管理员的权限分开。磁带备份的数据甚至存储在银行的地下保险库中。从理论上讲,一个人很难删除所有的备份数据,更不用说生动的物理了。

第二种是黑客攻击和内部员工破坏,这满足了一些旁观者的心理,因此传播得更快。但理性分析也不太可能。黑客注意潜伏和隐藏,做这种事等于是做自杀攻击。而内部人员不太可能,我仍然认为携程的操作和维护人员的行为和专业素养,在刑法的威慑下,除非像“法航飞行员撞山”这样非常个别的案件,在正常情况下,不太可能出现人为的恶意。

从这一现象来看,携程的应用程序和数据库确实被删除了。笔者分析,最大的可能是操作维护人员在正常批量操作中发生误操作。我猜测的版本是:携程已被“黑云”暴露-这是涉及大多数应用服务器和数据库服务器的安全漏洞;当操作和维护人员使用批处理操作(如pssh)执行脚本来修复该漏洞时,操作员无意中编写了错误的对象来删除命令,发生了相同的全局删除,所有应用服务器和数据库服务器都受到了影响。

多年来,这个笑话一直作为一个笑话在运营与维护界流传。我没想到会有这样的一天。

第二,为什么复苏如此缓慢?

上午11:00到晚上8:00,携程网站无法恢复。因此,许多朋友想知道,"为什么现场恢复得如此缓慢?"不存在数据库的备份?"这也是这个术语的一个流行的来源"数据库物理删除”。事实上,这是一个普通用户,了解站点的备份和恢复是一个类似于我们笔记本的系统备份和恢复的场景,认为只有备份才能立即导入和还原。

事实上,大型网站的简单性就像投入多个应用程序和数据库服务器一样简单。一个似乎没有长期变化的网站,后台是一个庞大的服务器集群,由SOA(面向服务的)体系结构组成,在一个看似简单的页面由数百个应用程序子系统组成,每个子系统包括多个应用程序和数据库服务器,您可以理解从主页跳转的每个次域名都是一个单独的应用程序子系统。这些实际上经常发布和改变的应用程序子系统可以少于核心子系统的20%,并且它们在发布时被添加,并且很少完全重新部署应用。

在通常的操作和维护过程中,会有针对常见故障的应急计划。但是,像携程这样的极端情况,包括数据库在内的所有系统都需要重新部署,显然不太可能纳入应急计划。在仓促作出紧急反应的情况下,技术方案的评价和选择、不同技术岗位之间的管理和协调、不同应用系统之间的耦合和依赖以及许多共同欠下的技术纽带已经爆发,更不用说许多不常见的子系统,这些子系统在联机后可能未被触及,在一段时间内将无法处理。更糟糕的是,网站的核心系统可能依赖于这个应用程序,这通常没有人关注,并希望绕过边缘应用程序,恢复所有的核心业务。更不用说在如此高的压力下,也存在大量的噪音和干扰,操作和维护工程师的反应也不像往常那样敏感。

简单地说,即使存在所有的代码和数据库备份,快速恢复业务也比从0重新构建携程更困难。携程的工程师今天一定睡不着觉。乐观估计,如果核心业务能在24小时内恢复,那将是非常好的。

世界的经营和维护是一个大家庭。携程的同事加油,尽快渡过难关!

第三,对失败根源的反思:黑箱运行与维护之战

无论何种原因,携程事件都将成为 IT 运营和维护史上的里程碑事件。 相信所有 IT 企业和技术人员都会认真反思和总结经验教训.. 但我相信,不同岗位的人,他们所看到的可能截然相反,甚至许多企业的管理者可能会被误导,开始制定更严格的规章制度,严格操作和维护人员犯罪。 在此,我想表明一下我的态度: 这是运维造成的问题,但真正的根源不仅仅在于运维,预防和治理应该从整个企业的治理入手..

长期以来,在所有企业中,运营维护部门的地位都是非常边缘化的。企业管理者会觉得运营维护部门是一个成本部门,只要它能够支持业务。业务部门只负责提高业务要求,开发部门只做职能开发,许多非职能问题不受重视,只能依靠操作维护人员在任何地方进行灭火,可以认为操作维护部门依靠自己的血肉来获取业务部门的信息。在这样的情况下,不单止企业的管理人员不知道如何评估操作和维修的价值,甚至很多经营者也不知道除了在任何地方灭火外,还应注意甚麽,当然他们也没有时间和精力去想。

在上述情况下,传统的操作维护人员实际上是所谓的“黑匣子操作和维护”,不断重复操作,经过很长一段时间,只知道自己管理的服务器能够正常的外部服务,而不知道应用程序内部的依赖性,哪种配置是有效的配置,即配置无效,只敢添加配置,不敢删除配置,欠下越来越多的技术债务。在这种情况下,当涉及到携程的极端情况时,当需要一个完整的重建系统时,很容易什么都不做。

对于这样的故障,我认为真正有效的根解决方案是从黑匣子的操作和维护到白盒的操作和维护。与傀儡等操作维护工具的概念相一致,操作维护的核心和难点实际上是配置管理。只有真正明确运维人员管理的系统的功能和配置,才能解决各地的灭火、跑来跑去的问题,才能真正杜绝今天携程等事件的重演,从根本上解决运行维护问题。

从黑匣子的操作维护到白盒的操作和维护,进一步实现了开发操作维护连接和软件定义数据中心,即操作维护2.0。显然,这个运营维护部门是不能单独做的,需要每个企业经理、业务部门、开发部去思考。因此,我希望今天的事件不要简单地让操作和维修承担责任,而是让大家真正从中吸取教训,启发我们。