———————————————上篇————————————————
前言
現在最前面，這篇文章一共分爲兩部分，第一部分主要是介紹運維工程師到底是個神馬鬼工程師，他真的是每天跑機房，每天裝機的麼？第二部分是圍繞運維工程師介紹技術棧以及運維體系架構。
運維工程師，在英文裏面名爲 “Operations Engineer”，看字面意思，貌似的確就是操作服務器、管理系統的工程師。我們可以根據公司大小的不同，把它分爲兩個大類：Ops 和 DevOps。Ops 即運維，DevOps 即開發運維。讓我們舉個例子來說明一下。
Ops
小明，當年從學校畢業，熟讀《鳥哥私房菜》N 遍，掌握了一手 Linux 操作命令。覺得自己已經碉堡了。遂進入一家創業公司，開始了第一份工作。
公司這個時候需要搭建一個網站，但是沒有機房沒有服務器。小明說：我來定服務器型號和裝系統吧！遂刷刷刷選定了一款 Dell 的服務器，插上了 N 條內存和幾塊硬盤，裝上了系統。剩下的譬如機房網絡等就交給了網絡工程師負責了。
Ops 必備技能入門款： 1、瞭解服務器基本型號。 2、熟練掌握使用系統安裝。
好，服務器裝好了，系統跑起來了。公司現在有 3 名開發工程師，小明分別爲這 3 名工程師添加好了用戶，並配置好了 SSH 讓他們可以遠程登錄服務器。同時配置了一下 Nginx，讓大家可以直接訪問 WEB 界面來調試代碼。
Ops 必備技能基本款： 3、熟練掌握服務器配置、添加用戶等基本操作。 4、瞭解 Nginx、SSH 等常用服務。
隨着公司的開發人員越來越多，以及服務器越來越多。小明覺得自己已經力不從心了，每天都在幫人給每臺服務器添加賬戶，添加管理配置，跑機房重裝系統。他覺得自己不能這樣，這樣效率實在太低了，而且現在他管理的機器已經亂成一鍋粥了，每臺機器的配置、分區、包全部都不一樣，導致開發那邊經常會說：
小明！爲啥這臺機器的根分區只有 10G，我其他的機器都是 50G 的！
小明！我這臺2臺機器怎麼連 apt-get 的源都不一樣，裝的包的版本都不同！
小明！我這兩臺機器怎麼一臺 128G 內存，另一臺只有 16G， 跑毛啊。
所以小明決定整頓一下把他們全部規整起來，制定了服務器的標準。同時在網上尋找了一些開源軟件，以實現服務器的批量管理。
Ops 必備技能進階款： 5、熟練使用 Cobbler 等工具實現自動網絡安裝。 6、熟練使用 Puppet、Saltstack、Ansible 等批量管理工具統一服務器基本配置。 7、定製服務器的規格以及系統標準（系統版本、分區、預裝軟件等）。
從此以後，小明再也不用跑機房裝機了！（所以運維工程師不是每天都跑機房的！）
同樣，隨着公司的發展，網站訪問量的增多。系統相關的問題以及需求也越來越多。網站經常會出現各種奇奇怪怪的問題，譬如 Nginx 服務器請求量特別高的時候發生丟包情況、內網機器時不時會丟包連不上、服務器 closewait、timewait變得特別多、虛擬機的 ksoftirqd 進程 CPU 佔用特別高等問題。小明開始驚慌失措，完全不知道怎麼解決。這個時候公司來了一位高級運維工程師，帶着小明解決了各類離奇問題。
Ops 必備高級款： 8、熟練掌握系統 sysctl 中常用參數的定義以及影響。 9、熟練掌握 iptables 的配置。 10、熟練掌握 /proc 以及 /sys 目錄下各個目錄以及文件的含義。 11、通過經驗的積累，逐步培養出遇到 bug 快速定位問題的能力。
到此爲止，Ops 相關的工作基本完成。
DevOps
隨着運維工具化的逐步完善，現在小明幫助開發完成操作的時間已經可以用秒來衡量了。可是小明遇到一個棘手的問題：他需要每天 24 小時待命去解決開發扔給他的問題。小明現在是看場電影也擔心有人找他。
這個時候，他覺得需要有一個運維平臺，代替他完成這些重複性的工作。
小明初步規劃了一下，大概總結出了以下幾個需求：
服務器自助申請，開發自行申請服務器，系統自動分配可用服務器。
服務器裝機的自動化，開發可以自行重裝系統。
服務器權限的自助申請，開發可以自行申請服務器的權限。
服務器基礎配置以及應用自動化，可以讓開發自行配置服務器包版本、Nginx 配置，並自行刷到服務器上。
同時還有以下需求，運維自身的需求：
服務器狀態報警，譬如網線或者硬盤壞了，服務器掛掉了。
對服務器的使用情況管理，定期發報告統計服務器的使用情況。
對服務器操作的審計。
小明把需求列出來之後，認識到自己面對了一個非常巨大的挑戰。總結就是：
DevOps 必備基本款： 1、瞭解數據庫基本操作。 2、熟悉至少一種後端語言（大部分DevOps都是用 Python）。 3、熟悉 Html、Css、Javascript 前端語言。
小明花了很長的時間，學習並大概寫了一個前端出來。大概是這樣的
他諮詢了一下開發，覺得他寫的前端怎樣。開發望了一眼，口吐白泡。
小明覺得這樣不行，遂繼續學習，他發現前端的框架都好漂亮，遂決定一試：
DevOps 必備進階款： 4、掌握 Tornado 或者 Django 等 Web 框架。 5、瞭解 API 規範（RESTful 規範）等。 6、熟練使用前端庫以及框架，譬如：jQuery、Highchart、AngularJS、ReactJS 等。 7、瞭解設計理念，尊重設計規範。譬如 Material UI，Bootstrap。
經過漫長的學習，小明終於把前端寫出來了，大概是這樣：
開發用過，都說贊。
然後，小明發現一個問題。他發現整個運維體系都特別的鬆散，沒有一個完整的規劃。基本都是開發需要什麼，他們才做什麼。所有的功能也是東一個西一個。
應該有一個非常明確的運維規劃，將所有運維相關的服務都整理彙總並串聯起來，才能做到有條不紊、環環相扣。
DevOps 必備高級款： 8、……
欲知後事如何，請聽下回分解。
———————————————下篇————————————————
關於 Windows 平臺，現在互聯網公司大部分用的還是 Linux 環境，對 Windows 環境，其實思路都是差不多的。只不過並不是特別瞭解。
然後是有人說到 “網絡工程師” 去哪了，好吧哈哈哈哈如果是小公司其實對網絡的規劃是比較弱的，當規模變大之後纔會考慮到網絡規劃、劃分 VLAN、交換機選型規劃等，本文就先不涉及啦~
同樣，對於前端，後端的所需要掌握的技術，其實並不需要特別多。舉幾個例子：
對於後端，你完全不需要考慮使用 Tornado 的異步框架來提高處理能力，你用 gunicron 跑多幾個進程就好了，雖然這樣會比較佔用系統資源，但是簡單吖，開發快啊，上手即用啊。
而對前端來說，你根本無須關心兼容 IE ，甚至你根本不用去兼容老版本的 Chrome，甚至如果你們沒有人用 Safari，你也不用去關心。因爲對於面向程序員的 Web 應用，他們基本都會使用較新的瀏覽器。兼容性不是問題，你打開自己常用的 Chrome，點一點功能，看一看樣式，沒問題就過了。
（專業前後端工程師請不要揍我，小弟知道小弟沒有寫單元測試）
梳理流程
小明經過之前的努力，雖然把各個功能都寫出來了，但是功能都特別的零散。所以他開始思考怎樣才能構建一個完備的系統。他覺得有必要過一遍服務器從採購到交付的所有步驟，這樣才能把整個系統的架構確定下來。列出來之後，小明把每一項都對應到了運維繫統當中，非常明確的目的導向型的架構。
1. 開發發現自己的服務器資源不夠了，決定需要採購服務器。
怎樣發現自己的資源不夠了？ =》資源使用量功能統計（對監控數據進行彙總分析）。
通過報警，還是報表？=》定期告知負責人的服務器的負載，如果負載超過某個閾值自動提醒。
2. 開發提出需求，需要服務器資源。並告知服務器的配置。
開發怎麼確定自己需要怎樣的服務器型號？ =》規範服務器型號，規格。
在哪裏申請？直接找你麼？ =》服務器自助申請頁面。
申請完成之後，狀態是怎樣的？ =》運維及時在系統中更新服務器申請進度。服務器可用時自動通知。
3. 將服務器配置單交給服務器供應商，供應商開始準備服務器。
怎麼提交配置單？人手工發？ =》供應商採購信息頁面，審覈通過後自動發送。
準備好之後？的信息怎麼錄入？ =》 提供給供應商接口，讓其在準備好服務器之後錄入服務器的信息。（對應機器的 mac 其實就夠了，其他信息在機器裝好之後可以直接調）
4. 服務器準備好後，快遞到機房，並上架。
郵件功能，告知新的服務器需要上架。
機房怎麼知道上到哪裏去？ =》上架功能。將機櫃位置以及 U 位、交換機口信息全部維護起來。系統會自動尋找空閒機櫃，爲新的服務器分配機櫃、U 位，並分配交換機口。
5. 安裝系統。
服務器的管理口 IP ，以及系統 IP 怎麼分配？ =》 IP 管理功能，維護所有服務器的 IP 地址。並可以通過接口調取可用 IP。
怎麼裝機？用 CD？ =》 PXE 網絡安裝系統（可以用 Cobbler, 當然如果你覺得它太龐大，可以試試 PyPXE）。
6. 服務器列表管理。
服務器太多了，我已經不知道我們有多少臺服務器了。 =》服務器信息彙總頁面，所有服務器應該都在這個頁面當中（Saltstack 的 `salt-key -L` 不錯）。
我想知道我有多少機器怎麼辦？ =》把服務器與負責人一一綁定，支持查看別人的服務器信息。
7. 系統環境。
系統裝好後，各種基礎包，個性化配置怎麼搞？ =》 Saltstack、Ansible、Puppet 等自動化工具的調用。
8. 開發權限的管理。
開發現在這麼多，服務器也這麼多，怎麼管理？ =》開發人員 SSH 的管理頁面（自動化工具都有管理 SSH key 的功能，你指需要封裝一下後端，實現下前端就好啦），自助申請服務器權限頁面。
9. 應用的個性需求。
不同的應用需要不同的基礎包或者壞境，怎麼破？ =》 封裝自動化工具的接口，讓開發可以自行管理自己服務器的模板。
運維架構
經過這樣梳理之後，小明覺得自己的運維繫統的框架大概出來了，剩下的就是一個一個去實現了。彙總一下各大類，其實一共就是 4 大塊的內容。
IDC 運維
管理機房以及網絡相關的東西，譬如機櫃、U 位的規劃，網絡、網段的規劃。上面提到的自動分配機櫃、U 位、交換機、IP 等就是在這一層完成的。
硬件運維
包括了採購服務器，上架這幾個部分。同時服務器列表，以及容量的規劃也是在這一層做的。
系統運維
包括服務器的安裝，服務器基本環境的部署。以及開發 SSH key 的統一管理。
應用運維
開發的權限管理，服務器個性化的模板管理。
其他
這裏面還有一些沒有提及到的，但是同樣非常重要的。譬如機器硬件的報警、系統使用率的報警。運維相關的報警是比較複雜的，在這裏先不詳細說了。
架構的進一步思考
小明其實知道，現在這樣一個到處都是 “云云云云” 的時代。隨便一個雲平臺，都號稱 ”1分鐘“ 爲你準備好一臺可以使用的機器。
小明看了一下自己的這個架構，仔細想了一下，我們現在申請一臺機器需要 1 周左右的時間，簡直不能忍。如果我提前買好服務器，是不是就可以解決這個問題了。
經過若干秒的思考，小明仰天一笑： ”Server as a Service"。看來可以引入服務器池了……
———————————轉自：https://zhuanlan.zhihu.com/p/20227654—————————————