什么是DevOps"最佳實踐”？
在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***實踐，我們是否真的會抑制我們試圖堅持的價值觀? 我希望不是。
【本文是51CTO專欄作者“王津銀”的原創稿件，轉載請注明出處】
