运维工程师有前途么？
就目前市面上来说，只会单纯的Linux传统运维可能薪资相对较低，有很多人在唱衰运维这个岗位，但是事实并非如此。
目前市面上运维工程师大致可以分为两个群体：传统运维、互联网运维，具体的工作职能可以看下图。
简单的将目前运维发展历史分为3个阶段：
1. 石器时代2013/05-2014/02
规模：
- 服务器：100台
- 流量：PV小于3000万
- 团队：<50研发，2个运维
问题：
- 安全问题
- 机房资源不足
- 监控：性能 | 维护成本
- 部署：手工操作，依赖于人
- DB压力
- 流突徒增
2.青铜时代2014/03-2015/04
规模 ：
- 服务器∶>2000台
- 流量∶ PV大于5亿。
- 业务∶出租车、专车
- 团队∶>300个研发，8个运维
问题 ：
（1）监控的问题
- 性能
- 维护成本
- 有效性
（2）部署的问题：
- 增量
- 业务个性需求。
- 迭代过快的变更冲突·
- 非静态文件·
- 数据的问题
（3）业务 同质化严重、迭代需求多
（4）业务扩容效率低
（5） 配置管理，关联关系
3. 黑铁时代 2015/05
规模：
- 服务器∶ >1w台
- 流量∶ PV大于50亿
- 业务∶10多个业务
- 团队∶ >1000个研发，25个运维
问题：
（1）过多的业务需求导致运维人力无法及时有效响应
（2）监控：有效性、覆盖率、监控指标量化
（3）部署：
- 多集群部署需求
- 部署接入耗时过长
- 扩容效率
（4）预案管理
（5）成本问题
传统运维弊端：
传统运维架构弊端： 生产环境的CPU或者资源利用率 18%
1、架构层次过多，排查问题较为困难 1.2-1.5倍 *2
2、 扩展性弱，无法快速做到弹性收缩
3、资源浪费严重，为了高可用，许冗余大量服务 KVM
4、架构重构性差，一旦成型，很难做调整
5、发布流程繁琐，很容易引起用户体验问题
6、运维经常救火，搞不好就要背锅 2-3点
7、监控做的粗糙，一深入业务就不好定位
就目前来说，传统运维冲击年薪30W+的转型方向就是SRE&DevOps岗位。
大型互联网SRE&DevOps运维核心在于：（也可以看作是一份学习路线图）
可观测性系统:
指标监控：即各种指标监控，比如基础资源指标，服务性能指标，业务的调用指标。
日志：各种设备以及服务的运行日志监控。 ELK
调用链：业务层面的 调用链分析，通常在分布式系统中帮助运营、开发以及运维人员快速识
别整体调用的瓶颈点
故障响应：及时性、准确性、自愈性 AIOPS 500-800条
CI/CD可集成和部署发布：
容量规划与弹性收缩：
1、当前的 容量是多少
2、何时达到容量极限
3、应该如何更改容量
4、执行容量规划
运维自动与平台化：
容器编排与微服务、服务网格
分享一下大型互联网公司运维核心架构图：
此外，微服务容器云方面技术也是当下运维工作需要掌握的
年薪50W+高端技术岗位必备核心技能：完整的路线图可以戳下方窗口获取
