DevOps 移動
不只是為開發者提供根本存取權限!
或甚至不如此。「移動」背後的大想法不只是為開發人員提供更多繩索
限制條件管理是程序的關鍵。您可以先找出系統中任何和所有瓶頸,重新聚焦於最佳化這些資源以達到最大效果。除了這些領域以外的最佳化幾乎不值得一提—
中繼器式開發
在排定的週期上透過自動化測試、促銷和發布流程鼓勵增量變更,是取得滾球的絕佳方式,但在 SaaS/PaaS 部署中,品質控制的大部分都涉及採用 *幹線式開發.
本質上,長期的多元化公升
Surgery on a patient must result
in good outcomes (at all times) for
that patient, not just for siblings
or future generations.
CI / CD 管線
中繼器式開發是過去 20 年來成長的所有後續自動化變更控制管線基礎。
法規遵循 (開發 + 基礎建設 + 組態).
先看一些歷史觀點;這四個段落之後的打卡行。這裡的常用討論串是 Apache 幾乎總是超前了。
回到之前CFEngine.
工作流程不理想:除了從頭開始將本端修正的 FreeBSD 連接埠樹狀結構建置成可建置 (二進位) 套裝程式之外,員工在建置對生產環境所做的變更、先確認版本控制、登入目標伺服器、更新其取出,以及可能重新啟動服務時,必須行使難以強制實行的 discipline。—
現在,他們將一切都保留在公升
- 支援的 puppet 來源樹狀結構,以及使用一般上游 Ubuntu 套裝程式直接佈建 / 部署 / 設定至雲端,這是自排定之後的一些現代化 IT 作業方法公升
另一方面,在 ASF (適用於實際的 Apache 軟體 TLP 專案) 推出類似 CI 的早期創新計畫Apache Gump.
這裡是 nutshell 的重點:您的所有來源 (開發、基礎架構和組態) 皆屬於所有 Devops 人員可複查的版本控制 (不一定共用相同的儲存區域),而且是修正程式修訂版本與生產部署之間完整測試自動化管線的一部分。在 IaC/CaC 設定中,視需要測試 / 佈建 / 部署變更的藝術狀態調查,位於我的朋友和視覺上的 Paul Hammant 網站上此處.
虛擬化與容器化:a 寵物與牛隻比較.
容器系統 (例如 Docker) 是可自訂且可重新部署的虛擬化技術,通常用來支援 MicroService 架構 (MSA) 應用程式叢集架構 (例如 Kubernetes)。他們會挑出虛擬化系統離開的位置,並針對以 Linux 核心為基礎的 VM,在每次 VM 作業系統中交易無限制的支援 (完全隔離),這些 VM 可大幅提升可程式化的自訂性,以及與執行所在的父項 Linux 主機整合。此外,也可以將它們重新建立並 * 上傳 * 至中央分配服務 (例如使用者自建物件),以跨多個相依性鏈結和原始可執行檔伺服器部署進行大規模重複使用。
垂直與水平縮放
可從中央伺服器下載的可重新設定容器,可讓您難以運用基本虛擬化技術實現目標 - 並未鎖定任何單一伺服器的硬體限制,以根據需求擴展服務。換句話說,透過在主機集合之間部署相同的容器 (** 隨選 **) 進行水平調整,是基於 Docker 的 MSA 架構可立即實現的第一級功能。正如在 same 主機上部署的容器數目多於 CPU 核心數目。
衡量、策劃及控制消防工作,實際與實際
其他要辨識的重要事項之一是區別 planned 和 unplanned 在您的任何生產力追蹤評量中皆能運作,以及如何將資源配置給這些任務。** 消防 ** 的非計畫性工作金額,如果在這些任務上花費太多時間 (超過 ~20%),則計畫性工作 (企業的實際業務需求) 會被積壓。
系統中的瓶頸很少會因應非計畫性工作,因此請務必擁有足夠的額外資源來處理增加的負載和後續的未交訂單。
2020 年初,COVID-19 的其中一個主要退課課程,就 IT 而言,就醫院容量而言,至少在開發人員配置 (硬體是另一個故事) 時,有這樣的事情是 too lean。雨天的應變計劃,包括「備援」員工或跨培訓計劃,結合定期預備演練,不僅讓醫生離開,更是「極度重要」**。
取得方案
在管理層,開發和作業變更之間的全域變更管理觀點至關重要。這兩組團隊都需要注意彼此的變化。理想上是規劃詳細資訊。** 當團隊在資料導向且透明的協作工作文化中混合了開發人員和作業人員時,很可能發生這種情況 **。
將男性持份者納入創作的理念,以及有形工作產品的 ** 革命 **,不僅僅是 dev 和 ops 團隊共用伺服器工程工作的控制與責任,也具有影響力。這堂課在現代的企業世界中不斷重複,因為創造性人類表達的新領域在業務領域中形成,並且重新塑造以往業務往來的老方法。