摘要: 如今，IT世界里的发布已经变成几小时内的事情，甚至几分钟就能完成。所有的内容都要垂直伸缩、水平扩展。因此，有一个良好的监控系统是必需的。在很多IT组织里，应用是业务的核心。但监控却由不写应用的OPS（运 ...
在RTB（实时竞拍）项目中应用MDD 经过一个理解、学习、失败、最终成功的过程，我们才帮开发人员掌握了度量。情况并不简单，开发团队从来没用过度量，而且突然要依靠度量结果去做决策。这个是漫长而艰难的过程，很多因素都会影响最终结果，比如公司文化、员工态度、管理层、甚至工作习惯。为了让管理层和开发团队“买账”，先把度量的价值展示出来就很重要。我们偶然在一个名为实时竞拍（Real Time Bidding）的项目里完成了这件事情。 RTB是一种相对较新的买卖方法，会实时在线显示广告，每次显示一个广告。简而言之，为了在特定网站向特定用户显示横幅广告，我们通过一个叫“Ad Exchanges”的结构接收请求，了解客户愿意支付多少钱。我们收到、处理请求的时候，会给发送端的服务返回响应。这个项目的运营需求是每秒处理四万个查询（QPS），单个交易的往返处理时间不超过一百毫秒。 应用发布到生产环境之后，情况果然非常糟糕，因为我们每秒只能处理五千个查询。而且近30%的交易都失败了，因为我们满足不了一百毫秒的需求。更糟糕的是，性能如此之差却没什么明显的原因。我们搞不清楚问题是源自网络、服务器容量，还是应用层。 最终是度量帮我们找出了问题的真正原因，并扭转了局面。我们每秒能处理的查询最终有七万多个（比一开始多十四倍多），同时能保证失败交易数低于0.5%（大概比原来低五十倍）。但为了实现这样的结果，我们对数据进行了更多分析和结构化处理，在接下来的章节中我们继续说明。 分层的指标 由于在RTB项目开始的时候我们已经有一个度量项目了，所以我们就在RTB应用里嵌入了一些指标。而且我们已经有针对服务器和网络方面的度量。但在数据的海洋里很难辨别出必要的数据、了解趋势，并找出我们的性能远远低于要求阈值的原因。很显然，仅仅有数据并不会带来多大的价值。 所以我们决定在三个层面对数据进行可视化： 业务指标 应用指标 基础设施指标 分层的方法让度量更加结构化了，对所有人（从开发人员到业务人员）来说都变得可用、易于理解。Business Dashboard成为检查应用状态的公共入口点。任何人都可以访问它，检查当前的状况是否符合要求的SLA、使用趋势或收入。如果需要的话，大家还可以深入到Application Dashboard去检查不同应用组件的性能、不同服务器组的延迟及数据增长。事实上，Application Dashboard上的一些指标在Business Dashboard上也有，只是更为详细。举例来说，我们在Business Dashboard上绘制了应用性能，在Application Dashboard上则绘制了应用不同部分的执行情况（见图1和图2）。最后，我们在Infrastructure Dashboard上检查关于CPU、内存和I/O使用率的相关信息。  图1. Business Dashboard上的应用性能  图2. Application Dashboard上的应用性能 要找出问题的根本原因（不仅仅是看结果），接下来要做的就是把不同的指标关联起来。我们把显示关键指标的图形叠加了起来，从上到下依次是业务指标、应用指标和基础设施指标。这种方法有两种用途。我们从上往下看这些图形的时候，可以清楚地看到QPS的变化是怎样影响应用性能和服务器CPU的（参见图3）。相反，从下往上看的时候，则可以看出I/O的增加是如何影响SLA的。  图3. 关联的指标示例（自上往下依次是：QPS、SLA、竞拍服务的性能、CPU负荷） 分层和可用的指标能让开发人员了解项目业务方面的内容。事实上他们能看到我们从哪里赚了多少钱。当新特性或Bug修复发布到生产环境里后，开发人员立即就能在Business Dashboard的金钱图标里看到这些内容对收益产生了怎样的影响。反过来，业务人员也能理解项目技术方面的内容，看到开发人员所面临的问题和我们的负载局限。在现实中，我们还根据度量设置了目标，借此把MDD嵌入到了Scrum里。最终，参与项目的所有人员都对项目的各个部分都有了认识，结果很圆满。 利用度量做决策 在任何活动里，最重要的事情都是认识和理解目标及其背后的原因。你可以创建不同的Dashboard、收集大量度量数据，但如果不作为决策的输入，度量就没什么用处。我见过好几个例子，都是团队创建了多个度量项，但大家却不理解度量的含义和必须设置的原因。所以他们也没利用度量指导决策。还有一个不好的例子，团队做决策时甚至不知道他们的应用到底是怎么运行的（我宁愿说这是我猜的）。他们有一些指标，但还不足以从中获取价值。 MDD的美妙之处在于，它还能最低限度地减少误解。当基于度量做决策的时候，几乎不需要任何解释。决定变得明确、有逻辑、易于阐述，因此也就不易被反驳。决定做得更快更准确，团队的气氛也好转了很多。此外，这也能带来跨团队边界的级联效应。团队间的沟通更多由数据驱动，不再那么情绪化了。换句话说，开发团队和运维团队之间、多个开发团队之间以前会相互指责，这种情况现在则很少发生，甚至完全消失了。 需要注意的是，在某些情况下我们可能从现有的度量里找不到证据，只会去猜问题的真正原因。解决办法是再创建一些指标，来支持或否定最初的假设。 在决策过程中使用度量对大家来说是一个双赢的局面。MDD的主要目标是提供基础设施和应用各个方面的信息，除此以外，MDD还有助于改进团队内部和团队间的关系。 |
