本文由『高效運維社群』的DevOps專家@景韻等人，根據3月18日DevOpsDays·Beijing大會上全球公認的 DevOps 之父 Patrick Debois 的演講整理而成。

這也是 Patrick Debois 首度在中國傳遞他的 DevOps 的理念和經驗，獨樂樂不如眾樂樂，歡迎大家傳播擴散。

本文內容包括：

1. DevOps 起源

2. DevOps 切入點

3. DevOps 四大改進方向

4. DevOps 八個實踐場景

5. DevOps 實施五大級別

6. DevOps 五個常見問題

7. DevOps 20個實踐點

Patrick Debois

CTO of Small Town Heroes

Patrick Debois 是著名的 DevOpsDays 和 DevOps 運動的創始人，因此被稱為“DevOps 之父”。此外，他還是互動視訊公司 Small Town Heroes 的CTO。

序：聽教父講DevOps起源的故事

你們記不記得這個遊戲，這是一款很老的電子遊戲，將這個球會從左邊扔到右邊，這是我當初想到 DevOpsDays 的時候，我可能需要Dev一點東西，Ops 一點東西。

下邊這個圖給我的感覺，就是我最初做 DevOpsDays 的時候，開發人員和運維人員之間總是相互不滿意，相互指責，在一個公司裡有很多矛盾。

然後我們開始做敏捷，敏捷給人的感覺很好，變得更加有生產力，我們工作更加的出色，大家都非常高興。

ITIL 我們也在用，ITIL 在運維裡給了我們很多的條條框框，很多的規則來遵循。

我之前是做運維的，大家看到有很多煙在冒（如下圖所示），有很多的問題：Agile 大家覺得很高興，ITIL 給我們很多原則、條款，但是，

我們在運維這塊還面臨很多問題。

在2008年的時候我寫了一篇論文，當時我們說到在一個運維團隊當中用看板，我開始在這些東西上面進行一些試驗。

與此同時，Flickr 也有人做了一個演講，當時2008、2009年的時候他們說每天做10次部署，然後有人說這個想法很瘋狂，然後問他們怎麼做得到，下圖就是他們的祕密所在。

Flickr 把開發和運維人員放在一起，讓他們相親相愛，他們不再對彼此指手劃腳、指責對方，他們一起工作。

當我把這件事解釋給我的孩子們聽，他們說這個有什麼可奇怪的，大人教導我們小孩子在教室裡面要跟小朋友玩在一起，但是你們工作卻不在一起，本來就應該大家坐在一起工作嘛。

之後我們在一些活動當中引入精益理念和端到端流程，我們用敏捷來讓我們的程序變得更快。你可以看到這裡有很多的原則和實踐，但是都沒有運維什麼事兒。

所以我們最終決定發起這個 DevOpsDays 的運動。

1、Patrick 親述 DevOps 切入點

我們有開發、測試和QA，然後是生產環境，從終端使用者那邊獲取反饋，之後反饋流轉到專案中，這就形成了一個迴圈。

這中間有一道高牆（部門牆）。我們需要讓資訊流動的更快來打破這道牆，獲得更多的反饋。

1.1 怎麼落地DevOps？

我們不僅僅是來優化開發這部分，也不僅僅優化生產部分，我們要怎麼做？在整個系統當中找到瓶頸所在，找到方法來解決它，而不僅僅做一個區域性的優化。

圖中上邊是技術問題，下邊則是人的問題，比如說人們之間不合作，有人不喜歡他的工作，這是人方面的問題。通常會分為這兩方面的瓶頸。

1.2 DevOps從什麼地方開始？

從任何一個地方開始都可以。我沒有辦法說你的公司的瓶頸是什麼樣的，你只有自己去找到瓶頸所在。

2、DevOps四大改進方向

當你的公司剛開始走上DevOps道路的時候，你可以找到四個部分進行改進。

1）端到端交付

第一部分更多談論流水線，持續整合，持續交付，更快投入生產。

2）持續反饋

第二部分強調更多的反饋，讓生產環境中的資訊以及終端使用者的資訊反饋到專案組當中，也就是一個反饋迴路。

3）開發向運維

第三部分關注將專案研發知識傳遞到運維領域，在第一個部分中我們需要很多的技術，比如說自動化工具等等，當這部分變得成熟的時候，我們就開始將更多的知識、更多的流程放在裡面。

比如說有一個人他釋出了一個新的軟體，他自然成為第一個月的運維人員，通過這一個月的時間，他可以更好地瞭解到運維人員的痛點，能夠感同身受的知道他們的痛苦所在。

4）運維向開發

第四部分關於將運維知識傳遞到專案開發環節，一旦我們部署到了生產環境中，我們就是知道終端使用者的反饋，知道下一步應該做什麼新的特性。

3、DevOps實踐場景

3.1 配置管理

我看到有很多運維人員首先開始做配置管理，他們有很多的工具，能夠讓服務交付更快，加快工作的進度。

做配置管理的時候，我們在開發和測試方面也要用同樣的方式，這不僅僅涉及到我們的伺服器，而且涉及到我們是否可以實現一個跨環境的運作。開發人員可以以程式碼的方式定義基礎設施。

3.2 環境管理

另外一個例子，要可以重複建立各種環境，我們現在有相關的技術，開發組可以重新創建出相關的一套設施。

3.3 監控與度量

接下來是監測，通常是由運維人員來做，但是他們不會和開發人員來交流觀察到的資訊，或者說通常也很難能夠讓這些開發人員拿到相關評測的資訊。

如果我們能夠讓開發和運維的人員在一起工作，不僅可以讓這個資料對運維人員瞭然於心，所有人都可以拿到這個資料，它會變得更有價值。

3.4 On-Call

讓開發人員和運維人員都實時值班，可以讓他們更好的感受痛點。

3.5 Chaos-Monkey

“創造混亂的猴子”的概念裡，我們假設事情會出問題，用這樣一個假設的情景是為了讓我們改變思維，我們總是假設一切都是完美的，不會出現任何問題。現在用這個工具，我們假設事情一定會出現必然的某種問題，那麼我們怎麼樣可以來解決它。

這個猴子可以用隨機的方式來讓某一個環節徹底崩潰，這個時候我們就需要知道我們用什麼方法能夠進行補救和修正。

如果我們進行更多的相關練習，系統會變得更加可靠。如果我們缺乏這種練習，一旦現實的工作當中出現崩潰，我們將很難加以應付。

3.6 ChatOps

你們聽說過ChatOps嗎？好像不是很多。大家都用手機聊天，原理就是你和人們聊天，但是在這個概念當中，在聊天室裡面，所有技術的資訊都包含進來，當我們進行了一次部署這裡面會出現相關的資訊，如果有人提交了一段程式碼，聊天室裡的人也都會知道。

我們在部署伺服器的時候會說我們要釋出一個新的版本，我們把它都放到聊天室裡面，這裡面很好的一個部分是所有東西都有一個聊天記錄，它不是一個把任何人排除在外的過程，所有人都是局內人，我們可以通過對話的方式在團隊裡形成一個很好的氛圍。

3.7 事故分析

接下來是做事故分析，我們在發生某一個問題之後研究為什麼會出現這樣的問題，做一個分析，我跟我的同事說，有的時候出現一個問題我會不高興，但我絕對不會指責你。

我實際真想知道的是如何來改進，這點更重要，這點也是我們能夠更好服務客戶的根本。我們做一個產品，沒有辦法保證產品不會出現任何問題，我們能夠做成的是可以盡我們最大的努力在最短時間內解決出現的問題。

然後我們發現我們的客戶也非常樂於接受這樣的方式，他們能夠看到我們真正是在努力，能夠為他們提供更好的產品，能夠提供更好及時的服務，這點也是我們一個可以考慮的方式。

3.8 遊戲日

還有遊戲日，有的時候我們會和整個公司進行溝通，大家可以共同總結一下整個系統之內出現哪些問題，我們可以對這些出現的問題狀況來進行記錄，

4、DevOps實施的五級精進

我們來看自己的系統如何能夠通過 DevOps 得到更好的提升，DevOps 其實是讓整個生產流程變得更加流暢，形成一個閉環，逐步為我們提升企業的實力。

4.1 個人級別——一馬當先

大家可能玩過這個遊戲，DevOps 可以是個人，比如說像我這樣。但是個人可能還沒有辦法做到完全自動化的方式，可能要找其他人加入，找一些有共同想法的人加入，將各自的技能放在一起。

我會問他你怎麼樣使用你的技能，你怎麼樣與別人分享你的資訊。這就是我們作為個人級別來實施 DevOps。

4.2 團隊級別——人多力量大

作為一個團隊，比如說我們有一個發展的策略，我們的團隊可以和其他的機構來進行合作，這是一個團隊層面的 DevOps 的案例。

4.3 IT組織級別——化敵共存

其實現在已經看到了運維人和開發人他們之間其實以前是有堵部門牆的，有一個筒倉的概念，但是現在通過 DevOps，跨越筒倉，我們能夠更好的讓他們合作在一起。

4.4 業務組織級別——眾人拾柴火焰高

我們要有非常好的技術，但是一定要有一個業務的視角來看待這些事情，不僅僅是侷限於技術層面。

4.5 跨越組織級別——達者兼善天下

之前我們聽過很多 DevOps 可以用到的工具和技術，非常包容。但是我們指的並不僅僅是這些工具，工具可以讓我們工作更快，但是更好的思維方式可以讓我們更好的工作，這是一定的。

5、DevOps實施常見問題

1）我該如何開始？

第一個問題，大家經常問的是我怎麼開始的，我會給大家講我是做了這件、那件或者是另外的事情，就做到了現在這樣。

1. 和其他的轉型沒有太大的區別

2. 不要花費太多的時間在反對者身上，專注於尋找志同道合的盟友

3. 不要過於自負，要尋求管理支援，個人影響力有限，我們要與管理層進行非常好的合作

4. 選一個小的專案並達成目標，成功最建立信心和信任的最佳方式。

5. 要選的第一件事情是一個大家都比較關注的痛點，做一些有意義的事情，但是一定要比較小，這樣你自己就可以用有限的資源完成。這會提示大家改變的意願

6. 開始動手做，不需要做過多的解釋，動手做就可以了。

7. 做了再說

8. 做出成果之後要及時溝通，可以有效建立信任

9. 度量改進效果

10. 持續改進

英語裡面表達的方式是先做再去求原諒，可能聽起來有一點奇怪，其實我們最終的目的就是想把工作做好，如果說我們有理由將我們的工作做得更好，沒有人可以對你有任何的非議。

特別是在一開始的時候，人們總會說我們真的能做到嗎，因為在過去，我們可能會去找很多人來進行這樣的一些溝通，會有很多的人來組織我們做這件事情。

但是不管他們怎麼說，我覺得還是有價值有必要去嘗試一下，一旦取得成功以後，再去找之前溝通過的一些人，比如說現在這件事情已經做成功了，然後跟他們講我現在需要你更多的幫助。

對於發展、提高，現在對於提高，我們不要很籠統把它稱為確實比以前好一些，要有實際的能夠量化的能夠測量的進展和提高，

如果僅僅跟人家說我們現在變得更好了，可能沒有人相信你。再有是可追溯性。要有一個獨立的 DevOps 團隊，個人可以做 DevOps，團隊可以做DevOps，其實並不重要，如果僅僅是想一個小的團隊開始做一件小的事情，可以把它叫 DevOps 團隊。

最開始做的時候，它是一個很小的團隊，我相信這是一個漸變的過程。過了一些時間以後，相信大家對 DevOps 都有自己不同的思維方式和理解，可以是一個自動化的團隊，也可以是 DevOps 的團隊，特別是對公司來講，每個人都要有 DevOps 這樣的思維方式。

2）我們應該設定獨立的DevOps團隊嗎？

當你擁有一個專門的 DevOps 團隊，那麼你做錯了，而且DevOps也不應該是一個崗位。但是臨時存在的 DevOps 推進小組是合理的。

3）如何衡量DevOps的效果

讓成果可衡量、可測量。如果說人們不相信合作會獲得更多的資源，我們一定要主動去相信我們通過更多的合作能夠獲得更好的結果。

如果是在聚會的時候，我們講很多的話，健談，這樣你可能會沒有辦法享受一個聚會，但是你的個人關係和周圍參加聚會的人可能會獲得比較好的推進。

我們也要看到合作是一種好的選擇，但是合作並不代表一定能給你帶來更好的更多的資源。

4）DevOps宣言是什麼？

我其實還沒有寫下真正 DevOps 的宣言是什麼樣的，我們現在剛剛開始做，但是我們已經取得了一些成績。對於我個人來講，我不需要什麼樣的宣言。

5）DevOps和ITIL的關係？

DevOps追求協作，ITIL中導致官僚主義和抵觸變化的內容應該避免。

還有另外一個問題，ITIL 合作是什麼樣的狀態，如果有些人知道 ITIL，剛開始使用這項工具，大家知道 ITIL 是一個什麼樣的工具。如果大家關注 ITIL，它其實是很有價值的。

其實現在有很多的資源和工具可以使用的，而且我們也很關注持續的提升和改進。我昨天提到的 CMDB 自動化，現在很廣泛，它已經深入了我們很多的環境裡面，這項工具可以讓我們更好地跟進這個市場。

現在關注的是人的問題，我還沒有提到這些，其實我們更應該關注信任，如果不相信其他的團隊，可能你就失去了瞭解他們的機會。

瞭解他們，與他們合作在一起，逐漸建立信任，相信他們的工作，信任是非常重要的一點，不管是我們以流水線的是在工作或者說使用工具，信任都是非常重要的。

有一點共情的能力，一定要去了解其他人是否他現在過得不順，再有就是他們真正解決不了的一些問題，我們要真正去理解他們現在面臨的很多情況。DevOps 的文化是重建信任，讓人們走在一起。

“我們通過他人的行為來評判別人，但卻按照我們自己的意願來評判自己”
這是兩句話，如果我們的意圖是好的，有很多人他有意圖想要做一些事情，但是他們做不到。

對於您這邊想做一些事情的時候，但是我們首先要考慮到其他人有什麼樣的想法和意圖，他們可能由於時間不夠或者其他原因，我們要嘗試去了解他們的一些問題。

還有新的拓展，然後是雲服務，我們會有很多合作伙伴工作在一起，我們不僅僅是在公司內部來進行，很多人都來問我問題，DevOps 實現之後，其他的都能實現API自動化，所以我們也不需要再與彼此溝通，我不相信這是 DevOps 最終的目標。

我之後也發現，如果用很多服務，我們可以把很多不同的服務用在不同的位置上，比如我們有很多的實踐，CDN 也是提供服務的，監控也是一種服務。我們現在沒有運營服務，我們使用的都是別人的服務，我們並沒有所有權，但是我們依然能做我們的事情。

6、常用實踐與工具

1）溝通你承諾的狀態並監控

2）監控服務並暴露度量資訊(API)

3）暴露內部資訊(API)

4）關心其他人  

5）暴露日誌  

6）明確錯誤資訊

7）備份外部資料
你對自己的資料應該負責，你應該自己想一想怎麼去做備份。如果你將你的運維所有都外包給其他的公司或者都把這些重要的工作給到其他的系統，這個是不太具有保障的。

8）更快的反饋  

9）讓內外部依賴更清晰  

10）主動讓別人保持承諾

11）讓別人瞭解變更

12）建立技術部落格

然後可以用部落格，部落格也是可以每天進行更新的一種交流的方式。我和外部的服務有很長的合作時間，做一個很大的記錄，我需要什麼東西，將一個反饋發給他們。

如果我不做這項工作，我就沒有辦法獲得更好的服務，只有把我自己的需求陳述清楚的時候才能獲得更好的服務。

13）去大會演講

14）讓別人很方便的使用服務    

15）給別人反饋

16）表達你在關注外部對你的依賴
之前和亞馬遜的一次合作當中，我是當初這個服務最早一批使用者，而且當初我收到任何一個反饋，我每提出一個問題一個需求，他們都及時給我反饋，我每提出一個投訴或者建議，他們都能很快進行反應。

另外我們還需要傾聽他人的看法，比如有的人會在社交網路上，一些聊天軟體上釋出一些資訊，表示他們遇到了什麼問題，這個時候我們可以通過這樣的渠道來更好的瞭解他們的訴求。

有一些公司甚至還可以允許我們的使用者直接和工程師見面，他們並不害怕這麼做，我們並不害怕這中間隔著好幾層的架構和阻礙，我們可以直接建立起這個喬樑，因為這對於公司來說也是非常具有價值的。

17）告訴別人你在參與改進

18）告訴別人你的工程師們不怕與人交談

19）對訪問請求負責

這是一個App的應用商店裡面的評價次數

20）讓其他人蔘與進來
大家發現問題，然後有什麼建議，都可以在裡面寫出來，這個時候就可以讓我知道我有什麼痛點，如果可能的話，我會盡可能來解決這些問題，通常有些問題會非常大。

有一些合作伙伴，他並不是非常具有合作的精神，這個時候如果短時間之內要換掉這些合作伙伴也非常的肯定。現在在公司的內部和外部，我們都可以看到有幫助我們改進的一些方法。

今天在自己的公司裡面，很多人都在說 DevOps，我們在公司外部的這些東西不能夠被看作是完全隔絕的，我們不能把自己的公司作為一個小團體、作為一個筒倉，而把自己的公司和外部隔絕開來。

其他一些可以給大家的啟示，有很多書籍，大家可以進行相關的閱讀，它可能未必是一個 DevOps 的操作手冊給你讓你按步驟完成，但是它會幫你理清思路，為什麼我們要進行公司內部的 DevOps 的改造。

如果大家對第三方的合作感興趣，我建議大家看這個視訊，解釋了相關的合作關係，一個非常有意思的演講。

之前我也說到過，我們非常努力地編寫了這本書，集合了我們多年的經驗，出版了這本 DevOps Handbook，這裡面的資訊非常多，可以作為一個參照檔案，從這裡面甚至也可以找到新的思路和新的啟發。

當然我們也歡迎大家分享你們的經驗，我將會非常期待聽到你們所有的意見和建議，謝謝大家。

高效運維 和 DevOps

DevOps 之父 Patrick 親自創辦的 DevOpsDays 大會，至今已經9年時間，是最資深、最頂級的 DevOps 會議，至今已經在全球舉辦了150多場。

國內的 DevOpsDays 系列活動，由高效運維社群和國際最佳實踐管理聯盟聯合舉辦。2017年3月18日舉行的 DevOpsDays 北京站，是全世界最大的一次。

高效運維社群創始人蕭田國和Patrick合影

Patrick先生接受蕭田國的專訪

文章來自微信公眾號：高效運維