[譯] 開始嘗試 DevOps：最適合你的是什麼樣的工具？

• 原文地址：Moving to DevOps: what tools do you really need?
• 原文做者：June Jung
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Starrier
• 校對者：suhanyujie

DevOps 是一系列問題的最新解決方案，每個問題的解決方案都有許多數字化工具庫：CI/CD 系統，測試框架，監控工具和安全審計工具等。哪些工具纔是你所須要的？哪些能夠解決你的組織所遇到的問題，痛點？在幫助各類規模的團隊時，我常常聽到的兩個問題是「咱們須要擁有什麼樣的組織結構？咱們應該使用哪些工具？」

這兩個都不算是問題，但單獨問時，它們都沒有抓住重點來問。在你直接回答這些問題的時候，你應該先評估你的組織須要解決的問題，而後再考慮解決方案。

組織經常認爲自上而下的模式（「使用這個！這樣作！」）會讓他們的團隊創新的更快。優秀的團隊領導會帶來一個新的 CI/CD 工具，讓每一個人都能工做餘上。有能力的團隊領導在引入新的 CI/CD 工具時，會確保每一個人都能掌握並運用它。而團隊領導在不能徹底理解其價值或爲何要這樣作的狀況下引入工具時，問題就出現了。甚至會出現一開始提出改變的人也忘了使用工具的初衷，指望獲得的效益。使人遺憾的是，一旦初衷被遺忘，很容易形成工具的濫用，致使各方面的損失，以及負面價值。

咱們須要 DevOps！

我瞭解了許多確認 DevOps 是他們全部問題的解決方案的組織，只要他們可以快速啓動並運行便可。

若是你如今處於這個位置上，問問本身「爲何要在組織中使用 DevOps？咱們想讓它爲咱們帶來什麼價值」。

在這個點上，咱們討論下，DevOps 是什麼，而不是什麼。

DevOps 是開發團隊和運維團隊之間的具體協做方案。本質上，它代表你已經在文化上將開發實踐應用到你的基礎架構中，並將實踐應用到你的開發週期中。這在實踐中是什麼效果呢？這可能意味着將基礎設置做爲代碼來維護，或經過構建可重用的組件來建立不可變的基礎結構，以便你能夠隨意刪除或啓用它們，從而提供版本控制和更改的歷史記錄。這也意味着讓全部的產品貢獻者更關注他們工做的最終結果 —— 它們是如何運做的？用戶如何與它們進行交互。讓人們關心質量意味着關心其商業價值和可用性。當構建產品的每一個人最後都關心質量的兩個方面，部署後會發生什麼以及最終暴露給用戶時發生什麼，這纔是真正使用 DevOps 的目的。

在個人經驗中，這種普遍的支持對於軟件團隊來講，尤爲困難，由於它須要來自具備不一樣技能和領域專長的人的配合。要作到這一點，既須要跨職能的團隊結構，也須要深思熟慮的溝通技巧。好比，若是工做上須要與業務方面的人討論數據庫問題，那麼他不只須要告知他正在處理的數據，並且要給出必要的問題背景，並將該人的注意力集中在他們應該關心的內容和緣由上。

是否應該引入新工具？答案或許是：可能。工具備時更像是一個快速修復而不是通用的解決方案。在個人經驗中，在引入新的 DevOps 工具以前，記住這些注意事項會增長成功的機會。

開始轉變以前：

1. 確保全部人意見一致。關於你試圖經過這種改變來達到目的的想法，每一個人在這個問題都應該達成一致，並在痛點上有所共鳴。

2. 慢慢開始。不要妄想讓這個組織在一晚上之間成爲 DevOps 模型的團隊。相反，從一個團隊開始，看看處理方式的改變，是否更適用於你的組織。若是看到了積極的改進，就能夠保持繼續改進。

3. 明白你所要作的工做。要明白，DevOps 可能並非解決你的組織問題的正確方案。有些公司在沒有 DevOps 的狀況下都取得了成功，考慮到他們的文化和產品，這些可能並不適用於他們。我我的以爲瀑布工做流會更適用於那些成功的組織。好比，若是機密性是公司產品策略的一個重要部分，那麼以增量方式交付來得到反饋對你來講，就會行不通，由於直到發佈前，你都須要將全部產品的詳細信息都封鎖，直至一個大型的發佈。在這種狀況下，構建 DevOps 文化會異常艱難。

4. 保證衡量。在你開始任何改進計劃以前，請獲取你當前狀態的指標（即，開發週期的時長）。在邀請 SRE 進入開發團隊以前，請先這樣作。一段時間後，就能夠看到它是否有效。在你作出改變的先後進行衡量，看看是否有所改變。好比，在衆多敏捷轉型時，不少公司採用了 standups，卻沒有真正理解緣由，也沒有衡量它是否對他們的團隊產生了積極的影響。這可能致使浪費的時間比節省的時間還要多。

5. 並非全部事情都適合自動化。至少不是一次性地向全自動化進行轉變。DevOps 的一個誤解是，全部的基礎設施和配置管理都必須自動化完成。這些被稱做「基礎設施即代碼」。但有些東西的手動操做效果會更好。自動化並非解決全部問題的方法。 考慮一下，你將運行這個自動化腳本多少次，以及你須要多少時間來實現自動化。你會頻繁使用自動化仍是隻是偶爾使用？有時，你必須用手動的方式，甚至找出什麼是最好的自動化解決方案。仍然渴望自動化麼？讓應用程序 Docker 化，是一種優秀的自動化解決方案，由於你努力付出的結果能夠被重複使用。自動化預生產環境是實現自動化的另外一種好方法。再舉例說明，你是否嘗試過防火牆自動化設置？考慮到目前許多防火牆軟件缺少 API 支持，這樣的嘗試可能並不值得。儘管對於災備來講，這樣有意義，但實際上來講，你從中所獲取的價值，可能遠不如你所付出的努力。

接下來呢？

若是你的組織正在考慮是否使用 DevOps，請先考慮下大家的交付速度和產品質量的問題。大家如今所遇到的真正問題是什麼？瞭解這些問題的答案，有助於大家組織的每一個人來了解如今的痛點所在，從而幫助大家在最正確的地方來改變它們。

在以後的文章中，我會經過一些實戰來幫助大家發現本身組織現現在的問題所在，幫你提升評估哪些工具或處理方法是解決這些問題的最優解的自信心。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。