今天主要有四個課題：
先聊一聊 DevOps；
然後跟大家聊一聊運維知識的體系和職業發展；
再是中小企業基於開源的 Web 架構演變；
最後是全鏈略自動化體系；
1、DevOps雜談
DevOps 我相信大家都已經不陌生了，這類的分享很多，DevOps 的1.0版本我認為是怎麼做持續交付，上圖右側的是一個持續交付環。
DevOps2.0 就是構建IT服務供應鏈，有人問我學 DevOps 應該學什麼？按照這些來學，敏捷、精益、持續交付和IT服務管理，想做好運維工作必須精通持續交付和IT服務管理，現在想成為一個 DevOps 工程師，敏捷和精益也是必需要去學的。
DevOps 的 CALMS 文化，我個人總結了一個運維的文化，稱之為”運維的批評與自我批評”，下面這張圖是我們武警部隊的例會，一般在每週二開的“民主生活會”，以班為單位，目的就是做批評與自我批評。
主要內容是每個人都發言，指出我們班在哪些方面做的不夠好以及自身存在的問題。我認為批評與自我批評是一種非常棒的模式，值得推廣。我個人做運維經理、總監的時候，我從來不會給團隊成員說你想漲工資的話要努力工作，好好學習這些鼓勵的話，我主要的激勵方式是靠打擊。
我之前有一個理論是“鼓勵”員工跳槽。你埋怨工資低，為什麼不跳槽？。很多時候工資低不是企業的問題，是個人能力問題。
完整的文章，請訪問下面鏈接：
《我為什麼“鼓勵”員工離職？》
我相信大家對這個話題都有自己的理解，我先說一下我的理解，在說之前我先發一個警告，我這個話題比較偏激，因為我要用這種相對“偏激”的話術來影響身邊的朋友，不一定是對的，但是可以引起大家的一些思考。
這就是我的運維“能力不行”論，其實總結起來就是要先從自身找原因，能讓你快速的強大起來，所有的原因可能都是自身能力不足導致的。
舉個例子，之前我在推動自動化部署落地時遇到很大的阻力，因為涉及到開發、測試、運維，很難推動。當時第一感覺是，隊友是傻X。後來慢慢醒悟（因為我定期會做自我批評）。反思這個事情為什麼會推行不下去，原因很簡單，我的溝通能力不行！
大家認為成為一個更高級的工程師，拿更多的薪資是因為你的技術嗎？大部分都不是，你拿多少錢不在於你技術的高低，而在於你能給公司帶來多大的價值。有人覺得自己技術很牛，為什麼工資沒有那麼高。你技術確實很厲害，但是沒有給公司創造價值，這是切實的問題。這可能是你除技術外其它能力不行！
自動部署這個事情，我後來天天請做開發的哥們兒吃飯，大家覺得很奇怪，怎麼用這樣的手段？我天天找他，把關係處的很好，之後跟他說“兄弟，我現在要推自動化部署，怎麼辦？”找他協助，這也是一種能力，誰說人際交往能力不是我們工作必備的能力呢？當然其實後來我找了他四次之後這個事情才落地。
可能有人認為在第一次協商失敗之後，就認為這個哥們兒不配合，不支持自己的工作。其實不是的，因為每個人都有自己的事情，你覺得重要的事情，別人未必覺得，千萬不要先入為主！這是我的經驗。
很多時候我們總是認為別人有問題，其實真正是自己能力的問題。不管是什麼原因，要記住，溝通也是運維必備技能之一，並不是掌握各種技術，很多時候軟技能反而起很重要的作用。
我希望大家不要把運維能力侷限於技術能力，儘量的把往外延伸。技術是成長的必備條件，但不是唯一條件。
2、運維知識體系與職業發展
大家過年回家有沒有跟家人介紹自己的工作，什麼是運維？，前些年，我在家裡就遇到過這個問題，我認真的回答後，有一個做Java開發的弟弟，想了半天，說他知道，就是網管。
這說明大多數人都小看運維了，所以我根據自己的一些經歷，編寫了運維知識體系，就是要告訴他人，不要小看運維，運維掌握的知識並不比其它職位少，甚至要多很多。
整體是按照一個HTTP請求從客戶端發出到服務端所經歷的層和涉及到的技術，並沒有嚴格意義上的上下關係。
存儲層並沒有按照文件存儲、塊存儲、對象存儲這樣的方式來進行劃分，而是統稱為文件存儲和數據存儲。
基礎服務和容器層，操作系統層列舉了運維必備的基礎知識。
基礎服務層，我們在做運維的時候有很多運維工具，自動化部署系統、監控系統都是我們做運維要做的，包括系統相關的如堡壘機這些。
最後面我放了自己對運維產品化和服務化的一些理解。
運維工作內容，這裡只是做了一個典型的案例，在你們的公司可能不是這麼劃分的。不同的層面做的事是不一樣。現在做運維其實開始場景化了。例如在招聘的時候，舉個例子，我是做 CDN 的，我招人的時候肯定想招一個做 CDN 運維的。
做電商運維的，到另一家做電商的公司，發現薪資各方面都好談。但是到一家做遊戲的就不好談，之前做電商的經驗拿到遊戲當中可能就不好使，或者不能發揮最大的價值。因為不同的業務對應不同的運維場景，需要的技術可能會有一些不同的傾向性。
運維的技術層次，我做了一個發展的概述。
第一，搭建服務，這是我們運維最早做的時候，把服務搭建起來了，就會覺得很棒，很有成就感。
第二，如何才能成為一個高級工程師呢，就是用好服務，想要用好服務那就需要深入瞭解一個服務的底層知識，能夠進行對應的性能調優，才能把服務用好。
第三，讓服務戀愛，到這個級別我稱之為架構師級別，可以讓不同的服務根據不同的方式結合起來，完成對應的工作。
第四，讓服務生孩子，就是產品化，這次大會咱們外面有很多展商，很多是面向運維的，運維的很多地方如監控、日誌、作業平臺、CMDB等等都可以做成一個產品來創業。
之前有人問我運維的職業發展，未來怎麼樣發展，覺得很迷茫。
這裡我做了一個選擇題，架構師、運維總監、某個領域的技術專家，雲解決架構師、業務運維專家，培訓講師、DevOps 專家等等。可以看到未來的方向有很多，可橫向（解決方案）、可縱向（某一個領域專家）等。
就像我剛才做的一個運維知識體系是用來讓運維人員找準運維的邊界，做好運維要掌握的知識很多，但是需要給自己劃一個邊界，剛才所說的所有關健詞，只要掌握一個就可以夠研究一輩子了，每一個領域深入下去會走的很深。
3、中小企業基於開源Web的架構演變
中小企業基於開源 Web 的架構演變，這個部分儘量加速略過。因為分享時間有限，我用了很多圖來更直觀的展示：單機、機群、文件、緩存、數據、異地災備。
單機時代在Web架構上非常簡單，單機時代我們關注的是單機的性能優化，這是很多人忽略的問題。
組建分離，我們的圖片要使用獨立的頂級域名。比如說我之前是做電商的，需要寫很多cookie到用戶瀏覽器，如果都在一個頂級下，由於Cookie作用域的關係，別人訪問圖片的時候瀏覽器也會發送cookie 到圖片服務器，這完全沒有必要，可以使用獨立的頂級應用來避免Cookie提交。
單機時代主要關注的是 Web 性能，咱們做運維的，尤其是想面試高級工程師，現在到公司面試問的全都是基礎問題。原因很簡單，會基礎了，其他的不會沒關係，只要基礎紮實就可以很快掌握，但是基礎知識不會，遇到問題就很難快速定位和解決。
session 的處理方案總結起來有三種：一是會話保持，一個IP進來的可以固定訪問到集群中的某一臺後端機器上。還有就是 session 複製，基本上不建議使用，曾經6個節點的 Tomcat 集群做 Session 複製就會出現各種問題。最後 session 共享是終極解決方案。
很多人會被文檔把思想固化住，要記住別人寫的東西未必是正確的，我可以說我今天講的也未必是正確的，一定要學會分析，然後沉澱成自己的東西。就像網上有一種文檔，就是你照著做，一定不會成功。
阿里開源的 Dubbo 是一個成功的開源 SOA 框架，幫助了很多公司，不過現在我司的一些服務正在從 Dubbo 框架遷移到Spring Cloud。這裡不討論孰優孰劣，真的是看具體需求了。
架構再往下發展就涉及到分佈式部署，看看騰訊的分享，它們在這方面會做的比較好。
存儲層面：0.tmpFS，最早玩 Squid 的時候，直接是掛載一個 tmpfs 文件存儲，性能特別的快，因為 tmpfs 是佔用系統的共享內存。
1. 本地硬盤
2.DAS 存儲
3.SAN 存儲都是塊存儲類型。
在做Web架構的時候，除了塊存儲用的最多的就是文件存儲。在集群架構中，文件存儲可以使用例如 NFS 的共享存儲，還可以使用文件的分發和同步。還可以進行多級的分發。
我司是在標準化的原則上，統一用分佈式的文件系統 Glusterfs 來做，早期圖片是用的MooseFS 。還有一個系統是用 FASTDFS，對於做小視頻或聽書類的服務，每個文件大概是5M-20M左右，用 FASTDFS 特別合適。
講完集群和存儲，就到了Web架構中的緩存，我編寫了一個《Web 緩存知識體系》，因為我在學習緩存的時候發現所有人的文章都是一個點，想把整個面都串起來的文章找不到，所以就自己把緩存的體系串聯起來。我們通常所的緩存，會包括讀緩存Cache和寫緩衝Buffer。這裡只聊讀緩存 Cache。
DNS 緩存，瀏覽器的 DNS 緩存，比如說 firefox 默認緩存60秒，操作系統DNS 緩存，DNS 緩存服務器，應用程序 DNS 緩存。瀏覽器是分發在千家萬戶的緩存代理，用好會非常的方便，所以瀏覽器緩存協商的三種方式是運維必會的，基於最後修改時間、Etag和過期時間。
代理層的緩存，反向代理反存，包括Web緩存，包括 Opcache 緩存。我之前在項目做過一個實驗，我們是 PHP5.5，我開了 Opcahe 之後，我們的用戶態CPU使用率從70%下降了40%左右。
做電商的對頁面靜態化比較瞭解，一般我們會有一個CMS系統，從後端服務集群獲取到產品詳細頁、列表頁等這些需要靜態化的服務，然後將獲取到的HTML本地緩存進行對應的修改後，直接使用Nginx發佈出去。
聊完緩存在Web架構中，比較重要的就是數據庫了
拿 MySQL 的主從複製做例，目前我們用的最多的是主主複製，單寫，因為雙寫有很多雙寫的問題，所以用單寫的方式來做。
目前使用最多的方案就是 MHA 了，之前使用 MySQL MMM 問題很多。
MySQL Proxy 的方案之前試用過 MySQL Proxy 和 Atlas，這個要看具體的需求，我不直接推薦。
MySQL PXC是我推薦的一個方案，當然和 Atlas 解決的問題不同。
如果從 DAL 層的觀點出發，MyCAT 目前應用案例相對比較多一些
但是真的要把 MyCAT 玩明白需要一個團隊，中小企業成本有限，很多使用客戶端分片不僅保險，而且成本低。當然運維成本就高了。
最後推薦一下 Tidb，底層是分佈式 KV系統，在 Tidb 這層實現了 MySQL 協議，訪問它幾乎就像訪問 MySQL 一樣。
最後聊聊異地災備：
創業公司倒閉機房著火哪個機率大？很多人會回答是創業公司，但是！說一個真實的案例，天津塘沽事故的時候，我們的服務器在託管在天津塘沽機房，當時我們啟動了臨時緊急災備，把數據全部往其它機房都做了備份。
對於很多互聯網公司來說，不管公司市值多少個億，要是機房真的沒了，整個公司就沒了，一點都不誇張。所以我強烈建議，不要考慮機率，災備必須做，可以實現低等級的災備，但是有勝於無。
根據災備國家標準六個等級七個要素，我們做了一個分層、分階段的建設，先有後完善。
我們當時的原則是先有，後完善，非對稱配置。徘徊在”冷備”和”雙活”之間，例如在 Nginx 上根據 IP 地址做分流，分一些量到災備機房，保證備用機房的服務是真正可用的，然後定期做這樣的測試。基本上是用了最低的成本做好了運維最後的防線。所以不要說自己是中小企業沒錢，沒錢有沒錢的做法，但是不能不做。
4、自動化運維發展歷程
自動化運維發展歷程，做自動化運維可能需要需要經歷標準化、工具化、Web化、平臺化、服務化、智能化。所有不以解決運維痛點的自動化運維都是耍流氓，現在很多公司都在做自動化運維平臺。我這裡有一個痛點案例：
我們有一個oracle數據庫要升級打補丁，涉及到停庫，先停備庫打補丁，未來再停主庫打補丁。需求是查找所有業務系統中03：00-06：00的所有定時任務（我們很多操作數據庫的定時任務是crontab管理的），確定哪些定時任務連接需要停機數據庫。如果你有上千臺服務器，自殺的心都有了。
雖然最後是解決了，但是告訴我們只有標準化、工具化是解決不了問題的，所以要往Web化發展，後來我們做了一個作業平臺，把定時作業全部通過作業平臺管理起來。想加一個定時任務，提交工單，工單把所有任務記錄下來，然後可以做查詢。
所以要分析自身情況，找準痛點，不要盲目的做。
基於開源的全鏈路自動化運維體系是按照一個項目上線的流程來整理的。從傳統的角度來說：
自動化系統安裝：從自動化安裝開始入手，使用Cobbler可以在企業中構建的自動化裝機平臺和私有Yum倉庫；
配置管理：系統安裝完畢後，然後我們需要在系統上運行服務，進行管理和配置，SaltStack可以幫助我們進行遠程執行和配置管理，當然雲管理也是SaltStack的非常棒的功能；
自動化監控：系統安裝完畢後，我們需要做的第一件事情就是監控，可以基於Zabbix構建自動化、分佈式、多維度的監控體系；
持續交付：應用服務使用SaltStack部署並運行後，我們需要將應用代碼部署到集群中，使用Jenkins可以完成持續交付相關的工作。
日誌收集：代碼上線後在業務運行中，會產生不同類型的日誌，那麼緊接著我們通過ELKStack（Elastic Stack）來構建一個日誌收集、存儲、和展示平臺。
基礎設施自動化：可以使用OpenStack、Kubernetes來進行基礎設施的虛擬化和容器化。
最後所有的數據庫放在 CMDB。所以說這是一個全鏈路的自動化體系。
從幾個層面介紹一下，一個是 OpenStack，我們兩個版本，一個I版，一個M版，做的多區域。
像上圖的架構是可以用 SaltStack 進行自動化的配置管理。
基於 Jenkins 的持續交付。做自動運維要做一個體系，要解決全鏈路的問題，而不是做某一個層面，要把整個方面全考慮到位。
上圖是我們基於 ELK 做的日誌數據分析平臺，我們這個有大數據的部分，會把數據全部寫在 Kafka 裡面，然後從 Kafka讀出來，一部分寫在 ES 裡面，一部分寫在 Hadoop 裡面。
然後基於 Hadoop 做數據分析和處理。 ES 主要是用於搜索和運維。這裡想強調一點，如果你的業務也用ES的話，你要把運維的 ES 和業務的 ES 分開。
我做了一套基於全開源的智能化擴容的實現。例如 Zabbix 觸發擴容，調用 Salt-Cloud 創建 OpenStack 虛擬機，將信息寫入到 etcd，然後調用 SaltStack 進行環境部署，調用 Jenkins 進行代碼部署，調用自動化測試進行測試。
最後 SaltStack 管理 Haproxy 的配置文件，進行自動重載，完成擴容工作。當然這只是一個簡圖，有 CMDB 的話，可以直接替換掉 etcd。
5、未來展望
下一步怎麼走？剛才講的做運維是標準化、工具化、平臺化、服務化、智能化，下一步是產品化，對於一些運維老司機，在運維行業深耕多年，找準機會就可以創業去了。
技術成就夢想，最後，希望所有運維人都能夠持續學習，不斷成長，事實證明，運維不僅僅可以背黑鍋，還可以站在舞臺的正中央。我為自己是一個運維人而自豪！