摘要 : 运维是一个细活慢活，业务发展的再快再好，也要平时累积资源和能力，正所谓养兵千日，用兵一时，关键时刻还是得靠自动化工具和流程来约束，而不是人肉维护。

今天凌晨1:30看到携程安全部负责人凌云微信朋友圈发文：经携程技术排查，确认此事件是由于员工错误操作导致，整个恢复过程花了较长时间验证。

不难理解，携程做为一个在线海量交易平台，后端还连接一个3万人的呼叫中心系统，以及对接国内外的海量的机票和酒店库存系统，系统的耦合度非常高，应用程序部署在数万台服务器上，即使SOA实施的再完美，这些应用程序二次发布无论是自动发布还是半自动维护，二次重新部署时间一定很长，就这些war包应用程序都有可能把整个内网的流量撑爆，这些应用程序还要分发到不同的IDC，专线肯定都不够用，恢复时长在所难免，同时交易链条越长，整个服务可用性验证也很艰辛。

携程今天出现的事故只是一个例子，但这个例子后面的企业IT架构，数据管理和容灾管理思路相信是目前绝大部分企业的特征，如有线上的服务，也有内部的支撑IT网络和系统，也有外部对接的ERP诸如之类的系统 ，有自己搭建的机房或私有云，也有购买的云计算产品 ；在此基础上，目前大部分企业实际做了一些。

在线类业务/核心业务，出问题，影响股价，影响品牌， 可能给企业带来灾难性的影响，本文重点讨论如何保护。一般来说，对业务的保护，要有防线层次，防范此类异常情况，一是应用发布平台要改造，应用程序动静态分离，严格的工作流审批发布程序；二是核心流程自动化测试，缩短应用上线服务验证时间；三是所有在线应用程序都要做备份和版本管理，需要一个可视化的集中管理平台维护最新版本和应用之间的关系；四是重视演练，灾难恢复要做到一周一小练，一月一大练。

总之，运维是一个细活慢活，业务发展的再快再好，也要平时累积资源和能力，正所谓养兵千日，用兵一时，关键时刻还是得靠自动化工具和流程来约束，而不是人肉维护。