翻譯：高效DevOps的7個習慣

新的市場進入路徑）但你同時掙扎在無法找到一種語境或者框架來與團隊和同事們溝通——如何實現DevOps？如何達成目標呢？每次都是老生常談，我們要求IT界的高管們學習精益制造的語言或者 W. EdwardDeming 教導的原則。在實體工廠和21世紀的比特工廠（軟件業）之間，似乎存在一條平行線。雖然工業的指導原則是有價值的，但要想在組織的產生變化和實行起來，他們（IT）還需要另一條學習曲線。

以上，我認為將一種流行的商業框架——《高效能人士的7個習慣》應用到想要轉型DevOps文化的組織里，會是一種有效的模型。讓我們看看它是否能解決你的溝通困境。

1、積極主動

讓我們先擁抱一個IT行業不變的事實：唯一不變的就是變化。如果你20年前入行，客戶端-服務器模式剛剛進入主流。如果你10年前入行，幾乎沒人看得上iPhone，AWS只有2項服務。如果5年前入行，Linux容器仍然過渡復雜難用，大型互聯網公司也沒有開源重要的框架。無論行業里多么令人尊敬的企業，無論創造過多大價值的細分市場，過去50年（它們）發生了翻天覆地的變化，如今都是科技的天下了。商業領袖必須認識到科技——正以超越以往更快的速度——驅動著變革，而且在下一輪變革中，我們必須積極主動擁抱變化。商業需要對行為、對結果、對增長負責的改革領袖。

2.以終為始

沒有業務負責人睡醒了說，“我們有個DevOps問題”。相反，為了新功能及時上線，降低安全風險，你常常犧牲了睡眠時間，更不要說完成那些和高層或底層掛鉤的業務指標了。這就是為什么我相信“發布到生產環境的信心”是DevOps實踐的最重要指標 。問題的核心是在頭腦中以終為始考慮問題：我們能將軟件安全穩定地發布到生產環境中嗎？從那一刻起，多久考慮一次這個問題，其中哪一項正考驗著我們的現有能力（人的因素），管理部署頻率的能力（文化因素），是否有合適的工具和平臺（技術因素）。把你的時間和精力集中在可控的事情上吧。

3.要事第一

把執行力聚焦在最重要的商務要事上。盡管想象中空白文化的組織采用DevOps文化是很容易的事，現實是對多數組織來說是不能馬上實現的。它們的組織架構是為過時的商業模式和分銷策略優化的。它們有太多應用平臺，各平臺為不同產品線獨立運

營。而且它們需要將應用移動化為了適應客戶緊急需求。要事第一是指核心元素需要在商業預期成功前到位，例如快速部署軟件到生產環境。自動化 -——需要核心構建的能力是自動化實現重復性任務，既包括應用層，也包括基礎設施層。對很多企業來說，聚焦在現有系統(Linux和Windows)和基礎設施（例如帶寬、存儲、DNS上）上更有價值，其次才是新應用和服務的自動化。

● 持續集成/部署的流水線 ——就像19世紀的工廠建立起了組裝流水線一樣，驅動當代軟件業的流水線需要集成代碼倉庫、自動化測試、代碼檢查和安全分析功能。為了滿足軟件持續迭代的需要，構建起管理流水線能力和流程的一整套框

架是至關重要的。

● 交付平臺 ——一旦編譯構建完成就，就需要部署到生產環境。當今世界，客戶要求軟件迭代更頻繁（例如移動應用的周更），所以通過重復性的方式部署應用更新和規模化滿足客戶需求就十分重要。管理每日眾多應用的不同任務，是交付平臺的事。多年以來，許多公司試圖打造并維護自有的交付平臺，但當它們意識到只是快速增加了交付的能力，而非平臺的能力。一旦這些要素到位，許多IT團隊就著手開始容器化他們的新舊應用了。

4.雙贏思維

關于DevOps的討論太多集中在開發和運維團隊之間的緊張和疏離關系上了。我通常稱之為開發提交新代碼的速度與運維接受更新和確保生產環境就緒的速度之間，發生了“阻抗不匹配”。在我們把所有問題怪罪于運維太慢前，審視一下為什么我們認為開發太快了是很有必要的。從2017年度DevOps狀態報告中，我們看到Gene Kim和他的團隊度量了開發者提交代碼到版本控制軟件的速度。他們并沒有度量設計和開發過程的速度。即使采用微服務架構，開發新特性實際還需要幾周甚至數月時間。

那么團隊如何營造潛在的雙贏局面呢？這有一些建議：

對于采用自動化工具的運維團隊，開發和運維要開始使用通用的實踐和流程。

● 對于開發團隊來說，要堅持安全人員嵌入到開發流程和代碼檢查中。安全不是流程的最后一步，而是在每日的開發和測試中。

● 對兩個團隊來說，需要將自動化測試變成日常迭代的一部分。當很多公司的新產品開始采用云優先或者移動優先的策略時，他們也該擁抱“經常自動化”策略。

5. 知己解彼

大概6、7年前，幾乎每個CIO都想嘗試評估互聯網巨頭的運維效率，例如Google一人管理一千臺服務器，對于開發者和業務響應更好。很遺憾那時硅谷很難找到達到類似層次的企業樣板。Google的技術（例如Kubernets）也不是公開的。但過去幾年發生了顯著的變化，不僅Google的技術開源了，能達到同樣層次的企業樣板也多如雨后春筍。

與其把架構師派往硅谷向大師學習，向同類公司學習更有價值。這會提煉出特殊行業、專業領域和相似公司的案例經驗。這將給那些雇不起100個以上博士級工程師的公司們一個有力的回答。有時恰當的答案就在撬動一大票正在為流行的開源項目工作

的工程師們身上。

6. 協同

任何想在DevOps中取得成功的人，他們需要從一年級開始學習。例如，“”和別人合作愉快”、“分享”、“禮貌”。挑戰來自于開發和運維的組織架構和財務動機在這些基本目標上常常沒有對齊。這里有一些柯維原則奉上。如果目標是明確的產出（比如更快部署軟件到生產環境），確保組織的模型不是完成目標的首要障礙。互相滲透的理念十分重要。組織之間需要共享目標、挑戰和資源可用性。你要和不同觀點的人一起發現并解決問題。

7. 不斷更新

IT組織需要確保他們的團隊在培訓和新技術上緊跟潮流，這種話說來容易。但這事變成預算忽略的項目太司空見慣了。正確的方式是宣布技術提升的需求作為實際工作的需要，而不是考慮作為培訓（例如報門課程，拿個證書）

來源： https://blog.openshift.com/7-habits-highly-effective-devops/

DevOps

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。