devops和ci
在上 一篇 文章中 ，我概述了DevOps為什麼與效率無關 ，以及在我們現在非常複雜的世界中，通過首先解決效率來解決“複雜”問題的舊方法實際上是無效或不靈活的。 實際上， 放開我們一個世紀的直覺，運用簡化派管理理論來建立高效的工作場所，可能會導緻更有效地建構複雜的系統，并具有靈活性和創新的空間。 最終， 創新推動了我們公司的前進，而沒有有效地保護我們已經擁有的東西 。 要發表意見，請讓我知道@christianposta
順便說一句，寫這篇文章的動機是将點點滴滴與我親眼目睹的東西聯系起來，并參加了一個特别預示的DevOps Internet Unicorn和我所通路的企業所見體系結構評估，分布式系統實作，雲本機應用程式，微服務，DevOps等……實際上，它們都是高度相關的……就像@littleidea在Twitter上最近釋出的推文
我的立場是CD，微服務和devop是同一現象不可分割的方面
那麼，這種“現象”是什麼？ ……讓我們嘗試将點連接配接起來。 TL; DR版本在結尾:)
是以，讓我們回到故事上來回顧一下 ：
- 我們所處的環境比以往任何時候都更加複雜
- 複雜系統的政策不能适應複雜系統
- 專注于可能适用于複雜系統但不适用于複雜系統的效率品種管理
- 為了處理複雜的系統，我們需要靈活性
- DevOps不接受Taylor等人将其神奇化的傳統還原論管理技術。 等
在1960年代處理複雜系統
我喜歡斯坦利·麥克萊斯特将軍在他的《團隊》一書中對NASA太空計劃所做的描述 。 它說明了DevOps原理的基礎，并且顯然（如您将很快看到的） 并不局限于開發人員或營運世界。 實際上，這些原則植根于系統思考 ，而這種思考要比現在大肆宣傳的DevOps運動早。
1962年9月12日，總統約翰·肯尼迪（John F. Kennedy）在賴斯大學（Rice University）的35,000人面前發表了“我們選擇登月”的演講 。 他宣布，美國将派遣人類在月球上着陸，并安全傳回，這是其他任何人都可以做到的：
Wwe将被送往月球，距離休斯頓的控制站240,000英裡，這是一枚300英尺高的巨型火箭，由新金屬合金制成，其中一些尚未被發明，能夠承受高溫并承受數倍的壓力比以往任何時候都具有更多的經驗，其精密度優于最好的手表，配備了推進，制導，控制，通訊，食物和生存所需的所有裝置……做到這一切，正确地做，并首先做在這十年結束之前，我們必須大膽。
總統說這簡直是大膽。 當時美國在太空和月球的競賽中令人尴尬地落後，而他宣稱“即使沒有發明金屬合金”，美國也将首先登上月球，這簡直令人可笑。一些。 大約四年前，蘇聯成功發射了第一顆人造衛星Sputnik 。 他們還把第一隻動物送入了太空，進行了首次月球飛越，首次進行了月球撞擊，不久之後，第一個人類進入了軌道 -第一個進入太空的人。
另一方面，美國有一些重大的失敗記錄。 1960年11月，美國國家航空航天局（NASA）進行了首次無人飛行試驗，水星-紅石一号（Mercury-Redstone I） 升空了4英寸，然後又降落下來 。 它的逃生火箭彈折斷了，飛向空中。 幾個月前，發生了類似的事情：水星飛船與Atlas火箭之間的結構不相容導緻這些努力失敗了。
然而，在肯尼迪發表演講不到7年後，尼爾·阿姆斯特朗（Neil Armstrong）登上月球，宣揚了他現在著名的話語“人類的一次巨大飛躍”……并在其他人之前做到了這一點，在肯尼迪演講之後不到7年。 另一方面，與此同時，歐洲發射器開發組織剛剛連續第五次未能完成完全相同的任務。
NASA和ELDO之間的差異與技術，專業知識，資源等無關。 差異後來歸因于組織的結構和合作方式。
NASA“系統思考”的成功
在載人航天辦公室（OMSF）項目啟動之前，NASA的組織方式似乎類似于我們今天在大公司中看到的“效率孤島”，這是受到泰勒簡化主義思想的啟發。 有些小團隊孤立地工作着自己的難題，而沒有考慮大局。 整個火箭的不可預測的振動影響了所有學科（結構工程，推進工程，電氣等），但沒有在自己的高度受控的專業環境中經曆這些力。 從未有如此多的電子裝置如此緊密地緊緊卡在一起，以至于每個元件都受到電磁幹擾，這又是他們在自己的倉庫環境中不會遇到的東西。 當他們将這些高效建立的作品放在一起時，它們将以意想不到的方式一次又一次地失敗。
NASA将通過系統管理，系統思考和解決其組織問題來克服這一問題，為20,000個承包商，200所大學，80個國家/地區管理300,000個人，并耗資190億美元。 他們不得不； 總統已經公開簽署了這項任務！
1963年，美國國家航空航天局（NASA）帶領喬治·穆勒 （ George Mueller ）上司（OMSF）項目。 Mueller最初反對，直到NASA同意重組他上司的項目後才接受。 MuellerSwift淘汰了舊的組織結構圖，并要求經理，工程師和高管（他們很樂于在自己的範圍和孤島中工作）每天互相交流并共享資訊。 這在NASA總部造成了嚴重破壞。
穆勒（Mueller）創造了一個環境，可以即時共享資訊，每天進行跨學科會議，設有實時更新資訊，測試結果等的現場中心。組織中的各個組可以即時進行交流。 它是網際網路之前的“網際網路”。 “您可以即時上下溝通”…“在組織内即時傳遞知識”一位管理者說：“它起作用并且我們如期準備就緒的原因是，我們每個人都需要在這個房間裡進行決定……到了關鍵時刻，我們可以在早上發現問題，并且通過停業就可以解決問題，配置設定資金，做出決定并使事情正常進行。”
在ELDO池塘的另一側，不同的國家生産了火箭，助推器，衛星測試車等的不同部件。他們沒有共享資訊，承包商直接向自己的國家機構報告，并且各自尋求最大限度地發揮自己的作用。經濟優勢。 多種界面故障導緻5次單獨發射失敗，法國記者讓·雅克·塞爾萬·施雷伯（Jean-Jacques Servan-Schreiber）認為，歐洲在太空競賽中的滞後不是金錢問題，而是他的《美國挑戰 》一書中的 “首先是組織方法”。
系統思考
這種方法（系統管理/思考）基于核心租戶，該租戶與還原主義思維本質上是沖突的……對于具有許多複雜互動作用的系統而言，它是複雜且未知的：
如果沒有對整個系統的基本了解，就無法了解系統的一部分。
最後，NASA建立的是整個項目所有團隊之間的“共享了解”，即使建立這種了解耗費了其他職責，并且“效率低下”。 NASA上司層了解到，當建立高度複雜甚至未知的産品時，将專家限制在筒倉中是愚蠢的。 高水準的成功取決于低水準的效率。 Wernher von Braun甚至是最熱衷于反對Mueller的方法之一的高層管理人員之一，也透露“使NASA滴答作響的真正機制是在房子的左右兩側之間不斷進行交叉饋送”。
這是否意味着我們都應該成為通才？
沒有。
專業化仍然是必不可少的，但是關鍵是要有“整體的基本了解”。 在McChrystal的書中，他将其稱為“共享意識” ，其中不同的專業團隊“對操作環境群組織有基本的整體了解”。
在吉姆·懷特赫斯特（Jim Whitehurst）的開放組織（Open Organization）中 ，他談到了點燃激情并将這種激情引導到一個共同的，共同的目的。
無論您怎麼說，我們的團隊都應該意識到共同的目标，在各個階段都看到并了解更大的願景，等等……并且為此付出的努力必将“效率低下”。
那是否意味着我們在“殺死開發人員”？
那麼， DevOps如何殺死開發人員呢？
是以，當我們談論“ DevOps”時，我們談論的是在開發人員和營運（以及其他人員）團隊之間建立“共享意識”。 “開發人員”的步驟，過程，自動化和實施實際上是在團隊之間建立“共享意識”，每個組織可能有自己的方式，這些方式是特定于該組織的上下文的。 DevOps僅僅是“自動化建構”或購買工具。 實際上，不管您為證明理由而嘗試使用什麼流行詞， 使無效的事情高效運作都是對時間的可怕利用 。
那麼我們是“殺死開發人員”嗎？
關于“殺死開發人員”的文章試圖在“ DevOps”之間劃清界限，這是對其餘跨職能職責的熟悉，然後跳轉到“全棧開發人員”的必要性。 由于作者聲稱這種全棧式開發人員思維方式源自初創企業，是以我們正在通過使他們成為通才來殺死開發人員。
不。 DevOps使開發人員更有效。
讓我們更進一步：DevOps，微服務，雲等都旨在提高組織的效率 。 這為将我們的組織視為複雜的系統而不是機器奠定了基礎。 這種方法使自己真正了解 回報 ， 失敗 ， 學習 ， 自主性和突發行為的價值 ，這對于任何複雜的系統在複雜而不僅僅是複雜的世界中展現并保持相關性至關重要。
點連接配接的靈感
我親身經曆了許多這樣的力量，并且正在尋找一種整體地表達它的好方法。 到目前為止，這些書在這方面有所幫助，我強烈推薦它們：
- 斯坦利·麥克萊斯特将軍 的團隊
- 關聯公司 戴夫·格雷 （ Dave Gray）
- Donella H Meadows 在系統中的思考
- 吉姆·懷特赫斯特 （ Jim Whitehurst） 的開放組織
第三部分？
那麼，出現并被冠以“ DevOps”之類的炫酷技術呢？ CI / CD，建構自動化等如何？ 這些都如何影響我上面概述的叙述？ 我原本打算寫兩部分，但我還有更多話要說。 請繼續關注第三部分！
翻譯自: https://www.javacodegeeks.com/2015/12/devops-myth-efficiency-part-ii.html
devops和ci