信息系统优化该怎么做，仁者见仁智者见智，其实没有一定之规。有些人说系统优化应该集中做，不应该做的太频繁，否则成本太高，影响生产系统的稳定性；有的人说不能等系统出大问题再去做优化，平时就应该把小毛病都解决了，这样系统才更稳定。如果让老白来当裁判，对于优化，无论什么观点都对，做优化肯定比不做优化强，是不是这个道理呢？持不同立场的人可能面对的实际情况不同，有些企业是比较适合做常态化优化的，有些企业只适合做专项的优化项目。这二者并没有哪个好哪个不好的区别，只是针对不同的企业效果不同而已。
今天老白和大家讨论的是信息系统常态化优化，对于一些有大量的系统在运行的企业来说，做项目型的优化项目的成本过高，这种情况下，常态化优化可能是一个比较合适的选择。以日常运维目标为出发点，不断创新技术措施，调整管控方法，形成一套信息系统常态优化管控体系。在优化实践中不断完善，可以全面提升企业信息系统安全运行水平。常态化优化工作主要从以下方面体现运维提升优势：
增强系统稳定性：消除系统隐患，提升系统稳定性，降低意外停机风险，保障系统安全性
改善用户体验：改善用户使用感受，增强系统可用性，提升系统使用效率，强化系统支撑能力
减少硬件投资成本：改变传统以扩容换性能模式，降低对高端服务器需求，保障现有软硬件投资，提高投资使用效率
提升运维保障能力：强化运维能力建设，打造一支经验丰富、业务优良、纪律严明、保障有力的运维队伍
既然在企业里，常态化优化工作作为一个专项被提出来，那么和日常的运维工作混为一谈就是不合适，的必须作为企业运维工作的一个专项来进行开展，确定独立的工作目标，建立完善的组织与管控体系，设置合理的建设目标与考核评估体系。在组织架构上面，可以采用实体团队或者虚拟团队的方式建立专项工作小组，并统一协调与整合目前的运维、研发队伍，形成统一的合力，积极参与常态化优化工作。虚拟小组可以按下面的方式建立：
优化管控组：掌握企业系统性能情况，负责统一组织、总体管控、协调各类资源、考核激励等；性能优化团队：负责与运维单位接口；负责收集运维单位各类需求及各类文档，进行分类汇总交付管控组，归档历史典型优化经验，建立、更新优化知识库；负责对运维单位提出的需求进行问题分析，并给出处理意见，无法处理疑难问题交付专家组，并定期给优化团队及运维单位进行培训；负责运维单位现场实施工作、定期现场巡检、特殊时期的现场保障；持续研究优化性能技术、指导运行单位建立性能优化常态机制、指导协助开发单位系统新版本发布测试验证、协助开发单位系统上线前架构审查、数模审查、代码走查、压力测试优化等；开发单位：负责对运维团队及性能优化团队提出的架构级、代码级、SQL语句等方案进行整改；运维团队：按要求建立性能优化运维体系，监测性能优化问题，按指导手册进行处理，处理不了的问题，以缺陷工单的形式上报到信通部优化团队，协助优化团队开展优化，确认优化成果，按时编制系统运行性能分析报告，反馈优化团队工单处理质量与客户满意度。提炼性能优化工作成果，上报优化团队，完善知识库。业务部门：反馈各类系统优化需求，并最终确认优化成果。常态化性能优化全过程，以技术过程为主线，以管理控制为手段，贯穿于企业信息系统建设的全过程：
整个优化工作分为上线前阶段与上线后阶段两个部分，上线前部分是系统建设阶段，将优化工作迁移到建设阶段可以在建设早期发现系统架构等方面存在的问题，避免问题老化，整改成本过高。在建设阶段，我们的优化工作可以主要集中在以下几个方面：在《概要设计》技术架构评审时，加入由企业IT主管部门组织的软硬件架构设计评审。评判硬件配备的合理性、软件选型与配置的合理性、软硬件组合方式的合理性、高可用设计的合理性。性能优化团队给出问题清单，并提供具体的《架构评审问题分析与优化建议方案》，在运行部门批复上线申请时，把关架构设计是否经过优化团队评估及已评估意见修订。在数模设计完成，开始开发之前，开发单位将完整数模提交给性能优化项目组进行评估，主要内容包括：表字段组成结构合理性、分区合理性、索引合理性、主外键合理性、数据生命周期设计合理性等，性能优化团队审核后提供《数模审核优化建议方案》，运行单位在验证具有相应材料后才允许上线。在系统提交测试之前，开发商将核心功能的程序包（优化团队通过技术手段，从中抽取SQL语句）、存储过程、函数提交至运行处性能优化团队进行审核，主要审核SQL语句编码的高效性、存储过程与函数中的逻辑设计高效性及内部SQL语句的高效性，以及反向审核表结构与索引设计的合理性。运行处性能优化团队给出问题清单，并提供具体的《代码审核问题分析与优化建议方案》，运行单位在验证具有相应材料后才允许上线。在系统部署与试运行阶段，需要建立系统的运行基线，从而为后续的常态化运行阶段的优化工作奠定基础。上线阶段与上线后阶段的优化工作如下。
上线前实施标准化检查
运维单位按照《标准化指导手册》安装配置软件环境，对部分无法标准化指导的，及非常规软件及使用方法等情况，由性能优化团队的工程师提供《安装部署规划与实施方案》并指导实施。
建立运行基线
由于不同系统的架构不同，上线后，建立适应系统本身的性能基线体系，性能问题各不相同，无法用一套指导手册全覆盖，需要在系统上线后，性能优化团队到现场进行性能优化，总结经验后，形成共享知识库。而这个过程，可以用项目形式来开展，分成需求收集、需求分析、方案设计、方案评审、方案实施和效果评估。
采用监测工具或脚本，自动发现性能问题，如CPU、内存使用率、网络、I/O、高消耗SQL等。运维团队判断可以自行优化的则自行优化，对不宜自行优化或者无法自行优化的，将问题提交至优化团队。优化团队受理的优化需求，需要出具可以指导运维团队或开发单位整改的《性能问题与优化建议方案》。用户优化刚性需求提报与优化
在日常工作中企业服务台（HELP DESK）收集用户使用过程中无法接受，需要优化的功能点。用户提报的性能问题体现在功能点上，由于程序是封装的，运维人员难以判断问题的原因，所以需要将需求提交至性能优化团队进行问题原因分析，并出具可以指导运维团队或开发单位整改的《XX功能问题原因分析与优化建议方案》用户实际操作行为性能体验监测优化
对用户主动参与不积极的情况下，需要有用户实际操作行为响应时间监测手段，解决用户不说问题，或说不清楚问题而只抱怨，或问题已解决，却仍凭着历史印象仍然向上反映或抱怨已经不存在了的性能问题。对通过辅助工具监测到的用户操作行为响应性能差的功能，由于程序是封装的，运维人员难以判断问题的原因，所以需要将需求提交至性能优化团队进行问题原因分析，并出具可以指导开发单位整改的《XX功能问题原因分析与优化建议方案》。例行性维护优化
对表碎片、索引碎片等，可以制定成定期任务，每月或每季度由运维团队定期实施。
还是那句老话，有因才有果，信息系统常态化优化是需要企业投入专项资金的，很多企业都习惯于把这件事当成一个任务压给开发商或者运维团队去干，不增加人手，不单列费用，这种做法恐怕是很难获得比较好的实效的。
常态化优化虽然需要投入一定的资金与人员，不过其收益还是十分明显的，在系统运行稳定性，对业务的支撑能力，以及节约硬件投资方面都能起到十分好的效果。不过企业如果不把这些看成是运维部门的功劳，只是觉得优化是在花钱，那么这件事也很难坚持干下去了。
另外一方面，常态化优化如果投入的人员成本过大，也会导致企业无法长期坚持下去。因此引进必要的工具，引入三线合作伙伴，建立一套低成本的常态化体系十分关键。老白的团队在2019年尝试利用D-SMART工具在某个省电力公司开展常态化优化与健康管理工作，取得了不错的成果。投入一个专人负责使用D-SMART进行健康与性能监控，由基石数据的三线专家队伍提供支撑，客户的运检中心与开发商积极配合，对40多套系统进行常态化优化工作，在第一个月就发现各类问题140多个，其中90%以上在15天内得到解决，取得了良好的效果。目前该工作覆盖的系统已经超过了100套，同时大量的在建系统也逐步纳入到常态化优化的工作范围中。通过工具、生态的建立，逐步降低常态化优化的工作成本，提升工作效率，是老白团队不断摸索的工作。以后再找时间给大家分享这个案例吧。
