关于csdn官网我想说没有十全十美的技术！携程事件之后，技术专家们的建议与反思

[按编辑]行车停机事件留给了业界无数的反思。当局起初说：“部分服务器受到未知攻击”，但由于“紧急恢复”推迟，5月29日凌晨恢复服务后，“是工作人员的错误操作造成的”。网上流传着数据库数据和备份数据被物理删除的人，每个节点的业务代码被删除的说法。(威廉莎士比亚，数据库、备份、备份、备份、备份、备份、备份、备份、备份、备份，本文基于微信群体的专家讨论和各公众号文章整理技术人员应得的启示。

地震，资深运维从业者，自动化运维和云倡导，前支付宝运维团队创始人(微信公众号：数据中心操作系统)是运维老手，地震首次在公众号上发出深度文章《深入解析和反思携程宕机事件》。

从现状来看，确实走了那段路程的应用程序和数据库都被删除了。这是运维引起的问题，但真正的根源不仅仅是运维，预防和治理要从整个企业的治理开始。运维需要预防小概率事件，运维制度化由产品化完成，制度和工序要固化在产品上。真正有效的根本原因解决方法是从黑匣子操作维护(运维人员持续重复工作，不知道应用程序相关性、哪些配置有效、哪些配置无效)转移到白盒操作维护。与Puppet等运维工具的概念一致，运维的核心和难点实际上是配置管理。运维人员只能真正清楚地了解托管系统的功能和配置，从根本原因上解决消防和耗尽情况。此外，今天可以重现这些事件，从根本上解决运营和维护问题。从黑匣子运输的角度来看，进一步实现白盒运输、devops(开发运输连接)和软件定义数据中心(所谓的运输2.0)。运营和维护部门本身是做不到的，必须由各企业的管理者、业务部门和开发部门思考。从这次攻击的事件来看，整个数据库极有可能遭到攻击。黑客可以从云存储的应用程序中删除数据，但服务器端可能仍然存在。能否恢复数据取决于私有云存储的架构。从公开的报道来看，内部私有云使用OpenStack，除非黑客也熟悉Swift的体系结构，否则很可能找到Swift的三个备份系统并将其物理删除。(威廉莎士比亚、温斯特里克、Northern Exposure(美国电视)、Northern Exposure(美国电视))，否则可以恢复数据。备份到存储一体化计算机上，我想可以找到数据。(大卫亚设，Northern Exposure(美国电视剧)，存储名言)最坏的情况是，黑客对大多数机器拥有根权限，但进行无差别的破坏性攻击(业务节点、数据库节点、存储节点)，后果是无法想象的。我今天在想，比起运输商品化，运输制度化更重要，更容易实现吗？第二，下面的IaaS层有问题吗？在这种情况下，必须删除有问题的虚拟机，然后直接重新部署新虚拟机。与其重复使用以前，不如完全不知道以前感染了什么问题。(约翰f肯尼迪，学生)王振，资深运维专家，腾讯、YY、UC运维(微信公众号：网络运维闲聊)很多技术层面的东西都值得仔细看。他们的DO分离、权限等级、确认重大更改、集成应用管理、灰色等。灰度是最重要的变更战略，都不遵守。要将制度和流程固化到产品中，将灰度变化作为工具的一部分，实现平台限制。使用灰度作为更改系统的基本功能，配置管理更改或上层更改不能让操作人员一次性操作整个网络。灰度有两个级别。一个是运营层面的机器级灰度。第二个是应用等级灰度。对于变更行为，运营和维护需要一点灰度部分机器，确保变更符合预期，然后逐步放量。(大卫亚设，Northern Exposure，)此外，应用等级灰度是根据用户信息进行灰度。例如，编号段允许一个地区的用户使用新功能。进一步确定工作职能的正常状态。运营层面的灰度化几乎是运营和维护规范意识的一部分，需要通过平台约束。否则，基于脚本的批量更改方法可能会导致这种结果。总是走在河边，没有不湿的脚。

胡慕华、多备份联合创始人CEO不难理解腾讯、格兰德(旅游)、一号店、历任董事、CTO、技术副总裁。这是一个在线批量交易平台，后端连接着3万人的呼叫中心系统、国内外庞大的机票和酒店库存系统、系统。这些应用程序的第二次发布需要自动或半自动维护，第二次重新部署时间较长。这些war数据包应用程序可能会引爆整个内部网的流量，这些应用程序必须部署到其他IDC上。专线肯定不够。恢复时间是不可避免的。交易链越长，整体服务可用性验证也越困难。为了避免这种异常，首先要改造应用程序发布平台，动态静态分离应用程序，并应用严格的工作流批准发布程序。第二，通过核心流程自动化测试缩短在线服务验证时间第三，所有在线应用程序都需要进行备份和版本控制，需要可视化的集中式管理平台来保持最新版本和应用程序之间的关系。第四，重视训练，灾后恢复要进行一周的小练习，1月1日进行大练习。总之，运维是一项细致的工作，业务发展再快，平时也要积累资源和能力。所谓杨炳泉一号，外援一点，关键还是要被自动化工具和程序约束。不是维持人肉。王涛、红杉数据库联合创始人兼CTO被CSDN评为2014 TOP50最有价值CTO。原来是IBM DB2 Lab核心成员的数据库专家就此次登船事件发表了文章《携程事件反思：是时候重视数据库灾备了！》。

基本池之间的延迟。由于主库构建在单独的数据中心中，因此internet延迟是必须考虑的因素。基础池之间的延迟越小，基础库出现故障时丢失的数据就越少。例如，如果主池之间的延迟可以缩小到1秒以内，则在主库所在的系统发生人为或无法控制的灾难时，切换主池造成的数据丢失将限制在1秒以内。因此，与整个门户网站的瘫痪相比，企业蒙受的损失几乎可以忽略不计。

占用带宽小。一般来说，生产数据中心之间的网络带宽非常昂贵。主备份数据中心之间的网络通常通过广域网进行，因此带宽的经济性不应假定为千兆或万兆带宽，如局域网。因此，网络传输时数据通道中的条形数、数据传输时的压缩比率是非常重要的指标。

安全的传输通道。因为数据是通过广域网传输的，所以如果有人在机房外面安装嗅探器，是否有可能拦截我们的网络通信？如果主备份节点之间总是以明文方式通信，这是一个非常重要的安全风险。因此，主备份数据中心之间的数据通信是否加密是第三个重要的安全指标。此外，还有安全领域专家的多篇分析。

Ctrip现已恢复正常，并于5月29日1时30分发表声明。

5月29日1: 30分，将进行技术调查，以确认该事件是由工作人员的错误操作造成的。Ctrip包含多种业务、应用程序和服务，因此花了很长时间来确保应用程序和服务之间的功能正常工作。Ctrip官方网站和APP 28日在23:29完全恢复正常。对于用户造成的不便，我再次表示歉意。服务越互联网化，技术越重要，技术人员的责任感和使命感就越强。没有完美的技术，但可能有更多的方案来保证服务的正常运行。留给大家的想法还有很多。