谈软件系统的高可用性规划和建设

　　对于软件平台的高可用性，首先需要充分理解客户的高可用性情况和对业务产生的影响。需要对构成系统的每个组件进行失效影响分析，并制定相应对策；对相关系统的架构、可靠性、稳定性、可扩展性进行整体的评估，提出切实可行的合理化建议。如果用平均无故障运行时间MTTF计算，高可用性至少达到99.9%水平。

　　在我们谈软件平台的高可用性的时候，首先要意识到高可用性是一个系统问题，不仅仅涉及IT硬件基础设施架构，也涉及到软件架构，设计和开发；同时还涉及到治理和管控体系。而对于软件平台的高可用性规划更是要以业务需求和目标驱动，标准体系和系统建设并重的思路进行。必须在从系统规划阶段开始就要考虑高可用性，而不是到了运维阶段才考虑；在规划设计阶段重点是软件应用体系架构，运行阶段重点是IT基础设施架构体系。

　　对于软件平台的高可用性架构规划可以参考IBM的一个图如下：

　　在这个图上可以看到首先是要基于业务目标驱动建立高可用性战略目标，不同的业务目标对于软件平台的高可用性要求显然是不一样得，其次是建立端到端的高可用性管理体系，这个管理体系包括了标准规范，业务流程和约束，管控制度等各个方面的内容，需要覆盖软件平台本身的全生命周期。基于以上两点就很容易对高可用性具体工作进行分解，即包括了IT基础架构，应用体系架构，安全架构，管控架构等各个方面的内容。要想做好高可用性这些内容都必不可少。

　　而从流程和动态分析的角度来看，高可用性规划和建设又包括了评估，规划，设计，设施和运行五个阶段，五个阶段形成一个闭环的持续改进的高可用性规划和建设的流程。具体如下：

　　评估期：建立符合企业业务目标的系统可用性目标，确定提升系统可用性的机会。
　　计划期：制定系统高可用性发展策略并建立实施路线图。
　　设计期：设计企业未来IT环境及架构，制定详细的实施计划。
　　实施期：在保持低成本的前提下，高效快速的协助客户全面提升可用性水平。
　　运行期：通过实施演练，发现系统风险控制的不足之处，制定进一步的提升方案。

　　下面对高可用性规划和建设的五个阶段做一个简单描述：

　　评估期

　　在评估期的重点是建立符合企业业务目标的系统可用性目标，确定提升系统可用性的机会。在评估期我们需要做如下几件事情，首先是明确业务目标和需求，业务究竟对软件平台的高可用性目标是什么?这个目标是否可以进一步量化？其次是对硬件平台和软件平台的现状进行分析和评估，现有的软硬件平台是否能够满足业务目标？现有软件平台是否能够满足业务未来几年的发展目标？如果软硬件平台相关部件失效会造成什么样的影响？(FMEA分析)。

　　在评估期我们会用到TPMC和业务测算模型，对需要的能力和现有的能力进行评估，并根据具体的高可用性要求确定潜在的风险点并作为规划阶段的重要输入。

　　规划期

　　规划期的重点是制定系统高可用性发展策略并建立实施路线图。再次说明高可用性规划是一个系统规划，包括了IT基础设施和硬件平台的规划，中间件平台的规划，软件平台和应用架构体系的规划，软件平台治理和管控体系的规划，安全规划等各个方面的内容。

　　在规划期的重要输入就是评估期的业务目标，现状评估和潜在风险输入。硬件平台是否具备高可扩展性？中间件平台是否足够健壮以支撑大数据量和高并发的业务要求？我们设计的软件是否有足够的容错机制和健壮性保证持续的不停机运行，这些内容都必须在规划的时候就考虑全面。规划完全可以看做是一个高端的设计，如果在规划阶段选型出现失误，很多时候直接影响到架构设计，而且在软件平台正式上线后很难再通过简单的变更进行弥补。

　　设计期

　　设计期是设计企业未来IT环境及架构，制定详细的实施计划。在我看来一个软件系统的高可用性设计包括了IT基础架构的设计，包括了服务器，存储，网络方面的设计；同时也包括了软件方面的设计，在软件方面的设计一方面是中间件平台的选型和设计，一个是基于中间件平台我们自主研发软件的设计。而这个软件的设计类似与软件中的架构设计，这个时候的架构设计重点又在于业务目标中非功能性需求的满足。要知道，很多时候软件平台可用性或性能出现问题，并不是硬件本身能力不足，而是我们软件本身设计和实现上存在缺陷，如选择了不适合的软件框架，实现方式和算法的问题，没有针对性能问题有单独性的设计方案等。

　　如果说到SOA平台来看，设计期更是重点，除了包括高层的SOA服务架构设计外，还包括了SOA服务识别，服务的粒度把握，对服务的调用频度，数据量的分析，服务究竟是同步还是异步？这些都直接影响到服务本身的高可用性问题。
　　实施期

　　实施期重点是在保持低成本的前提下，高效快速的协助客户全面提升可用性水平。如前面所说，如果是全新上线的软件系统在一开始就必须考虑高可用性和非功能性需求。而如果是对已经上线的软件系统，如何在保持低成本的基础上，提升高可用性水平就是关键问题了。

　　如果规划和架构阶段本身存在先天的缺陷，可以说很难在实施期显著提升高可用性水平。根据实际的经验，我们能做的就是加大对系统硬件平台的监控，通过硬件平台的监控反馈回的性能消耗数据来查找软件本身存在具体的性能问题的地方，并逐步的对这些代码进行性能优化和调优。我原来写过一篇性能问题分析的文章，即时是一个性能问题，其本身也涉及到中间件平台的基础设施和调优，数据库的基础设施和调优，数据库存储过程和视图的优化，软件代码本身的分析和优化等诸多环节。

　　已经上线的软件系统不可能进行大改动，这个时候软件本身的稳定性已经高过一切，如果进行大的架构修改和调整，根本无精力再做全面的系统测试和回归测试。只能是逐步调优。

　　运行期

　　运行期的重点可以说已经在运维阶段，包括ITSM，ITIL等各种运维方面的体系和标准也都是在间接的提升IT系统的高可用性问题。如果对于事件管理，问题管理和变更管理都是偏事后的分析和处理，那么对于基于软件平台，硬件基础设施的监控则是一个风险预警机制。

　　运行期的高可用性的重点一定是要从问题管理转化到风险管理，从报警转化到预警，从日常的运维中不断的收集硬件和软件平台的运行数据，通过数据分析找出潜在的性能问题点并有针对性的进行改进。SLA服务等级协议是关于网络服务供应商和客户间的一份合同，其中定义了服务类型、服务质量和客户付款等术语。在运行期引入SLA就是一种分级的管理策略和报警预警兼顾的高可用性管理方式。