DevOps 2015 - 超越基本指标

现在是 2015 年了，您知道您的 Web 应用程序在生产环境中的表现如何吗？或许您已经安装了一些前端分析插件，并配置了一些服务器监控，以便查看服务器的处理器和内存利用率。然而，核心问题是：您真的知道代码在做什么吗？您能否在特定时间点获取整个服务器集群的快照，并逐行分析应用程序服务器正在执行的操作？内存和处理器利用率是衡量服务器健康状况的绝佳指标，但对您用户的体验又有多少了解呢？硬件指标只能告诉您故事的一部分，您的 Web 应用程序还有许多其他重要的指标，例如服务器响应时间、跳出率和销售转化率，这些指标对您的业务部门来说意义重大。

DevOps 已迅速成为软件行业的时髦词，它提倡许多开发人员和 IT 管理员都不喜欢的东西：协作。根据维基百科的说法，“DevOps 承认软件开发、质量保证和 IT 运维之间的相互依赖性”。通过让技术部门的所有三个分支进行协作，可以以高标准和高效率生产软件产品和服务。在本文中，我们将回顾 IT 运维部门如何更好地关注客户体验，并在无需开发工程师进行任何代码更改的情况下，协助软件开发团队在生产环境中隔离问题。我们将以 AppDynamics Application Intelligence Platform 为例，说明这些协同作用如何为客户带来更好的产品。

Web 性能 – 比以往任何时候都更重要

网络开发者中有一句俗语：性能就是一项功能。对于精通技术的人来说，这句话似乎简单明了，但对于一般的业务分析师来说，可能不太有体会。围绕这句话的一些传闻数字包括：

• Google 发现，页面加载速度慢半秒会导致流量下降 20% – Marissa Mayer，《Google I/O 2008 主题演讲》
• Amazon 发现，页面加载速度减慢一秒钟每年会让他们损失 16 亿美元的销售额。– 《Fast Company》

这些是您 401k 或共同基金投资组合中那些大型上市公司的数据和细节，您可以相信它们非常重视性能。Google 对页面性能的重视程度如此之高，以至于他们已将性能添加到页面排名算法的组成部分中。

讽刺的是，Google 的分析和网站管理员工具并未提供太多关于页面速度的见解。“每次会话页面数”这一数字显示在默认仪表板上，但它并未显示任何关于单个页面速度的信息。

Google 的网站管理员工具通过一个图表提供了一些关于页面性能的见解，该图表显示了 Google 爬虫在请求您网站内容时所遇到的情况。同样，它并未清楚地说明哪些页面性能缓慢，也未清楚地说明在请求期间发生的任何其他事件。

我们需要能够深入了解我们应用程序内部机制的东西，以提供更好的性能检测。如果我们转到托管提供商，例如 Microsoft Azure，我可以通过在线 Azure 门户查看有关处理器和内存利用率的信息。

很好，我可以在 CPU 负载过重或内存不足时添加警报。我还可以通过根据这些指标自动扩展我的 Web 应用程序的功能来增强这一点。

同样，这感觉像是在摸着石头过河：我的客户体验是否良好？页面请求的响应是否足够及时？我只能监控服务器的健康状况，IT 运维部门对此非常重视。服务器是因为访问量增长而繁忙，还是因为软件工程师缺乏性能调优？

获取全貌

要全面了解您的应用程序，如果您组织的应用程序至关重要，您就需要一个整体视图。您必须采用应用程序平台监视器，例如 AppDynamics Application Intelligence Platform。此应用程序监视平台与其他先前讨论的工具类似，您无需更新应用程序源代码即可使其运行。本文讨论的所有功能都无需编写或更改任何代码即可获得。这是开箱即用的。

与前面暴露整个主机或应用程序单个请求信息的示例不同，Application Intelligence 将交互测量为一个完整的业务事务。这种细粒度的测量允许我们在清晰的系统仪表板中审查每个交互对整个平台的影响。

在这个仪表板上，我们可以立即快速查看应用程序的平均响应时间，并查看生产服务器环境中任何运行缓慢的元素，因为它们会以红色突出显示。这种对应用程序的全面概述使 IT 操作员能够即时识别其标准的服务器性能，并显示了应用程序中客户体验的起点。

为什么某些服务被识别为运行缓慢并以红色突出显示？此工具带来的优势是，它会自动计算您应用程序的客户体验基线，然后进行测量。这种动态计算的基线是验证您的客户每次访问都能获得一致体验的关键。

当操作员发现应用程序的性能超出正常参数时，他们可以从这个仪表板开始进行调查。

从这个视图中，我们可以深入到一个特定的事务，并查看其数据如何流经整个平台。

在这个级别查看事务时，很容易发现与数据库的交互存在严重的缓慢，来自右下方 PaymentWS 节点的 ADO.NET 事务需要超过 16 秒才能完成。我们的操作员可以点击 PaymentsWS 节点上方的“Drill Down”指示器，并更详细地查看这些交互。

我们可以在此视图中看到两个问题：连接打开步骤花费了近五秒钟完成，以及一个 ExecuteNonQuery 调用（以蓝色突出显示）花费了超过五秒钟。下一个可用的分析点是我最感兴趣的——我可以检查那个确切的 SQL 语句。

这正是我所擅长的：我现在可以与我的数据库管理员一起对这段代码采取实际行动。我们拥有关于此查询性能及其在平台中如何使用的具体指标。此时，开发人员和数据库管理员可以决定是优化此查询还是优化数据库索引以提高应用程序的性能。

哦，我们还可以检查到“visa.com”的信用卡处理 HTTP 调用的性能（注意：这不是真实地址，与 VISA 无关，仅用于演示目的）。点击 MovieProcessingRole 的“Drill Down”按钮将进入一个完整的堆栈跟踪，该跟踪指向 HTTP 调用。

显然，我们可以看到放慢速度发生在 UploadValues 和 ServiceBus 传输中。检查 UploadValues 调用会反映出发送的用于上传数据的 HTTP 调用。

现在我们清楚地了解到，同步 HTTP 事务会将处理延迟近三秒钟。有了这些信息，我们可以决定采取措施改变架构，以尽量减少此网络交互的影响。

真正的业务指标

一旦客户体验得到优化和监控，IT 运维团队就可以安心了，他们知道自己的服务器运行良好，并且内存和处理器利用率的指标健康。但是，关于我们希望从应用程序收集的测量和指标，故事并未就此结束。

业务真正关心的指标围绕成本和收入。许多以业务为中心的应用程序已经有反向管理应用程序中的报告，以显示销售数字和应用程序的使用情况。但那些那些未直接出现在标准销售报告中的错失的机会呢？如何分析那些没有点击“购买”按钮或以您预期方式使用应用程序的访问者？

对于构建应用程序业务部门的营销和销售团队来说，这些附加指标是必要的，但很难挖掘。您如何跟踪在应用程序中没有采取哪些操作？使用 Google Analytics，我可以使用其访客流量功能来开始看到一些信息。

这提供了一个有趣的起点，但我们可以做得更好。AppDynamics 设计了支持收集这类自定义业务指标的功能。平均业务用户不想深入研究源代码，甚至不知道从数据库的哪个位置提取数据来做业务决策。他们通常寻找一个快速的仪表板视图，展示他们正在寻找的关键指标。例如，销售部门非常关注收入，因此家电零售商的合适仪表板可能看起来像这样：

这看起来不错，但感觉不像销售人员能快速完成的东西。在开发朋友的帮助下，可以将自定义收入指标添加到流程中，以便进行跟踪和呈现。自定义指标可以读取代码中的任何公共方法调用，拦截调用并记录值，而无需添加额外的 Windows 事件日志指标。

随着这些值的收集，我们可以将其与已收集的有关我们应用程序访问者的任何其他指标进行映射。在这种情况下，我们正在收集客户支付的总金额以及客户支付的货币。

随着关于业务交易随时间变化的附加信息的收集，并使用有关访问者的其他已知指标，我们可以开始看到一些有趣的趋势。在仪表板的右下角，我们注意到曲面电视的销售额是平板电视的两倍。也许是时候改变网站的布局，推广库存中较旧的平板电视，同时将曲面屏幕添加到待订购列表中了。

摘要

DevOps 是 2015 年一个崭新的世界，我们需要让开发团队与运维团队合作，以确保我们的生产 Web 应用程序平稳运行。然而，我们在示例中看到，平稳运行和盈利运行不仅仅是开发和运维的关注点。借助 AppDynamics 这样的高级系统管理工具，业务分析师可以获得他们所需的指标，以做出适当的决策来提高应用程序的业务绩效。最终，到头来重要的是应用程序的正常运行时间，而是该 Web 应用程序的投资回报率。先进的指标和分析应该是您在 2015 年的标准工具，以实现这些业务目标。