1. 将基础运维服务（发布变更、监控处理、数值调整、数据提取等）尽可能做到运维无人值守，运维提供解决方案（工具）；
2. 同事负责随时调整解决方案，但不能提供重复性的操作服务，由使用者自助或者外包团队操作；
3. 运维分出一部分精力，尝试“用户体验优化”和“运营决策辅助”等运维增值服务。
2. 蓝鲸的涉及思想
和很多公司的情况不同，在腾讯游戏设计运维技术体系，有4个天然的难处。
1. 在运维眼里，这里几乎有着互联网行业中所有的业务类型：有重客户端游戏，网页游戏，各类官网，移动终端游戏，大型游戏平台（平铺式架构，拓扑关系复杂，模块数量上百，服务器数量几千）……
2. 这里几乎有着互联网行业中所有的流行技术，因为腾讯游戏300多款业务中，大多数是由世界各地开发商开发出来，由腾讯独家代理的所谓“独代游戏”。 因此，这些游戏所使用的开发语言、开发框架、操作系统、数据库等技术组合，是没有直观规律的。而且由于游戏从签订代理合同到上线运营之间的间隔时间越来越短，开发商很难为了运维体系而对架构或技术做大规模的修改。
3. 300多款游戏相互之间是没有关系的，发布变更、故障处理等运维操作场景和操作流程是没有直观规律的，即便是同一个游戏，也可能因为上了一个新版本，新增了几种后台server，或者改变了表结构，而导致运维操作流程发生改变。
4. 这些游戏的服务器数量，也就是操作单元，有十余万，而随着容器技术的普及，操作单元的数量还会暴涨。
因此，蓝鲸的设计，不能侵入业务架构，不能依赖业务架构，不能依赖业务所使用的技术，不能依赖有统一的运维操作流程。
甚至，也最好别指望开发商为你做什么改造，还得支持海量场景（最好能支持十万级操作单元并发）。
最终，我们总结出来的共同点是：
运维通过linux命令，可以搞定所有“发布变更故障处理等”运维操作流程。
虽然只有这一点，但也足够了，这至少说明，运维的基础服务，不论是发布变更还是告警处理，都是可以分步骤的，步骤可能是串行的，也可能有分支结构。
蓝鲸的设计思路是：尽可能将单个步骤抽象为原子，再将原子自动化，而后通过任务引擎连接成“串”或者“树状分支结构”实现全自动化。
这种参照SOA的设计，其最大优点在于不依赖业务类型，不依赖架构，不依赖场景，只要运维手工能做的，都可以做成无人值守。
运维需要做两件事，将原子自动化和将原子集成为工具，这两件事也正是蓝鲸体系武装运维的切入点。
1）将原子自动化：
运维通过命令可以做的步骤，在蓝鲸作业平台上封装个脚本，就变成了可集成的自动化原子，而运维通过其他运营系统页面操作的步骤，由蓝鲸集成平台中的ESB平台与其对接好接口之后，也变成了可集成的自动化原子。
2）将原子集成为工具：
运维/运营工具的开发对传统运维是有一定障碍的，蓝鲸通过几方面的工作来解决这个问题。在“蓝鲸集成平台”（蓝鲸体系目前有6个平台）中构建了一个PaaS模块，业务运维（devops）无需关注找服务器、部署环境（各种包、mysql、nginx等）等步骤，只需要写好工具本身的逻辑代码上装到PaaS容器就行了，同时还免除了工具的运维成本（高可用、故障修复等）。基于docker技术，工具的部署也是一键式的。