就目前市面上來說，只會單純的Linux傳統(tǒng)運維可能薪資相對較低，有很多人在唱衰運維這個崗位，但是事實并非如此。

目前市面上運維工程師大致可以分為兩個群體：傳統(tǒng)運維、互聯(lián)網(wǎng)運維，具體的工作職能可以看下圖。

簡單的將目前運維發(fā)展歷史分為3個階段：

1.石器時代2013/05-2014/02

規(guī)模：

• 服務(wù)器：100臺
• 流量：PV小于3000萬
• 團隊：<50研發(fā)，2個運維

問題：

• 安全問題
• 機房資源不足
• 監(jiān)控：性能 | 維護成本
• 部署：手工操作，依賴于人
• DB壓力
• 流突徒增

2.青銅時代2014/03-2015/04

規(guī)模?：

• 服務(wù)器∶>2000臺
• 流量∶ PV大于5億。
• 業(yè)務(wù)∶出租車、專車
• 團隊∶>300個研發(fā)，8個運維

問題?：

（1）監(jiān)控的問題

• 性能
• 維護成本
• 有效性

（2）部署的問題：

• 增量
• 業(yè)務(wù)個性需求。
• 迭代過快的變更沖突·
• 非靜態(tài)文件·
• 數(shù)據(jù)的問題

（3）業(yè)務(wù)同質(zhì)化嚴(yán)重、迭代需求多

（4）業(yè)務(wù)擴容效率低

（5） 配置管理，關(guān)聯(lián)關(guān)系

3.黑鐵時代?2015/05?

規(guī)模：

• 服務(wù)器∶ >1w臺
• 流量∶ PV大于50億
• 業(yè)務(wù)∶10多個業(yè)務(wù)
• 團隊∶ >1000個研發(fā)，25個運維

問題：

（1）過多的業(yè)務(wù)需求導(dǎo)致運維人力無法及時有效響應(yīng)

（2）監(jiān)控：有效性、覆蓋率、監(jiān)控指標(biāo)量化

（3）部署：

• 多集群部署需求
• 部署接入耗時過長
• 擴容效率

（4）預(yù)案管理

（5）成本問題

傳統(tǒng)運維弊端：

傳統(tǒng)運維架構(gòu)弊端： 生產(chǎn)環(huán)境的CPU或者資源利用率 18%

1、架構(gòu)層次過多，排查問題較為困難 1.2-1.5倍 *2

2、擴展性弱，無法快速做到彈性收縮

3、資源浪費嚴(yán)重，為了高可用，許冗余大量服務(wù) KVM

4、架構(gòu)重構(gòu)性差，一旦成型，很難做調(diào)整

5、發(fā)布流程繁瑣，很容易引起用戶體驗問題

6、運維經(jīng)常救火，搞不好就要背鍋 2-3點

7、監(jiān)控做的粗糙，一深入業(yè)務(wù)就不好定位

就目前來說，傳統(tǒng)運維沖擊年薪30W+的轉(zhuǎn)型方向就是SRE&DevOps崗位。

大型互聯(lián)網(wǎng)SRE&DevOps運維核心在于：（也可以看作是一份學(xué)習(xí)路線圖）

可觀測性系統(tǒng):

指標(biāo)監(jiān)控：即各種指標(biāo)監(jiān)控，比如基礎(chǔ)資源指標(biāo)，服務(wù)性能指標(biāo)，業(yè)務(wù)的調(diào)用指標(biāo)。

日志：各種設(shè)備以及服務(wù)的運行日志監(jiān)控。 ELK

調(diào)用鏈：業(yè)務(wù)層面的調(diào)用鏈分析，通常在分布式系統(tǒng)中幫助運營、開發(fā)以及運維人員快速識

別整體調(diào)用的瓶頸點

故障響應(yīng)：及時性、準(zhǔn)確性、自愈性 AIOPS 500-800條

CI/CD可集成和部署發(fā)布：

容量規(guī)劃與彈性收縮：

1、當(dāng)前的容量是多少

2、何時達到容量極限

3、應(yīng)該如何更改容量

4、執(zhí)行容量規(guī)劃

運維自動與平臺化：

容器編排與微服務(wù)、服務(wù)網(wǎng)格

分享一下大型互聯(lián)網(wǎng)公司運維核心架構(gòu)圖：

此外，微服務(wù)容器云方面技術(shù)也是當(dāng)下運維工作需要掌握的

年薪50W+高端技術(shù)崗位必備核心技能：完整的路線圖可以戳下方窗口獲取