工作流程與第一性原理

《科技工作講》 EP235 | 工作一堆做白工超阿雜？ 談到工作中常見的一種情況：

員工被要求執行某些流程，卻不知道這些流程為何存在。

有些人可能一直在等待審核，或是花很多時間處理看似沒有意義的程序。這一集引用的是馬斯克的工作五步演算法，討論工作上 SOP 的必要性以及常發生的問題。

不過，我對這個問題有另外一個角度的看法。

平台團隊的治理角色

以前我是負責 Infrastructure and Cloud, Operation and Platform 的工作，提供 IT 資源、AWS、K8s 等 IT 基礎設施給公司內部團隊使用，大概就是節目中提到那個設計流程的角色。這些細節，在我的書 《SRE 實踐與開發平台指南》 有詳細介紹。

從管理平台的角度來看，我們是治理單位，負責制定規則、執行辦法、落地，有點像政府機關。但矛盾點在於，我們本身不是生產單位，在公司的能見度與話語權比產品團隊低。這是實際上的隱性衝突點。

當我們制定規則並要求其他團隊遵守時，就很容易遇到節目中提到的問題：

「為什麼一定要遵守這個 SOP？」

「為什麼申請資源需要經過這麼多關卡？」

「為什麼不能直接跳過中間步驟？」

「為什麼申請一個 K8s 資源，還要進行架構審查？」

現象就是會覺得被卡東卡西。

規則必須 白紙黑字 留下歷史背景

我的做法是，制定規則時，必須把規則存在的原因與歷史背景一起寫下來。

例如，我們規定具有持久性需求的資料，不應直接放在 K8s 裡，像是 Redis / RabbitMQ 或資料庫，這些服務應該 AWS 的 ElastiCache 或 RDS、或自己在 EC2 上安裝。

我們會在 Policy 裡清楚寫下，這項規定是在哪一年、哪一天，因為哪一個系統 / 服務、哪一次事故而產生，然後為什麼要這樣做。當時曾經有團隊把 Redis 放在 K8s 裡，但環境沒有完整支援持久化儲存。Pod 發生漂移或重新建立後，Volume 裡的資料消失，整個服務因此掛掉。

那次的事故影響非常大，促成制定這項規則的原因。當然這只是其中一個。

註一：那次事件也促成我的團隊接管整個公司的 K8s 維運，促成 K8s 平台架構。那大概適在 2017 ~ 2020 年間發生的事。
註二：有些公司是允許在 K8s 跑 Stateful 的，但實務上通常會很慘。

架構審查的目的

架構審查並不是單純增加一道關卡，而是協助開發團隊提發現出問題。

系統的架構層次包含系統設計是否符合既有的 Policy、協助網路設計、防火牆規則、K8s 架構如何規劃、應用程式要如何對外提供服務或與內部系統連接。除了架構層次，也包括成本估算、監控設計、Log 收集、告警串接 (Slack / SMS) 與維運方式等問題。

很多開發團隊並不熟悉這些基礎設施與維運細節，因此我們的團隊會協助他們把問題梳理清楚。真正的重點不是替他們設計所有東西，而是先幫他們找出問題，再讓他們回去思考資安、成本、網路、效能與維運等面向。

我們所做的工作，有一部分很像 AWS Solution Architect 或者 Well-Architected (WA) 在做的事。

註：這段過程催生了 R3 Model 的制定，這段故事發生在 2017Q4。

Policy 本身也需要 Policy - Governance

我覺得節目中提到的那些案例，問題通常不只是員工不知道規則為何存在，而是負責制定 Policy 的人，沒有思考如何讓 Policy 可以持續維護、延續與更新。制定 Policy 本身，也需要一套 Policy。也就是說，我們必須定義：

「規則由誰負責審閱？」

「這條規則為什麼存在？」

「什麼情況下應該修改？」

「過去發生過哪些事故？」

「現在是否仍然適用？」

以前這些事情都要靠人工處理，所以公司還在起步前期 (少於 200人) 時，整個 Infra / IT / Platform 的 Policy 都是我寫起草的，後來我也逐漸培養其他人獨立撰寫，而我只負責 Review。

現在有了 AI，這件事情反而更容易做，因為 Policy 相對適合被文件化、結構化與管理，也比較容易透過 AI 協助整理歷史背景、檢查一致性與提醒更新。

所以，大部分員工在執行任務或 SOP 時卡關，我認為這通常是公司各階層管理者的問題。真正有問題的未必是 Policy 本身，而是管理 Policy 的方法，也就是 IT 治理 。

白紙黑字

如何有效管理 Policy？

對我來講，「人」要面對自身實際的問題：記憶力不可靠

職涯中，我遇過很多聰明人、天才、頂大名校、世界級名校的、Ph.D、國家級研究員，記憶力超好、理解力超強、思緒轉動超快，但是最後認知到一個事實， 他們終究還是人 。只要是人就會有實際的問題：記憶錯亂。

註：這件事情，在我冥想練習了幾年之後，反覆觀察與探索得到的結論。

特別是當主管之後，Context Switch 的密度、次數異常的多，記憶力經常性的錯亂，早上才說，下午就忘了、上週才說過的，這週從來沒映像。

我不是聰明的人，但我很早就認知這一切，也很早就在面對。

有次跟朋友聊天，他問我：

主管的工作很忙的時候、或者思緒很亂的時候，我怎麼靜下來？

我回答：

寫文件，或者寫下當下的片段想法。

寫文件可以讓我去深思很多事情，從文字中組織心裡的思緒與脈絡。所以那段時間，我隨手寫下很多類似的心得與想法。目的都是透過文字，輔助人類記憶力不可靠這件事。

寫的時間不限於上班時間，也包含下班時間。因為思緒與情緒的狀態，很難因為上下班就會直接切換過去，長尾非常久。所以更多時候是下班之後，深夜時候敲下想法。

除了上班、下班時間，交通時間更是我記錄想法的高峰期，所以我的臉書上有很多隨筆寫的東西，都是在記錄這些思緒。

一家公司政治問題多或者少，我會從 「員工如何取的政策、政令的管道」來判斷，都是「聽說」、「誰說」、「某某高管說」，這種的，大概都是治理還很不成熟。如果員工都知道，執行的方向是遵循哪個規範，規範在哪都知道，那代表這家公司的管理層在治理上有做到位。

註：另外造就政治問題多寡的源頭之一，就是 R&R (Role & Responsbility, 角色與權責) 的分配。誰負責分配與安排 R&R？這一定是主管的工作，特別是高階管理的工作。高階管理 Title 為 CxO / VP 以上者。這些人除了要處理業務 (對外) 的挑戰，也要安內，認知道如何做好工作的安排，以及妥善規劃獎逞制度。最後，最重要的，就是安排好平行組織之間的權責，一個 VP 底下可能有好幾個 Director，這幾個 Director 之間的權責與邊界，以及遇到灰色地帶的處理方法。

相關「寫文件」的文章整理如下：

開發團隊應如何處理不合理流程

換一個角度來看，假如你是開發團隊，在執行流程時遇到這些問題，應該怎麼辦？

首先，要把可能造成的損失、風險與責任想清楚，講出來。

如果某個程序會耽誤專案，但流程負責人無法說明原因，就應該直接和對方溝通，確認風險究竟是什麼。真正需要處理的是風險管理，而不是盲目遵守程序。

只要風險可以由自己承擔，理論上就有討論跳過程序的空間。但如果風險的承擔者是流程中的另一個單位，就必須詢問對方是否願意承擔。

該由主管承擔的責任

如果這是一個跨部門的管理問題，最好的做法通常是向上升級，讓自己的主管去處理，主管應該直接和對應單位的主管溝通。

員工需要做的，是把整件事情的資訊串起來，整理清楚時程、利害關係人、可能損失與風險，再交給主管協調。

員工必須有意識地讓主管知道，這是主管需要承擔的管理責任，而不只是執行者個人的問題。

因為：

誰做是政治問題
怎麼做是技術問題

主管的工作之一，就是處理政治問題。

當然，員工也可以向前多跨一步，先整理 Stakeholder、背景資料與簡單分析，再和主管討論。

實際上，很多「主管」不一定具備這種意識，也未必知道這原本就是他的工作，或者其實他根本就不想處理這些「政治」問題也大有人在。

這個過程，也可以看得出來主管的跨團隊協作能力、政治手段、以及是否誠信正直。

大型企業的狀況

我上述的經驗是在規模約 200 - 600 人的公司，我也在超過 80,000 人規模的公司服務過，本質上問題是一樣的。只是執行的過程，需要更有制度化、更加 Top down 的授權，讓組織之間不會踢皮球、或者能夠處理一些可能虛假的訊息。

像是大公司裡最常出現的現象就是：

「某某 VP 曾說過，如何如合 。。。」

「某某長官說如何如何。。。」

「某次事件後，某長官說以後如何如何。。。」

這些話，只要一句話就可以確認：

請問具體的 書面 (Email) 以及 行政命令 在哪？

一個有治理、有管理的組織，如果是會議決策，那就應該有行政命令管道，最後落下白紙黑字，讓所有人知道前因後果，以及誰下的決策、什麼時候。以及，應該要有專屬的團隊，去不斷的改善 Policy 的內容，讓 policy 可以與時俱進。像是，如果到一家公司裡，發現「星期五不能部署」，為什麼卻沒人說的清楚，那就是有問題？資訊不能是一堆 傳說、聽說，或者各種俠著某 VP 的口令，假傳聖旨。

同時這個團隊也有義務要協助，因為 Policy 更動，執行團隊需要處理的汰舊換新流程。像是 OSS 過去十幾年，出現過幾次條款改變，從 Open Source 變成 Close Source，最著名的就是 Redis 換 ValKey。這種東西的汰換，要有專屬政策團隊決策是否要更換，以及更換的目標時間，但是也有義務，協助已經使用 Redis 的團隊如何下車。否則只會變成民怨製造者。

沒有這個「行政程序」，最後就會變成節目中大家在討論的，很多不知道為什麼的流程，然後又要跨很多單位協作，各單位又有各自的立場與時程，整個就會卡住。

上述我只是簡單整理，這種 IT 治理、政策更迭在大公司裡是非常必要的，但我鮮少看到做到白紙黑字，維護得很完整的。大多都是一封 Email、一個簡報到處亂送就當作已經通知了。剩下就是直接壓 Schedule 要所有單位配合。最後附上一句話說這是 OO VP 的要求，其實是很不及格的。

小結

這段紀錄，是我在爬山時，聽 Podcast 當下，透過 Voice Memo 記錄下來的想法。

我講的故事以及經驗，都在 《SRE 實踐與開發平台指南》 有完整介紹，其中 R3 Model 也是當時催生的制度。

當時制定的 Policy 都有其時空背景，所以不見得完全適合現在。

節目 最後 討論到 AI 的部分，做越快，老闆會不為壓寨員工，其實我在 知識飛輪的推與拉 - 知識複利 都講過了。

Comments

▲ TOP ▲