到这一阶段，运维不只是执行和满足需求的单位了，而是能够为业务的发展产生积极推动作用的角色了。
如果运维把自己定位成被动的满足需求的角色的话，那就是自己把自己的地位放低了；运维手上有大量的数据，只要愿意思考并利用这些数据，运维是有很多机会可以产生很多附加值的。
深入熟悉业务
架构图
函数之间的调用关系
找到核心问题
找到技术方案
业务的架构不能充分利用最新的技术能力，改造之
- 传统服务架构-云服务/微服务架构-无服务器架构演进
-核心能力：
-
- 对业务逻辑的深入理解。
- 比业务更广、更好地接触新技术，将新技术应用到业务中来。
-具体技术能力：
-
- 服务编排、服务治理（访问控制）
-工作案例：
- 扑克头像从传统架构迁移AWS
- 统一组件进程间通讯改造，支持DNS通讯，上线Docker集群运行
- 尝试引入Athena替代Hive，引入EMR替代传统Hadoop
- 引入API Gateway对外提供S3文件查询的服务
- S3上传文件引入Lambda函数，实现文件大小的监控和报警
- 日志拉去和分析使用Cloudwatch Events+Lambda+S3+Athena
- 优化BPT包下载流程及方案，从业务机器迁移到统一的CDN服务器上
- 整个BPT项目，由于运维容器（swarm/k8s）推广而彻底转换到微服务架构上来
运维有大量的一手数据，有必要提炼出来发挥作用
- 大数据分析和有价值数据提炼
- 业务趋势/异常信息，机器学习中的无监督学习模式（例如：ES通过日志分析异常数据）
- 把报警从事后提前到问题出现之前，找出隐患
-核心能力：
-
- 日常大数据的搜集整理能力。
- 高度数据分析能力和数据敏感度。
- 对业务用户特征的理解。
-工作案例：
- 德州葡语CDN日志分析，推动业务从欧洲迁移至美国，优化南美覆盖
- 服务器低负载报警，推动数十个老业务下线
- 服务器负载/网络异常突增报警，协助发现德州低效率代码
- redis/MySQL连接数异常报警，协助发现Lua网络代码bug
- 通过磁盘IO利用率的异常上升，简介发现低效率find命令。