DevOps的基礎知識-Part 1

本文將討論一些DevOps的基本知識與概念，包括實行Full stack的DevOps的效益: 文化實踐與自動化。目的是減少企業在IT實踐中的終極目標，哪就是:

• 增加品質
• 加快功能上線速度
• 成本

DevOps是甚麼東西?

DevOps是從ITIL、Lean(精實)與Agile(敏捷)所產生的IT最佳實踐進化而來的。DevOps鼓勵一種"協助與學習"的文化以協助IT單位能夠交付"又好、又快、又便宜"的商業價值(理想中的)。

DevOps是一場”運動、哲學或意識形態”文化變革，它鼓勵IT單位內開發與維運團隊互相協作。所以實行DevOps勢必會改變組織的文化，所以如果您所處的企業是”Command and Control”的企業文化，請謹慎評估使用DevOps。

既然DevOps鼓勵開發與維運團隊之間的"協作與溝通"，哪是勢必需要借助一些"自動化"方式與工具來達成此一目的。因為”協作與溝通”是需要花成本的。DevOps聚焦於文化、自動化與新的實踐來解決不同組織的IT挑戰。

傳統上，開發團隊需要不斷的發布/修正其系統的功能，所以"快速的變更"對開發團隊來說是常態。然而對維運團隊來說則是相反，他們希望系統/服務是可靠且穩定的，最好都不要有異動。所以這兩個團隊的基本目標是相反的。DevOps做的就是在這兩者中取的平衡。另外，即使在高度監管的環境，DevOps還是一種可行的實踐。

DevOps不是甚麼東西?

• DevOps不是一種專屬的工作職稱或團隊
• DevOps不專屬於新創公司或開發團隊(因為它是一場原則、實踐與價值的運動)
• DevOps不是要消滅維運團隊(因為它是鼓勵兩個團隊間的協作)
• DevOps不等於用一堆自動化的工具(我們的現行教育教導我們解決事情要用不同的工具解決，但卻變成了知其然而不知其所以然)

整個DevOps的Full Stack實踐應該是以下這樣的

DevOps的商業價值

所謂的商業價值是企業所提供的服務滿足或超越顧客期望的程度。 該服務以客戶為核心。對客戶來說，該企業存在的價值是企業能達成它所承諾的事物與保持在哪個目標之上。所以企業的價值來自以下三種維度:

第一個維度是服務品質:
所謂的服務是指客戶指定的功能性要求(包括非功能性的)與保固。

第二個維度是成本:
企業運作需要成本，這個維度是指客戶會為了這項服務付出多少代價。從客戶的角度來說，客戶付費用會收到多少價值。服務成本是在客戶是可負擔與企業有獲利的雙重限制產生的數字。

第三個維度是速度:
在當今快速變動的商業世界，客戶的需求隨時都在變。若無法及時跟上客戶的需求，哪麼就是有高品質、低成本的服務也沒有用。

而這三個維度企業必須取得某種的平衡，根據自己所處的產業與風險偏好。甚至因為企業內各種不同的產品線與客戶群也會產生不同的維度取捨。也就是說"又快、又好、又便宜"這三種特徵不可能同時達成。

狩野模型/Kano model

1984年，狩野紀昭(Noriaki Kano)教授發展出了一種客戶滿意度模型，稱為狩野模型。這是協助企業如何找出「產品/功能/服務」優化的方向。

狩野分析認為，要改善客戶滿意度「功能越多越好」這種不斷增加新功能的導向，是一種無效的策略。但是企業可以透過調查與分析從中發掘哪些因素與特徵是客戶真正重視的，並決定各項功能的權重。將每個功能產品屬性(如：功能、價格、效益)歸類的三個價值屬性當中，便可以看出客戶的滿意度來自哪裡。但是客戶的需求隨時都在改變，所以這些屬性都是動態而不是靜態的。

• 基本屬性(必須有):
  最基本的功能要求。這一類屬性通常不具商業價值，這只屬於進入某種市場的門檻。
• 效用屬性(想要的):
  功能具競爭力的，但不是基本需求。這會增加客戶滿意度;相反的，少了該屬性客戶就部會滿意(跳槽去別家)。這與企業提供的服務/產品品質有關。
• 基礎屬性(驚艷的):
  能與市場做出區別的。因為這大大超出了客戶的期望，進而大幅增加滿意度。然而要做到這樣的程度就必須持續性的創新、優化與學習，才能站穩市場領導者的角色。

今天，持續不斷的創新已變成了企業的基本功能，因為”adapt or die”。而IT單位已經從企業的傳統支援角色轉變為產生商業價值的角色。

變革的外在驅動力

根據ITIL的分析外部環境的PESTLE方法和分析組織本身的服務管理的四個維度(詳請請參閱本部落格 — 企業的戰略旅程 — 我們現在在哪?一文)，企業的變革有一項會來自外部所驅動。對於企業來說，採用DevOps的外部因素是:

1. 新興的雲端技術 — 不斷變動的商業環境造就了雲端技術的產生，雲端(特別是公有雲)提供了服務的高可用度、低運算與儲存成本。這讓企業運作IT基礎設施的成本從CapEx轉變為OpEx。
2. 全球供應 — 新興技術、網際網路與全球化得以讓企業將其服務擴展至全球各地，但同時企業需要面對的競爭也是世界級的壓力。
3. 勞動力自動化 — 企業開始頃向將重複性的工作交給電腦。勞動力自動化迫使企業開始思考傳統的IT運作是否合於今日的商業競爭環境。因為自動化有助於增加品質、減少成本與加快速度的特性。但是要做到具"效能與效益"的自動化需要組織的文化與實踐的支持。
4. 數位式的破壞性競爭 — 數位式破壞性競爭讓一些老牌企業感受威脅，尤其這些企業長久以來的模式一直不變，無法更上客戶的需求。並且讓一些新興企業的進入門檻降低。

各自為政

在我們檢視企業為何會各自山頭並各自為政，進而造就穀倉效應的狀況下來回顧企業進行DevOps運動的目標:

• 快速進入一個市場
• 增加生產力
• 讓IT與內部團隊與利害關係人能更好的協作與整合
• 作業內容是可見與透明的
• 提升反應能力
• 提升彈性與敏捷度
• 提升代碼與佈署的品質

DevOps尋求的是數位轉型。而數位轉型是一場深刻的變革，涵蓋企業內所有的活動、流程、技能、領導力和文化態度。數位轉型使企業能夠利用數位技術帶來的變革和機遇。數位轉型還使企業能夠以戰略和優先的方式受益於其不斷加速的商業世界的衝擊，使技術成為戰略優勢，而不是需要克服的障礙或挑戰。

哪麼我們需要自問，為何我們組織內的IT無法交付其商業價值呢?而為什麼各自為政造就了穀倉效應呢?這一切其實跟企業的組織架構有關，是組織架構造就了以上的這些問題。

18世紀，國富論的作者 — 亞當.史密斯相信並教導我們使用技術不純熟的勞動力來製造高品質的產品。可以這麼做是因為將整個產品製造流程拆解成足夠可以自動化作業的足夠小的作業內容，企業的管理層被這一學說所吸引。隨後而來的福特汽車生產學說與泰勒主義又加深了此一論述，總稱"科學化管理(也可以稱為機械式管理)"。這一類的學說認為員工只要帶著雙手來上班而不需要帶著腦袋來即可。

而因為此種論述造成了每一個人只負責自己一小部分的作業，因為這才跟該員工的KPI有關，其他都不關他的事，也沒有協作的意圖，而這樣"穀倉效應"就出現了。

穀倉效應造成了組織內所有的人缺乏系統性思考，也就是見樹不見林。穀倉效應讓我們認知我們在組織的相對位置(也就是R&R)，但它們會蒙蔽我們檢視在大型體系（在地圖上的位置），從而最終到達我們需要到達的位置。系統性思考意味著認知到一個單一業務功能是整個大型系體系中相互關聯、相互依賴的部分。所有組織內的人應該需要有"Think globally, act locally"的思維，

穀倉效應同時也對IT單位內製造了混亂之牆。混亂之牆是指開發和維運無法從根本上理解對方為何這樣做或他們的需求是什麼，從而降低了他們共同交付商業價值的能力。開發要的是敏捷、速度與創新，而維運要的是成熟度、風險管理與合規。

局部優化與流程複雜性的加劇

如果沒有系統性的思考而只有穀倉效應的企業，哪麼企業中的每一個人或團隊、單位都會它帶著它本身的世界觀來優化自己的作業流程。自我保護和部落主義的穀倉效應將開發和維運分開，也加劇了 IT 在交付價值時面臨的下一個挑戰 — — 複雜且低效的流程和實踐。這就像一個工廠中的生產線機台，每一個機台只想著優化自己的效能，沒有取考量從頭尾的生產作業。這一類的概念可以參閱由高德拉特所寫的"目標"這一本商業小說書籍。

而穀倉效應也造成官僚風氣的產生，官僚風氣有其優點，但也有其缺點。他們分別是:

優點:

• 將勞動立劃分為有職責範圍和專業領域
• 明確的階級制度和上級單位
• 明確的規範和規則
• 基於技能和資格的工作分配
• 按資歷晉升
• 對每個辦公室任職者的監督與治理

缺點:

• 成為控制的鐵籠
• 作為對流程失效的反應，越來越多的政策與規則隨著時間的推移而增加
• 很難改變或逆轉
• 分工促進穀倉效應的行為與文化
• 階層結構可能意味著較長的批准時間（例如，必須上下指揮鏈才能完成任務）
• 偏向穀倉效應與整體組織目標的決策偏差

局部優化但未整合或無法協作的穀倉的最終結果是資源(時間、精力與金錢)浪費。 企業應該評估浪費的資源，以及流程中妨礙和不必要的面向。 檢視由於過於複雜、官僚主義和低效的流程而造成浪費的作業，這些浪費成為 IT 交付業務價值的障礙。例如:

• 重複發生的事故(Incidents) —
  不找出主要問題，而浪費資源去處理同樣的事故
• IT資產 —
  這個可以靠自動化解決
• 多重的服務台(Service Desk) —
  沒有一個統一集中的窗口分類進行事故與問題處裡。各搞各的重複一堆的流程與工具
• 過期的供應商合約
• 事故單處理
• 多種不同的變更管理流程

以上的這些種種問題代表了企業在當今商業世界需要一個革命性變革。傳統上企業將IT的80%資源放在BAU(Business as usual)只有20%放在轉型與成長。但事實上應該反過來，80%的資源投入轉型與成長，20%資源在BAU。

IT的死亡螺旋

穀倉效應帶來了IT的死亡螺旋(如下圖)，而死亡螺旋產生的IT的技術債(technical debt)。

所謂的技術債是許多複雜的臨時性方案和重工(rework)的累積，當持續實施簡單的解決方案而不是最佳解決方案時，就會發生技術債。 工作流程變慢會帶來越來越多的挑戰，技術債也會不斷累積。

如果 IT 無法交付價值會怎麼樣？隨著內部和外部對 IT 服務的需求增加，由於前面描述的原因，IT 面臨自身能力的相應下降。缺乏系統性思考的穀倉文化會導致局部最佳化。 官僚主義增加了問題的複雜性，導致流程和實踐設計不當，造成大量浪費。

因此，IT 必須花費更多的時間和精力來維持業務運行，從而使他們的創新時間有限。 隨著時間的推移，他們使用的系統和工具會因技術債而不堪負荷。所有這些問題最終都會相互影響，形成惡性循環，並不斷惡化，導致 IT 無法交付他們所要求的價值。

而DevOps 尋求解決所有這些問題。這不僅僅是組織內利害關係人和管理層的問題。這個問題不僅僅是因為內外部利害關係人需求太多或沒有向 IT 單位提供足夠的支援來完成要求他們完成的任務。

這是一個文化、實踐和技術問題。這是我們必須解決的價值差距。對於許多 IT 部門來說，追求 DevOps 的決定可能會影響他們的生存。

如果不解決這個問題，領導階層就會做出他們不喜歡的決定。 這已經開始在許多組織中發生。 雲端技術和全球競爭的發展推動了客戶、合作夥伴和利害關係人需求的增加，這也意味著 IT 領域的競爭日益激烈。 如果組織決定尋求替代 IT 選項，則可以有更多選擇。

使用「影子 IT」投資有一個明顯的趨勢，即業務單位直接從外部市場提供 IT 服務或為自己的 IT 能力提供資金，因為企業內部的人認為 IT 服務品質差、速度慢、成本高。

「影子 IT」只是「內部 IT 越來越不重要」的另一種說法。 如果這種情況持續足夠長的時間，而企業失去了根據預期收入可以取得的資金，那麼就只有一種可能的財務結果。

在更微觀的層面上，當涉及 DevOps 需要解決的問題時，IT 的目標與大型企業的目標沒有什麼不同。 所以DevOps的IT目標應該需要:

• 快速的功能交付 —
  客戶、內部合作夥伴和利害關係人要求更快的上線時間，這意味著 IT 需要比平常更快地交付功能。
• 持續的軟體交付 —
  IT 的最終目標是提供他們所需的價值。
• 協作與溝通的增加 —
  內部合作夥伴和利害關係人需要與整合，這意味著 IT 需要加強內部協作和溝通
• 具生產力的團隊 —
  內部合作夥伴和利害關係人需要提高生產力，IT 可以透過生產力更高的團隊來支援這一點。
• 有更多的時間進行創新 —
  客戶、內部合作夥伴和利害關係人也需要更高的靈活性和敏捷性，如果 IT 有更多時間進行創新，就可以提供這些靈活性和敏捷性。
• 快速且徹底的問題解決，而不是workaround方案
  內部合作夥伴和利害關係人需要提高 IT 的回應能力，這意味著 IT 需要一種能夠更快解決問題的方法。
• 降低管理複雜性 —
  內部合作夥伴和利害關係人要求更好的可見性和透明度，IT 可以透過降低管理複雜性的流程來實現這一點。

DevOps協助IT找到一個平衡

DevOps 幫助 IT 找到平衡。 還記得開發和維運之間的混亂之牆 — 開發和維運遇到相反的優先事項的地方嗎？

DevOps 的出現是為了幫助 IT 找到平衡點，並圍繞交付業務價值的單一焦點實現看似不可能的整合目標。 當今的企業越來越需要同時保持穩定性和變革，同時保持前所未有的品質水準。