1. 程式人生 > >Google DevOps 能力模型(下):什麼領導特質可以打造世界級可靠系統?

Google DevOps 能力模型(下):什麼領導特質可以打造世界級可靠系統?

本文由 Gene Kim 根據對 Randy Shoup 的採訪整理,深入討論和講解谷歌 DevOps 的提升之道,下面一起深入瞭解。本文系 OneAPM 聯合高效運維編譯整理。

前言

Randy Shoup 曾協助領導 eBay 和 Google 的工程師團隊,他是少數能將「建造高效產出 DevOps 與世界級可靠性系統需要怎樣領導特質」描述清楚的人之一:

Dr. Spear的模型有如下四大能力:

  • 能力1:在問題發生時馬上就能發現;
  • 能力2:一旦發現問題立刻叢集式解決(Swarming),並將此記錄下來儲備成新知識;
  • 能力3:在整個公司範圍內傳播新知;
  • 能力4:以開發為主導。

這也是採訪 Randy Shoup 的基礎,此次採訪還揭示了一些在谷歌與 eBay 中未曾廣泛討論過的實踐案例。

本文主要介紹其中的能力3和能力4,關於其他兩個能力,請詳見下文:

能力3:在整個公司裡傳播新知識。

Dr. Spear 寫道:

高效率公司通過在全公司內部(不僅是發現者)傳播知識,增加新知識的產出效果。他們不僅分享問題的結論,還分享發現問題的流程——學到了什麼,怎麼學到的。

儘管在大一些的系統中,他們的競爭對手在發現問題後,仍然讓問題留在發現的地方,與解決方案放在一起。

但在高效率公司中,負責者會將發現的問題,在全公司進行傳播。

也就是說人們在開始工作時,會吸收公司裡其他人的經驗。這樣,我們會看到乘數效應的幾個案例。

Q:問題發生時,知識如何傳播?區域性的發現如何轉化為全球性質的進步?

其中一部分,儘管不是最大的那部分,是來自事後剖析會的文件。有這樣的跡象:谷歌與其他公司一樣頻繁出現事故。在谷歌一旦有引人注目的停機事件,你可以肯定幾乎公司裡每個人都會讀到事後剖析報告。

也許預防未來故障的最強大機制就是:全谷歌共同擁有的單一程式碼庫。

不過更重要的是,由於可以搜尋整個程式碼庫,利用別人的經驗就很簡單。不管檔案多正式多有一致性,更好的辦法就是看看實踐中人們的做法——「去看看程式碼」

但是,也有消極的一面。一般來說,使用服務的第一個人可能會使用隨機的配置,然後在公司裡瘋狂傳播。突然間毫無理由,像「37」這樣的隨意設定傳的到處都是。

只要你讓知識變得容易傳播又容易獲得,它就會到處傳播,並很有可能出現一些最優設定。

Q:除了單一的原始碼庫和無責的事後剖析,還有什麼其他的機制可以從區域性學習轉化為全域性改進嗎?知識傳播還有什麼辦法?

在谷歌原始碼庫中,最棒的事情之一就是你什麼都能找到。所有問題最好的回答就是「看看程式碼」。

其次,還有隻要搜尋就能找到的優秀文件。

還有極好的內部小組。就像任何外部服務一樣,寫個「foo」就能列出一個叫做「foo-user」的郵件列表,然後你就可以向列表中的人問個問題。聯絡到開發者當然很好,不過大部分情況下會是使用者給出回答。

順帶一提,這種做法,類似本行業大量成功的開源專案。

能力4:以開發為主導。

Dr. Spear 寫道:

高效率公司的管理者確認:常規工作的一部分就是釋出產品和服務,以及持續改進產品與服務釋出的流程。他們教人們如何持續改進自己的那部分工作,併為他們提供充足的時間與資源。這樣一來,公司在可靠性與高適應性方面都能夠自我改進。

這是他們與失敗的競爭對手最根本的不同。

高效率公司的管理者,並不負責通過一系列指標來命令、控制、斥責、威脅或者評估別人,而是確保公司在以下方面有所提高:自診與自我改進、發現問題的技巧、解決問題、通過全公司傳播解決方案來提高效率。

David Marquet 的名言(《Turn This Ship Around》的作者):「真正的領導人的標誌就是在他/她之下還有多少領導者。」這位潛艇前指揮官比歷史上任何潛艇艦長帶出過的領導者更多。

他要解決的主要問題是:一些領導者解決了問題,但一旦他們離開,問題又重新出現了。這是因為他們沒能讓系統在離開自己的情況下,繼續正常運轉。

Q:谷歌的領導層是怎麼發展的?

谷歌已經實踐了你能在任何一家健康運作公司中能找到的幾乎所有辦法。我們有兩類職業道路:工程師道路與管理者道路。任何一個在職位上有「管理者」字樣的人主要負責「讓事情成為可能」,並鼓勵他人進行領導。

我將自己的職責視為創造每個人都很重要的小團隊。

每個團隊都是一個交響樂團,與工廠截然相反:每個人都能獨奏,但是更重要的是,他們都能彼此合作。我們都有過那樣的糟糕體驗:團隊成員衝著彼此吼叫,或者誰也不聽對方的。

在谷歌,我認為領導者最強大的影響在於,我們打造重要工程專案的文化願景。大的文化規範之一,「每個人都寫很棒的測試;我們不想成為一個寫蹩腳測試的團隊。」同樣,有這樣的文化「我們只僱參與者」——對我在情感上也很重要。

在谷歌,在評估與改進過程中,一些這樣的東西被寫進法典。這聽起來很糟糕,因為那意味著,我們只管做好提升所需的那一份工作。

但是另一方面,評估過程讚譽很高,幾乎公認是可觀的:人們獲得提升知識,因為他們作出了相應的貢獻,並且很擅長他們所做的工作。我從未聽過誰升職是因為他們「抱對了大腿,拍對了馬屁」。

管理者和主管職位的主要標準就是領導力:也就是說,那個人是否作出了重大的影響,他的影響是否遠超你工作的團隊以及某個「只做自己事情的人」。

Google App Engine 服務是在7年前成立的,在叢集管理組中有著一群令人驚訝的工程師,他們認為「嗨,我們擁有這些創造可擴充套件系統的技術。是不是可以編一個,讓別人也能使用呢?」

「App Engine 建立工程師」的頭銜被授予給那些倍受內部員工尊重的人,比如 Facebook 的建立者。

Q:新任管理者如何做事?如果領導者必須培養其他領導人,新任管理者或者一線管理者如何瞭解工作減輕的風險?

在谷歌,你只會得到「你已經在做」的那份工作,這與其他大多數公司都不相同,在別的公司都是做「希望你能做的工作」。

也就是說,如果你想要成為首席工程師,那麼就做首席工程師的工作。在谷歌,就像很多大公司一樣,有很多的培訓資源。

但在大多情況下,如何完成工作的文化規範影響太大,可能確保文化規範延續就成了首要趨勢。就像是一個自我選擇的過程,增強文化規範與技術實踐。

當然,這也跟公司高層的風格有關。谷歌是兩個怪咖工程師建立的公司,在高層風格的影響下,這種文化也在不斷增強。

如果你在一個命令與控制型的公司裡,公司的領導者討厭別人,那麼這種不良資訊也會傳遞並在公司裡強化。

結論

再次重申,我從 Randy Shoup 那裡學到的太多了,難以言喻。如果你對此有興趣,想要了解更多並用於公司實踐的話,不妨直接通過 LinkedIn 詢問 Randy,他目前從事諮詢工作。