作服务的必看：应用性能管理成熟度模型 --Idea Worth Spread

 --Idea Worth Spread

 

在企业中证实APM

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

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

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

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

• 问题的数量和严重性级别
• 平均修复时间（MTTR——一般是从问题产生影响到被解决的平均时间）
• 对业务影响进行量化测量（例如：每分钟损失的美圆、丢失的潜在用户、每分钟丢失的交易）
• 对每一个问题进行故障排除所涉及的平均员工数
• 每次事故的根本缘由

你将会在后续的评估文档和业务证实中使用到这些数据。

 

2. 清点你所拥有的工具

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

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

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

3. 发现你的盲点

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

1. 终端用户体验监控：测量你的应用和终端用户之间全部交互方式的响应时间。仅仅理解应用在数据中心范围内跑得有多快是不够的。
2. 应用拓扑映射：自动检测和展现全部应用交付所涉及的组件。你须要知道在任意指定时间内使用了哪些应用组件，特别是当某个问题对你的用户形成影响的时候。
3. 业务事务分析（Business Transaction Profiling）：检测和测量由单个用户发起的请求所涉及的全部应用组件活动中的响应时间。这与测量单个web页面的响应时间是不一样的。
4. 深度应用诊断：检测和测量代码在你应用容器中执行的运行时间。若是你当前或将来的解决方案无需加载到应用容器中，那你将不须要此项重要功能。
5. 分析：数据的智能应用将为你提供可供执行的信息。分析与报表是不一样的，分析能够（应该）做为多个竞争方案间的关键鉴别方式。

对于能在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摇滚巨星的惟一方式是谨慎地平衡好三个部分：人员、流程和技术。

关于做者

Jim Hirschauer是AppDynamics的技术布道者。在加入AppDynamics以前，Jim在APM用户端的问题处理，紧急状况处置以及推进APM供应商精益求精方面花费了多年的时间。Jim的观点源自于他在高压金融服务环境下的工做，可是这些方式也适用于任何追求卓越的IT机构

 

查看英文连接：http://www.infoq.com/articles/apm-maturity-model