比如，通过各地的服务器日志实时分析用户的登录、注册、消费、等各种指标，找出区域性的用户使用问题。
再比如，上了一个新功能，可以通过和研发约定的日志分析用户的使用情况和各种用户行为，或者为了某个营销活动或者新版本，临时的专项设置一些精细化监控，或者为了定位某个问题。
应用运维一般来说都是对口服务某个业务的，对自己的业务形态以及从用户的角度如何使用都很熟悉，这就决定了：运维是可以理解产品运营策略的，也有能力推测出哪些数据经过怎样的处理，是有辅助运营价值的。
蓝鲸数据平台的出现，降低了运维使用大数据的门槛，直接推动了“运维增值服务”的拓展。
在我们应用运维团队内部，催生了很多由应用运维团队主导的，基于大数据的运维服务化项目，比如探索中的“云梯项目”。也就是说在这个阶段，“数据化运维”、“大数据运维”等说法，在蓝鲸体系中不是说着玩的，而是很普通的日常工作。
从应用运维“岗位价值”的角度来说（我们认为一个岗位的价值可以从被其他岗位替代成本来衡量），当蓝鲸体系将应用运维武装到第三个阶段，就算是逆天了。
如果说第一个阶段的运维工作，开发等团队可以通过IaaS的高弹性（现在还不大靠谱）及业务架构的高可用（假设他们做得到）轻松替代的话，那在第二个阶段就要付出一些成本了，毕竟是硬性增加了开发团队的建设及维护工作量。
而在第三个阶段，对业务开发来说就太为难了，也就是说应用运维们借助蓝鲸数据平台可以大量进行业务开发团队从成本上难以承受的工作——运营环境大数据分析，来进行产品运营的决策辅助。
所以，业界当前在担忧的运维危机，我们在几年前也担心过，而现在无所谓了。
“数据运维”在我们内部还属于优化推进阶段，蓝鲸数据平台也在逐步成熟中，我们希望协助产品策划人员，在红海竞争中通过我们对精细化运营的一些努力，为业务提升一点点竞争力。
我们希望为产品策划人员提供尽可能全面的辅助运营服务，或许当他们某一天离开腾讯后，会感觉各种不适应。
记得我们在杭州办蓝鲸沙龙那次，中间茶歇的时候，有个哥们跟我们说了一句话“我现在感觉腾讯游戏成功的背后有很多我们不知道的因素”。
虽然我们很清楚，在腾讯游戏发展的过程中我们所起到的必然不是决定性因素，可能只是其中很小很小的一部分，但他的这句话里所流露出来的那一点点意思，依然给了我们很大的鼓励。在腾讯的很多部门，即便是边角的支撑团队，也在为其所支撑的产品线的市场竞争力和口碑而倾尽全力。
3. 蓝鲸服务
蓝鲸的服务可以分成两类：PaaS和SaaS。
上边提到的所有服务，都是PaaS：
1. 比如蓝鲸集成平台，不管门槛多低，应用运维都需要自己去开发工具APP；
2. 比如蓝鲸作业平台，应用运维需要自己上去写脚本；
3. 再比如蓝鲸数据平台，运维需要自己用脚本写采集逻辑、用yaml写计算逻辑，如果需要结果的实时展示，还得在蓝鲸集成平台做展示APP。
对应用运维来说，PaaS服务是万能的，几乎没有场景限制，只要是原子能覆盖的流程，都能做得出来，非常灵活，还能最大化发挥应用运维的技能，体现其价值：
1. 比如可以针对某一种发布做个蓝鲸APP
2. 可以针对某个告警的处理逻辑做个“故障自动恢复”工具APP
3. 针对某个场景，开发一个实时刷新的数据视图APP…
蓝鲸大力发展PaaS服务，也印证了我们的理念：即依靠运维，武装运维，使其能提供更高维度的服务，而不是取代运维，同时迎合了 运营、开发、测试等岗位人员的需求。
用PaaS构建的服务工具，适配场景几乎无限制，高度的定制化使得体验最好，但有“重复建设”以及对于基础运维服务“难以统一化管理”的问题。
因此在很多高频场景，蓝鲸也联合应用运维团队，提供了不少SaaS。
比如针对发布变更场景，结合蓝鲸集成平台上大量的发布变更类工具，蓝鲸推出了“标准运维”APP，使得已经慢慢变成大多数应用运维负担的大量的花样繁多的“操作类APP”得以下架。
这样使得我们逐步的在应用层构建起了标准化场景组件，再允许大家从其他的APP调用“标准运维”接口，也就是说，进行更高层面的“场景调度”。
或者直接使用“标准运维”提供的APP Maker功能针对某一操作流程，拖拽生成类似于快捷方式的“轻应用”，以实现轻量操作类APP的免开发拖拽生成。
这样，也使得蓝鲸生态在运维基础服务层面对业务来说更加安全可靠，面对运维人员的流动，抗风险能力更强。