【IT168 专稿】前几天在朋友圈中看到朋友的一条微信，说的是在一家咖啡厅，听见俩姑娘讨论说，搞不懂OneAPM一个做APM的还要做啥Oracle?看到这里，我不禁呵呵。且不说OneAPM能不能做成中国的Oralce，也不说何晓阳是否被神话，但有一点可以肯定的是，APM在中国市场获得了相当高的关注度。
其实APM在全球IT领域发展已超过10年，之前一直处于一个滞怠期，但去年12月New Relic在纳斯达克上市，市场估值接近20亿美元，在中国撕开了一个新的风口，这就是企业级软件的VC投资热潮。今年5月OneAPM宣布获1.65亿元C轮融资，紧接着6月听云在新三板上市，APM在中国迎来了全面爆发。
APM在中国的爆发得益于近几年云计算、移动互联、大数据的快速发展，其中低门槛、低成本的移动互联网创业火爆的同时也带来诸多问题，如网络中断、应用卡顿、响应速度慢，服务器宕机等问题无从定位，这都直接影响到用户的体验，运维人员与开发人员压力持续增大。
▲OneAPM联合创始人、Mobile Insight产品的负责人黄东
如何保障移动互联网的用户体验?这一需求被持续放大，针对这一需求，日前OneAPM推出了一款针对移动端应用性能管理平台—Mobile Insight，据说可以帮助开发者及时发现、准确定位、快速解决移动应用的性能瓶颈，就此老鱼专访了OneAPM联合创始人、Mobile Insight产品的负责人黄东，针对Mobile Insight进行详细的解读。
以下为老鱼采访黄东实录：
老鱼：OneAPM重装发布Mobile Insight产品的背景即核心原因是什么?
黄东：Mobile Insight其实是在去年7月份，随着我们AI(Application Insight)产品一起发布，我们现在一共有四款产品， AI(Application Insight),BI(Browser Insight),MI(Mobile Insight)，SI(Servers Insight)组成一套完整的端到端解决方案。而现在之所以重装推出Mobile Insight，是因为我们认为现在的市场环境与去年相比有了很大的不同，移动应用的性能问题已经逐渐成为开发者非常刚性的需求。
今年投资者给APP的生存时间更短，去年一个APP上线之后有更多的周期去换流量，而现在时间窗口更短了，这导致众多APP厂商或开发者更加关注应用性能，可以说应用性能等同于用户体验。性能问题已经成为APP的生命线，厂商或开发者必须要迅速的解决这一问题，让资金转化成流量的效率更高，才能让自己的企业走的更快，这就是我们在现在这个时间点重推去发布Mobile Insight产品的核心原因。我们希望与现在正在成长的APP企业共同打造生态圈，从使用APP的角度，去减少性能问题导致的用户流失的困境。
老鱼：Mobile Insight能帮助用户的应用解决哪些问题?
黄东：Mobile Insight能帮助开发者及时发现、准确定位、快速解决移动应用的性能瓶颈，通过与AI产品组合使用获得端到端分析的能力，可以很容易的区分缓慢或崩溃的原因是网络问题，server问题或者是手机适配等问题。
权威数据表明如果移动端的响应时间增加1秒，就会降低7%访问量，还会导致33%用户选择竞争对手的产品。
目前最影响移动端用户体验的问题，主要包括3类：HTTP 请求缓慢，HTTP 错误或网络错误以及Crash，前两者更是让开发者最为棘手。而通过 Mobile Insight可以轻松解决用户遇到的这些性能问题。
老鱼：请介绍下Mobile Insight帮助用户应用性能监控与诊断的技术逻辑?
黄东：Mobile Insight 由 Mi探针、 Mi管理服务器以及Mi管理控制台组成。其中，Mi 探针通过加载 SDK 的方式来监控移动应用，负责收集移动应用的性能数据，然后管理服务器接收来自智能终端设备的性能数据和相关用户数据，以单个用户为单位进行数据的匹配关联，并将其存储在性能数据库中。
最终，通过 Mi 管理控制台，实现对移动应用性能监控、故障诊断、代码级问题定位、告警、以及历史性能对比分析。 通过与OneAPM Application Insight 产品的结合，还可以实现从智能移动终端到后台应用服务的端到端监控。
老鱼：目前正在使用Mobile Insight的用户主要有那几类?
黄东：从我们的用户看，愿意使用我们产品的用户主要有2类：首先是创业公司，创业公司无论是人手还是资金都不充裕，如之前所说，投资者给APP的生存时间更短，而性能问题已经成为APP应用的生命线，因此APP厂商或者开发者必须迅速解决这一问题，创业者只需要集中精力开发功能就好，性能问题交由Mobile Insight来做。相对来说，创业公司的需求比较简单，只需要MI产品的基础功能就能解决他们的问题。
其次是中大型企业愿意使用我们的MI产品，相比创业公司来说，中大型企业的需求更为复杂，过去中大型企业是没有移动端的，以中国移动举例来说，整个业务系统从前端到后端有7层，从APP到应用服务器到数据库，要解决应用性能问题，实现完整的端到端，实现难度与创业企业来说完全不一样，虽然中大型企业有技术实力去解决这些问题，但因为投入产出比等方面的原因，用我们的产品性价比更高，如阿里巴巴虽然也有做这方面的工作，但阿里巴巴有些团队也在用我们的产品，因为OneAPM的产品更加简单，易用。目前互联网O2O，金融，教育等垂直领域TOP 20的企业中有很多都在用我们的产品。
老鱼：作为Mobile Insight产品负责人，能否告诉我们Mobile Insight的目标是什么?
黄东：我们的目标是把Mobile Insight做成移动端监控分析类产品中最易用的产品
老鱼：您说的最易用的产品特征是什么?什么才叫做最易用?
黄东：Mobile Insight此次重装发布比之前多了一个新的功能，组合分析与自定义Dashboard，用户通过这2个模块，可以实现将网络请求，流量，崩溃这样的信息与运营商，接入方式,手机型号等任意角度的信息放到一起分析展示，用户完全可以按照自己的使用逻辑来使用MI产品。实质上现在市面上的移动监控类产品离用户期待的功能，还差的很远。OneAPM是目前唯一能做到这种程度的厂商，这也是我们非常大的优势。
老鱼：我看到大部分的移动监控都是需要在用户应用中植入SDK，抓取数据，这是否会对用户应用增加负重?导致应用加载更慢?产生更高的流量消耗?
黄东：其实用户是有这样的担心的，我们经常被用户问到这样的问题
关于流量，应用我们的MI产品后，我们的组合分析能直观的告诉用户，用OneAPM后的流量消耗，这是我们很容易的告诉用户的一个事实。我们只在APP运行时每分钟发送一段很少的数据，大概只有几K甚至几个字节，这个数据量是非常少的，对于用户而言是完全无感知的。如果用户还有流量方面的顾虑，我们也给用户提供了2种选择;一、用户可以在后台自主选择在WiFi网络状态下传数据，3G时候不传数据;二、用户可以在后台调整APP传输数据的间隔时长。
关于负载，我们认为厂商并不关心SDK对CPU和内存的负载有多高，为什么不关心?上线之前，厂商对APP会有严格的测试，在测试的环境中，有没有负载测的很清楚。大家会更加关注植入SDK对现有APP会不会产生Crash，产生卡顿。在这个层面OneAPM做了很多的努力。这里透漏个数据，我们的一次上线测试通过率超过99%，出现个别影响使用的问题，OneAPM也会在7x24小时响应解决。用户可以放心大胆的测试和使用。
老鱼：用户选择移动监控类产品时最关注的问题是什么?
黄东：最关注的是功能，功能能否满足用户需求，能否真正解决用户问题。其次是售后服务，反馈的问题能否得到及时解决，正如上面提到的，我们承诺用户提出的P1问题，也就是影响用户基本功能使用的问题，我们严格按照SLA标准都是7x24小时响应，一般一周之内都可以解决。
老鱼：用户会关注价格吗?
黄东：用户会非常关注价格，众所周知，友盟等诸如此类的第三方移动统计分析工具是免费的，通过流量换广告方式运作，我们的用户不止一次问过这样的问题，但你会发现在APM领域都是收费的。我们现在的标准价格，如果你是1万的月活，一个月只用299元，这个价格于创业公司而言并不是太大的负担。当然APP的流量增长有时候是呈指数级增长的，也许你这个月1万月活，下个月就变成10万了，针对这种情况我们也有流量包的优惠方案，详情可以咨询我们，总之我们是希望能找到一些跟OneAPM共同成长的企业。
老鱼：最近听云在新三板上市，您怎么看待这个事情?
黄东：听云上市，对我们来说也是一件值得高兴的事情，这说明APM领域逐渐被资本所认可，这是对所有APM厂商都有利的事情。APM领域的竞争更像是一个长跑，成败的关键取决于产品能不能真正解决用户需求。大家其实都不是很缺钱，包括何晓阳和我在之前传递的一个最核心的观点， TO B 和TO C最大的区别在于，TO C的生意很容易满足用户需求需要做大做好，而TO B生意的核心是在于你的产品是不是真正满足用户需求。谁的产品好，谁才能成为真正的玩家。Oneapm的产品已经被中国的一线企业打磨多年，这方面我们还是比较有自信。
老鱼： Mobile Insight下一步有什么计划?
黄东：下一步我们计划将Mobile Insight与Server Insight做深度的打通，完成从业务角度的端到端链条。打通后用户很容易在Mobile Insight产品与Server Insight产品之间来回切换。目前还没办法从业务的角度将Mobile Insight的产品与Server Insight打通,比如说登陆业务，将登陆业务跟后台的多个复杂请求串成一个完整的业务进行展示报警,现在我们这个事情还没做,现在只能做到从请求端的角度将APP与server连接，请求是一个技术的角度，并不等于一个业务。
