在企业中证明APM

　　在企业IT机构中工作过的人都会发现，一些好的工具很频繁地遭遇废弃。有时是因为工具本身没有满足原本的预期或需求；有时是因为该工具的倡导者离开了机构；又或者仅仅是因为在供应商被收购或产品被废弃之后，技术因此而变得过时。对于应用性能管理（APM）方面的工具来说也会面临这样的问题。对于该问题，并没有终极的解决方案。但是，如果你的工作正好是采购像APM这样的工具的话，这里有一些可以供你参考遵循的步骤，可以尽可能避免发生你所采购的软件最终被束之高阁的窘况。以下是我在作为监控架构师和APM买家这一职业生涯中所学习到的一些课程。

　　1. 记录下那些让你痛苦的事情

　　没人会同意为一个工具无端端的买单，除非真的出现了一些伤害到你业务的问题需要去解决（例如：收入减少、生产力影响、客户满意度等）。如果你要证明一次采购的合理性，那就得找出切实存在的问题并将它记录下来。最好是与业务或任务关键应用（比如你的电子商务平台、在线交易应用、支付网关、风险计算、结算系统等）相关的问题。

　　找出那些由于性能不佳和（或）故障时间从而对你业务产生严重影响的应用或服务，并记录以下内容：

　　－问题的数量和严重性级别
　　－平均修复时间（MTTR——通常是从问题产生影响到被解决的平均时间）
　　－对业务影响进行量化测量（例如：每分钟损失的美元、丢失的潜在用户、每分钟丢失的交易）
　　－对每个问题进行故障排除所涉及的平均员工数
　　－每次事故的根本原因
　　－你将会在后续的评估文档和业务证明中使用到这些数据。

　　2. 清点你所拥有的工具

　　很多IT机构都拥有着数十个很少被使用的工具，或者只是曾经被使用过。如果尚未完成统计的工作，你需要清点已经拥有的这些软件并将它们记录下来。只要你持续地更新这个清单，你将会在后续的很多年内一直使用这些信息：

　　－存在哪些工具以及这些工具该如何归类？（例如：数据库监控、网络监控、操作系统监控、桌面监控）
　　－我们拥有哪些软件许可以及哪些许可现在还在有效期内？
　　－这些工具擅长的领域？
　　－这些工具不擅长的领域？
　　－什么可以被归为APM工具？
　　－如果我已经拥有了APM工具，为什么它没有被合理的使用？

　　为你拥有的工具加上标签以便于理解他们的功能。这样做有助于帮你识别出你们薄弱的环节在哪里，并且可以发现那些你所拥有但尚未被充分利用的工具。

　　3. 发现你的盲点

　　现在你已经纵览了整个监控系统体系的全景，你需要查看下是否还存在漏洞。一种检查的方式是将你现有的工具集与一个应用性能管理解决方案应包含的工具集模型进行对比，比如，Gartner定义的APM的 5个维度。针对一个“完整的”APM解决方案，Gartner模型包含了以下5个标准：

　　－终端用户体验监控：测量你的应用和终端用户之间所有交互方式的响应时间。仅仅理解应用在数据中心范围内跑得有多快是不够的。
　　－应用拓扑映射：自动检测和展示所有应用交付所涉及的组件。你需要知道在任意指定时间内使用了哪些应用组件，特别是当某个问题对你的用户造成影响的时候。
　　－业务事务分析（Business Transaction Profiling）：检测和测量由单个用户发起的请求所涉及的所有应用组件活动中的响应时间。这与测量单个web页面的响应时间是不同的。
　　－深度应用诊断：检测和测量代码在你应用容器中执行的运行时间。如果你当前或未来的解决方案无需加载到应用容器中，那你将不需要此项重要功能。
　　－分析：数据的智能应用将为你提供可供执行的信息。分析与报表是不同的，分析可以（应该）作为多个竞争方案间的关键鉴别方式。
 
　　对于能在APM解决方案中寻找什么，Gartner模型应该使你有了一些概念。但是大多数软件本身并不包含以上所描述的APM的五个方面，因此很多机构通过使用不同工具的组合来满足他们对可见性的需求。仔细审查一下你们库存软件清单中的工具列表，从而可以找出你们现有APM策略中的漏洞。

　　一旦你在机构中证明并建立了APM流程，甚至获得了一款APM工具，后续的重点将是开始测量APM程序的有效性并识别出需要改进的方面。这便是APM成熟度模型可以帮助你评估和分析的所在了。

　　一个新的APM成熟度模型

　　成熟度模型通常因为过于偏重理论而难以成功。供应商将成熟度模型强行推销给他们的客户并尽其最大努力来提升对该模型的采用和留存率，而客户则因为过于忙着解决问题而没有对此很上心。这便是我之所以要提出属于我自己的APM成熟度模型的原因，该模型将基于现实世界的经验，帮助我们解决迫在眉睫的问题并使用好APM工具，而不只是停留在应该如何使用APM这一理论上。在这一章节中，我将提出我的新成熟度模型并提供一些APM买家或用户可能在每个阶段提出的典型问题。

　　你会提出什么样的问题？

　　在成熟度模型中，对于你身处何处的最好指标取决于来自你们机构的问题以及陈述的类型。举个例子，当我的孩子问起小宝宝来自何处时，我就马上知道了他目前在生命成熟度模型中所处的位置——并且当任何别的孩子问起相同的问题时，那么不论其年龄大小，很可能也处于相同的阶段。为了更容易地识别出你和你的机构目前所处的阶段，我已经了整理你在流程中的每个阶段可能提出的不同类型的问题，并以此来组织好我的成熟度模型。

　　Hirsch的APM成熟度模型

　　第0级 —— 什么即将发生？

　　－我们刚接到了一连串的电话表示网站或应用变得很慢。这是真的吗？
　　－CPU、内存、磁盘和网络看上去都很正常啊。为什么它还是那么慢？
　　－你开始拨打电话或开启/加入电话会议以询问
　　　　－你是否做了什么改动？
　　　　－你在日志中有发现什么吗？
　　　　－我们的网络是不是出了问题？
　　　　－谁能让DBA马上上线？一定是数据库出了什么问题！
　　　　－系统刚才又重新开始工作了。有谁做了任何修改吗？
　　　　－问题是不是已经修复了？

　　－凌晨三点来自求助台的电话…系统又出问题了。该死的！
　　－某个业务事务是如何与IT基础设施关联的？

　　第1级 —— 过多的信息！

　　－我们的新监控工具确实提供了很多的数据。但是看完所有的这些图表并深入挖掘这些数据将花费好几个小时。
　　－设置所有的警告阈值将花费很长的时间，但是我敢打赌这是值得的。
　　－为什么会有这么多的警告？难道每个功能都在同一时间出了问题？
　　－是不是真的出现了什么状况？我不清楚，只能去测试一下站点或应用把问题找出来。
　　－系统在开发/测试/qa的环境中都运行的很好。生产环境中有什么不同吗？
　　－我们在开发环境中对我们的代码进行了分析优化，但是它在生产环境中仍然越来越慢。这是为什么？
　　－系统在客户那为什么还是这么慢？可是在我们办公室看上去很正常啊。
　　－我们的APM工具在测试时表现得很不错，但是我们还不敢在生产环境使用它。
　　－有谁知道在我们的应用之间存在的依赖关系吗？
　　－我听说过所谓的DevOps。它到底是什么？

　　Level 2 – 唷，变得越来越好了!

　　－我们仍然会得到很多的警告，但是一旦应用变慢或出现问题我们会马上知道。
　　－我们不再需要去经常地设置警告的阈值；当重要的指标偏离他们的基准线时，我们的工具会自动向我们发出警告。
　　－貌似我们应用中的一些功能通常都比较慢。让我们专注于优化那些使用得最多或最重要的功能吧。
　　－我们为应用构建了一个面板来展示它何时变慢或出现了问题。
　　－我们可以看到在测试环境或生产环境中发生的一切，并且知道不同环境间的区别。
　　－由于我们监控了每一个业务事务，所以我们知道是否有终端用户受到了影响。
　　－是的，该问题对应的代码在DoSomething方法的第45行。
　　－我们会为应用自动部署监控。这是我们现在构建或发布流程的一部分。
　　－我们应用之间的依赖会通过工具自动进行映射。当我们做出变更时，不再需要去猜测哪里会出现故障了。
　　－当工作负载出现高峰时我们能自动做出反应从而避免我们的站点变慢或宕机，这是不是很酷？
　　－我想知道业务是否会受到来自该问题的任何影响？

　　Level 3 – APM 摇滚巨星（Rockstar）

　　－我们构建了一个业务与技术的面板以便于每个人可以看到任意指定时间产生的任何影响。
　　－我们整合了所有的监控工具以提供整个应用以及每个组件的健康情况的整体视图。
　　－每当存在某个应用由于用户活动高峰而造成速度变慢（或者当我们预测到将会变慢）时，我们的工具将自动适应并在高峰结束前运转起新的实例。
　　－当我们应用中的任意节点无法正常工作时，我们的工具将会自动移除掉已损坏的节点并替换以新的功能节点。
　　－来源于APM工具集的这些数据将被机构中很多不同的功能组所使用，而这些组横跨了技术和业务。

　　通过查看这些问题和陈述，你基本上已经可以识别出你和你的机构目前属于哪一级别的成熟度模型。甚至更重要的是你或许已经有了一个想法：通过查看你在模型的下一环节需要完成的事项来推进成熟度进程。很明显，利用APM软件是达到APM成熟度高级别的有效部分，但是好的流程和训练有素的人员同样是成功的关键组成部分。成为APM摇滚巨星的唯一方式是谨慎地平衡好三个部分：人员、流程和技术。