雖然平台即服務 (PaaS) 解決方案本身無法改變個人和團隊協作的方式，但它們通常可以作為組織變革的催化劑，以回應 IT 技術日益增強的靈活性。
實際上，只有當組織的角色、職責和關係發生變化時，才能最大化 PaaS 的投資回報。幸運的是，像 OpenShift Container Platform 這樣的 PaaS 解決方案足夠靈活，每個 IT 組織都可以根據所涉及的人員和流程來決定變更的速度和範圍。
在企業容器化的第一階段，首要任務是將容器平台作為新的應用程式部署系統。此時，組織將熟悉的任務與熟悉的角色綁定，以便回應開發團隊在儲存系統、部署環境等問題上的標準請求。在容器化的後續階段，它已經涉及自動化或為開發人員提供自助服務功能，以減輕系統管理員的負擔，並將開發人員的自主性和回應能力提升到更高的水平。這就是組織邁向 DevOps 的第一步。在企業容器化的最後階段，將採用更清晰、更規範的 DevOps 模型，其中許多先前的任務和工作將轉移到跨職能團隊的控制下，這些團隊不是按平台或技術分組，而是以確保應用程式或應用程式服務正常運作為目的。
在這篇文章中，我們將提供有關如何進行必要的組織變革以及隨著容器技術引入企業，傳統 IT 角色如何變化的指導。
將新工作與舊角色聯繫起來
PaaS 組織模型的基本初始形態旨在更靈活、更快速地將 IT 資源分配給應用程序，作為運行時環境。雖然這為系統管理員帶來了一些優勢，但開發人員通常無法獲得任何顯著的收益或新功能，因為在這個階段，企業完全可以不需要自動化、自助服務或對部署流程進行根本性的改進。儘管 PaaS 在此階段對開發流程的影響微乎其微，但它仍然提高了 IT 系統的敏捷性，使管理員能夠更好地回應開發人員的需求。例如，以前需要從多個資源建立開發環境，現在只需幾個資源即可。 虛擬機 建立和部署儲存磁碟區可能需要數天甚至數週時間，並且需要多位管理員的參與；而在PaaS模式下，所有操作都更加快捷，只需一位管理員即可完成。換句話說，開發團隊提交請求的方式與以往相同，但實現這些請求的工作現在將按照新的模式進行。
邁向 DevOps 組織
透過啟動 PaaS 並將 IT 營運和應用程式開發人員轉移到該 PaaS，組織可以繼續實施 DevOps 方法，其中包括以下核心原則：
- 將工作分解成小步驟儘早獲得回饋，降低風險並避免「分析癱瘓」；
- 充分實現操作自動化，以免在應用程式部署過程中產生障礙或瓶頸；
- 知識共享 – 建立信任的關鍵；
- 定期償還技術債，在每個工作週期中分配一定的時間用於系統改進。
在容器採用的第二階段，開發團隊自然而然地開始看到改進的空間，企業也轉向更規範的 DevOps 模式。傳統的工單機制如今被視為瓶頸，因此組織尋求自動化重複操作，並為開發人員提供自助服務功能。並且，給定工單中的這些開發人員功能由 IT 平台營運和應用程式交付團隊共同決定。換句話說，處理開發人員工單的系統管理員被上述兩類人員取代，他們負責定義和執行管理開發人員可以自行執行哪些操作的政策。自動化流程有助於確保合規性，並在不符合政策要求時協調行動。
過渡到迭代式開發計畫（IT 環境和營運模式會隨著時間的推移而不斷迭代變化）是企業 DevOps 成熟度規劃中的關鍵里程碑。 DevOps 的採用程度取決於每個組織對變化的容忍度以及哪些變化能夠帶來最大價值。例如，如果建立新環境或應用程式的需求並不頻繁，那麼優化這些活動就不如增強開發人員對應用程式生命週期的控制力重要。
IT 組織遷移到 OpenShift 時面臨的新挑戰
在本節中，我們將了解已遷移到 OpenShift 的組織通常使用的角色和任務，以利用技術和 PaaS 加速自動化和自助服務。
下表列出了已採用 OpenShift 的任何組織中存在的頂級任務，以及與之相關的職位和技能範例。此任務清單不應與工作分解結構或團隊組織結構圖混淆，而應理解為一組必須由負責支援 IT 環境的人員負責完成的任務，以成功實施容器平台。事實上，我們稍後將展示，採用容器技術為企業內部更成熟的 DevOps 策略創造了先決條件，這反過來又提高了團隊之間的跨職能協作程度，並降低了個人和團隊層面專業化程度過低的風險。
表 1. OpenShift 任務定義
任務
所需技能
IT基礎架構的自動化和配置
作品：
- 硬體解決方案的設計和構建
- 組織和支援初始設定的自動化
- VM 和主機所準備的設計和自動化
- 資料中心設計與實施
- 系統管理 Linux
- 自動化場景
- 儲存系統知識
- 網路設計與實施領域的知識
- 安全
安裝與管理 OpenShift 平台
作品：
- 執行叢集安裝
- 基礎設施服務管理
- 管理平台擴展
- 平台級身份驗證和授權
- 系統管理 Linux
- 網路技術知識
- 自動化腳本（Ansible）
- 儲存系統知識
- 了解容器技術和架構
- 了解 Kubernetes 和 OpenShift 架構
- 平台安全
- 監控集成
管理租用戶配置，隔離 IT 容量
作品：
- 在平台內創建用戶和團隊
- 配額的設計與管理
- RBAC的設計與實現
- 了解 Kubernetes 和 OpenShift 架構
- 了解容器技術和架構
- 自動化場景
- 對專案、配額、角色分配和調度程序有良好的了解
建構和管理基礎鏡像
作品：
- 開發修改影像的工作流程
- 根據標準開發影像
- 系統管理 Linux
- 自動化場景
- 配置應用程式和中間件的運行時元件
- 了解容器架構
- 應用程式建構框架
- 對圖像、圖像流和模板有很好的了解
設計和管理部署管道
作品：
- 傳送帶標準的設計與記錄
- 快速指南和模板的開發
- 開發人員培訓
- 原始碼管理
- 應用程式的設計和實現
- 自動化場景
- 自動化測試
- 程式碼品質測試
- 了解容器架構
- 了解不可變基礎設施
- 安全性－管理對管道階段的存取、批准工作流程等。
- 熟悉 OpenShift 範本、元件建置配置、部署設定、服務、路由、設定圖
應用和測試開發
作品：
- 應用程式編碼
- 自動化測試的開發
- 對部署流程中的測試失敗做出反應
- 回應應用程式故障
- 用戶驗收測試
- 應用程式的設計和實現
- 自動化測試
- 原始碼管理
- 應用程式監控
- 了解雲端原生應用程式架構
營運監控與應用管理
作品：
- 設計應用程式以提高效能
- 在運行時監控應用程式
- 應用程式擴充（或自動擴展）
- 管理應用程式可用性
- 請求配額和資源管理限制
- 效能和 IT 容量測試
- 設計和實現應用程式效能
- 應用性能監控
- 效能和負載測試
用戶驗收測試
作品：
- UI（設計和使用者互動）測試
- 自動化測試的開發
- 使用者介面的設計和測試
- 自動化測試模板
- 測試框架
- 應用程式設計模式
遷移到 OpenShift 後 IT 組織中出現的新角色
隨著組織模式向以 DevOps 為中心的轉變，專業化角色的數量通常會減少，而跨職能團隊和角色的數量則會增多，從而最大程度地促進協作。我們認為，使用 OpenShift 的 IT 組織中的關鍵職位清單大致如下：
- 應用營運工程師或站點可靠性工程師。以前，該職位可能被稱為應用程式伺服器管理員。
- 應用程式開發人員/軟體開發人員/軟體工程師。
- 集群/應用平台管理員。以前，這個角色可能被稱為“系統管理員”或“管理員”。 Linux-平台」。
- 發布經理/建置工程師。
RACI 角色和任務矩陣
最後，我們將對上述職位和任務進行梳理，以便大致了解在 OpenShift 平台上實施 DevOps 的組織架構。最初，以下列出的角色可能由舊有傳統組織架構的不同分支執行。但隨著時間的推移，組織架構會進行整合，並會出現新的基於應用程式的團隊，涵蓋以下列出的大部分或全部任務。
任務
角色
應用營運工程師/站點可靠性工程師
應用程式開發人員/軟體開發人員/軟體工程師
集群/應用平台管理員
軟體發布經理/組裝工程師
IT基礎架構的自動化和配置
I
I
R / A
C
安裝與管理 OpenShift 平台
C
I
R / A
C
設計和管理部署管道
C
C
I
R / A
管理租戶配置、隔離和 IT 容量
C
I
R / A
I
建構和管理基礎鏡像
R
C
R / A
C
應用和測試開發
C
R / A
I
I
營運監控與應用管理
R / A
C
C
I
用戶驗收測試
C
R
I
I
RACI矩陣符號
來源：
- 負責 – 執行者是做一切必要事情來完成任務的人。
- 負責 – 負責任 – 對正確、徹底地執行任務或取得結果負有最終責任的員工；也是唯一可以將工作委派給執行者的人。
- 請教 – 顧問通常是某個領域的專家，我們會向他們尋求建議；我們會與他們保持雙向溝通。
- 知情 – 知情者 – 隨時了解事件動態的人（有時僅在任務完成或結果取得後）；他們單方面接收資訊。
DevOps 組織中的團隊如何協作
傳統的資源取得流程通常涉及多個團隊執行的資源分配請求週期。最終，所有所需資源均已分配並由請求者確認。這些流程通常部分或完全由人工完成，需要團隊之間頻繁且多次的互動才能成功處理每個請求。
圖 1. 傳統 IT 組織
上圖展示了傳統 IT 組織中團隊之間的典型關係。在這種模式下，團隊使用或多或少正式的溝通方式（例如工單系統或電子郵件）向其他團隊要求工作。這些請求隨後被排成隊列，等待輪到自己完成。漫長的等待往往會導致團隊之間的緊張關係變得緊張，甚至加劇。由於團隊成員很少見面，通常只分享少量訊息，這種緊張關係進一步加劇。
圖 2. DevOps IT 組織
此圖展示了 DevOps 組織中的協作方式。上圖中的團隊摒棄了導致團隊各自為政的低效溝通方式，轉而採用面對面互動，從而在團隊之間建立了持續的溝通管道。這些管道培養了一種混合技能組合，幫助個人更好地理解和表達其所代表團隊的需求、挑戰和機會。團隊透過自動化自助服務入口網站相互賦能，共同完成工作，而無需像以前那樣手動處理來自他人的變更請求。由於這些管道，這些自助服務系統能夠快速適應其服務團隊的需求。為了進一步增進整個組織的理解和知識共享，團隊成員定期輪換角色，以累積與不同團隊互動的經驗，並更好地了解其所支援的 IT 系統的整體情況，從而提升其跨職能能力和價值。
總結
在本文中，我們探討了 PaaS 如何幫助組織採用 DevOps，並在過程中改變傳統的角色和任務。為此，我們列出了組織遷移到 OpenShift 時面臨的主要 IT 任務，以及完成這些任務所需的技能。我們還提供了在建立跨職能 DevOps 團隊時出現的一組核心組織角色，以及一個將新角色映射到新任務的 RACI 矩陣。最後，我們探討了 OpenShift 及其相關的 DevOps 如何改變組織的組織結構，使其從傳統的層級結構和工單系統轉變為具有更高層次面對面溝通的跨職能團隊。
來源： www.habr.com
