Service Catalog


記錄 之前 寫下的 Service Catalog 的概念。

Service Catalog

之前與同事討論 Artifacts Management (AM)Config Management (CM)、還有 Provisioning 時,我帶出了 ITIL (IT Infrastructure Library) 裡的概念: Service Catalog (SC) 。SC 負責管理企業內產品服務的 生命週期管理異動管理 (Change Management)

依據 SC 定義出適合市場的需求,每個服務客群由不同服務組成,這個組成稱為 Service Portfolio (服務組合, SP) ,例如 SC 裡有十個產品線 (Product Line, PL),依據市場需求,例如北美市場需要由 8PL 組成,這是北美市場的 服務組合 (SP1);歐洲市場需要 10PL 組成,稱為 SP2。

另外 SC 規範要有 Versioning,換言之,每個 SP 裡的 PL 都有 Versioning 的指定。透過這樣的定義,可以讓 IT 團隊精準且可有效的利用自動化程序,搭配一開始提到的 CM 與 AM,以及 Cloud Native 相關技術,可以很快速的擴展業務市場的需求。

SC 市場上也有類似的產品,設計用來管理、維護產品線的生命週期。AWS 的 Service Catalog 就是其中之一,它包含 SC 的定義、SP 規範、然後整合了 CloudFormation 做 Provisioning … 不過這套概念不錯,但前提是都是使用 AWS 的產品,才有辦法完整的整合。

導入 Service Catalog ?

SC 通常需要組織到一定規模以上才需要,產品線、系統架構、組織規模不到,導入 SC 很容易變成一個高大上的想法,但是卻完全感覺不到好處以及意義。同時 SC 是個程序性很高的東西,換言之,定義、流程是他的主軸、核心概念。這些概念跟很多專案管理很類似,所以工具不會是重點,重點是如何定義釐清:什麼叫做一個 Product Line?這個 Product Line 的生命週期管理、異動管理。

SC 的重要目的在於多區域、是市場服務管理,本質就是『資訊管理』。透過這樣的制度,讓資訊傳遞在組織裡不會紊亂,透過這樣標準化的溝通與制度,讓各單位可以專心面對市場與業務需求。

SC 導入我個人認為的前提:

  • Artifacts Management (AM)
  • Config Management (CM)
  • Provisioning

這三個都是最基本的,沒有到一定成熟度,是不適合的。成熟度指的不是技術或者實踐,而是組織內對於這些東西的概念,有標準的訓練,讓主要的人知道 AM / CM / Provisioning 是什麼。有了這些概念,談 SC 才有具體的東西可以前進。


延伸閱讀

站內延伸

參考資料


Comments