靠數據指標（KPI）引導團隊

領英是個數據公司，公司上上下下的所有決策都是靠 KPI 來引導的，像是每月獨立訪客、客戶留存率、各功能的使用人數等等，都是我們這個單位最關心的數據指標。

對於怎麼靠數據指標引導團隊，我有個親身的體會。在我在領英的前兩年，我們的 CI 環境有種種的問題，常常因為各種不同的原因，CI會失敗

• git checkout 失敗：領英的 CI 環境有兩千台機器，隨時都有人在對 git 做讀取及寫入，超過了單一台機器能夠處理的吞吐量。
• maven repo 的吞吐量問題：跟上面的問題很像，因為同時在跑的 CI 機器太多，所以隨時都有機器在跟 maven repo 拉 jar 下來，超過了我們 maven repo 能處理的上限。
• 測試用的整合環境不穩：有些測試並沒有使用 mock 來編寫，而是直接打整合環境，如果這個環境的某個底層服務出了問題，那麼這些整合測試就會失敗。
• 測試用的工具庫不穩：我們用在前端測試的某個函式庫有「記憶體漏失」（Memory Leak）的問題，偶爾會出現錯誤，但是重跑就好。
• 隊友互相踐踏的問題：我們的 CI 是設定成，某個版本（commit）如果失敗， CI 會自動再切換回上一個版本，在重新測試一次。但是如果在短時間內有數個 commit 例如 v0 --> v1 --> v2 ，但是若 v1 是有問題的， CI 會把版本回溯回 v0 的，既使 v2 測試是沒有問題的，還是會被 CI 蓋掉 v0 --> v1 --> v2 --> v0 ，需要重新再送出一次。
• CI 排程問題：雖然領英的 CI 有兩千台機器，但是當兩千台機器都在忙時，新的版本只好放在某個 Queue 裡面排隊，因為某些歷史遺留問題，這個 Queue 大小只有 10 個空位，如果滿了，使用者需要自己重送。而且這個 Queue 是有兩台機器做 DNS round robin，但是這兩台機器很不穩定，常常會有一台死掉需要重開，而且兩台機器之間不共享資料，所以有時候雖然 submit 成功，但是因為機器當掉了，這個 submit 就消失了，或者是 DNS 剛好拿到的是死掉的機器的 IP ，那麼 submit 會失敗，需要再重送一次。

以上種種問題的發生率並不高，但是一個系統的可用度（availability）是所有子系統的乘積，例如假設以上六個問題的發生率各是 1% ，那麼這個 CI 的可用度是 99%^5 = 95%，也就是說二十次 commit 會發生一次問題，等於兩三天就會碰上一次。有時候在午餐前送出 commit ，想說午餐之後回來看，沒想到因為環境的問題，需要在重送一次，長久下來，大家積怨很深。

領英每三個月會做一次問卷調查，問問看所有工程師對內部的開發工具的評價，每一年也會做一次對公司的滿意度調察，看看所有員工對公司的抱怨有那些。在工程單位抱怨了超過一年之後，總算高層打算對這個狀況做出反應，成立了跨部門的「艾因斯坦」計劃，各團隊派出士大夫工程師，來支援這計劃，身為 CI 的受害者，我自然自願參與了這個計劃。

在我們招開第一次會議時，我是很興奮的，因為可以跟公司其它的士大夫及工程總監合作，其中還包含了一位麻省理工的資訊博士，想說大家可以一起動手做，與工具部門一起解掉這些問題。但是開幾次會之後發現，我們並不會實際動手去寫程式或寫設計稿，反而是我們花了三個月的時間，去訂一個新的數據指標 （KPI）出來，訂出那些的錯誤是可以就責於 CI ，那些的錯誤是要歸究於其他的開發工具單位。

當時我是非常的失望的，三個月的時間只有在開會，沒機會真的去解問題；後來又跟我們單位借了一個工程師，去寫了一堆的正規表示式（regular expression），去把錯誤訊息分類；但是，沒想到在訂出這些數據指標的一年之後，我們所有的 CI 問題都解決掉了，如果 submit 失敗，通常是自己程式碼出錯了，再也不會看到一堆人在下班前 submit 互相踐踏，然後回家後發現 CI 失敗，又繼續互相踐踏的狀況了。

在大公司內，還是有部門本位主義的，不可能讓其它單位的人，來修改自己單位的程式碼，第一是外人對整體架構的發展計劃不會清處，只會做些對自己有用的修改，而去忽略這些變動可能造成的問題，第二是外人做的修改，還是要自己單位來做未來的維護，為了權責相符，不可能讓外人來做不用負責的改動，第三還有自己團隊的人材培育問題，有危機才有新專案，有新專案才有新人發恢的空間，這種機會當然要留給部門內的人力來做才對。我們這些外人，還是把時間花在把需求描述清楚上面就好。

這個是我第一次親身參與用數據管理的案子，第一次接觸到，怎麼樣去樹立一個目標出來，然後沒有給出具體計劃，讓底下數百人的團隊自己去訂定實行計劃，各單位自己往終點的方向去前進。事後站在高層的角度來看，越往高層走，只能靠越「抽象」的方式來做事，不可能真的自己跳下去定計劃，入門工程師靠寫程式碼過活，士大夫工程師靠寫規格書過活，到了副總的高度，就只能靠訂數據指標來過活了。關於抽像思考，未來會有專章討論。

註：這個「艾因斯坦」計劃也不是完全成功，另一個子計劃是要把我們的整合環境給弄穩定一些，然而這個子計劃沒有弄清楚，整合環境不穩定乃是因為大家沒有把整合環境也當成生產環境（Production）來維護，把上面的基儲服務弄到 99.9% 的高可用度，所以才會發生再之上的應用層不穩定。這個子計劃去弄了幾千萬美金，蓋了另一個資料中心出來，但是因為沒有多給人力經費給各單位去照顧上面的應用層，所以這環境很快就廢棄掉，最後這個新資料中心也變成我們生產環境的一部份，子計劃宣告失敗。

註二：後來領英的 git 變成主從式架構，有一台主伺服器，五台子伺服器，所有的寫入是寫到主伺服器上，然後透過 commit hook 立刻同步到另外五台機器上。雖然仍有可能發生 CI 跟子似服器拉不到新版本的問題，但是既使發生了，我們的正規表示式可以抓到這些問題，並自動統計發生的頻率，再去看需不需要花人力下去解決問題。

TODO

補上 PROD - STAGING - INT - TEST - DEV 環境的介紹