大家“尽量”将重复性的，由“运营环境”触发的工作，例如缩容、扩容、开区、合服、告警处理、故障处理等做成全自动化的无人值守，业务架构或者业务需求有变化的时候才去调整解决方案，这算是解放了应用运维自己，至少晚上可以好好睡觉。
因为这类运维基础服务，应用运维必须做好，至于付出的成本和代价，产品策划和开发团队其实并不在意。或许只有运维经理或运维总监在意，不但在意团队做这类工作的质量成本和效率，还在意做的方式，至少在一个组织架构下，必须是相对标准化的，绝不能是一个人搞一套，走一个员工就要对单个业务的单个场景工具做交接或者推倒重来。至少在蓝鲸体系下，这类工具用的都是相同的原子组件，相同的集成方式。
阶段2：辅助产品运营自动化 将“人”（产品、策划、开发等）触发的工作例如发布、变更、配置调整、日志或数据提取等工作封装成蓝鲸集成平台上的自助APP工具，由产品自己操作或者转给外包操作。
这样既进一步解放了应用运维自己，也让相关岗位的同事不用再看运维脸色，等运维排期，自己就能随时做“产品运营”。
如果做到这一步，应用运维就算是切入业务运营核心流程了，因为越是竞争激烈的重点产品，在“运营”过程中越需要频繁的做重复性的不涉及业务架构的功能或配置调整，例如改数值、改图片、上传加载新脚本等等，其实就是业务的“后台管理端”。不同业务的管理端，功能大多各不相同，在过去往往是业务开发兼做管理端，自己找服务器、搭环境、写代码、部署、最可怕的是产品用的不习惯，整天改改改……这对业务开发来说简直是噩梦，因为他们的本职工作（业务功能开发）不会因为一个管理端而减少，而且业务开发团队的人手永远是不够的，所以大多数业务开发团队都会让新手做这类“永远做不完”的工作。
现在运维能干这类工作，而且不用考虑工具自身的高可用和运维（PaaS是免运维的），用业务开发的话讲，“现在的运维真是帮上大忙了”。
在我们内部的某些产品团队，每当设计一个新产品，业务开发和应用运维团队会各自收到来自产品策划人员发来的需求设计，运维的那一份是《运营工具交互设计文档》。
而在我们内部，个别团队的业务开发在应用运维忙不过来的时候偶尔会自己跑到“蓝鲸集成平台”开发“后台管理端”，然后再和应用运维商量后续修改维护谁来做，很有联合team的感觉。
达到这个阶段，应用运维实际上已经在支持“产品自动化运营”了。
阶段3：数据化运维 接下来，当蓝鲸团队将大数据实时汇集计算的能力作为原子服务并入蓝鲸体系的时候，应用运维的职能翻开了新的一页，也就是第三个阶段。
在传统模式下，应用运维如果想做运营环境大数据分析，需要自己写脚本采集日志或OS指标，传输，入库，交叉查询计算，再搞几个页面展示出来，虽说有开源的东西能做一部分，但一来承载有限，二来易用性不够，最关键的，实时性、稳定性、完整性等都有欠缺。
而让业务开发团队做这个，也真是为难了，比做“管理端”更为难：
因为相对于单个项目开发团队来说，实现实时计算所投入的成本相对太高了。所以很多公司选择在支撑团队内，为所有的业务部门专门组建“商业智能组”或者“数据挖掘组”之类的公共服务团队。
但这类团队大都在忙于做“经营类数据分析”，而且人手永远“不够用”，很少有舍得用他们给运维做运营环境数据分析的，应用运维们可能更多的在底下做这些数据平台的“运维”工作，而不是在使用大数据平台。
蓝鲸数据平台是参照运维的技能树量身设计的，运维做运营环境大数据分析，只需要做三件事：
2. 用yaml描述所上报数据的计算逻辑，用于storm实时计算；
3. 在蓝鲸集成平台上用APP来展示实时数据视图。