談談 Ops（三）：事務、團隊和時間分配
作為普通的開發人員，我們會遇到對於時間分配的思考，沒有金標準，只有某些看起來也未必靠譜的“最佳實踐”。不同人眼中對於整體的時間分配也有自己的看法，這篇文章旨在探討其中的一兩種情況。
Ops 的事務型別
Ops 的事務很多很雜，首先要明確一點的就是，Ops 遠不止 oncall，遠不止線上產品維護。整個軟體工程流程中的配置、部署、環境搭建、升級、打補丁，甚至問題定位、故障排查等等，都或多或少可以算作 Ops。
記得在讀書的時候，老師給我們把日常事務劃為四個象限：緊急重要、緊急不重要、不重要但緊急，以及不重要不緊急。Ops 和一般軟體開發活動在這四個象限的分佈上來比較，更多地，會偏重於“緊急”（左側一半），並且不重要不緊急的比例尤其低。換言之，就傳統的 Ops 觀念來看，不重要不緊急的事情根本就不會有人主動去搭理——“Don’t touch my code.”，甚至，在 Ops 中重要不緊急的事情都會一拖再拖。可見，平心而論，Ops 在傳統軟體開發人員的心目中，並不具備特別高的地位。
另一個典型例子也可以反映 Ops 地位，作為績效評估，特別是 promotion（晉升）相關的績效評估，我們通常都能看到一條，或者“國際慣例”一條“產品/特性的設計開發”，也就是說，如果沒有設計開發一個複雜度足夠高的產品/特性，這樣的 promotion 提議不具備說服力。但是，相比較 Ops 方面在這裡的分量卻並不常見。換言之，如果一個工程師設計了一個複雜、高效的系統，這可能會成為 promotion 上舉足輕重的砝碼，但是如果一個工程師在 Ops 工作上兢兢業業，積極響應，極少出錯，卻不能夠成為決定性的 promotion 資料支援。
Ops 個人與 Ops 團隊
幾乎每一家公司都有 Ops 分工的討論。我的觀點是，一個健康的研發體系，絕大多數 Ops 的工作，就應該交給普通的軟體工程師來完成。
有人會有不同的看法，說我們還有單獨的 Ops 團隊協助呢。
沒錯，是這樣。可是仔細想想，即便有 Ops 團隊，假使有充分的工具與設施，他們到底還能夠幫到多少忙，我們到底還需要多少單獨的 Ops 團隊？
Ops 團隊，專門做運維的團隊，有的公司叫做維優團隊（一線團隊）。他們往往精通於運維技能，但對開發測試技能要求沒有那麼高。他們往往被要求熟諳流程，快速響應，長期待命。
前面已經說過，Ops 遠不只是維護線上產品，這裡面的大多數行為只有開發團隊才能做，且無法被替代。即便是 oncall，Ops 團隊也無法完成很多問題的追蹤修改，我見過許多 Ops 團隊只能充當人肉靶子，處理一些迴應策略已經清晰但重複率高的問題，以及過濾掉一些基礎和客戶響應類問題。
而這一類真正可以委託給 Ops 團隊做的事情，恰恰有一個共同的特點——都是簡單勞動，而且可以自動化。換言之，缺少的是充分和有效的工具。
於是就有人說了，開發人員沒有那麼多時間去建立這些工具，所以我們需要 Ops 團隊。一定程度上說，這話沒錯，但從成本等角度綜合考量，許多 Ops 團隊的引進只是類似我在前一篇 關於 Ops 的文章中介紹的流程，是一種較為簡單粗暴的解決問題的方式。長遠來說，多數情況下，投入到工具開發的成本，和讓開發人員來做 Ops 的成本，最終會小於聘用 Ops 團隊的成本。
我記得有這樣一個“段子”。說一個工程師團隊本來獨立運作，但是突然有一天來了一個糟糕的程式設計師，開始寫糟糕的程式碼，質量一塌糊塗。老闆看不下去了，給配了一個測試團隊來保證質量。可這哥們不只是程式碼質量不行，時間管理也不行啊，於是老闆給多配了一級 manager 來管理。又發現他態度不行，於是又搞了流程管理的一套來約束。程式碼上線了，不得不配了運維團隊來第一時間響應客戶抱怨，報告給別的工程師來修復他程式碼裡的問題。於是一個接著一個，隊伍就這樣壯大起來了。
這似乎有誇張的成分，但是這個樸素的道理卻很清楚。Ops 需要反哺，一般情況下，就像只有開發人員才能做好測試一樣，只有開發人員才能做好運維。除了開發人員自己做 Ops，沒有任何一種組織結構能夠提供這樣沒有回饋損耗的反哺機制，沒有任何一種方式能讓開發人員“吃自己的狗食”。另外，我想起了了對於某些團隊而言，和客戶直接溝通也是這種反哺機制最好的實踐之一。Steam 上有不少獨立遊戲，都是小團隊完成的，他們的開發人員可以直接在論壇中和客戶討論。討論的內容不只是需求，更有問題。
Ops 的時間比例
無論是否“正確”或“合理”，基於現有的這般事實，我們在評估和衡量 Ops 時間比重的時候，要積極考慮。對於絕大多數團隊來說，Ops 不應當成為團隊最大的時間投入。除了特殊的專職 Ops 的團隊，我認為普通開發團隊中 Ops 的比重應當保持在 25% 以下，即便是一些相對來說業務發展已經成熟，因而天然的運維壓力較大的團隊，這個比例也不要超過 35%。為什麼有了工具還有那麼高的 Ops 成本？因為不是所有的問題都值得做一個工具去解決，這裡一定存在一個主要基於投入產出比例的 trade-off。
如果這個比例過高，有許多負面因素會加速情況的惡化：
- 忙於救火，忙於解決歷史問題。這些問題都是具體而侷限的，為了解決這些問題很難保證方案的合理性。實際操作的時候往往都是著眼於問題本身的，只要解決了問題，合不合理很難得到足夠的約束。
- 開發人員容易疲勞，這遠不只身體的疲勞。據我所知大多數工程師還是更喜歡有節奏的、合理的特性開發，而非不可預見的各種 bug fix。前者更為系統，後者雖然帶來職業不同角度的成長，但也容易掉入侷限和缺乏規劃的境地。
- 重複勞動，特別是限定時間壓力下的重複勞動。可能有朋友想起了 oncall，其實無論是不是 oncall，天然地，從 Ops 的角度來看，重複勞動都是難以避免的。我們能通過工具、指令碼、自動化等種種途徑簡化這樣的勞動，但是既然說 Ops 比例過高，這裡幾乎就意味著這樣的途徑是明顯不足的。
- 缺少願景和規劃來吸引人才。這也是顯而易見的，一個忙於做 Ops 的團隊，其吸引力往往敵不過那些做著有趣和有影響力產品開發的團隊。這不止表現在能否吸引外部的人才，也表現在能否留住內部的人才。我見過一些 AWS 的團隊，從外面看高大上，但是內部的員工流失率卻出奇的高。
- ……
同時需要看到的是，Ops 的比例過高固然不好，要把它降到一個很低的值卻也往往很困難，這其中需要付出的代價往往得不償失。我確實也經歷過或者見到過一些 Ops 比例很低的團隊，他們有一條或多條這樣的特點：
- 這是一個做專案，而非做產品的團隊。我在這篇文章 中曾經探討過。這是第一條，也是最常見的原因。就是天生有一些團隊，把專案做起來，驗收交付出去，故事就結束了。他們就可以轉投另一個專案去了。從長遠來看這樣的團隊並不適合工程師平衡發展。
- 業務緊要程度低。有時候這就純粹是一個花瓶團隊了，也許產品已經接近廢棄了，也許沒有那麼多挑剔的使用者了。
- 當然還有一個常見原因——這是一個新團隊，在做一個新產品。樂觀地說，這不是業務緊要程度低，也不是 Ops 工作量不大，而是時候未到。
- 有人說，還有一個可能，某些團隊有專門的 Ops 團隊配合，因而 Ops 工作比較少。我覺得不是這樣的，對於一個健康的體系來說，即便有 Ops 團隊，大多數和 Ops 相關的事情，還是需要原始的工程師團隊來完成。這一點，前面已經講到過。
那麼如果發現這個比例已經過高了，需要做什麼來緩解這樣的問題呢？我聽過太多不同的說法了，畢竟這是一個太過普遍的問題。但我認為最重要的一點，是把責任明確到和交回給開發團隊。不要期望非開發團隊去解決程式碼層次的問題，工程師們請把“自己的狗食”拿回來。
對於現有 Ops 壓力過載的問題要花大量時間去分析和規劃，而不是定義數量上的目標來關閉問題。問題的分析時間往往要大過問題的解決時間。不能期望這些 Ops 的問題可以在一夜之間消失掉，這些是所謂的技術債務，長遠看解決他們往往是比各種規避方式要更節約成本，但短期內的回報卻未必，這裡的平衡需要一個穩定和自洽的團隊來把控。一個走馬燈一樣換的管理團隊不可能具備遠見。
最後也是最重要的一點，是要尊重軟體規律，堆人和追進度的結果，就是留下一堆債務，就是被迫陷入從 dev 趕工到 ops 噩夢的最常見原因。如果這樣做了，就要承擔數倍於原有時間等工程開銷的後果——
和其它軟體工程的問題一樣，Ops 沒有銀彈。