作者 | Amit Gupta

　　譯者 | 張鋒

　　策劃 | Noe

　　多年來，公司管理員負(fù)責(zé)運(yùn)維、集成和開發(fā)——而開發(fā)人員只需要編寫代碼。在那之前——由于運(yùn)維開發(fā)兩個(gè)孤島之間幾乎沒有交流，所有專家都在項(xiàng)目上單獨(dú)工作。

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

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

　　你對DevOps了解多少？

　　DevOps代表運(yùn)維和開發(fā)，是一種旨在合并質(zhì)量保證、開發(fā)、運(yùn)維基礎(chǔ)集成和部署的實(shí)踐。這些目標(biāo)領(lǐng)域被組合成一組流程，是一致交付方法的自然延伸。

　　采用DevOps的優(yōu)勢

　　為你的業(yè)務(wù)采用DevOps有幾個(gè)優(yōu)勢。以下是采用DevOps的三個(gè)主要好處和優(yōu)勢，涵蓋了開發(fā)的文化、業(yè)務(wù)和技術(shù)方面。

• 滿足客戶需求

在DevOps IT解決方案中，需要持續(xù)更新和新功能來以高效和結(jié)構(gòu)化的方式滿足客戶需求。因此，價(jià)值交付和上市時(shí)間進(jìn)度加快。

• 質(zhì)量改進(jìn)和產(chǎn)品快速發(fā)布

在使用DevOps時(shí)，會遇到產(chǎn)品持續(xù)交付和快速發(fā)布的問題。通過允許開發(fā)人員修復(fù)bug并鼓勵(lì)盡早反饋，從而來改進(jìn)我們的服務(wù)。當(dāng)你選擇DevOps時(shí)，你將體驗(yàn)到更高的效率和更好的產(chǎn)品質(zhì)量。

• 改善工作環(huán)境

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

DevOps團(tuán)隊(duì)成員包括運(yùn)維人員和開發(fā)人員，他們共同努力幫助業(yè)務(wù)更平穩(wěn)地運(yùn)行。你需要明白DevOps不僅僅是行動(dòng)。你不需要對業(yè)務(wù)進(jìn)行任何實(shí)質(zhì)性的技術(shù)改變，因?yàn)镈evOps主要聚焦于改變?nèi)藗兊墓ぷ鞣绞?。?dāng)你堅(jiān)持鼓勵(lì)團(tuán)隊(duì)溝通的DevOps原則時(shí)，你將會獲得完全的成功。

　　你希望通過DevOps實(shí)現(xiàn)的原則

　　假設(shè)你擔(dān)心DevOps無法滿足你的期望，并思考為什么沒有達(dá)到你期望的效率、滿意度和質(zhì)量水平。也許你也在嘗試遵循別人的策略來實(shí)現(xiàn)你的目標(biāo)。

　　你將希望通過嘗試以下這些DevOps原則來構(gòu)建一個(gè)計(jì)劃。

　　為你的業(yè)務(wù)制定DevOps原則

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

　　通過不斷調(diào)整、測試和自省，可以提高運(yùn)維效率，這是開發(fā)過程的一部分。一個(gè)完美的DevOps組織可以自我修復(fù)并適應(yīng)持續(xù)的情況變化。通過遵循一些原則，你可以在沒有總部機(jī)構(gòu)的任何幫助的情況下來改善整個(gè)組織。

　　可供采用的8條基本DevOps原則和實(shí)踐

　　1、創(chuàng)建自組織系統(tǒng)

　　有一些簡單的規(guī)則，當(dāng)遵循這些規(guī)則時(shí)，就會創(chuàng)建一個(gè)自組織的系統(tǒng)。這些規(guī)則使整個(gè)團(tuán)隊(duì)受益。在DevOps中，開發(fā)團(tuán)隊(duì)必須與服務(wù)提供商進(jìn)行交互，而無需與內(nèi)部團(tuán)隊(duì)同步。簡而言之，他們可以擁有一個(gè)有組織的系統(tǒng)，而無需過多的內(nèi)部溝通。

　　2、可能對你的組織有益的規(guī)則

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

　　你需要定期檢查并允許你的團(tuán)隊(duì)創(chuàng)建自己的方式來處理和實(shí)施這些規(guī)則。重要的是：

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

　　3、與其組建團(tuán)隊(duì)，不如組建專職任務(wù)組

　　我們將DevOps視為交付開發(fā)過程的敏捷擴(kuò)展，它打破了運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)之間的隔閡。你也可以在其他組中使用DevOps 。專職任務(wù)組的工作方式是模糊開發(fā)和運(yùn)維的界限，并將它們整合為一個(gè)整體。

　　將正常開發(fā)團(tuán)隊(duì)轉(zhuǎn)變?yōu)橐粋€(gè)專職組的過程并不像聽起來那么簡單。你不能僅通過將名稱從開發(fā)團(tuán)隊(duì)更改為專職任務(wù)組來實(shí)現(xiàn)這一點(diǎn)——其是針對需要全面知識的特定運(yùn)維而設(shè)計(jì)的。

　　你可以把你的開發(fā)團(tuán)隊(duì)轉(zhuǎn)換成一個(gè)專職任務(wù)組，通過在不同的方面工作來升級你的DevOps原則和實(shí)踐。

　　4、作為多能力中心的任務(wù)

　　一項(xiàng)任務(wù)必須被視為一個(gè)多能力中心，其動(dòng)機(jī)是進(jìn)入一個(gè)項(xiàng)目，然后幫助運(yùn)維和開發(fā)團(tuán)隊(duì)加快他們的交付過程。

　　技術(shù)債務(wù)如何耗盡你的速度？

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

　　專職任務(wù)組可以幫助項(xiàng)目的方式是：

• 識別緩慢的流程——例如，現(xiàn)場團(tuán)隊(duì)工作、入職面試等。
• 將緩慢的過程自動(dòng)化，例如應(yīng)用程序測試、基礎(chǔ)設(shè)施測試、容器構(gòu)建過程、 ChatOps 、登臺的按需環(huán)境等。
• 通過新聘幫手、聚會、培訓(xùn)實(shí)驗(yàn)室、棕色包發(fā)布等來幫助團(tuán)隊(duì)成員提高績效。
• 確保你的團(tuán)隊(duì)繼續(xù)使用DevOps IT解決方案開展工作。

　　5、與敏捷教練合作

　　我們知道敏捷是DevOps的延伸。因此，最好有一個(gè)敏捷的產(chǎn)品開發(fā)教練。如果您覺得有需要，請雇傭一位，因?yàn)槟阈枰晃怀珜?dǎo)者。你的數(shù)字化轉(zhuǎn)型是與他人共同創(chuàng)造愿景的基礎(chǔ)。你可能會達(dá)成共識，因?yàn)槟悴⒉豢偸怯姓_的答案。

　　現(xiàn)在，大多數(shù)人都有了采用DevOps的想法。這將通過保持系統(tǒng)關(guān)閉來告訴您是否錯(cuò)誤。你需要理解開發(fā)的目的。一旦你實(shí)現(xiàn)了你的目標(biāo)，讓敏捷教練去完成他們的任務(wù)。這是邁向進(jìn)步的重要一步。

　　6、授權(quán)你的團(tuán)隊(duì)

　　給你的團(tuán)隊(duì)空間。建立信任并確保他們也信任你。明確你想要什么以及如何實(shí)現(xiàn)任何目標(biāo)的愿景。讓你的團(tuán)隊(duì)做出某些決定并根據(jù)他們的想法工作。確保你已授權(quán)你的團(tuán)隊(duì)成員。

　　7、團(tuán)隊(duì)技能培訓(xùn)

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

　　軟技能包括：

　　SSH

　　高級水平的Bash使用

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

　　Git提交的使用，我們?yōu)槭裁匆炇鹚鼈儯?/p>

　　Open SSL

　　AWK/SED

　　8、與不確定性成為朋友

　　這是一個(gè)簡單的規(guī)則：

• 首先，你應(yīng)該知道如何接受和管理失敗。
• 讓一小群開發(fā)人員或工程師了解KPI或?qū)嶋H情況。
• 重視他們的想法，讓他們?yōu)橹Α?/li>
• 重復(fù)這些步驟。

　　進(jìn)行KPI審查，為初創(chuàng)公司工作，知道如何控制失敗，舉一反三并記住從失敗中學(xué)習(xí)，使其成為一種經(jīng)驗(yàn)，并實(shí)現(xiàn)里程碑。培訓(xùn)你的團(tuán)隊(duì)成員教你如何防止他們重蹈覆轍。

　　請記住，這與技術(shù)實(shí)施無關(guān)

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

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

　　緊跟時(shí)代潮流是關(guān)鍵

　　充分利用所有可用資源并進(jìn)行相應(yīng)更新。在這個(gè)技術(shù)時(shí)代，人們必須了解他們的周圍環(huán)境并保持這種意識同時(shí)使用它來改善自己。DevOps的原則和實(shí)踐正在幫助許多公司提高和增強(qiáng)其適應(yīng)性。許多像DevOps咨詢公司這樣的公司是一種生存方式，因?yàn)樗麄冊诟鱾€(gè)方面都在幫助我們。

　　原文標(biāo)題：8 Basic DevOps Principles and Practices

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

　　譯者介紹

　　張鋒，51CTO社區(qū)編輯，長期從事技術(shù)顧問工作，專注于運(yùn)維/云原生領(lǐng)域，精通網(wǎng)絡(luò)疑難故障分析，有很豐富的大型銀行運(yùn)維工具建設(shè)實(shí)踐經(jīng)驗(yàn)。