作者 | Amit Gupta

　　譯者 | 張鋒

　　策劃 | Noe

　　多年來，公司管理員負責運維、集成和開發——而開發人員只需要編寫代碼。在那之前——由于運維開發兩個孤島之間幾乎沒有交流，所有專家都在項目上單獨工作。

　　最近， DevOps已成為最知名和廣泛討論的軟件開發過程之一。 DevOps以改善產品交付而聞名，并被 Amazon、Facebook、Netflix 以及眾多其他公司廣泛使用。

　　假設你有任何采用DevOps的想法，以使你的業務表現更好、更成功。在這種情況下，你必須從DevOps咨詢公司雇傭DevOps工程師開始。

　　你對DevOps了解多少？

　　DevOps代表運維和開發，是一種旨在合并質量保證、開發、運維基礎集成和部署的實踐。這些目標領域被組合成一組流程，是一致交付方法的自然延伸。

　　采用DevOps的優勢

　　為你的業務采用DevOps有幾個優勢。以下是采用DevOps的三個主要好處和優勢，涵蓋了開發的文化、業務和技術方面。

• 滿足客戶需求

在DevOps IT解決方案中，需要持續更新和新功能來以高效和結構化的方式滿足客戶需求。因此，價值交付和上市時間進度加快。

• 質量改進和產品快速發布

在使用DevOps時，會遇到產品持續交付和快速發布的問題。通過允許開發人員修復bug并鼓勵盡早反饋，從而來改進我們的服務。當你選擇DevOps時，你將體驗到更高的效率和更好的產品質量。

• 改善工作環境

在DevOps中，實踐和原則有助于團隊成員之間更好地溝通。這會提高敏捷性和生產力。與其他公司相比，采用DevOps溝通方法的公司更熟練，也更有效率。

DevOps團隊成員包括運維人員和開發人員，他們共同努力幫助業務更平穩地運行。你需要明白DevOps不僅僅是行動。你不需要對業務進行任何實質性的技術改變，因為DevOps主要聚焦于改變人們的工作方式。當你堅持鼓勵團隊溝通的DevOps原則時，你將會獲得完全的成功。

　　你希望通過DevOps實現的原則

　　假設你擔心DevOps無法滿足你的期望，并思考為什么沒有達到你期望的效率、滿意度和質量水平。也許你也在嘗試遵循別人的策略來實現你的目標。

　　你將希望通過嘗試以下這些DevOps原則來構建一個計劃。

　　為你的業務制定DevOps原則

　　在了解原則之前，你需要知道使用DevOps的原因和目標。當然，所有企業都希望更快的軟件開發。如果你使用SAFe 、Kanban、Scrum 等其他方法，你可能無法獲得更高的效率。 DevOps將幫助你以更快、更有效的方式實現目標。

　　通過不斷調整、測試和自省，可以提高運維效率，這是開發過程的一部分。一個完美的DevOps組織可以自我修復并適應持續的情況變化。通過遵循一些原則，你可以在沒有總部機構的任何幫助的情況下來改善整個組織。

　　可供采用的8條基本DevOps原則和實踐

　　1、創建自組織系統

　　有一些簡單的規則，當遵循這些規則時，就會創建一個自組織的系統。這些規則使整個團隊受益。在DevOps中，開發團隊必須與服務提供商進行交互，而無需與內部團隊同步。簡而言之，他們可以擁有一個有組織的系統，而無需過多的內部溝通。

　　2、可能對你的組織有益的規則

• 提供對當前正在進行的工作的適當訪問。例如，使用任務、會議記錄、項目、討論、鏈接等在線公告欄來代替電子郵件。
• 為避免混淆上下文，請一次完成一項任務。
• 檢查團隊的可用性并做出相應的計劃。例如，我們可以說人們正在計劃內。

　　你需要定期檢查并允許你的團隊創建自己的方式來處理和實施這些規則。重要的是：

• 在加速之前接受你的減速。這將幫助你更有效地成長。
• 如果第一次迭代不是最好的，請不要停止。
• 幫助你的同事處理內部問題。

　　3、與其組建團隊，不如組建專職任務組

　　我們將DevOps視為交付開發過程的敏捷擴展，它打破了運維團隊和開發團隊之間的隔閡。你也可以在其他組中使用DevOps 。專職任務組的工作方式是模糊開發和運維的界限，并將它們整合為一個整體。

　　將正常開發團隊轉變為一個專職組的過程并不像聽起來那么簡單。你不能僅通過將名稱從開發團隊更改為專職任務組來實現這一點——其是針對需要全面知識的特定運維而設計的。

　　你可以把你的開發團隊轉換成一個專職任務組，通過在不同的方面工作來升級你的DevOps原則和實踐。

　　4、作為多能力中心的任務

　　一項任務必須被視為一個多能力中心，其動機是進入一個項目，然后幫助運維和開發團隊加快他們的交付過程。

　　技術債務如何耗盡你的速度？

• 如果您不使用最新的安全性更新DevOps咨詢公司，將會出現問題。大多數時候，除非遇到問題，否則公司不會做出任何改變。這會導致數據損壞和金錢損失。
• 假設你不進行新的性能更新；你會放慢產品開發速度。
• 等待遷移計劃達到EOL會減慢產品團隊的速度并給企業帶來更多成本，從而產生影響。

　　專職任務組可以幫助項目的方式是：

• 識別緩慢的流程——例如，現場團隊工作、入職面試等。
• 將緩慢的過程自動化，例如應用程序測試、基礎設施測試、容器構建過程、 ChatOps 、登臺的按需環境等。
• 通過新聘幫手、聚會、培訓實驗室、棕色包發布等來幫助團隊成員提高績效。
• 確保你的團隊繼續使用DevOps IT解決方案開展工作。

　　5、與敏捷教練合作

　　我們知道敏捷是DevOps的延伸。因此，最好有一個敏捷的產品開發教練。如果您覺得有需要，請雇傭一位，因為你需要一位倡導者。你的數字化轉型是與他人共同創造愿景的基礎。你可能會達成共識，因為你并不總是有正確的答案。

　　現在，大多數人都有了采用DevOps的想法。這將通過保持系統關閉來告訴您是否錯誤。你需要理解開發的目的。一旦你實現了你的目標，讓敏捷教練去完成他們的任務。這是邁向進步的重要一步。

　　6、授權你的團隊

　　給你的團隊空間。建立信任并確保他們也信任你。明確你想要什么以及如何實現任何目標的愿景。讓你的團隊做出某些決定并根據他們的想法工作。確保你已授權你的團隊成員。

　　7、團隊技能培訓

　　提供高度集中、簡短、實用的技能培訓。培訓他們使用日常工作的工具。你的團隊必須對他們的方法感到滿意。這樣，他們才能更容易采納。

　　軟技能包括：

　　SSH

　　高級水平的Bash使用

　　GitLab （詢問他們可以為改進添加哪些功能。并告訴他們區分入門/青銅或終極/黃金）

　　Git提交的使用，我們為什么要簽署它們？

　　Open SSL

　　AWK/SED

　　8、與不確定性成為朋友

　　這是一個簡單的規則：

• 首先，你應該知道如何接受和管理失敗。
• 讓一小群開發人員或工程師了解KPI或實際情況。
• 重視他們的想法，讓他們為之努力。
• 重復這些步驟。

　　進行KPI審查，為初創公司工作，知道如何控制失敗，舉一反三并記住從失敗中學習，使其成為一種經驗，并實現里程碑。培訓你的團隊成員教你如何防止他們重蹈覆轍。

　　請記住，這與技術實施無關

　　我們知道DevOps的目的是通過精益開發原則幫助敏捷擴展和改進生產。我們也可以說這完全是關于改進的交付流程等等。在DevOps出現并實施其基本原則之前，Google提出的SRE 或站點可靠性工程就已經存在。我們可以將這種敏捷和DevOps視為SRE的一種進化機制。 DevOps是一個失敗的過程，解決問題并適應情況，然后不斷重復。

　　CD/CI pipelines和微服務容器編排等最佳實踐可幫助我們通過設計從故障中恢復過來，并且它們傾向于解決我們處理故障的速度。從定義上看，這是精益和敏捷的。

　　緊跟時代潮流是關鍵

　　充分利用所有可用資源并進行相應更新。在這個技術時代，人們必須了解他們的周圍環境并保持這種意識同時使用它來改善自己。DevOps的原則和實踐正在幫助許多公司提高和增強其適應性。許多像DevOps咨詢公司這樣的公司是一種生存方式，因為他們在各個方面都在幫助我們。

　　原文標題：8 Basic DevOps Principles and Practices

　　原文鏈接：https://readwrite.com/basic-devops-principles-and-practices/

　　譯者介紹

　　張鋒，51CTO社區編輯，長期從事技術顧問工作，專注于運維/云原生領域，精通網絡疑難故障分析，有很豐富的大型銀行運維工具建設實踐經驗。