有幸參加了高效運維社群組織在2017年2月24到26日的DevOps Master認證培訓。

在原有的印像中，認為所謂的DevOps無非是“開發”+“運維”，即運維要懂開發，能利用程式語言去實現平臺運維自動化。但通過這幾天的培訓，對DevOps有了更清晰的認識：DevOps是一種文化，是一種跨團隊(Cross-Team)的團隊協作，通過單件流(one-piece-flow)，JKK的理論，在保證業務連續性(Business Continuity) 的前提下，實現持續整合(Continuous Integration)、持續交付(Continuous Delivery)的要求，最終實現提升業務產量(Business Outcome)的目標。

在這次培訓中，印像最深刻的是“鳳凰專案(Phoenix Project)沙盤”（以下簡稱PP沙盤）。和幾位同學私底下閒聊，我們都認為這是一個“針對於企業的高階版桌遊”（據說每個人實際的參與價格要500元）。

像傳統的桌遊一樣，PP沙盤中有很多角色，由上自下的角色分佈為：

CEO、CISO

CIO、CFO、Retail Operation、Human Resources

VP of IT Operation（VP）、Application Department（AD）、IT Support（ITS）、Technology Operation（TO）、IT Test Team（ITT）、Change Management（CM）

另外在Technology Operation中還有額外的一個Lead Engineer。

每個角色的精力是有限的（DevOps的文化中，強調Work-Life balance，不提倡Overtime），也就意味著在一個週期內，只能承受一定的工作量（Workload）。而CEO會在一個週期內同時下發多個任務，而這些任務的工作量總和可能會大於這個週期內所有人可承受的工作量總和（這也非常符合現實中的情況）。

通過PP沙盤，總結了出以下最佳實踐，希望能夠帶給大家一些感悟，幫助提升IT持續交付的能力、提高業務產出。

思考一：使用視覺化看板來解決業務視角與IT視角的差異性。

業務驅動IT，是一個在現實工作中很普遍的問題。

由於種種原因（如獲客引流、提升企業形象、新功能開發等），業務部門會決定對一個專案立項與否。而此時，由於IT部門並未參與前期的專案需求討論，業務部門對於整個專案所需要消耗的人天、乃至投入的資金是不得而知的。

而與此同時，IT可能同時面對著幾十個甚至幾百個這樣的專案。由於人力資源的侷限性，IT可承受的工作量是有限的（且通常會遠遠小於業務的需求量）。因此必須進行取捨。

視覺化看板能很好的解決這個問題。

視覺化看板可以以全域性的角度去衡量每個專案在每個條線所需要的人天及專案進度。去權衡該做哪些專案，該放棄哪些專案。以達到業務產量最大化。

思考二：充分進行團隊協作，從而有效地保護瓶頸點。

Lead Engineer是PP沙盤一開始的一個瓶頸點：

1、很多工只能由Lead Engineer去完成，其他人沒有Lead Engineer的能力

2、Lead Engineer可承受的工作量是所有角色中最小的

按照瓶頸理論(Theory of Constraints,TOC)，需要提高這個短板。

而通過知識共享以及培訓，可以實現與TO、ITS團隊協作（Collaboration），形成一個資源共享池，以在一定的範圍內進行工作量的平衡。

現實中，每個團隊也會有一兩個這樣的Superstar，釋放他們的工作量，同時將他們的知識共享給其他teamplayer，會有效提供整個團隊的效率和專業水平。

思考三：指定把關人(Gatekeeper)，並對於每次變更進行記錄。

在PP沙盤中，當一個專案被確定要進行執行後，會把具體的任務分解到各個團隊中。但是由於事先沒有良好的變更記錄，導致某些任務被重複執行，浪費了工作量。

指定把關人，決定哪些做，哪些不做，並對變更操作進行記錄，可以提高變更操作的有效性和準確性。

思考四：平衡工作量，適當取捨，學會說“不”，使用單件流（one-piece-flow）模式，避免“半成品”。

在PP沙盤中，前期IT有很多瓶頸：

1、團隊知識、資源未共享，導致無法分擔彼此的工作。

2、Lead Engineer成為整個IT的最大瓶頸。

3、完成業務部門專案的工作量遠大於實際可以完成的。

這時候，VP的作用非常重要，需要平衡業務部門的壓力和實際IT團隊的工作量（而非一味接受），對於業務部門看起來“很重要”，但對於整個公司層面ROI改變不大的專案進行取捨，say no。

而IT團隊內部會使用單件流，進行持續交付，避免半成品的出現。

思考五：對工作進行合理分類。

IT的工作可以分為四大類：業務專案、IT內部專案、變更、緊急事件（issue）。

PP沙盤後期，IT團隊的可承受的工作量已經足夠大，瓶頸已經轉移到了業務層面。這時我們發現有大量的工作量閒置，開始著手進行IT內部專案（因為不牽涉到業務部門的工作量，同時可以充分利用IT的閒置工作量）。但我們忽略了“緊急事件”對我們的持續影響，以至於最終市值和股價受到了一定的影響。

因此，在這一方面，更類似於時間管理。

我們需要在不同階段，權衡時間、精力同各項工作之間的關係，以更全域性的視野制定策略，排定優先順序，進行任務分工和團隊協作。

當下可能會有短暫的損失，但從辯證的角度來看，這種損失可能是值得的，應為它會在長遠期帶來更多的收益和回報。

通過這次的培訓，對於DevOps文化有了更清晰的認識。

很高興結識來自於各行各業的夥伴。

感謝蕭幫主、汪老師、王老師的專業授課，也感謝叢琳小姐的全程支援保障。

我們是DevOps Master。

原文出處：http://www.jianshu.com/p/b70cac925b09