在IT中，有很多令人喜歡的框架，無論敏捷，ITIL，精益，COBIT，六西格瑪或其他，其實這些背後都是透著對“最佳實踐”指導的渴望，這種渴望不可替代。

“最佳實踐”的概念本身是一種謎。 誰能決定一個實踐是否真的是最好的？ 最適合誰？ 儘管在大多數框架中都倡導“採納和適應性”，但依然存在著針對已釋出的最佳做法進行不斷調整和優化。 無論是為了推動“最好的”，“世界級”還是“最佳實踐”，許多組織都將這些術語作為某種形式的競爭優勢。

是不是真的？ 難道業務結果不應該是真正的競爭優勢，並衡量IT實踐是否真的是滿足客戶要求的“最佳”？

DevOps研究所成立於2015年，作為新興DevOps實踐的全球學習社群。 自推出以來，我們有意避擴音及DevOps“最佳做法”。

我們認為DevOps的做法不斷湧現，在許多情況下，它們在顛覆被證明。

通過研究、訪談、專業會議和我們的董事和合作夥伴的經驗，DOI的目標是通過知識，教育和認證模式識別，捕獲和共享新的DevOps實踐，這些模式最適合學習社群和企業IT。 當成功的DevOps所需的專業知識和掌握程度不明確並且可能不適用於一個人時，我們認為將個人認證為“專家”或“大師”為時過早。

DevOps相當年輕。 它沒有一個單一的知識體系。 對其哲學，運動或框架的表述依然還存在分歧。 儘管如此，DevOps正在跨越從創新者到幼小生命體的鴻溝，比任何其他IT框架更快。 為什麼？ 也許這是因為DevOps談到許多IT長期積累的文化和技術挑戰，並尋求解決方案。

所以我們不是專注於最佳實踐，而是同意DevOps的核心原則：

• Go faster（跑得更快）
• Shorten feedback loops（縮短反饋環）
• Experiment and learn（實驗和學習）
• Cultural transformation（文化轉變）
• Deliver business and customer value constantly and consistently（持續且一致性的交付商業和客戶價值）

毫無疑問，一些實踐或者稱之為做法已經明顯浮出水面，對於實現DevOps的核心原則至關重要：

• Agile software development（敏捷軟體管理）
• Continuous integration（持續整合）
• Continuous delivery pipelines（持續交付流水線）
• Automated and continuous testing（自動化和持續的測試）
• Proactive monitoring（主動監控）
• Improved communication and collaboration（改進的溝通和協作）

不過，過去一年，DOI還根據額外的做法作了一些補充：

• DevSecOps/rugged DevOps(DevSecOps和堅固的Devops）
• ChatOps
• Agile service management（敏捷服務管理）
• Lean（精益）
• Immersion practices (Garage, Lofts, Dojos)沉浸式實踐（）
• DevOps teams(DevOps團隊）

明年會出現什麼？ 誰知道 – 但這是DevOps的激動人心的部分。 隨著時間的推移，矛盾越來越少，完善得越來越豐富。 每個新興的實踐似乎是完善和微調之前的事情。

即使沒有一個標準的定義，DevOps已經鼓勵組織檢查他們的當前特有做法，查明差距，評估其自動化，最重要的是進行協作討論。 變革已經播下種子，但沒有明確的最佳實踐。 棒極了！ 我們不要通過附加一套靜態的最佳實踐來扼制動力。

最終會達成DevOps的最佳做法嗎？ 也許。 DevOps幾乎涉及IT管理的各個方面 – 人員，實踐和自動化。 這就類似於一整套的最佳實踐。 當然有些人會嘗試釋出他們的“確定”版本，用來描述DevOps知識體系。 即使是“DevOps手冊”，這是今年晚些時候出版的一本重要的圖書，它是DevOps運動的許多早期創始人之間的合作努力。 他們的觀點和洞察力將是非常棒的，但沒有限制。

我知道缺乏一套知識和成文的最佳實踐令人沮喪。 在過去的框架中，知識體系既是一種有用的工具，也是限制性的，知識內容很難保持現狀。 對於DevOps，讓我們通過推動一個有相容性和集體性的新興實踐知識體系，從而真正擁有分享、協作和持續創新的真正精神。

如果我們確定了一套DevOps最佳實踐，我們是否真的會抑制我們試圖堅持的價值觀？ 我希望不是。

文章來自微信公眾號：網際網路運維雜談