Db2與CICS現代化DevOps實踐

隨著數位轉型浪潮席捲全球，企業紛紛尋求提升 IT 系統的敏捷性和效率。對於許多仍然依賴大型主機系統的企業而言，如何在 Db2 和 CICS 等核心系統中匯入 DevOps 實踐成為了一項關鍵挑戰。本文將探討如何在大型主機環境下實踐 DevOps，涵蓋自動化工具、敏捷方法論、Scrum 和 Kanban 等關鍵技術，並以程式碼範例說明 CICS 交易處理流程與 DevOps 的結合，最終目標是提升大型主機系統的開發效率、可靠性和交付速度。

Db2生態系統

與IMS類別似，Db2擁有廣泛的生態系統，包括各種會議、使用者群組和教育計畫。IBM也開發了多種工具來提高生產力，例如：

• IBM Data Server Manager：一套管理工具，簡化Db2資料函式庫的設定、使用、監控和管理。
• IBM Db2 Advanced Recovery Feature：在Db2強大的資料備份和還原功能基礎上，提供額外的還原能力。
• IBM Data Studio：針對Db2 for z/OS、Db2 for i、IBM Informix和Db2 Big SQL的開放原始碼整合環境。
• IBM Lift：一種自助服務系統，用於將私有本地資料來源的資料透過網際網路傳輸。
• IBM Db2 Augmented Data Explorer：一個根據網頁的平台，可連線到本地或雲端的Db2資料函式庫。

例如，Nordea Bank就使用IBM Data Server Manager來管理其資料函式庫系統。作為歐洲最大的金融服務機構之一，Nordea Bank藉助這些工具提升了其資料管理的效率和可靠性。

CICS 事務管理系統的發展與應用

CICS（Customer Information Control System）是IBM於1966年開始開發，並於1969年推出的事務管理系統。該系統的開發靈感來自於IBM為美國航空公司開發的Sabre系統，主要用於處理即時交易，解決了批次處理的限制。

CICS 的早期發展與演變

最初，CICS主要針對公用事業領域。然而，由於IMS（Information Management System）獲得更多關注，CICS幾乎被取消。但由於公司內部擁護者的努力，CICS得以繼續開發，最終成為最成功的軟體系統之一。

CICS 的技術特點與優勢

CICS支援多種平台，如MVS（Multiple Virtual Storage）、ESA（Enterprise Systems Architecture）、Unix、OS/390和z/OS。開發人員可以使用COBOL、REXX、C、C++、Java和PL/I等語言來構建應用程式。

CICS類別似於子系統，管理複雜任務、控制使用者存取和許可權、管理記憶體分配，並提供對資料的同時存取。z/OS仍然是大型主機系統中的最終決策點。

CICS 的運作機制

CICS使用多區域操作（MROs）來管理多個例項。每個CICS例項都在獨立的地址空間中執行，以確保高效的事務處理。

CICS 的交易處理流程

在CICS中，**交易（Transaction）**是指來自終端機、網頁或智慧手機的單一請求。每個交易都有一個最長四個字元的交易識別符號（trans-id），並在程式控制表（PCT）中定義。

• 任務（Task）：每當CICS接收到請求時，會啟動一個或多個任務來執行交易。
• 工作單元或還原單元（Unit of Work or Unit of Recovery）：這是一個可還原的完整操作，CICS可以提交或在發生重大問題時復原該操作。

CICS 程式設計的最佳實踐

由於CICS需要處理大量的交易，使用傳統的對話式程式設計會導致效率低下。因此，**偽對話式程式設計（pseudo-conversational programming）**成為了更佳的選擇。在這種模式下，當程式啟動時，會傳送一個畫面，但不會等待使用者輸入，而是直接結束。當使用者輸入資訊時，程式會重新啟動，從而減少主機資源的閒置時間。

使用基本對映支援（BMS）設計使用者介面

開發CICS應用程式時，需要使用**基本對映支援（BMS）**來設計使用者輸入和輸出的畫面。BMS根據組合語言，透過定義不同的地圖（map）來建立畫面。編譯後，BMS會生成物理地圖集（physical mapset）和符號地圖集（symbolic mapset），前者用於繪製畫面，後者則作為COBOL程式的一部分。

#### 內容解密：
此段COBOL程式碼展示瞭如何使用BMS來定義畫面地圖。
- `DFHMSD`巨集定義了一個地圖集。
- `DFHMDI`巨集定義了地圖的佈局。
- `DFHMDF`巨集定義了畫面上的欄位。
此程式碼的作用是建立一個使用者輸入畫面，用於接收交易請求。

CICS 的應使用案例項與優勢

許多大型企業，如銀行和保險公司，依賴CICS來處理大量的交易。CICS能夠提供高效、可靠的事務處理能力，並且具備高度的可擴充套件性。

DevOps：大架構下的現代化變革

DevOps 是結合開發（Developers）與維運（Operations）的實踐，旨在打破開發團隊與維運團隊之間的隔閡，提升軟體開發的效率、品質並減少錯誤。傳統上，這兩個團隊往往各自為政，導致軟體開發流程緩慢且容易出錯。因此，DevOps 的目標是促進團隊間的溝通、透明度、協作和敏捷性。

DevOps 的挑戰與演進

儘管 DevOps 帶來了諸多好處，但其實施過程通常需要較長時間，並可能面臨文化上的阻力，尤其是在依賴大型主機系統的大型組織中。不過，隨著時間的推移，DevOps 已成為一種日益增長的趨勢，並展現出卓越的效果。

如同其他技術領域一樣，DevOps 在過去十年中經歷了顯著的演變。這種動態變化是技術領域的典型特徵，DevOps 的實踐是一段持續的旅程。

DevOps 的核心概念與工具

在本章中，我們將探討 DevOps 的主要概念及其不同實踐方法。同時，我們也將介紹各種自動化工具，這些工具能夠有效地支援 DevOps 流程的實施。

自動化工具與實踐

DevOps 的實踐離不開自動化工具的支援。這些工具涵蓋了從程式碼構建、測試到佈署的整個流程，能夠顯著提升開發效率並減少人為錯誤。

為何 DevOps 在大型主機開發中至關重要

對於大型主機開發行業而言，DevOps 或許是最大的趨勢之一。傳統的開發方式已經難以滿足現代企業快速發展的需求，尤其是在與靈活的新創公司競爭時。因此，採用 DevOps 成為許多企業提升競爭力的關鍵。

CICS 與 DevOps 的結合

在前一章中，我們探討了 CICS（一種用於管理交易的大型主機系統）。CICS 允許企業以高效的方式處理大量交易，而將 CICS 與 DevOps 相結合，則可以進一步提升交易的處理效率和系統的穩定性。

程式碼示例：CICS 交易處理

EXEC CICS SEND
    MAP ('INVMAP01')
    MAPSET ('INVMAPS2')
    FROM (INVMAP02)
END-EXEC.

內容解密：

這段程式碼展示瞭如何使用 CICS 將一個名為 INVMAP01 的畫面從 INVMAPS2 地圖集中傳送到使用者終端。其中，INVMAP02 包含了要顯示的資料。這種方式能夠實作高效的交易處理和使用者互動。

EXEC CICS RECEIVE
    MAP ('INVMAP01')
    MAPSET ('INVMAPS2')
    INTO (INVMAP02)
END-EXEC.

內容解密：

這段程式碼則演示瞭如何接收使用者輸入的資料。當使用者在終端上輸入資訊後，CICS 將資料接收到 INVMAP02 中，以便後續處理。這種互動方式是 CICS 系統中的重要組成部分，能夠實作實時的交易處理。

隨著 DevOps 的不斷發展和成熟，越來越多的企業將採用這種方法來提升軟體開發和維運的效率。對於依賴大型主機系統的企業而言，將 DevOps 與現有的系統（如 CICS）相結合，將能夠更好地應對未來挑戰並保持競爭力。

DevOps 的優勢與軟體開發方法論

DevOps 是一種強調開發與維運協同合作的文化與實踐，能夠顯著提升軟體開發的速度、品質和客戶滿意度。以下將探討 DevOps 的優勢，並比較傳統的瀑布式開發方法與現代的敏捷開發方法。

DevOps 的優勢

1. 速度與品質：DevOps 能夠在快速開發的同時保持高品質。企業如 Amazon 和 Google 已經證明瞭這一點。
2. 創新：DevOps 有助於打破大型組織中的官僚流程，促進創新。
3. 提高客戶滿意度：透過持續的反饋迴圈，DevOps 能夠改善客戶體驗。
4. 減少非計畫性工作：DevOps 能夠減少非計畫性工作，提高工作效率。
5. 提高生產力：DevOps 有助於減少開發人員的閒置時間，提高生產力。
6. 降低成本：透過自動化，DevOps 能夠降低軟體釋出成本，並減少 Bug 修復的時間。

例如，Liberty Mutual Insurance 在實施 DevOps 後，佈署程式碼的速度提高了 200 倍，穩定性也得到了提升。

瀑布式開發方法

瀑布式開發方法是一種線性的軟體開發方法，各階段按順序進行，不允許重疊。該方法的階段包括：

1. 構思：專案的想法階段，團隊進行頭腦風暴。
2. 啟動：評估專案所需的資源。
3. 需求：制定詳細的需求檔案。
4. 設計：評估 IT 基礎設施的需求。
5. 實作：開始編寫程式碼。
6. 測試與除錯：測試和修復 Bug。
7. 佈署與維護：將應用程式投入生產，並追蹤其效能。

瀑布式開發方法的優點是結構嚴謹，適合用於大型、關鍵任務的應用程式開發。然而，其缺點是缺乏彈性，一旦專案完成，很難進行重大更改。

程式碼範例：瀑布式開發方法的階段

graph LR
    A[構思] --> B[啟動]
    B --> C[需求]
    C --> D[設計]
    D --> E[實作]
    E --> F[測試與除錯]
    F --> G[佈署與維護]

內容解密：

此圖示展示了瀑布式開發方法的各個階段及其順序。從構思到佈署與維護，每個階段都是線性的，且前一階段必須完成後才能開始下一階段。這種方法雖然結構嚴謹，但缺乏彈性。

敏捷開發方法

敏捷開發方法是在 1990 年代興起的，以應對網際網路快速發展的需求。它強調靈活性、快速迭代和持續改進。與瀑布式開發方法相比，敏捷開發方法更適合用於需求變化快速的專案。

程式碼範例：敏捷開發方法的迭代

def agile_development():
    requirements = gather_requirements()
    while True:
        design = create_design(requirements)
        implementation = implement_design(design)
        testing = test_implementation(implementation)
        feedback = gather_feedback(testing)
        if is_satisfied(feedback):
            break
        requirements = update_requirements(feedback)
    deploy(implementation)

內容解密：

此程式碼範例展示了敏捷開發方法的基本流程。它不斷迭代，從收集需求到佈署實作，每一步都根據反饋進行調整，直到滿足客戶需求為止。這種方法能夠快速回應變化，提高客戶滿意度。

敏捷開發方法的演進與實踐

在軟體開發的世界中，敏捷（Agile）方法已經成為主流的開發哲學。它的誕生源於對傳統開發模式的反思和對快速變化市場需求的回應。早期的新創公司在開發過程中各自發展出自己的方法，例如快速應用程式開發（RAD）、極限程式設計（XP）和動態系統開發方法（DSDM），但這些方法導致了開發過程中的碎片化。

敏捷宣言的誕生

為瞭解決這種碎片化的問題，一群著名的軟體開發者於2001年在猶他州的Snowbird聚會，共同制定了一套指導原則，這就是著名的《敏捷軟體開發宣言》。該宣言根據以下四個核心價值：

• 個人與互動勝過流程和工具
• 可用的軟體勝過詳盡的檔案
• 與客戶合作勝過契約談判
• 對變化作出回應勝過遵循計劃

敏捷方法的實踐

敏捷方法是一種開放的開發哲學，沒有固定的要求或範本。它強調根據實際情況調整開發流程，並根據客戶的反饋不斷迭代和改進。敏捷開發的過程中，優先順序別的設定非常重要。專案通常會被分解成多個功能或任務，並在短時間內（例如幾週）完成一部分，然後進行展示和評估。

產品負責人的角色

在敏捷開發中，產品負責人（Product Owner）扮演著至關重要的角色。他們需要從客戶的角度出發，制定「使用者故事」（User Stories），並確保開發團隊理解產品的需求和目標。同時，產品負責人還需要維護待辦事項清單（Backlog），根據客戶的反饋和專案的進展動態調整優先順序別。

敏捷方法的挑戰與限制

儘管敏捷方法能夠加快開發速度，但它並非完美無缺。如果過度追求速度，可能會導致品質下降或專案延遲。此外，急於增加人員可能會使專案進展更加緩慢，這種現象被稱為「神話般的人月」（Mythical Man Month）。有效的開發團隊通常規模較小，正如亞馬遜的Jeff Bezos提出的「披薩規則」：團隊成員不應超過兩個披薩能餵飽的人數。

與其他方法的結合

敏捷方法可以與其他開發方法結合使用，例如Scrum、精實（Lean）和看板（Kanban）。每種方法都有其特點和優勢，可以根據專案的需求進行選擇和調整。

Scrum的起源與實踐

Scrum的概念最早由Hirotaka Takeuchi和Ikujiro Nonaka兩位教授在1980年代中期提出。他們觀察到傳統的產品開發方式過於僵化，無法應對快速變化的市場環境。Scrum靈感來自橄欖球運動中的並列爭球（Scrum），強調團隊成員之間的緊密合作和快速迭代。

在Scrum框架下，團隊成員共同合作，從專案的開始到結束都保持緊密的互動。這種方法強調團隊的自主性和對變化的快速反應能力。

結語

總之，敏捷開發方法是一種靈活且迭代的開發哲學，它強調客戶協作、快速反應變化和持續改進。儘管它存在一些挑戰和限制，但透過與其他方法的結合和實踐，敏捷方法已經成為現代軟體開發的主流趨勢。未來，隨著技術的不斷發展和市場需求的變化，敏捷方法將繼續演進，為軟體開發帶來更多的創新和可能性。

此圖示說明瞭敏捷開發中的迭代流程，從制定使用者故事到根據客戶反饋進行調整，最終完成專案。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Db2與CICS現代化DevOps實踐

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

此圖示呈現了Scrum框架下的開發流程，包括產品待辦事項、Sprint計劃、每日站會等關鍵環節，以及如何根據Sprint回顧的結果進行調整或結束專案。

探討敏捷開發的核心價值

敏捷開發的核心價值在於其對個人與互動、可用軟體、客戶協作和對變化的快速反應的強調。這四個核心價值構成了敏捷開發哲學的基礎，引導著開發團隊在複雜多變的專案環境中前進。

程式碼品質與檔案記錄

在敏捷開發中，雖然可用的軟體被置於首位，但這並不意味著檔案記錄可以被忽略。事實上，適當的檔案記錄對於確保程式碼的可維護性和團隊成員之間的知識分享至關重要。

def calculate_area(radius):
    """
    計算圓的面積。

    引數：
    radius (float): 圓的半徑。

    傳回：
    float: 圓的面積。
    """
    return 3.14159 * (radius ** 2)

# 使用範例
radius = 5
area = calculate_area(radius)
print(f"半徑為 {radius} 的圓面積是 {area}")

內容解密：

1. calculate_area函式接受一個引數radius，代表圓的半徑。
2. 函式內部使用公式πr^2計算圓的面積，其中π近似為3.14159。
3. 函式傳回計算出的面積。
4. 在使用範例中，我們首先定義了一個半徑值5，然後呼叫calculate_area函式計算對應的圓面積，並將結果列印預出來。

隨著技術的不斷進步和市場需求的日益複雜，敏捷開發方法將繼續演進，以滿足新的挑戰和需求。未來，我們可以預見敏捷開發將與更多的新興技術和方法論相結合，例如人工智慧、機器學習和DevOps等，共同推動軟體開發領域的創新和發展。

敏捷方法論的演進與實踐

敏捷方法論（Agile Method）已經成為軟體開發領域的主流趨勢，其核心價值在於快速迭代、靈活應變以及持續交付價值。敏捷方法的發展源自對傳統軟體開發流程的反思和改進，特別是在面對快速變化的市場需求和技術環境時，傳統的瀑布式開發模式顯得過於僵化和低效。

Scrum：靈活的專案管理框架

Scrum是一種流行的敏捷框架，最初由Ken Schwaber和Jeff Sutherland在1990年代應用於軟體開發。Scrum的核心思想是透過簡化流程、增強團隊協作以及持續改進來提高專案的成功率。Scrum團隊通常規模較小，成員之間分工合作，共同負責專案的推進。

Scrum的主要組成部分

• 產品負責人（Product Owner）：負責管理產品待辦事項（Backlog），確保團隊的工作與產品目標一致。
• Scrum Master：負責維護Scrum流程，排除團隊成員在工作中的障礙，確保團隊能夠順暢地進行工作。
• 開發團隊：跨功能團隊，負責將待辦事項轉化為可交付的產品增量。

Scrum透過將專案劃分為多個短期的衝刺（Sprint），每個Sprint通常持續1至4週，使團隊能夠快速回應變化並交付價值。Sutherland在其著作《Scrum：用半額薪水，做出兩倍成果》（Scrum: The Art of Doing Twice the Work in Half the Time）中分享了許多成功的案例，其中包括FBI的系統轉型專案。該專案最初採用瀑布式開發方法，但最終失敗並浪費了超過4億美元。轉而採用Scrum後，專案不僅按時完成，而且成本降低至約4千萬美元。

Kanban：視覺化的工作流程管理

Kanban是一種源自日本豐田生產系統的工作流程管理方法，最初用於工廠生產線的管理。Kanban在日語中意為「視覺化設計」，後來被David J. Anderson等實踐者引入軟體開發領域。Kanban透過視覺化的看板來展示工作流程，使團隊能夠清晰地瞭解專案進展並協同工作。

Kanban看板的主要組成部分

1. 視覺化符號：使用卡片或貼紙代表不同的任務或使用者故事。
2. 欄位（Columns）：代表工作的不同階段，如待辦、進行中和已完成。
3. 在製品限制（WIP Limit）：限制每個階段的任務數量，促使團隊專注於完成任務。
4. 承諾點：代表待辦事項的來源，團隊從中選擇下一個要處理的任務。
5. 交付點：代表工作的終點，通常是產品交付給客戶的階段。

Kanban工具如Trello、monday.com和Wrike等提供了豐富的功能，包括整合其他應用程式、自動化和報告功能，使團隊能夠更高效地協作和管理專案。然而，Kanban也有其侷限性，例如看板可能會變得複雜難以管理，且責任歸屬不明確。

精實軟體開發：消除浪費與提升效率

精實（Lean）軟體開發是一種源自豐田生產系統的管理方法論，強調消除浪費、提高效率和交付客戶價值。Mary和Tom Poppendieck在其2003年的著作《精實軟體開發》（Lean Software Development）中，將精實的原則應用於軟體開發。

精實軟體開發的七大原則

1. 消除浪費：去除任何不為客戶創造價值的工作，如不必要的功能、重複學習和多餘的交接。
2. 放大學習：透過短週期的迭代和使用者反饋，不斷學習和改進。
3. 盡可能延遲決策：在足夠的資訊基礎上做出決策，避免過早鎖定技術或設計方案。
4. 快速交付：專注於構建最小可行產品（MVP），然後根據使用者反饋進行迭代。
5. 授權團隊：鼓勵團隊成員參與決策，並提供必要的資源和支援。
6. 構建完整性：確保軟體系統的完整性和一致性，避免技術債務。
7. 關注整體：從整體上最佳化流程，避免區域性最佳化導致的整體效率低下。

精實軟體開發強調持續改進和客戶價值，透過消除浪費和提高效率來實作快速交付和高品質的軟體產品。