今天跟大家聊聊IT运维。

我们的生活和工作，越来越依赖于IT系统，无论支付、办公、吃穿住行……离了互联网和软件，一天也玩不转。当然，与前端应用日益丰富对应的，就是IT系统后台的日益复杂、运维工作的日益困难。可以说，IT运维工作支撑着社会运转的基础，离每个人都不遥远。

如果你是某单位的IT运维人员，那么下面这些状况一定不陌生：

• 周一，网络部门做了负载均衡的升级，业务部门反馈偶尔出现业务响应慢，是升级的问题还是应用系统的问题？
• 周三，文档系统进行了硬件迁移，用户发现文档系统的页面打不开，是网络问题？服务器问题？还是应用问题？
• 周日，大量用户投诉办理业务卡顿，系统的架构非常复杂，毛病出在哪儿？

业务部门和用户眼巴巴等着，你怎么办？如果短时间找不到问题原因，搞不定系统，那这个锅你算背定了。其实，在很多单位，IT运维部门基本就是专业背锅侠。

尤其是，IT监控技术已经从传统的NPM（网络和基础设施监控）进化到APM（应用监控），从数据为中心进化到业务为中心，上面三个例子，都必须由APM技术出马搞定。

要扛住系统压力，拯救宇宙苍生，维护世界和平，没一套盖世武功怎么行？今天，浪迹IT江湖三十年的老戏骨融哥，就给你讲讲IT运维技术的天下大势，教你怎样练就一身张无忌般百毒不侵的九阳神功，重重进阶，金刚不坏。

九阳神功第一重：氤氲紫气

当下将“九阳神功”的练法和口诀传了无忌……丹田里的真气似香烟缭绕，悠游自在，那就是所谓“氤氲紫气”。——《倚天屠龙记》

何谓紫气？正所谓紫气东来，数据来源是也。要想洞察IT系统的运转情况，监控数据的来源当然是基础。这就是九阳神功第一重。

采集IT系统的运行信息，有哪些主流技术？大致有四种：agent、代码植入、主动探测和今天要讲的旁路流量抓包。

简单讲讲前面几种技术的弊端：agent曾经非常流行，但它要求在业务服务器上安装和运行新的软件，本身就会消耗服务器的性能；代码植入，要求对被监控的应用系统进行改造，植入监控代码，这对很多动辄几十套、上百套应用系统的大型单位来说不可能；主动探测，与前两者类似，也是一种消耗系统资源的方法。总之，这三种都是带有一定“侵入性”的技术。

而旁路流量抓包技术，是近年来出现的一种新的监控技术，从网络设备的镜像端口把服务器之间的流量直接导出，接入单独的监控系统，完全不消耗业务服务器的资源，也不需要做应用系统的改造，是一种非侵入性的技术。

而且数据包是最真实的，做不得一点假。通过反向工程，从数据流中重建应用系统之间的一切交互，计算指标，发现问题。

下图就是交换机SPAN抓包技术，通过交换机流量拷贝到一个新的端口，获取所有被监控系统之间的数据流。当然还有很多技术，如为了提高性能可以引入多台TAP SWITCH，以后有机会再谈。

采用流量抓包技术做APM监控的，目前国外主要有Compuware、Riverbed APM等，在国内很多大型机构有使用。国内厂家中，掌握这种技术的不多，华青融天的EZSonar（鹰眼平台）是毫无疑义的扛把子。作为国内厂商当然具有价格实惠、定制开发灵活等优势，而系统的品质也并不弱于国外同行。

那么，从数据流中如何区分出各个应用系统的流量，并计算出性能指标，发现异常呢？

简单地说，我们可以考虑四个主要性能指标：交易量、响应时间、响应率、成功率。通过从数据包中识别一笔交易，可以计算交易量；通过计算请求发起时间（T1）到反馈时间（T2）之间的时延，可以计算响应时间；通过判断是否有T2存在，计算响应率；通过判断反馈数据包中是否包含业务返回码，计算成功率。

当然旁路抓包技术是复杂的，融哥的讲解只是蜻蜓点水，要想get到武功精髓，各位少侠还得勤学苦练哦。

九阳神功第二重：易筋洗髓

易筋洗髓是为深厚内功，得此功犹入无人之境。——《倚天屠龙记》

修炼到第一重，获得了旁路数据流量，只是具备了监控的基础，怎样解析它，让数据包说话，从中重建出各个应用系统之间的信息流，计算指标和发现问题，才是挑战所在。

经过系统的报文解析，将杂乱的数据流转化为规范的信息项，正所谓易筋洗髓，改头换面，呈现出所有应用交互信息和指标的本来面目。

很多大型商业机构如银行、证券、运营商等，动辄几十上百套应用系统，有些是标准的商业软件，有些是国内定制开发的行业软件，它们的数据报文格式五花八门，犹如进了联合国，要求监控系统必须有几百种语言的同声传译水平。而且性能也是一个关键挑战，因为每秒都有若干GB的流量汹涌而来，能否及时地解析它们，要求软件的流量工程能力极强。

例如，上面就是一段报文。肉眼一看，如看天书 。但是如果解码引擎合理地配置了报文解码规则，就像大脑内置了一本强大的字典，就能解码报文背后的应用信息，进而计算出各种指标。

有哪些常见的报文协议类型？DNS、FTP、Telnet、ICMP、Syslog、SNMP、HTTP、POP3、IMAP3、DHCP、RSYNC、NFS、RSH、MEMCHAED、REDIS、XML、Weblogic JMS、Tuxedo、XML OVER TCP、EJB、RMI、JSON、SOAP、CUPS、CTG、Oracle TNS、短信通知平台（移动，电信，联通）、MYSQL、DB2……

可见，对于一个APM系统的建设，应用系统报文协议的解析规则是重要一环。一方面，开发商需要具有深厚的积淀，具备丰富的报文解析规则库，能解析常见的商业软件；同时，建设单位需要提供自身的定制化系统的报文规则，供系统配置补充，这方面也必须方便易用。

对于第一次接触APM系统的人来说，最惊讶的往往是业务层面的一些信息都可以被解读，例如银行的交易金额、程序中使用的SQL语句等等。对于掌控业务运行态势和分析性能问题来说，这些信息是必要的。但需要特别提到的是，如果某些信息是敏感的，可以向厂商说明，对这部分信息屏蔽不做解析。

下面我们就一起来看一看，报文被解析出来以后，监控系统将如何使用和呈现。

九阳神功第三重：至阳热气

至阳热气，全力施展可将人焚为焦炭，专门克破所有寒性和阴毒内力。——《倚天屠龙记》

天下武功，唯快不破。

如果系统已经出现了性能劣化，甚至应用已经宕机，你肯定不希望明天早晨才发现。所以，对于应用监控系统来说，性能计算和告警的时效性是关键，第一时间发现问题先兆，听风辨器、及时预警、防患于未然，才是运维的最高境界。业界往往把数据分为热数据（实时）、温数据（warm）和冷数据，对于关键性的业务监控系统而言，对于数据的要求一定是最高热度的，正所谓至阳热气。

例如，上面是一个金融单位的典型的业务监控界面，每个业务板块和业务系统的性能指标实时刷新，当某系统出现问题时，红色告警就会闪现。这些性能指标的更新和告警的判断，要求后台的计算引擎有着最强大的计算和判断能力。

各位少侠要了解，告警的判断是一个非常复杂的问题。如果仅仅是与静态阈值相比较而触发告警，是远远不够的。例如，一家机构的业务量往往具有一定的时间分布特点，如工作日较高节假日较低，上下午会各有一个交易高峰等等，只有具备智能的算法，对一段历史时间内的指标进行动态基线比对，发现指标的浮动超出了一定范围，才判断为异动，触发告警，提请用户注意。

告警的分级、压缩和降噪也是一个重大问题，如果简单地把所有告警呈现给用户，往往数量过多，使重大问题淹没在一堆无意义的告警之中。智能的后台引擎，必须善于识别出真正的问题，屏蔽假告警，呈现真问题。

要做到这些，让热气腾腾的性能和告警数据实时呈送到界面，就需要在秒级完成从数据流采集到报文解析到性能指标计算和告警识别。具体技术，各村都有各村的高招，华青融天通过采取不落地的内存计算方式，能够保证数据的秒级处理，在近期一家金融机构的实测中，每秒处理的交易量超过70万笔。

好了，恭贺各位少侠，修炼至此，各位已经具备了九阳神功三成三的功力。要想继续进阶，彻底通关，且听融哥下期分解。