摘要: 如今，IT世界里的发布已经变成几小时内的事情，甚至几分钟就能完成。所有的内容都要垂直伸缩、水平扩展。因此，有一个良好的监控系统是必需的。在很多IT组织里，应用是业务的核心。但监控却由不写应用的OPS（运 ...
我们学到了什么 我们走了很长的路才在整个组织里应用了MDD实践。这不仅仅是技术的变化，更重要的是文化上的改变。每个人都需要转换观念、态度、对开发过程的理解。在达成愿景的过程中，我们发现了不同的结果。因此，我想和大家分享两个对你可能有益的经验教训。 我们学到的第一个重要经验是，你应该尽全力为开发团队创造尽可能顺利的体验，避免充当中间人。我们最初尝试的解决方案是让运维团队和开发团队共用一个度量服务器。但效果并不理想，对我们来说主要原因有两个。第一，开发团队受制于运维团队，开发团队做的每个修改都需要运维团队的授权。第二，运维团队不喜欢开发团队频繁修改内容。所以我们决定给开发团队专门提供一台服务器，让他们从中获取所有服务器相关的度量信息。开发人员在那台服务器上修改内容不需要按发布过程执行，也不需要特殊的授权。事实上，他们可以在这台服务器上做几乎所有的事情——甚至从监控里删除其他服务器。尽管让开发人员自由去决定、实施并负责变更看起来有些匪夷所思，但这确实是我们做过的最好的决定之一。 第二个非常实用的经验是，我们花费时间去写“监控愿景”或“监控工具的需求”，但都是浪费时间，因为我们的期望和实现在整个过程中变更了好几次。而且它们会继续变化。花费过多的时间去选择一个度量工具也是一种浪费。没有工具能满足你所有的需求，所以挑一个你用着顺手、适合你们愿景和公司的就可以了。我们选择了Zabbix——一个开源工具。尽管它有一些局限，而且导航复杂（我们甚至称它为“一点就死的工具”），但它能让我们迅速开始。最后，别忘了给最常见的用例准备几个收集数据、图形化展示数据的例子。 让MDD变得有趣些，而且让大家都能看到。把显示重要指标的电视放在门厅或工作空间里。如果可能，图形化显示不同项目的收益。给一定的成就设置奖励，比如连续成功发布的次数（参见图4）。大家一起度量最好的成绩，比如每天、每周、每月最高的访问量或交易数，并一起为之庆祝。这种方法会引发大家的好奇心，让大家提出问题，并参与到度量里来。通常情况下，你可以从添加一些简单的图形开始。同事们在门厅看到后，会立即提出一些很棒的改进意见。  图4. 成功发布的奖励 对参与MDD的所有团队来说，尤其是对开发人员来说，MDD要求的文化变化还是很冒险的。他们开始用自己的应用来观察问题，之前大家都不了解这种做法。Adform的思维模式完全发生了变化。原来的态度是，只要没人抱怨，就认为一切都正常。现在，所有人都知道这不是度量应用性能的好办法。开发人员现在都能很自如地处理度量了。出乎意料的是，开发团队原先看不到度量信息，对自己的应用倒是感觉良好，而现在只要指标不可用，他们就会觉得不舒服。 目前的工作重点和未来计划 我们要在整个组织里推行MDD，新的挑战会随之不断出现。当多个团队有不同的需要、愿景、对度量的理解，却在一起创建指标的时候，事情就会变得很混乱。我们要定期删除不用的指标，并以类似的方式让度量覆盖到新项目。 目前，我们正试着为开发人员创建准则，以确保所有开发人员达成共识。每个开发团队都要能回答下面三个问题： 你怎么知道你的应用运行正常？（Bug少并不够，必须提供进一步的证据，比如模拟） 应用的性能随着时间的推移会有怎样的表现？（比如说，和上一个版本相比，它是越来越快还是越来越慢？在高负载情况下是否仍能良好运行？） 你的应用的使用频率是多少？（比如有多少用户会在同一时间去生成报告？系统在白天会发布多少横幅广告？我们收到多少笔交易？） 这些问题有助于确保所有的应用在进入生产环境前都能被度量，并达到相同的度量覆盖水平。 至于以后的改进，我们现在正在做一个交通信号灯监控层（为了获得更快的反馈，最终达到外包一级响应等级——参见图5），还有度量驱动的硬件容量评估。  图5. 应用信号灯 总之，把度量加到开发过程里有很大的潜力。在整个组织内推行这种实践是很难的。但潜在的好处也很巨大：应用和业务表现对开发团队和业务人员来说是可见的，大家可以基于真实的数据更快、更准确地做决定，而且团队内和团队间的沟通也能得到提升。 |
