這一段圍繞著一個主題：如何從組織中「人」的角度來看容器。

如果只是想讓自己的工作更順暢，容器無疑是個好用的技術；但如果想要讓容器融入組織的開發交付佈署流程中，那就需要從組織中各個角色來看容器的影響。尤其是在這樣比較嚴苛的條件之下：

• 在一個天生不追求DevOps且已存在既定分工流程的組織中使用容器
• 想要以較低的磨損來換取容器在開發維運上更高的價值發揮(如:更完整的自動化)

首先，容器可以是一個政治議題。我不確定這個議題是否會浮現，但在有既定分工流程的組織中碰到的機會較高。主管尤其需要考慮這個議題。

再者，容器是對維運端友好的技術，但前提是要能降低管理成本(借助容器平台(A))、及早參與容器樣板的訂定(S)，以及開發端要調整應用架構(C)。但維運端面臨組織規範的阻力，採用容器的難度較高。

所以多數組織還是會先在開發端使用容器，開發端可以發揮容器的價值，但容器的使用效果需要明確的量測(M)，需要誘因鼓勵人使用容器。

任何技術的導入，誘因都是很重要的。先問問容器解決了誰的問題，才知道誰會最想導入容器，若受限於團體壓力下會很難進展。

如果要跟不懂技術的高階主管說明容器的價值，可以從簽核流程來說明容器可以消除浪費(L)，調整流程順序先處理到重要的事情。

前面埋了一些英文字母，你注意到這些字母和 DevOps 之間的關係了嗎？

容器是實踐 DevOps 的重要工具之一，但更重要的是在組織文化，也就是「人」的層面。希望這幾篇文章能對大家有幫助。