第一天：選擇運維
運維值不值得幹
對於沒進入和剛進入IT行業的新同學來說，如果你在思考這個問題，說明你出身平凡，上流社會是不需要考慮這種問題的。當然，如果你考慮了，說明你還是屌絲中的進步青年。在過來人看來，這個就跟上大學一樣，專業不是很重要，大學很重要。所以，選對行業和公司對以後還是很有幫助的，對於運維來說，目前互聯網行業機器比較多，發展也比較好，我認爲進入這個行業是不錯的選擇。選擇完了，我們來看下運維職業發展的問題。
運維職業規劃
說實話，我不太喜歡搞職業規劃，扯淡居多，當然你可以不信，但確實有位大師也是這麼說的，對於我這種只觀大略的來說，大師的名字就別指望我記得了。在我看來，搞職業規劃不如多去了解自己的興趣！如果你對技術有興趣，也選擇了運維這個職業，我們再來看看運維怎麼發展。
其實沒太多說的，技術類的職業發展大同小異，基本會有管理線和專家線兩條路，看自己興趣了。所謂管理，就是leader，總監，VP，所謂專家，就是…,統稱大牛，領導得給你面子，但活還得幹。
運維的缺點
到目前爲止，恭喜你已經成功成爲運維攻城獅的一員了，我說下運維工作的缺點吧，這裏妹子稀少，成天對着電腦，還尼瑪只有文字的屏幕，有點逼格的可以搞黑底綠子，也就這樣了。不要抱怨，要知道，你旁邊的碼畜也好不到哪去。沒事去產品那逛逛，也許會有好看點的妹紙或者散發着雌激素的基友。當然，會找女朋友的一定不在這裏找，得去女人堆找，質量高，選擇面廣，至於哪裏是女人堆，請私信我。
第二天：開始運維
看來你已經接受運維的缺點了，讓我們開始工作。
鳥瞰運維
古語有云：不謀全局者，不足謀一域。要想做好運維工作，瞭解下運維的全貌也是有必要的。讓我們圍繞一項業務的生命週期來了解運維工作的大概內容。
假設一個網站做完了，需要給用戶使用，怎麼辦呢，我們需要上線，首先需要服務器，服務器放在哪？機架，機架放在哪？機房。服務器要對外服務，還需要網絡，服務器上要運行我們的網站程序，需要操作系統，程序還需要保存數據到數據庫，需要對外服務的web服務器，這樣用戶就可以訪問網站了。在這之後，網站運營期這些軟硬件都隨時可能出問題，所以要進行監控，告警。網站也可能還有******，還需要考慮安全。業務發展過程中需要變更，網站下線後資源需要回收，這大概算是一個運維工作的最小原型了，實際情況也遠比這個複雜，在一家大型的互聯網公司，這些環節都是需要分工合作完成的，讓我們看看一個大型互聯網公司的運維部門基本組成。
先讓我們記住一些關鍵詞：上線，運營期，下線
服務器 機架 機房 網絡 操作系統 數據庫 web服務器 監控 告警 安全 變更 資源回收
上圖只是標出了運維人員的組成，在實際的組織架構中，往往還包括產品，研發，質量，項目管理，大數據部門，因爲大數據往往也屬於基礎設施，他們與運維共同組成更大的部門。
雲計算與運維
從上面的圖我們基本可以看出，運維工作需要的知識面非常廣，小公司不可能招聘這麼多的人來進行基礎設施建設，但他們又需要這些產品和技術，於是就有廠商專門提供這種服務，成立了雲計算公司，當然雲計算的形式不只是圖上的這些，但目前最激烈的戰場就在基礎設施這裏，國外知名的像亞馬遜，國內的有騰訊雲，阿里雲等等，他們的業務規模天然適合做基礎設施雲計算。所以運維要是能去雲計算部門，算是去對了地方。
業務運維是個神馬角色
業務運維也是運維，但爲什麼要單獨來提，主要是因爲我原來就是幹這個的，另外，業務運維人員較多，與其他運維的工作也有不同之處。首先我們看看業務運維在工作中的定位。
業務運維往往和項目組組成一個虛擬的組，所以需要了解業務，同時又需要和基礎設施部門對接，相當於業務和基礎設施之間的紐帶，也就是說，業務運維不僅需要了解大量的基礎設施技術，還需要與人溝通的能力，是一個需要綜合能力的工作。
業務運維的工作內容
上面對運維的介紹相對籠統，還是不容易理解，運維到底乾的都是哪些事。我們還是圍繞一個項目來介紹。
一． 開發階段運維宣導
做過軟件開發的都知道，以前應用都基於操作系統，但互聯網應用則是基於雲，也就是圖中提到的基礎設施，由於專業分工的關係，開發人員對這些基礎設施並不一定全部瞭解，基礎設施有什麼好處，有什麼限制，使用上有什麼規範，所以需要培訓，可以起個好聽的名字，運營規範宣導。項目開發階段運維也需要介入，跟蹤項目進展，最好是能對項目的物理架構提供一些建議，很多問題越早發現越好，互聯網公司雖然大牛衆多，但也不是每個項目組都有大牛把控，如果不加限制，後期維護將非常困難，對產品，對運維都沒什麼好處。（有的部門在產品開發階段會有委員會進行評審，委員會成員既有研發也有運維）
二． 項目接入前檢查
在項目開發快完成的時候，運維需要及時介入對項目進行可運維性評審，比如瞭解項目的物理架構，配置文件管理，部署，變更複雜度，可用性，容量，容錯處理，可監控性等等，儘量排除一些問題。
另外還需要根據項目的發展規劃，重要級別等，申請相應的基礎設施資源，在申請階段還需要考慮物理部署的問題，這個階段如果做的好，會給後期的運維帶來很大的方便。驗收完成後運維也需要根據項目情況提供相應的SLA。
我曾在一線互聯網公司的多個部門呆過，發現即使在這麼大規模的公司，發展也極不平衡，有的部門在產品上線前期就做了大量的工作，而很多部門的運維只是被動的上線，什麼再難也要頂上，人肉戰術，疲於奔命。我想這應該是管理上權利與責任不對應的問題，在互聯網的世界裏，線上的產品就是公司的生命線，運維對線上負責，也應該有相應的權利，這樣才能更好的保證線上業務的穩定。
很早以前運維過一個項目，半路接手的，數據庫IP地址分散在幾十個文件中，有配置文件，腳本，代碼，而具體修改點竟有上百處，這還是我自己調查的，其他地方有沒有開發都記不清，大家可以想象項目亂到什麼程度了，我也終於理解前面的哥們爲什麼不幹了，也感慨如此規模的公司竟然也有這樣的項目。所以這就是前期控制的重要性，我想我遇到的問題在許多公司仍然存在，不少兄弟應該有同感吧。
三． 項目接入
如果前期工作都做的很好的話，這個階段的工作不難，自動化強的很輕鬆，自動化弱的無非耗點體力，總之難度不大，這裏不多說。
四． 運營階段
項目上線後，隨着業務的發展，可能需要擴容，上新版本，也可能會遇到各種問題，這個階段都是常規打法，記住變更需要慢慢來，一般稱爲灰度發佈，這個做法其實很容易理解，比如我國要改革開放，改革開放到底行不行，不是誰說了算，先拿深圳搞個試點，行了再逐步開放其他城市，這麼做無非就是避免大規模失敗。
如果遇到故障，不僅需要排查，還需要記錄，一般稱爲事故管理。
如果遇到奇怪的問題不能解決，也需要記錄，一般稱爲問題管理。
如果需要變更線上環境，也需要記錄，一般稱爲事件管理。
五． 業務下線
不多說，過程是愉快的。
六． 總結：
在我看來，如果把運維工作按照項目上線分成三個階段的話(上線前，上線，上線後)，那麼上線前是最重要的階段，正對應了那句話，好的開始是成功的一半。
這裏給出一張運維工作和ITIL的對應圖，完整的ITIL比這個要複雜，實際的運維工作也比這個要複雜，但這張圖也基本涵蓋了運維工作的核心內容。
第三天:運維的技能
運維是門手藝活，怎麼掌握這門手藝，我這裏列出一些書籍和開源軟件，希望能給大家提供一些參考和學習方向。
書：
大學計算機系科目
鳥哥的私房菜
linux fromscratch
RHCE RHCA書籍
深入理解linux內核
Linux內核設計與實現
Linuxprogramming interface
Tcpip詳解
高性能mysql
MySQL內核:InnoDB存儲引擎
構建高性能web站點
軟件構件與中間件技術
大話存儲
正則表達式
一些開源工具
Cobbler 系統安裝
Ansible，puppet，fabric，saltstack 配置管理，批量操作
Zabbix，cacti，nagios 監控告警
kvm，xen，docker，coreos 虛擬化
nginx resin php memcache redis lvs 常用軟件
top sar iostat vmstatiotop strace perf tcpdump dstat tcpflow tcprstat tsar nmon 性能監控