企业特别是大型企业这些年在信息化建设方面投入很大，很多企业已经从传统企业转型成为信息化企业，有些企业正在向信息化企业转型的路上，不过这个世界已经从从信息化时代在向数字化时代迈进了。所以说，近些年来，企业的信息化建设速度是在不断的加速的。
企业信息化的加速就意味着大量的信息系统快速的建设起来并得到了充分的应用。而信息系统建设过程中所出现的弊端也不可避免的被带了进来，给系统的运行、使用、维护带来很大的挑战。以我们这些年对系统做运维与优化的经验来看，对于普通的传统企业，信息系统运行过程中遇到的各种问题，包括可靠性、性能等方面的问题，至少有80%的问题是建设阶段遗留下来的或者和建设阶段有关。这些问题大多数会在系统上线后3-5年被暴露出来，主要的特征就是对系统的运行带来一定的隐患或者给用户带来较差的使用体验。面对这样的问题，企业所能做的事情就是优化。实际上，在系统优化这个名词被大家广泛接受之前，这种优化往往被误解为系统资源不足，于是我们常用另外一种方式来替代系统优化，就是系统升级。系统升级包含一部分应用代码被重构和优化，从而解决一些系统资源升级所不能解决的问题，而绝大多数的升级工作是采取资源升级的方式。也就是把我们使用的服务器、网络、存储等进行升级，采购更为强大的硬件资源来替代原有的能力不足的硬件。
通过系统资源的升级可以很快的解决大部分系统存在的问题，于是这一招成为传统企业解决系统问题的灵丹妙药。不过随着企业信息系统的密集建设，以及系统出现问题的时间越来越早（从最初的系统上线3-5年出现问题逐渐提前为系统上线后1年就开始问题不断），这种方式就无以为继了。2004年，我们在参与一个优化项目的时候,我就问这个客户的IT主管，如果你这套系统硬件用了3年后就跑不动了，而优化能让你这套设备多用2年，你愿意为优化出多少钱？他没有直接回答我，只是说，我们这套系统的硬件投资是3000多万，规划是5年后升级换代，不管下次升级换代的费用是多少，每次升级投入的各种资源、系统停机带来的损失都是十分巨大的，让我的系统的更新周期每增加一年的经济价值是十分巨大的，都不是三五百万能够衡量的，这也是为什么我们愿意花2百万来请你们做优化的原因。
实际上，在这些年系统优化工作中，真正遇到十分懂得算账的IT主管也不是十分容易的。很多企业在系统建设上投资多大都是愿意投入的，但是在系统运维与优化方面的投资却十分抠门。这也导致了很多企业的系统实际上是在亚健康状态长期运行，一旦出现问题，其后果是十分严重的。
我所服务的最大客户也经历过这么一个阶段，从2008年开始，企业信息系统从简单的分散建设阶段转变为集约化高速建设阶段，这个阶段大家的重点都放在建设上，在三集五大的顶层规划下，数十套信息系统建设起来，投入运行。随着大量的系统上线，IT部门就发现，很多系统都或多或少的出现了一些运行问题，具体表现在业务部门的用户的使用体验越来越差，抱怨也越来越多。甚至很多业务部门都投诉因为信息系统的性能问题，导致了本部门的业务受到了很大的影响。刚开始的时候，有些问题也确实通过升级硬件后得到了部分解决，因此IT部门也把这些问题归结为系统设计阶段容量设计不足导致了这些问题。
但是随着信息系统建设的深入，很多刚刚上线一年左右的系统也出现了严重的问题，甚至有些系统在硬件资源升级后不久又出现了严重的性能问题。因此IT部门发现资源升级并不是解决问题的灵丹妙药，弄清楚到底在哪个地方出问题才是解决问题的关键。于是在建设处的牵头下，在2011年的10月，成立了大型企业中的第一个专业优化团队，开始开展系统优化工作。第一个工作就选择了当时使用单位反馈最多的“财务系统”。优化团队认真分析了财务管控系统的整体架构，发现应用服务器、数据库服务器的系统资源都是充足的，但是从用户单位反馈的情况来看，十分不乐观。很多用户因甚至因为系统太慢而无法在8小时内完成自己的本职工作，需要通过加班来弥补，给财务部的业务人员造成了极大的困扰。
经过综合分析，优化小组定位问题主要在数据库服务器上，由于财务管控系统使用了VPD技术，并使用了大量的临时表来存储中间结果，导致系统的共享池争用十分严重，同时SQL的性能十分糟糕。因此优化小组抓住了这两点进行针对性的优化，通过优化VPD核心控制代码的PL/SQL代码，使VPD所涉及的所有SQL语句都得到了数倍甚至数十倍的性能提升，通过数据库系统层面的优化，使SGA争用得到了极大的缓解，系统整体性能提升10倍以上，很多以前需要5-10分钟完成的模块优化后只需要几秒钟就可以返回数据了。通过系统优化，使数据库服务器与应用服务器的资源使用率都得到了有效的提高，系统响应速度基本上达到了业务部门能够承受的范围，使国家IT部门的优化工作一炮打响，甚至受到了公司高层的关注。
财务系统优化获得巨大成效的事情被业务部门写成了一篇新闻稿发到了企业内部的报刊上，引起了很大的反响。有用户找到优化小组，说本省建设的一套营销系统，才上线两年，系统的负载就接近90%，业务高峰期感觉明显存在瓶颈。如果要扩容，需要投资2500万，想想系统才建了2年不到就要淘汰，又有些不甘心。于是2012年春天，优化小组进驻客户现场，开始分析营销系统的问题。通过半个月的分析，找到了问题的根源，在系统层面，将RAC集群的通讯网络从千兆升级为万兆；在应用层面，通过数据表、索引的碎片整理，以及对部分历史数据进行归档等工作，使CPU资源使用率从接近90%下降到35%左右，数据库的数据量也从7.8TB瘦身到5TB左右。本次优化后，这套系统在3年内不需要做硬件资源升级了。通过优化RAC集群的内部通讯网络，使集群内部通讯能力从80M/秒提高到890M/秒。当业务负载增加较大，现网的两台IBM P570无法支撑的时候，再采购一台新的小型机加入到集群中，组成三节点数据库集群，就又可以增加30-40%的处理能力了。
2011年与2012年这两个试点工作的成功，让IT部门感受到了系统优化对信息化的核心支撑作用，于是从2013年开始将系统优化工作列为常态化的工作。首先根据IT监控、客服投诉等渠道筛选存在问题较多的系统，列入年度优化计划，列支专项费用进行系统优化工作。从2013年到2018年这段时间的持续优化工作中，也发现了大型企业系统优化工作的复杂性。
这个复杂性体现在需要优化的系统范围十分广泛，几乎所有的信息系统都存在或多或少的需要优化的地方，优化的需求十分分散，采用一刀切式的总部统一安排的方式，在工作推进过程中出现了效率不高，最终用户体验不够理想等问题。总结起来有几个方面，一个是方法论不够完善的问题，这将直接导致优化效果与优化成本相比不够理想的情况；第二个是优化实施队伍的建设问题，系统优化对参加优化的团队能力要求很高，如何构建一支强有力的实施队伍对优化工作的成败至关重要；第三个是成本选择的问题，如何进行优化才具有最佳的性价比，花最小的钱，获得最好的效果是每个企业都追求的；还有就是项目组织的问题，如此庞大的优化项目，所需的人员很多，人员的水平又参差不齐，如何才能组织好优化队伍，使优化工作能够顺利的进行；最后一个问题是效果持久化的问题，如何让优化效果持续的保持下去，从而提升系统优化的价值。
在这些年的工作实践中，我们的优化团队遇到了很多问题，并对这些问题提出了针对性的解决方案，这些解决方案对于大部分传统行业的企业来说都是十分有价值的。
在优化工作方面，按照传统企业的特点，很容易把所有的优化工作都归口，安排统一的经费，统一的团队开展工作。看上去这符合企业集约化办大事的原则，实际上这种一刀切的办法很难面对复杂的应用现状。每个用户，每个部门的系统运行情况都是不同的，系统出现问题的原因也是不同的，所以优化工作也没办法按照一套标准模板去开展。要想破这个局，就需要我们把优化工作根据工作的方法与内容的不同划分为几个小类，分门别类的开展工作。
像我们前面所说的优化工作实际上是一种目标十分明确的专项工作，我们可以称之为专项优化。专项优化一定是选择问题十分突出，优化价值十分大的系统去开展，投入精兵强将，攻坚克难。
实际上我们的信息系统并不总是遇到一些十分严重的问题。日常中遇到一些小问题的几率更高，这种问题有可能一个有点经验的工程师花上个把小时就解决了，没必要兴师动众。这种优化我们就称之为常态化优化。常态化优化的目的是为了解决日常运维中遇到的一些小问题，一般来说都可以由本地的运维人员来完成。
还有一类是系统架构方面存在的问题，由于我们系统的架构设计方面存在不够优化的地方，导致信息系统运行一段时间后出现各种问题。这类问题往往是企业的共性问题，发现问题后，需要有经验的团队设计总体的优化方案，并将该方案交给建设单位去实施。如果建设单位实施能力不足，优化团队的专家还需要给与一定的技术支持。
最后一类问题是应用的问题，如果我们发现某些问题是应用代码的问题，那么普通的优化团队是无法解决问题的。必须通过专门的反馈渠道，将问题反馈到开发单位，由开发单位按期整个，信息管理部门必须对这些问题进行闭环管理，否则开发单位很可能是存在较大的惰性的。
按照这样分类，优化工作就变得更为复杂了，面对一个拥有全国性分子公司的集团企业，一个二三十人的优化团队要高质量的完成这些工作是十分困难的。必须依靠一定的技术手段去进行一定的自动化处理。这个技术手段就是我们今天所说的方法论的一部分。我们解决这个问题的方法就是信息系统健康分析。
系统健康分析是通过将各种运维自动化系统或者监控系统采集的系统运行指标数据进行提取加工和建模，通过模型随时计算系统及系统附属各个组件的健康度。将存在健康风险的事件推送给监控人员，从而帮助运维人员发现系统需要优化的点。当某个问题推送给运维人员后，运维人员可以使用健康管理工具提供的诊断路径对这个问题做深入的分析，从而快速定位问题，快速形成优化方案。通过信息系统健康管理这个核心工具，可以将上述的四种优化工作有机的串联起来。
上面的图例就说明了系统健康分析与四种优化的关系。系统健康分析发现的问题如果属于常态化优化范畴，首先交给现场运维人员去做常态化优化。在常态化优化工作中如果发现某个问题是共性的难题，则交给专项优化团队继续完成（日常运维团队工作十分忙，对于一些较为复杂的问题可能会占用过多的资源），如果发现某些问题是和架构优化有关的，则交给架构优化团队去完成。如果发现某个问题是应用的问题，则将这部分工作交给应用开发厂商去解决。如果系统健康分析发现的问题直接能够定位为架构问题，则直接交给架构优化团队，其他类型的发现也类似处置。
通过上面这样的划分，并且引入系统健康分析后，这个难题就有解了。不过要做好系统健康分析也不简单，关于系统健康分析该怎么做，在后续的章节中会有详细介绍。
