昨天我們談到了工程定錨的 Situation，主要的面向有沒有發現都跟維運有關？

Why?為什麼是維運作為數轉的出發點？一般來說不是就是要有新產品嗎？

以下就來分享團隊之所以這麼做的層面分析~

Task

• 為什麼要定錨, 為什麼決定什麼是現行版本, 是要解決以下兩個問題：

  • 什麼是現在？
    • 現行版本的定義跟假設是什麼？不定義清楚，你會發現一堆人都活在平行時空之中，再來就是過去多美好了，到時候光要處理這些問題，就會讓專案很難往前了。
  • 要怎麼回來？
    • 盤點找出現在的輪廓跟限制，用以上這些標準知道要怎麼回來，因為要回到異動前，實務上要處理的不是個 0 到 100，然後 100 回到 0 的過程，其實是 100 可以回到 0，50 時也可以回到 0，100 可以回到 0，也可以回到 50 的場景，因為有時候就是異動開始就沒辦法回到原點，那如果要做到這樣，要知道怎麼做，跟這些動作回到那一步的影響，來決定能不能做，跟可不可以做，跟怎麼做，怕亂做更糟，因為有異動一定會有意外，然後沒想清楚這些，你很容易就進入平行時空了，你以為回到的原點，不是真的原點。

• 大型長期專案，免不了就是個長期試錯的過程，這些準備都是讓我們有足夠的試錯空間跟彈性，要有這些原點設定，一步步推進專案。

  • 在人的方面，若是沒有定義清楚，每一次的異常或是非預期結果相關的後續處理（回到看官們幻想的所謂美好過去），就會消耗掉想要推進專案成員的精力，讓專案更難往前了，清楚的定義每一階段儲存點的定義跟假設，讓專案成員專心推進專案，而不是被外行人士扯後腿讓專案無法往前，這樣說好了，很多人的出發點都是好的，但是有些人還是不要出發好了。
  • 在事的方面，要考量這麼多標準，主要是要確保每次的異動，不會一廂情願，結果導致更多的問題，舉例來說，業務單位因為自己方便，希望有個功能直接可以存取任意使用者的資料，也要自動把資料加密的部分移除，方便他們日常作業（實際案例），若當下沒有適當溝通調整，當作業流程依此需求調整，系統照此持續發展，回頭因資安問題，要再處理這些陳年舊帳，就會產生更多非預期成本，過多這些問題，就會讓專案無法推進了，確認每一個版本的功能定義跟假設（可以支援的範圍跟限制），是讓專案持續小步快跑前進的關鍵。

• 以上的東西看起來要整理考慮的真的是錯綜複雜，那該如何開始呢，此專案是從資訊部門本身的重整開始，後續會有章節說明相關重點，這邊只是先概略說明筆者團隊採取的方式，以下會從作業面、組織調整、定錨實作三方面說明

• 作業面的重點是如何確保所有的需求到正式異動，可以被妥善管理，以批量批次的方式進行異動，這樣才有辦法跟配套的備份還原機制正確聯動，說到底，如果沒有人的管理配合，再多機制都是枉然。

• 組織調整的重點是如何確保專業跟當責可以跟上。

• 定錨實作的重點是如何確保每一個版本的功能定義跟假設（可以支援的範圍跟限制）。

Action

• 作業面
  • 流程面
    • 導入敏捷框架 (ex. Scrum、Kanban)
    • 專案管控框架（ex. Jira）
    • 知識庫管理框架 (ex. Confluence)
    • 跨部需求溝通框架（收斂溝通節點）
    • 各項工程解決方案標準（ex. MS O365、D365、Azure、GitHub、C#、PHP、Node.js、Lavarel、Python、DevOps、CI/CD ... etc）
  • 專案管理（就是報告框架）
    • 上接數位轉型委員會，下接組織高階管理團隊，長期專案沒有基本固定報告框架，會失焦，失焦的風險，不是做的事情沒人看到（因為沒看到是常態），是沒有聚焦，會有上述的問題，一堆看官（假專家）會想辦法進來搶眼球，然後專案又走鐘了，長期專案要要有基本固定報告框架，讓大家知道我們的重點在哪。
    • 此專案範例是聚焦在下面幾點：
      • 營運韌性
      • 數位轉型
      • 資安風險
      • 其他
    • 特殊專案，像是資安事件等，是以另案說明的方式，進行特案追蹤說明。
• 組織調整
  • 重新分組（開發、維運、MIS）。
    • 要開始實作就不能大鍋炒了，每一個動作都要有負責人，負責人若專業知識無法支撐起他負責的範圍，一者配合教育學習，在時限內完成提升，二者換掉。
  • 重新定義每個人的 R&R，考核標準及機制，配合流程面的調整，進行資訊部門本身的資源迭代。
    • 資源有限，800人的組織，原先只有十位員工，還大多待退中，因其過去作業模式的慣性，很難要求員工接受新事物，賦能不是單方向的，舉例說明，縱使有請新資深工程師，教原生團隊使用 Git，半年後還是極度抗拒，員工如果沒有動力，賦能也不會落地發生，原生團隊會自我學習也就不會有需要轉型專案的出現了。
    • R&R，考核標準及機制，流程面的調整，都是要引導團隊前進，若跟不上怎麼處理也是於法有據，跟傳統團隊價值觀最大的差異，通常是傳統團隊都會說我有做事呀，但是新觀念是你有價值產出嗎？這種差異不是口頭上討論會有結果的，現實狀況大部分人資也不具備可以協助溝通的能力，重新釐清 R&R，考核標準與機制，是比較明確的做法，也比較不會有法律上的爭議。
• 定錨實作 (User、Network、System、Application、Data with Time constrain)
  • 框架跟作業模式定稿後，以下的數據都會進行即時或至少定期備份，確保作業線的專案時間推進是一致的
    • 開發
      • Software Development and Management
      • 開發環境的設定，讓協作模式落地（不要服務只能從某一台開發機出來的才可以用）
        • Windows 的開發環境一致
        • Linux 的開發環境一致
      • 日常作業模式
        • 舉例，Daily Scrum
      • 專案及文件管理模式
        • 舉例，以 Jira and Confluence 為準，需求若只是在 email 的不成立，有統一事實標準。
        • 舉例，各需求沒有經正式程序核可的不成立，防止工程師私下接需求造成異常。
      • Release Management
        • 舉例，不該手動去正式環境進行手動異動。
    • 維運
      • Infrastructure and Platform Management
      • Deployment Management
      • 正式服務環境的管理
        • 微網段切分各種不同服務目的系統（AD、Web、DB ... etc）
        • 作業系統及應用程式版本收斂
        • Service Configuration management
        • Service Continuity Management
          • 從帳號、作業及應用系統環境、設定、版本管理外，數據資料應該怎麼備份、各種數據資料的備份週期應該有不同的規範，數據資料的生命週期管理，這些都要釐清，不然你怎麼問，業務團隊都只會跟你說都需要，如何在備份跟成本取得平衡是要從定義就開始的。
          • Windows environment 的管理規範
          • Linux environment 的管理規範
          • 各種 Device (ex. Router、Switch ... etc) 的管理規範
      • 從開發到正式環境的生命週期管理
        • 從開發到正式環境應該怎麼設定（ex. Development、Testing、Staging、Production ... etc）
      • 監控及異常處理程序
        • 這邊的重點是服務應該監控什麼？那些紀錄要留？稽核配套的機制？各種相關自動化程序，這些相關的東西都是服務的一部分，也是要定義清楚的，也是屬於要備份跟服務一起配套的（跟數據資料時間性要一致的概念是相通的）
    • MIS
      • 帳號盤點、權限收斂、相關監控
        • 各類型帳號使用標準及生命週期管理
        • 基礎設施及系統存取權限管理（含 VPN ... etc）
      • 使用者終端設備管理、明定支援範圍也只限支援範圍
        • 硬體資產盤點、硬體規格收斂、支援範圍收斂（基本電腦技能不行是你自己的問題，你家裡的電腦問題不要拿到公司來問）
        • 作業系統及應用軟體盤點、解決方案收斂、版本收斂、支援範圍收斂（電腦不可以裝公司允許以外的軟體，軟體支援僅限公司使用軟體）
      • 使用者場景管理（舉例如下）
        • 辦公室
        • 遠距（初期透過 VPN 遠端桌面作業環境架構、後期以雲端為中心架構 ... etc）
        • 協力單位
        • 訪客

Result

• 以上的動作都需要時間調整，所以實務上，可能需要一到兩季的時間逐步落實，在此專案的效益上，就是在後續專案推進，內部資訊部門的專業性、作業流程跟效率都獲得顯著的提升，外包商的品質也獲得顯著改善，後續遇到的資安事件也有能力進行處理，一改之前原生團隊打到哪算打，做不到也無能為力的狀況。
• 後續章節會提供幾項實例產出案例供參考。