0312 從失敗學 - Resoure management, Power and Stability

其實你如果也是作 Qualcom 平台的,你會知道我到底在做什麼(自爆)。

這一個領域,要說小,他不過就是一個晶片組裡面的一個小功能。要說大,哪一台現在的電腦最大的 stability 問題不是 share resource 的管控(包含 clock, power... )?換句話說,只要我還在這個 function team 裡面,那我就是少數可以從底層功能知道整個產品實際運作全貌的人之一。

一個領域能做大做小,除了那個領域的先天的限制之外,有的時候也是看人力資源的多寡。

舉例來說,在我加入之前,其實這個功能在這間公司,應該只有兩個人會(正確來說,應該是兩個半個人,跟一個人),而大家都忙的要死。在我被調來支援之前,其實我就已經被告知,我可能除了一些基本的知識外,我得不到什麼像樣的指導或幫忙。

一般人聽到這樣大概就打退堂鼓或是找理由作回原本的事情去了,就如同之前一些人被調過來但是沒有多久就又回去原本的單位了。

然而我那個時候心裡是這樣想的:『太好了!越少人會越好!』

因為這樣我在這個領域可以作到多大,就取決於:
1. 我可以自力學習挖出來多少東西
2. 因為沒有太多人會,沒有標準可以當作我的表現的基準,也就是前無太多古人,後面的人變成要 follow 我建立的標準
3. 因為沒有參考的標準,就算我作得不好,其實也無法判斷我到底作的好不好

一開始因為手上的案子不多,所以我基本上是支援跟著已經在進行的案子。我除了處理每天被交付的事情外,就是每天看文件,跟著看 issue ,有不懂的,就問為什麼要這樣處理,或是怎麼樣判斷、怎麼樣找出來問題的,能怎麼樣把問題收斂下來進而找到 root cause。

而事實上,我所受的訓練,跟有興趣的領域其實都是這類的。我有興趣的,其實是在受限的範圍內以有限的資源找出一套解決方式,大致上就是尋找系統平衡,然後去調整穩定,偶而開發個新功能或是組合個有趣的功能。

我並沒有很喜歡從無到有建構一個新的東西,或是去維持一個穩定的東西。也就是說,我自己的性格並不喜歡完全的新創公司(但是從新創到成長這一段我會有興趣),也不喜歡到已經成長到底穩定為優先的公司(我沒有喜歡去作穩定維持的工作)。這沒有什麼對錯,這只是每個人個性喜歡作的事情不同而已。所以這間公司之前看起來成長到頂的時候我沒有興趣,現在開始滑下坡的時候反而是我比較有興趣的時期。

因為其實工作內容會比較接近從新創到成長的時候,只是某些東西的方向是反過來的,像是案子在成長期的公司是一直增加,你不會知道自己是不是選了一個之後會被 cancel 掉的案子;案子在衰退期的公司是一直減少,你通常會知道自己加入的案子會被 cancel 掉。所以偶而加入了一個不會被 cancel 掉的案子真的是會很驚喜,當然更驚喜的在更後面,你會被迫在人力一直減少,時程一直壓縮的狀態下要完成一個案子... 莫名其妙這個案子就這樣出貨了...

也因為這個案子的開拓期結束了,所以我正在把這個案子的東西交接出去給其他的同事,然後才發現,咦,原來我這半年在這個案子裡面累積了不少東西。然後要交接業務的同事則一直讓我很不安,因為這個領域,在我跟其他同事的開拓之下(後來還又加了兩個人,不過我其實還是最資淺的),已經從單一 function team ,變成了一個 Power stability team。

而 Power Stability ,需要很多的背景知識,包含對整個系統運作的了解,每個 clock source, power domain 的認識,底層的 driver 跟 kernel 怎麼搭配呼叫、IC 的 spec 等等。而有的時候,專注查找現象,其實根本無法收斂問題。這也是我在現在這領域建立的第一個 concept:

Rule 1: Symptoms are not always the root causes.

啊你應該會想這不是廢話嗎?但是事實上,有的時候這兩者非常難分辨。你如果沒有足夠的背景知識,足夠的經驗,光是應對每種奇怪的現象就會焦頭爛額了,然後你看到一個可能的原因的時候,就會開心地說:「就是這個原因!」

結果其實這個依然是個 Symptom,真正的 root cause 其實還在更深、更隱晦的地方。例如說,你看到 memory corruption ,就很開心地說這就是原因把這個 issue 轉給別人。結果大家忙了一陣之後,發現這個是因為你 own 的 function 中你自己有東西沒寫好造成 clock timing 有問題造成的。雖然問題最後還是解決了,但是你少不了去跟被你害到的人賠罪一番。

當然這不是問題,因為最後問題依然有解,而且大多的時候其實那就是原因。只是因為問題到 power stability 層級的時候,通常已經變成疑難雜症,任何現象都可能只是現象,而非造成問題的主因。

所以要接得下我手邊的舊業務,需要建立非常大量的背景知識,而且幾乎沒有人可以問,或是可以有系統的教下去,因為不太可能有人有辦法把自身的經驗在短時間內化為文字或是系統化的教學。而且比較新的東西是這樣,當他可以化為系統性的文字、成為一套有系統的教學方式的時候,通常就已經過時了。

像我就非常苦於 Qualcomm 的文件都很舊,新的東西通常文件寫得很模糊,或是 spec 拿來跟實際的 code 一對照,發現用了很多 reserved/undefined 的東西,要問又問不出個所以然,只好自己想辦法去整理去吸收。然後一會了趕快整理一份 Summary 去讓其他的同事能夠大概理解 -- 不然只有我一個人會會累死。(不過也發生過剛搞懂,然後就整個架構被改寫成新版的架構,舊版的就也瞬間變成過時的了)

<待續>

Comments

comments powered by Disqus