關于DevOps，你不知道的那些事兒
在本文中我們將會討論一些人們對DevOps的誤解，同時會介紹一個能夠帶來DevOps文化轉變的流程。
什么是（不是）DevOps？
在一篇題為“不，你并不是一個DevOps工程師”的博文中，Cloud Technology Partners公司的副總裁兼***架構師Mike Kavis談論了一些與DevOps相關的錯誤想法。例如，他提到一些團隊是如何誤用術語DevOps的：
|
企業正在為DevOps苦惱。他們都想得到DevOps，即使很多企業并不知道它到底是什么。在很多情況下，我會看到那些自稱DevOps的基礎設施團隊在領導一個基層倡議。當我問他們開發團隊在哪里的時候，他們通常會說“我們并沒有邀請他們”，甚至更糟“我們并沒有同他們交流”。 |
一些工程師將自己宣傳為DevOps，但是他們并不是，因為根據Kavis所說“DevOps并不是一個人，一個角色或者一個頭銜。即使你可以聲稱自己是一個DevOps工程師，但是這僅是你自己的看法，實際上你并不是。”如果DevOps不是一個角色，一個資格，一個頭銜，那么它到底是什么呢？Kavis的定義是：
|
DevOps是一種文化轉變，或者說是一個鼓勵更好地交流和協作（即團隊合作）以便于更快地構建可靠性更高、質量更好的軟件的運動。 |
然后他詳細描述說：
|
DevOps是軟件開發生命周期（SDLC）從瀑布式到敏捷再到精益的發展。DevOps超越了敏捷，它的關注點是從SDLC中移除浪費。通常情況下，發現浪費或者瓶頸的形式包括：不一致的環境，人工的構建和部署流程，差的質量和測試實踐，IT部門之間缺少溝通和理解，頻繁的中斷和失敗的協定以及那些需要珍貴的資源、花費重要的時間和金錢才能保持系統運行的全套問題。 我看到的另一個重復模式是：一個“DevOps”團隊的***步通常是決定他們是否應該使用Chef或者Puppet（或者是Salt、Ansible等其他任何熱門的東西）。他們甚至還沒有定義自己打算解決的問題，即使他們手頭的工具可以解決它們。這些團隊通常會緊張地構建數千行腳本，但是這就產生了一個問題：“我們的職責是編寫Chef腳本還是通過質量更好、更穩定的產品更快地進入市場？”。在大多數情況下，這些團隊會將自己逼入絕境，大量的專有腳本實際上是增加了系統的浪費，而隱藏在DevOps運動之后的驅動力是從系統中移除浪費，這些團隊并沒有做到這一點。 |
如何實現DevOps？
如果說DevOps是一種打算讓開發某個產品的多個團隊之間能夠更好的交流和協作的文化變革，那么下一個問題就是我們該如何實現DevOps，我們如何將這種文化引入到自己的公司中？
DTO Solutions的共同創建者Damon Edwards在2013年的DevOps Days Mountain View上做了題為“如何發起一個DevOps變革”的主題演講，他推薦通過一個三步走的過程將DevOps文化引入到某個組織中：
一、弄清楚“為什么？”
根據Edwards所說，首先非常清楚組織成員為什么會聚到一起，知道他們試圖實現什么，清楚他們的目的是什么是非常重要的。為了找到這些問題的答案我們應該直接與組織中的這些人交流，詢問他們為什么會出現在這里。組織的主要目標是我們實現DevOps文化的唯一原因，除此之外沒有其他原因。
Edwards認為DevOps僅僅是達到目標的一種手段，但是它自己本身并沒有結束：“DevOps并不是你的為什么，不是你合作伙伴的為什么，當然也不是你業務的為什么”。他甚至建議忘記DevOps團隊，而是使用服務交付作為替代，因為“我們的職責是創造服務”。
二、實現組織合作
按照Edwards介紹的過程，接下來需要做的是使整個組織合作，讓所有人基于一組共享的條件和規則向一個共同的目標努力。當你能夠把同一個目標指定給多個人的時候，一個組織就實現了正確的合作，他們會選擇同樣的方式去實現各自的目標；他們對于同一個問題有同樣的答案。這可能是“組織合作的***夢想”。
為了完成這種合作，組織內部必須要有人描繪一個DevOps愿景。這并不能通過教學過程實現，因為人們只會嘗試著機械性地遵循這些步驟。我們需要的是教會大家一種思維方式。根據Edwards所說，這可以通過遵循下面的幾個步驟實現：
1、教導基本的概念，例如“單件流、批量工作、限制在制品的數量、拉式vs推式、持續交付”以及可以使用的工具等組織將會共享的一些通用詞匯的概念。
2、讓所有人目標一致，通過：
a. 價值流程圖——一個精益概念，它詳細描述了一個組織內部發生的信息流和制品流，引導價值創造。
b. 時間線分析——試圖發現時間花費在哪里，瓶頸在哪里。
c. 浪費分析——確定一個組織所產生的各種各樣的浪費以便于盡可能地消除浪費。
3、發展度量鏈，它的意思是對價值交付鏈中的各個活動進行度量，發現各個活動相互之間的影響。
4、針對基線識別項目/ 實驗。識別哪些項目或者活動偏離了基線，并且采取糾正措施。
5、重復第2至4步。這一步構成了持續改進流程。
為了實現這些想法，Edwards建議了一個3天的計劃：
- 第1天—— 教導原則，提出一個方案進行研究，模式和反模式
- 第2天——分析組織當前的狀態，提供問題識別技術和改進指標
- 第3天——討論解決方案和工具鏈自動化原則，構建一個路線圖
三、持續改進循環
這些循環的目的是通過制定計劃、實現計劃、測量輸出和決定如何持續地改進流程。
