本文由 dbaplus 社羣授權轉載。
前段時間，我一直在看東方衛視的《急診室故事》。那段時間剛好是我接手我們核心系統 IT 負責人的時候，這個角色的其中一個重要職責就是運維。
急診室和運維的相通與不同
我發現急診室和運維有很多相通的地方：
- 急診室每天都有如潮水般涌來的病人，運維每天也會收到鋪天蓋地的故障或請求；
- 急診室的醫生和牀位永遠不足，運維的人手也是捉襟見肘。
因爲請求太多，資源太少，急診室要做的第一件事就是通過觀察病人的病情，判定輕重緩急，優先處理重症患者。
但運維面對的困難是，由於業務與IT存在巨大的知識鴻溝，加上業務過程本身就很複雜，每個國家或地區又有不一樣的情況，我們也無法身處現場，所以要理解每個故障或請求本身就比較困難。
加上我們未必有能力判斷某個故障或請求對業務的真實影響，只能相信業務方的“一面之詞”。
如果只有一個業務方，這還好辦，所有請求都來自於他們，讓他們排個隊就好了。但我們是一個系統支撐亞洲和歐洲共十個國家或地區的業務，每個國家和地區都會說他們的請求，而且沒有一個業務代理人能代表他們給出一個全球的統一優先級，此時負責運維的還是我們這一小撮人，這就是我們比急診室更難的地方。
我們曾經試圖定義一些標準問題，通過讓業務回答這些問題來判定業務影響，但效果不佳。
首先，如果問題太空泛，得到的答案也不會有什麼價值。其次，如何提出更具體的問題，也是一個難題。
如果沒有清晰的價值判定，我們很容易陷入這樣的窘境：
- 一方面我們這邊非常忙碌地清理積壓的故障和請求；
- 另一方面業務看不到我們在處理他們認爲最重要的事情。
最後大家都不愉快。
通過看板原則確保處理優先級
我想到了看板方法的限制在製品原則。
我們面對的最大問題是，業務方有十個國家或地區，他們各自有自己的請求，但是他們之間是不會有相互協商的統一的優先級的。
然而，每個國家或地區內部是可以對他們自己的所有請求進行排隊的。這些國家或地區之間的業務量也不太一樣，有四個國家或地區的業務量最大，我們戲稱他們是“四大家族”，其餘的則要小得多。
於是，我們做了這樣的調整。
1、形成一對一的對接模式
在我的團隊裏，每個人負責指定的一個或多個國家或地區；在業務方，也要求每個國家或地區指定一個或兩個和我們的對接人，從而形成一對一的對接模式。那些業務方對接人就負責對他們所在國家或地區的請求進行排序。
2、對每個國家或地區限制在製品
然後我們設了一個“潛規則”——對每個國家或地區限制在製品。因爲我們人手實在有限，對於“四大家族”，我們只處理他們隊列中的頭兩個請求；對於其他國家或地區，我們只處理他們隊列中的隊列中第一個請求。
舉例說明：
這樣，便可以確保我們一直在處理每個國家或地區認爲最緊急的故障或請求。一旦上表中某個國家或地區的任何一個故障或請求處理完了，相應的IT對接人便從該國家或地區的隊列中拉入下一個優先級最高的故障或請求。
3、將處理進度透明化
在急診室，雖然對於大多數病人來說，等待時間都會很長，但因爲有排號系統，你起碼能知道自己排在哪裏，有個心理預期。因此，我們也會把上表公開給業務（通過 Confluence 與 JIRA 結合形成一個動態實時頁面），讓他們能看到我們在處理哪些故障和請求。
當然，重大的故障，需要我們所有人停下手頭工作全情投入的，可以打破這個“潛規則”，被優先處理。
通過這個手段，我們解決了不同國家或地區優先級無法統一的問題，確保我們一直在處理每個國家或地區認爲最緊急的故障或請求。
重要事情沒人管？
借用 Scrum 時間盒理念顯神功
作爲 IT 系統負責人，我們需要應對的事務有很多，既有緊急的事務，也很多重要非緊急的事務。如果不進行有效管理，我們每天的時間都會被緊急的事務全部佔據，沒有時間進行持續改進，陷入只有“苟且”，沒有“詩和遠方”的窘境。
我們要應對的事務大致可以分爲以下這些類別：
- 日常運維（包括生產環境故障處理和業務請求）；
- 各種開發請求；
- 故障數據分析；
- 故障處理完畢後的跟進（包括如何避免重現與 Bug 的修復）；
- 遺留問題的跟蹤與修復；
- 實現部署流水線，實現自動化部署；
- 增強自動化監控；
- OS 補丁與升級；
- 災備演練；
- 數據備份與恢復演練
- ……
我們在進行 DevOps 轉型後，開發運維一體化，已經不再像過去那樣有一線、二線、三線的運維體系。
在過去，一線運維把緊急問題處理完，業務影響消除後，就可以交由二線、三線團隊負責後續跟進。這一點很像急診室，急診室對重症病人進行簡單處理，待病人生命體徵穩定後，便會交由住院部相應科室進行後續處理。
現在我們和急診室不一樣的是，作爲 IT 系統負責人，除了處理一線的故障和運維請求外，系統的一切事物也都需要處理，包括緊急的和重要非緊急的。如何在資源短缺的情況下平衡和處理好所有事物，對我們是極大的挑戰。
在上面羅列的事務中，除了頭兩項，其餘的都是重要非緊急的事務。面對着每天撲面而來的各種故障和請求，我們很容易陷入被動。
那麼如何才能讓團隊在應對緊急事務之外，還能持續地關注重要非緊急事務，實現持續改進呢？
經過我們的實踐，借用 Scrum 的時間盒理念，通過固定週期的循環例會，可以確保我們對重要的事務保持關注與維持進度。
1、利用每日站會
一般來說，每日站會都是用來跟進日常工作的。
在我的另一篇文章《我家的供應商系統又多又舊，能實現持續交付嗎？》中提到，我們有了搭建部署流水線實現自動化部署，從而解放我們在部署上的人力和實現持續交付的思路。
但是，由於日常的交付和維護工作佔用了我們幾乎全部的工作時間，這類重要而不緊急的事情通常都會無疾而終。爲了避免這種情況，我們利用每日站會來討論落地細節和跟蹤進度。
我們把站會分爲兩類：一、三、五討論日常工作；二、四討論這個流水線的實施。
這樣我們便可確保每天都有進度，並在一個多月的時間內實現了預定目標。
當這個想法實現了以後，我們繼續利用週二、四的例會討論和跟進其他的重要改進點。
2、利用每週例會
每週，我們都會有固定的回顧會議，分別進行故障數據分析、討論故障處理完畢後的跟進以及遺留問題的跟蹤與修復。這樣確保我們能持續關注這些重要而不緊急的事務，實現持續改進。
目前，我們的每週固定會議有：
- 每週故障分析會議——回顧本週收到的故障與業務請求，以及後續跟進情況，趨勢分析；
- 每週遺留問題跟蹤——作爲全球金融機構，我們有嚴格的風險管控，包括針對IT系統的，每一個潛在的安全風險問題必須在期限內修復，確實無法在短期修復的，也要遵照嚴格程序獲取延期豁免。這些都需要持續跟蹤，避免過期；
- 每週回顧會議——針對日常運維發現的其他潛在問題和可改進點進行具體討論，落實具體改進方案，並進行追蹤。
所有的事情都和時間與資源分配有關，而時間和資源，永遠是緊缺的。通過固定週期的持續關注，能夠確保我們日常不留意的重要改進能夠持續進行，而這個週期也不能過長，超過兩週就會陷入無疾而終的狀態。
總結
運維和急診室一樣，資源永遠是短缺的。
通過看板的限制在製品原則，確保我們聚焦在各業務方最緊急的故障和請求上。
借用 Scrum 的時間盒理念，通過固定週期的循環例會，確保我們能對重要非緊急的事務保持關注，實現持續改進。
番外篇
利用 Sprint 理念進行個人精力管理
我們經常說時間管理很重要，但其實另一句話更有道理：要管理精力，而不是時間。時間是無法管理的，每個人的時間都有固定的上限，但精力關乎單位時間的效率。
一天的工作時間，少說都有 7-8 個小時，如果你一直坐在工位上持續地工作，很快你就會筋疲力盡，很難再有飽滿的精力應對接下來的工作。
在 Scrum 裏，每個迭代都叫 Sprint，而 Sprint 就是“衝刺”的意思。因此，通過 Scrum 的方式做一個產品或項目就是一次又一次衝刺的過程。
既然長時間持續工作不可持續，那麼把一天的工作拆成一個又一個 Sprint，每個 Sprint 間有個小憩，是否是更有效的工作方式呢？
相信有些朋友也聽說過番茄工作法，也就是每工作 25 分鐘，小憩 5 分鐘，而在那工作的 25 分鐘裏，集中精力完成一件事情。
但是我們知道，很多時候我們很難把所有工作切成 25 分鐘爲一個單位。因此，我們可以把它改良一下：以一個小的工作目標或任務作爲一個 Sprint，在 Sprint 中，集中精力只完成這個小目標或任務，然後就徹底放下工作，小憩幾分鐘，回血一下，再開始下一個 Sprint，完成另一個小目標或任務。每個 Sprint 的時間不應該超過一個小時。
通過這種方式，勞逸結合，同樣的工作時間，精力和效率則可能完全不一樣。這也是我們可以從 Scrum 中借鑑的理念。
作者介紹：
劉華（Kenneth），就職於世界500強銀行，負責基金服務業務軟件開發與交付，DevOps團隊負責人。敏捷、精益、DevOps領域專家，精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧。著有《獵豹行動：硝煙中的敏捷轉型之旅》一書。