一个CEO的内部分享：企业级IT服务的变与应变

 移动互联网的广泛应用和云计算的高速发展，给企业的传统IT架构带来了巨大的挑战：用户体验前置、IT基础设施广泛云化，产品迭代速度越来越快，传统运维随着DevOps理念的普及正逐渐转向云运维、业务运维。

云智慧从2010年推出监控宝，至今已经形成了一套完整的企业级应用性能解决方案闭环，以解决企业用户体验前置带来的挑战，和云计算的快速发展带来的系统架构变化的挑战。云智慧这几年为什么会走出这样一条产品发展路径?其企业级应用性能解决方案是如何炼成的呢?

以下是云智慧CEO殷晋对云智慧产品发展路径的思考和分享：

大家现在都知道，云智慧围绕应用性能提供了一套完整的企业解决方案，形成了云智慧的吉祥三宝：监控宝，透视宝和压测宝，那么为什么云智慧要选择这种产品发展路径呢?云智慧产品的发展路径不是拍脑袋作出的决定，更不是复制国外APM产品得来的，其“原动力”非常简单：依据真实的客户需求，发现用户的真实问题并予以解决，这就形成了云智慧的三款产品。

监控宝是如何成为站长神器的

回溯云智慧的发展历程，为什么会在2010年上线第一款产品监控宝呢?当时的出发点其实非常简单，我们希望从运维同学最痛的点出发，来解决他们无法实时感知自己的网站在用户端是否能顺利访问的问题!

在2010年前后，中国的网络状况是非常差的，连基本的互联互通都会经常出问题，DNS更是经常造成大面积的网络瘫痪。运维最痛苦的事，就是完全没有办法知道用户是否能够访问自己的网站。所以那个时候，有些站长工具流行起来，包括现在大家还能看到的“阿里测”等。用户投诉说网站访问不了的时候，运维都会去用阿里测来Ping一下自己的服务器，看看哪些地方有问题。但是这种做法明显属于亡羊补牢，因为用户已经受到了影响，更何况大部分用户在这种情况下只会骂一句：什么破网站，然后默默的关掉浏览器!

监控宝的出发点就是想解决这么简单的一个问题。开始的产品思路也非常简单，如果把HTTP/Ping这种一次性使用的工具变成一个自动化的，周期性的监控，那么它就变成了一个服务，而按照这个思路出发，监控宝就做出来了!

监控宝问世以后，受到了广大用户的欢迎，用户数量增长很快，后面的发展基本上就是用户真实需求在驱动产品的发展了。监控宝的功能从最初的网站监控延伸到服务器监控、服务监控，再到自定义监控。做完这些功能以后，监控宝在功能上的发展出现了一段停滞期，因为从基本的运维监控需求出发，这几个功能已经覆盖了中小客户的日常运维需求，包括运维巡检的需求。

监控宝的商业化之路

云智慧花了一段时间不断优化监控的使用体验，同时开始考虑监控宝的商业化之路。因为经过一段时间的用户接触，我们发现监控宝在设计之初，对企业用户的服务理念是有重大缺陷的。

监控宝最早的用户以个人站长为主，所以那时候没有账户的概念，只有用户。但对于企业来说，企业里面有团队，有团队就会产生协作的需求，所以当时采用了一种共享用户的策略来满足这种需求。

为什么会采用共享用户的方式呢?因为那段时间恰逢微博兴起，监控宝完全按照分享的思路来设计，这非常有利于传播。利用分享的概念，以病毒式传播迅速树立起口碑，所以监控宝的早期用户增长非常快，迅速覆盖了运维圈，这是好处。

但是不利之处在于，当我们真正开始把监控宝卖给运维人员超过3个人的公司的时候，我们发现，原来的模型无法支持企业级的权限控制和协作。于是才有了监控宝在功能上几乎停滞了半年，我们花了大量的时间和精力去重构底层的账户模型，监控宝才有了企业版的概念和模型。

当监控宝真正的不断应用于大企业的时候，我们开始考虑市场和需求的变化，从2013年开始，监控宝陆续的增加了很多功能：内容监控，API监控，网页性能监控，安全监控等等。

每一次产品的迭代和发展，都是云智慧面对市场的一个选择，比如：

l 内容监控主要是想把监控宝发展到政府部门对网站监控的市场，但是后来证明我们在很小的规模的时候不具备攻克政府客户的能力，所以选择了把这个功能下架;

l API监控是因为我们看到了移动App的迅猛发展，对运维形成了新的挑战，运维需要新的工具来解决这个问题;

l 网页性能监控是因为我们想把网页性能更加详细的展示给客户;

l 安全监控是想把监控宝的价值进一步提升，为用户提供一站式的监控服务。

这就是监控宝的发展过程，我们能够发现，监控宝的定位非常明确，就是给企业的运维工程师提供一个高效易用的工具，把运维的日常巡检工作自动化，把他们从繁琐的日常监控工作中解放出来，做更有价值的事情。

因移动互联网而生的透视宝

作为企业服务型公司，产品不断的发展总要有一个路径可循的，我们遵循的路径就是IT成熟度模型。

这是当初考虑开发透视宝这个产品时的思考模型，里面有两个维度，X轴是IT成熟度，Y轴是商业价值。监控宝的定位在于一种简单的场景，解决最基本的全栈IT基础设施监控的问题，对于很多IT成熟度很高的公司来说，这种工具的价值并不明显，因为监控宝解决的问题在他们的成熟度下已经被解决的比较好了。

于是我们就开始考虑，对于IT成熟度很高的客户，他们有什么样的需求，需要什么样的产品呢?非常幸运的是，当我们思考这个问题的时候，我们正处在一个最好的时间点：

1.移动互联网飞速发展

2.云计算快速普及

在这个时候，如果我们还是考虑切入传统的ITSM，ITOA， ITOM等等领域，估计已经无路可走了。移动互联网+云计算带来了一个新的命题，叫做用户体验前置。什么是用户体验前置呢?我们看看传统的银行系统，如果你不去柜台，或者登陆他们的网银，你是不会接触到他们庞杂的IT系统的。但有了移动互联网，一切都不一样了，通过手中的App/微信公众号等，开始无缝的和他们的IT应用系统打交道，IT应用再也不是看不见摸不着的东西了。

这块是一个战略的空白区间，云计算的发展更是给企业传统IT应用架构带来了巨大的变化。用户体验前置，IT应用架构变化，但是市场上没有一个很好的工具能够帮助用户解决他们在这两块的监控难题。

在传统的IT成熟度很高的企业级客户那里，原来的IBM、HP、CA、Oracle、Compuware、Riverbed、Netscout等公司已经给他们建立了非常完善的监控系统，如果没有移动互联网和云计算的冲击带来的变化，云智慧作为一个创业公司肯定是没有什么机会的。

正是因为行业的巨大变化，作为创业公司，云智慧的机会就来了。我们发现这块市场几乎是空白的，但是客户的问题又是客观存在的，所以开始考虑做透视宝这款产品。

刚开始做透视宝的时候，我们并没有完全想清楚这个问题，所以立项的时候，是以监控宝企业版2.0开始的。但是在不断梳理用户需求的过程中，我们发现，这块需求完全不是监控宝应该覆盖的用户需求范围，所以我们决定把它作为一个独立产品来做。

那么怎么做呢?

上面那张图是我们一开始考虑的产品技术架构，下面这张图是我们梳理清楚了透视宝要满足的需求之后画出来的端到端应用监控架构图。我们认为，如果要解决用户体验前置的问题，必须从用户端着手开始监控和采集数据，同时在整个用户体验交付链条的每一个环节都要进行监控。采集所有的数据，通过对数据的分析，来发现和解决可能发生在每一个环节的影响用户体验的风险因素。

透视宝从2014年4月22日开始立项，到了8月份，我们推翻了原来的设计和架构，重新做了一版，并于2014年12月18日对外发布了第一个版本的产品。为什么会推翻重来，就是因为我们在开始没有把透视宝的真正需求梳理清楚，上面的两个图没有搞出来。当我们把透视宝的定位搞清楚之后，自然形成了一个产品的价值阶梯。

同时也梳理清楚了监控宝和透视宝这两款产品的边界：

现在的透视宝产品发展，基本上都是延着这条路径在不断的向前发展。有了监控宝+透视宝，云智慧基本上建立起真正覆盖IT成熟度较高的企业级用户需求的产品力。我们第一次有能力来服务企业级客户，而这些产品的发展就构成了云智慧在2015年从SMB市场向企业级客户市场迈进的动力。

企业级用户的大规模压力测试需求

到了企业级用户市场，我们又发现了新的用户需求痛点，就是性能测试问题。在SMB客户那里，产品上线之前不会做大规模的性能测试，很难产生性能测试需求。而答案还是在上面的那张IT成熟度模型图里面，因为SMB客户的IT成熟度较低，同时网站/应用的商业价值也比较低，所以他们不会、也没必要投入那么多资源来做这种事情。

而在IT成熟度高的企业级客户那里，压测是产品上线前的必备流程，甚至在很多DevOps实践比较好的企业里，压测不仅用于上线前的测试，而是和他们的CI系统集成，作为每次Build都要执行的常规监测手段，从而实现Release Automation。

然而现在市面上的性能测试软件几乎在这种新的变化面前是无能为力的。用户体验前置要求性能测试基于真实的场景和真实的链路来进行，而和CI系统的集成也不是那些传统测试软件能够搞定的事情。

所以基于云智慧全球分布式部署的服务器网络、公有云资源、客户私有云资源构建的压力测试网络，根据真实用户在网站和APP上的使用场景进行测试，提供开放的API接口可以让CI系统驱动测试自动运行的压测宝就应运而生了。

有了压测宝，云智慧的应用性能解决方案形成了一个闭环，能够帮助企业解决用户体验前置带来的挑战，以及云计算的快速发展带来的系统架构变化的挑战。

Q：能说说APM技术各种可能的发展方向吗?在这些方向中，云智慧都会去哪里?

A：APM现在的基本技术有几个关键字，端到端，软件探针覆盖各种开发语言和框架。我认为未来可能会有几个演变的方向。

1， 各个基础的云平台会默认集成APM的技术来帮助云上的应用更好的运行，和云的深度结合是一个方向

2， 微应用架构带来的全新挑战

APM现在主要的价值在于复杂IT应用架构的场景下帮助用户快速的自动绘制应用拓扑和代码级问题定位，但是微应用部署本身就是对复杂的IT应用架构的解耦。所以在微应用架构不断演进的情况下，APM的后端监控技术和方案也会不断变化。

在用户入口层面(App， Browser， H5 in wechat/dingding)的监控会越来越重要。对于我们来说，怎么能够让透视宝更加开放，易于和用户的使用场景整合是一个值得深思的方向，就像监控宝，用户可以完全通过API来无感知的使用监控宝。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。