我的团队做系统优化是从2003年开始的。应hp service的邀请，2003年我加入了他们的海尔系统优化组，负责oracle数据库的优化工作。这是我第一次参加大型系统的优化工作，甚至那时候我还不知道一个大型售后服务系统的优化该从何处入手。我是带着李维斯的一本书出发去青岛参加这个优化项目的，通过这个项目，我对oracle数据库的优化有了初步的认识。后来我又帮助hp完成了对华为scm系统所采用的caf平台的性能评估，并对决策者建议及时中止这个项目，避免更大的资金浪费，因为这个项目已经无法优化了。后来hp采纳了我的建议，关闭了基于caf平台的项目，华为也重新选择了oracle ebs作为scm系统和erp系统的基础。从那以后，我们的团队规模越来越大，做的优化项目也越来越多，也锻炼出了一批做系统优化的专家。
2011年，我们开始帮助国家电网做系统优化，刚开始的几个项目在专家的带队下，效果都特别好。客户希望我们扩大优化范围，制订了一个需要近百名DBA的大型优化项目。我们从很多合作伙伴处招募了数十名DBA共同参与这个项目，为了确保项目的质量，我们对整个团队进行了多次集中培训。不过最后这个项目做下来效果很不理想，最主要的原因就是DBA的能力参差不齐，大多数没有参加过大型优化项目。从那个项目开始，我也在思考传统的依靠人和专家的运维模式存在的问题，希望找到一条道路，能够让专家的经验发挥更大的作用。这是我开发D-SMART，一个运维知识自动化系统的初衷。要想构建一个知识自动化系统，必须提高运中的数字化程度。不过传统行业IT运维的数字化程度很低。其主要原因有几个方面。
资源有限：很多企业可能没有足够的资源去投入研发和实施智能化运维系统，或者可能认为将资源投入其他方面更有回报。
文化因素：一些企业可能更愿意依靠人工经验而不是自动化系统，可能是因为他们缺乏对自动化系统的信任，或者他们可能认为在紧急情况下专家的判断比机器更可靠。
技术限制：一些企业可能缺乏必要的技术基础设施来支持智能化运维系统，这可能需要较高的成本投入来升级设备和系统。
意识不足：一些企业可能没有意识到数字化运维的潜在优势，或者可能没有足够的知识和了解数字化运维的实施方法。
虽然传统行业在运维数字化上存在各种认知的不足，但随着技术的发展和数字化的日益重要，智能化运维将成为未来信息系统运维的一个趋势，也是一个必然的方向。
反思我们这些年做系统优化与运维的工作经历，经验不足的技术人员是导致优化工作效果不佳的重要因素。优化工作需要专业知识和技能，而不是仅仅依靠经验。可能需要更加系统化的培训来确保所有参与优化工作的人员具备必要的技能和知识。此外，优化工作的效果也受到多个因素的影响，如系统设计，数据质量和优化工作的过程等。
随着技术的不断发展，现在已经有许多智能化的算法与方法可供使用，可以大大提高运维效率和减少人为错误。通过运维知识自动化工具可以提供智能化分析和自动化操作，以帮助DBA更好地管理和优化系统。如果企业有足够的资源，可以考虑引入这些工具和系统来改善运维效率。“运维知识自动化系统”结合了大数据分析、人工智能等技术，以及专家经验和工作积累，构建了一个全面的运维知识体系，可以帮助提高运维工作的效率和质量。通过监控指标体系、健康模型、运维知识图谱、异常检测算法等技术，“运维知识自动化系统”可以自动化地分析和解决系统性能问题，同时还能提供智能化的优化建议和决策支持，为企业的运维工作提供了强有力的支持。
实际上D-SMART系统开发的最重要的目的是对我们这个团队这二十多年在IT运维与系统优化上的经验的总结，让团队中的专家把这些年积累的经验变成可自动化执行的数字化知识库。并通过不断的迭代知识库，让运维知识不断的能够在平台中沉淀与积累，从而不断提升自动化分析的能力。
这个系统的研发不仅仅依赖于研发团队，知识工具的研发完全由DBA完成，而没有借助于普通的运维人员。这是因为普通的研发人员并不了解IT运维，不了解数据库，不了解性能优化。只有做过运维工作的DBA才能够更加准确的把专家的思路变成自动化的工具。
D-SMART系统的起点是指标体系，我认为指标是专家经验的一部分，而且是十分重要的一部分，专家认知后的指标才是可以完全解读的指标。而目前很多数据库监控软件提供的很多指标，运维人员无法正确解读，哪怕这些指标出现了异常，可能也无法被发现，或者说发现了指标异常也无法感知到系统哪个地方出现了问题。而专家梳理出来的指标数据都是单一可被专家解读的，因此每个指标都会被专家进行标注，打上特定的标签。
D-SMART的第二步是完成指标的准确采集，准确的采集到每个指标的数据对于智能化运维系统来说十分关键。要确保每个数据都能够准确的反映出数据库的真实状态十分关键。很多数据被采集回来后，需要经过加工才能变成可被使用的指标，这些加工算法里也体现了专家的经验。通过这个步骤，D-SMART系统在不断的获取数据库运行状态的数字化模型。
第三步是对采集回来的指标、日志数据进行自动化的建模分析。我们通过健康模型判断数据库的运行状态是否正常，是否存在风险；通过性能模型了解数据库的总体性能状态；通过负载模型了解数据库当前的负载情况；通过故障模型发现数据库可能存在的隐患，并及时报警。
第四步是利用这些被采集回来的数据自动完成各种巡检工作。比如日检，每天半夜系统会自动对前一天采集的数据做分析，发现其中的风险与隐患，并生成日检报告。每个月或者每个星期，可以定制任务对最近采集的数据进行自动化分析，生成巡检报告。这种巡检能够分析全面的数据，比传统的靠人工采集数据，人工进行分析的方式拥有更为丰富的数据。通过自动化分析的算法也更加高效。
利用这些数据，还可以做很多有价值的分析工作，比如容量预测、性能优化、专项审计等。同时利用标准化的指标体系，我们还可以构建一线运维与二三线运维的数字化沟通，通过完善的指标集，可以尽可能全面的为三线运维提供数据库运行的全景视图，真正做到不用到现场，专家可以尽知天下事。
前阵子80多岁的母亲一定要给我过个生日，这些年在外面跑，已经有十多年没有过生日了。插蜡烛的时候才发现，过完生日已经54岁，离退休已经时日无多了。我想在现在还能做点事情的时候，尽可能的能够把这些年积累的经验都数字化了，能够留下来，这样也就没有遗憾了。
