知識星球
作者 | Magnus Hedemark
譯者 | aiwhj ? ? 共計翻譯：4 篇 貢獻時間：28 天
想要實現 DevOps 但是不知道如何開始嗎？試試這 5 個最佳實踐吧。
想要採用 DevOps 的人通常會過早的被它的歧義性給嚇跑，更不要說更加深入的使用了。當一些人開始使用 DevOps 的時候都會問：“如何開始使用呢？”，”怎麼才算使用了呢？“。這 5 個最佳實踐是指導你的 DevOps 之旅的很好的路線圖。
1、 衡量所有的事情
除非你能夠量化輸出結果，否則你並不能確認你的努力能否使事情變得更好。新功能能否快速的輸出給客戶？帶給他們的缺陷更少嗎？出錯了能快速應對和恢復嗎？
在你開始做任何修改之前，思考一下你切換到 DevOps 之後想要一些什麼樣的輸出。隨著你的 DevOps 之旅，將享受到服務的所有內容的豐富的實時報告，從這兩個指標考慮一下：
上架時間 衡量端到端，通常是面向客戶的業務經驗。這通常從一個功能被正式提出而開始，客戶在產品中開始使用這個功能而結束。上架時間不是工程團隊的主要指標；更加重要的是，當開發出一個有價值的新功能時，它表明瞭你完成業務的效率，為系統改進提供了一個機會。
時間週期 衡量工程團隊的進度。從開始開發一個新功能開始，到在產品環境中執行需要多久？這個指標對於你瞭解團隊的效率是非常有用的，為團隊層面的提升提供了一個機會。
2、 放飛你的流程
DevOps 的成功需要團隊佈置一個定期（但願有效）流程並且持續提升它。這不總是有效的，但是必須是一個定期的流程。通常它有一些敏捷開發的味道，就像 Scrum 或者 Scrumban 一樣；一些時候它也像精益開發。不論你用的什麼方法，挑選一個正式的流程，開始使用它，並且做好這些基礎。
定期檢查和調整流程是 DevOps 成功的關鍵，抓住相關演示、團隊回顧、每日會議的機會來提升你的流程。
DevOps 的成功取決於大家一起有效的工作。團隊的成員需要在一個有權改進的公共流程中工作。他們也需要定期找機會分享從這個流程中上游或下游的其他人那裡學到的東西。
隨著你構建成功，好的流程規範能幫助你的團隊以很快的速度體會到 DevOps 其他的好處
儘管更多面向開發的團隊採用 Scrum 是常見的，但是以運營為中心的團隊（或者其他中斷驅動的團隊）可能選用一個更短期的流程，例如 Kanban。
3、 視覺化工作流程
這是很強大的，能夠看到哪個人在給定的時間做哪一部分工作，視覺化你的工作流程能幫助大家知道接下來應該做什麼，流程中有多少工作以及流程中的瓶頸在哪裡。
在你看到和衡量之前你並不能有效的限制流程中的工作。同樣的，你也不能有效的排除瓶頸直到你清楚的看到它。
全部工作視覺化能幫助團隊中的成員瞭解他們在整個工作中的貢獻。這樣可以促進跨組織邊界的關係建設，幫助您的團隊更有效地協作，實現共同的成就感。
4、 持續化所有的事情
DevOps 應該是強制自動化的。然而羅馬不是一日建成的。你應該註意的第一個事情應該是努力的持續整合（CI）[1]，但是不要停留到這裡；緊接著的是持續交付（CD）[2]以及最終的持續部署。
持續部署的過程中是個註入自動測試的好時機。這個時候新程式碼剛被提交，你的持續部署應該執行測試程式碼來測試你的程式碼和構建成功的加工品。這個加工品經受流程的考驗被產出，直到最終被客戶看到。
另一個“持續”是不太引人註意的持續改進。一個簡單的場景是每天詢問你旁邊的同事：“今天做些什麼能使工作變得更好？”，隨著時間的推移，這些日常的小改進融合到一起會帶來很大的結果，你將很驚喜！但是這也會讓人一直思考著如何改進。
5、 Gherkinize
促進組織間更有效的溝通對於成功的 DevOps 的系統思想至關重要。在程式員和業務員之間直接使用共享語言來描述新功能的需求檔案對於溝通是個好辦法。一個好的產品經理能在一天內學會 Gherkin[3] 然後使用它以平實的英語構造出明確的描述需求檔案，工程師會使用 Gherkin 描述的需求檔案來寫功能測試，之後開發功能程式碼直到程式碼透過測試。這是一個簡化的 驗收測試驅動開發[4](ATDD)，能夠幫助你開始你的 DevOps 文化和開發實踐。
開始你旅程
不要自餒哦。希望這五個想法給你堅實的入門方法。
關於作者
Magnus Hedemark – Magnus 在 IT 行業已有 20 多年，並且一直熱衷於技術。他目前是 nitedHealth Group 的 DevOps 工程師。在業餘時間，Magnus 喜歡攝影和劃獨木舟。
via: https://opensource.com/article/17/11/5-keys-get-started-devops
作者：Magnus Hedemark[6] 譯者：aiwhj 校對：wxy
本文由 LCTT 原創編譯，Linux中國 榮譽推出
