一个历时3年的综合运维监控项目所带来的感想

           还在2011年时，A客户主动联系到我们，想和我们合作为他们构建行而有效的运维监控平台。在初次接触时，客户的思路和我的思路竟然不谋而合。那时作为多年的技术顾问，一直提倡的是越是做的细致的运维监控平台，越得需要时间去消化，这个消化的过程不仅是客户，也是事实团队面对新的被监控环境的消化过程。于是，在2011年时，和客户进行了细致的交流咨询后，就把整个项目规划了三年，每年工期2月，实现的效果以及客户的要求也很明确：

             1、对数据中心所有基础架构设备进行监控

                   涉及所有windows\unix系统、Sql server\Oralce数据库、Exchange\IIS\Citrix等应用以及各类网络设备

             2、对生产业务系统进行以业务为主导的监控

                  涉及SAP R3以及EBS

             3、实现业务监控层与基础架构层的有效关联

             4、集成邮件、短信告警平台，展示屏

             5、偏重可用性、同时突出业务性能

             6、涉及小量的二次开发工作，维护工作量要低

          很直观的可以看出，客户想要的很简单，不想浪费过多的人力资源去维护这个系统，所以尽量少二次开发。

          偏重可用性、同时突出业务性能，也能看出客户想要什么，就是通过运维监控系统可以最大限度降低MTTR，进而保障生产系统的可运行时间，最大限度的减少不必要的经济损失。

          之后，就是产品选型以及如何把这些工作分三期做完，客户之前仅仅是了解一些运维监控方面的知识，而且很多也是通过考察国外总部时学习到的，他们看到国外总部成熟的运维监控经验给企业所来的真实经济数据，所以一回国就开始着手做这件事。为了保证企业的统一性，通过与他们总部工程师详细沟通，了解到他们总部采用的HP Openview方案，而且已经持续做了六年！现在已经基本做到了智能自动运维的效果（有时候，真的佩服老外做事的耐心，有些事情是需要花时间做才能从本质上发生变化的），跟我沟通的工程师，一个人维护着一个几百台服务器设备的数据中心。于是，我开玩笑的跟A客户说，我们用不用也规划到智能自动运维监控系统，A客户说，不用做出智能，都智能我这帮同事咋办。呵呵。

        于是，就采用HP Openview方案。HP的运维监控平台，是我一直很喜欢，并且比较专注的监控平台，覆盖广，操作简单，自定义性强，本地支持化好，毕竟是牌子货。

          考虑到客户初次上这样的系统，是否能最快的融合到客户本身工作流程中，怎样可以在最短时间内体现出它的作用，成为了一期的目的。在客户可以数量上手后，二期的目的，是在一期基础上，横向扩展，把一期的效果扩展到整个数据中心以及其他分数据中心。随之三期的任务也就有了，纵向发展，将业务层的监控与基础架构层的监控有效映射，行程完整的面向业务为中心的综合运维监控平台。

         规划的架构如下：

    

          那么在一期，做的很简单，采用的是HP OM 以及 NNMi，由于是有代理监控，所以一期仅仅对几台服务器、几十台网络设备进行了监控，完成与邮件和短信平台的集成。其实真心喜欢，A客户的耐心，这样一个量级使得技术人员在短时间内可以熟悉监控平台所具备的主要功能，并学习到如何去维护他，同时按照我们规划的工作流，完成日常工作。而且在项目刚刚投入上线的第一周内，就有效的解决了两次生产环境网络设备凌晨宕机的情况，第一时间得到告警，技术人员第一时间处理了故障，生产线没有受到任何影响。

           在2012年，顺利进入二期阶段，扩容的同时，增加了应用的监控的相应的HP OM SPI，基本覆盖数据中心以及分中心的所有设备。监控方式，依然延续一期，以可用性为主，性能为辅。

          根据我们的意见，A客户的运维监控平台并没有关注，像数据库的缓存命中率、应用处理错误页、锁请求过多等这些特别细致的指标，仅仅是状态、连接数等这类直接反应可用性的数据。这样思路，避免了技术人员面对繁复的监控指标一头雾水，不用每次都为一个性能问题的告警而半夜心跳，这里并不是性能监控不重要，只是在基础架构的日常监控中，过多的性能监控往往会造成人员处理监控的疲劳度的增加，进而影响的是非常重要的可用性的监控，尤其是在被监控对象特别多的情况下。当然有个别工程师提出自己所关注的性能要求，我们也为他所负责的设备单独进行性能监控的细化和扩展。

          在二期，我们在项目进度里增加了试运行，监控优化调优过程，在初次试运行阶段，发现了大量的报警风暴，被测技术人员可怜的说，手机短信收到死机，呵呵，当然这个是我们的疏忽，忘记把挡板启动起来。单从这方面也反映出，简而有效的监控策略以及良好的消息抑制策略，对一个大量级监控是非常重要的。

           刚到2013年不久，A客户又通知，三期启动，他们很期待，历史两年将基础架构系统运维监控融入到日常的工作中，并对生产环境的高可持续性能运转起到了良好的保驾护航作用。但随之带来的问题也就凸显了，监控无法做到100%全面覆盖，何况基础架构的监控是以可用性为偏重点，纯业务角度的监控是当前监控的盲点。不论过么复杂的基础架构监控，目的是为了保证其支撑的业务可以良好运行，那么业务层监控的目的就是实现，直接从业务的角度，主动探测业务的可用性以及性能。

           其实这个原理很简单，基于HP Loadrunner可以对众多协议的业务进行脚本的录制和开发。这样依托这样的一系列脚本，我们就可以在无人看守的情况，让HP BPM主动去探测这些业务的可用性和性能问题，并且可以对这些业务进行分析。

           这样的一种方式，让客户感觉更加简单直观的得知自己生产业务系统的健康状态。同时依托基础架构层的监控，也可以发现很多重大故障。

           在三期过程中，耗费大量时间的是对业务的调研工作，因为后期业务和基础架构的映射关系，就得需要这些资料，最终决定的是监控的有效性。我们的调研做到了多细致呢，直接看示例图（注：该图仅是示意图，不代表任何客户系统架构，请勿盗链，谢谢）：

         

                依靠这些详尽的业务流调查，最终的构建成的非常详细完整的业务层与基础架构层的监控Topology map（不代表任何客户环境）：

                      这样的一种拓扑映射图，让客户直观的看到业务和基础架构层的整体健康状态。是一种自顶向下的360度监控。

                      再秀一下其他的图：

                       上图，为HP BSM业务监控层根据采集层HP BPM自动生成的树状监控界面，其中绿色表明业务处于高可用性和高性能状态。

                       该界面支持“托拉拽”。

                       当鼠标指向摸个业务时，自动弹出红色方框所示显示小板，可直观显示该业务的运行状态以及该业务当前的性能响应时间。

          至此，A客户的为其三年的三步走，使得自己拥有了一个较为全面的面向业务为中心的综合监控平台。在近三年的过程中，我们和客户一起进行这相互的学习，我们学习到如何可以使运维监控系统更加高效率的融入一个工作环境中，同时最大限度为相关数据中心保驾护航，客户也熟练掌握了如何有效利用这样的一个平台，将自己的IT价值转换为业务价值，进而转换为企业的价值。

          虽然，这样类似的项目已经做过了很多，但是这是为数不多愿意以一个特别踏实的心态去尝试、学习、融入，让运维监控平台更加行之有效的为企业服务。现在，客户准备将这项工作继续进展下去，下一步就是运维监控自动化，其实在一期开始，我们应客户的需求就在某些监控策略上，进行了自动故障处理的小脚本或者小程序的埋入。大多数情况下，还是比较好使的。客户也想通了，自动运维监控并不是要缩减编制或者人员，是让技术人员有更多的精力到更加需要他们的地方去为这个企业的IT乃至业务而服务。

          下面秀一下其他的监控图，同样不代表任何客户：

             业务细分报告

              HPBMS可以对没个具体业务进行事务诊断，可以直观看到每个业务在不同通讯阶段所消耗的时间，以此可以对业务的优化提供相应参考数据。

     业务代码诊断

  

          可下钻到方法层

     等等

                                                                                                      【结束】