高旭磊 : 业务连续性管理之我见

常常有人问笔者，达成系统高可用性，有什么捷径？我说有，就是如履薄冰地按照ISO20000、ISO27000、ISO22301 这样的标准， 做好每一项工作。链条总是在最薄弱的环节断裂，笔者也试图简化这些标准的要求，但总是一次又一次地被现实挫败。其实，每一条标准要求的背后都是“累累白骨”，它们冷漠地惩罚着每一个蔑视其尊严的人们。如果问，这些年来有什么体会？我会说，在严格执行每一条最佳实践的同时，参考以下观点或许对您更有益。

        IT 系统的连续性管理是一项系统性的工作，按照信息安全事件发展的阶段可以分为预防、响应和恢复三个阶段。

预防阶段

        俗话说“防患于未然”，预防阶段的目标是减少信息安全事件发生的概率和影响，广义上说该阶段涵盖了IT 系统开发和运维的很多方面，重点是抓好四个关键：架构标准化、高频度演练、灰度发布、变更标准化。

        架构标准化的关键词是“简化”。在每一个层级删繁就简，消除多样性，做尽可能简单的事情，然后在简单层级的基础上进行叠加，在多个层级之间尽可能地松耦合，让整体像局部一样简单、精确地工作。该逻辑既适用于应用架构，也适用于基础架构，是从顶层设计的角度来解决连续性问题，从根源上减少信息安全事件发生的概率。

        以互联网企业的做法为参考，互联网应用的核心思想是通过“去中心化”的分布式架构来减小单一节点的影响。以腾讯大数据平台为例，通过自主研发的Gaia 云操作系统对CPU、内存、网络IO、磁盘进行调度，实现了最佳的扩展能力和容错能力。单个集群的节点数最大可达8800 台X86 服务器，而即使在使用个人电脑硬盘的情况下，平台的可用性依然达到99.999%。另外一个案例是淘宝自主研发的负载均衡系统LVS，其性能远超商用负载均衡设备，为支撑“双11”的巨额交易量提供了支撑，也保证了系统的可用性。

        有别于互联网企业，金融IT 更强调数据的强一致性，照搬互联网企业的做法不可取，也很难具备“BAT”那样的研发能力，采用经典的“IOE”架构为当前最现实的选择。从长远看，减少开发环境和开发规范的多样性、核心解耦、系统拆分、加大非功能性需求的研发力度、减少对商用数据库的依赖，是努力方向；从短期来说，设计标准化的系统架构、减少硬件种类、减少系统软件的版本数、形成配置参数规范，是可行之举。

        高频度演练的关键词是“习惯”。毕竟可用性故障是小概率事件，不可能每天发生，因此员工在处理故障时容易出现精神紧张，行动慌乱的现象。而高频度演练的首要目的，就是通过频繁地模拟真实故障，让员工经常感受子弹呼啸而过、心跳加速的感觉。通过不断演练，熟能生巧，形成习惯。像日本的地震演习，道理相同。除此之外，设计良好的高频度演练也是发现问题的有效手段。

        灰度发布的关键词是“试错”。对于采用负载均衡架构的应用，采用先发布到其中一台服务器的做法，观察一段时间再发布到所有服务器，以避免全局故障；如果具备预生产环境，先在预生产环境发布，并将少量客户端交易引流到该环境，以检验应用的功能、性能、可靠性等。

        变更标准化的关键词是“规范”。其核心是标准化的操作规范（简称SOP），即通过将变更步骤和命令标准化，避免误操作，减少个体之间因技能、意识不同导致的结果差异，从而降低变更过程中人的风险。

响应阶段

        顾名思义，响应阶段的重点是对已经发生的故障进行响应，尽快确定故障原因，其关键点是尽快通知到应该通知的人，尽快判断发生故障的位置，以便采取针对性的恢复手段。

        响应阶段最重要的三要素是：通讯、工具和预案。

        为了尽快通知到应该通知的人，需要解决两个问题：一是通知谁及先后顺序，二是如何快速通知。第一个问题要求加强通讯录的管理，该通讯录不是简单的办公系统中电话号码的罗列，而是根据应急职责和通知顺序结构化之后的通讯录（简称Call Tree），并且要经常通过Call Tree 演练进行校验，确保电话号码的有效性，尤其要加强第三方机构和供应商的通讯录管理。第二个问题要求解决拨号效率问题，在应急过程中，需要快速通知到所有相关人员，提高沟通效率，并且通过明确的分工，减少各类电话询问对故障诊断过程的干扰。

        为了尽快判断发生故障的位置，主要依赖诊断工具和应急预案，包括监控系统、诊断脚本、故障场景、个人经验，通过诊断信息与故障场景的匹配快速确定故障发生的位置（注：不一定是故障的根本原因）。为达到这一目标，对诊断工具和应急预案的基本要求是：信息更新及时、信息精确投送、场景精确匹配。由于系统的复杂性和故障的多样性，这三点（尤其是第三点）是应急管理最核心、最困难的课题。

恢复阶段

        对于“高频低损”的一般故障而言，一旦定位到了精确的故障位置，恢复相对简单，笔者认为自我修复、半自动化回退和恢复应是努力方向；但对于“低频高损”灾难事件来说，恢复本身是一件复杂的工程，需要通过有序的组织来实现，而灾备演练是检验人员和系统的不二之选。

辩证看待“黑天鹅”型事件

        “黑天鹅”事件，总是在我们自以为是的时刻发生，对于高度不可能事件以及不可预期事件的发生，我们有时显得无能为力和手足无措。

        金融危机的发生是由金融体系的脆弱性内生决定的，金融体系的脆弱性积累到一定程度就会演变成某种形式的危机爆发出来。银行业机构“天然”具有脆弱性，具体表现在资产与负债流动性的不一致、“内部人控制”、信息不对称等方面。同理，信息科技风险也是由IT 系统的脆弱性内生决定的，是与IT 系统相伴而生的，当IT 系统的脆弱性积累到一定程度就会演变成某种形式的信息安全事件爆发出来。

        在IT 体系发展的不同阶段，导致脆弱性的根源不尽相同。在金融电子化的早期，IT 系统以省甚至是市县为单位独立运营，不同运营主体之间依靠低速的网络专线连接。当时面临的问题是业务和管理的低效，以及IT 管理的粗放，但单次信息安全事件的影响范围有限，不足以造成巨大的社会影响。而目前的IT 体系是随着20 世纪90 年代后期的“数据大集中”形成的，其核心特点是“集中”。系统的集中必然导致风险的集中。全局性的、系统性的信息科技安全事件正是在这样的背景下发生的。当今的金融IT，体系庞大、系统众多，凡是能够电子化的基本都实现了电子化，IT 成了金融企业赖以生存的空气。一丁点的缺氧就会带来身体不适，严重一点的缺氧则将直接导致业务休克。当今的金融IT，架构复杂、盘根错节，SOA、数据总线、

        云计算等理念的推行，导致了横向流量的激增，IT系统之间的关联关系变得无比复杂，变更和上线的影响分析比以往更难。应用软件的复杂性，电子元器件的自然损耗，IT 系统对电力、制冷等基础设施的高度依赖，内外部环境对IT 系统的影响，发布和变更对稳定性的影响——种种因素都在威胁着IT 系统的稳定运行，完全杜绝故障实际上成为了一件不可能完成的任务。

        面对这个残酷的现实，我们金融IT 人的应对之策应该是什么？《黑天鹅》的作者塔勒布给出了建议：一是不要预测。对于不可预测的事情作出错误的预测而采取错误的行动，只会犯下更大的错误。二是谨慎预防。我们不能预防灾难，却能预防灾难，充分地分析最极端黑天鹅事件发生的破坏性，并作最充分的预防。三是保持充足冗余。就是凡事留有非常充分的余地，目的只有一个，以防万一。

（文章来源：金融电子化杂志）
 

扫码即可手机
阅读转发此文