文 / 程立
我的經曆
我的經曆很簡單，2004 年之前一直在學校讀書，讀到 30 歲。2004 年跟着一個師兄做外包項目，為淘寶網做一個 重要的架構更新——把原來 PHP/MySQL 架構換成 Jave EE 架構。2005 年 2 月份正式以實習生身份加入支付寶。
2005 到 2014 年，我主要的崗位是支付寶架構師。2013 年， 當時螞蟻的 CTO 要回美國，螞蟻當時的 CEO 彭蕾找我談 過話，我當時對帶這麼大團隊完全沒有信心。我最沒有信心 的不是帶技術團隊，而是 CTO 另外一半的職責，作為公司 經營管理的一部分，怎麼跟 CEO 對話。
前任 CTO 會在公司管理會議上和業務吵得面紅耳赤，我 覺得我做不到。後來王堅博士約我去喝茶，他說沒有關系， 每個人都是不一樣的，但是每個人都能用自己的方式解決 問題。這給了我信心。
于是，2013 年我開始帶支付寶整個技術團隊，經過一年 的考察，在 2014 年公司任命我為螞蟻 CTO，2014 年到 2019 年我一直在這個崗位。
2018 年，公司發現技術确實會對在某些業務起到更加關 鍵作用，需要更強的技術背景同學進入業務。當時對技術 有很強需求的是螞蟻的國際業務，就讓我做了兩年螞蟻國 際業務的 COO。2019 年年底，轉任阿裡巴巴的 CTO。 又過了一段時間，菜鳥也需要一位 CTO，就讓我兼任菜鳥 CTO。
商業與技術共同進化之旅 @ 螞蟻
我挑了幾個螞蟻 CTO 工作的節點，非常好地印證了“商業和技術的共同進化”。最早期支付寶非常簡單， 就是要做一個網際網路的第三方支付平台，技術隻要 能把業務需求實作就好了，項目最大特點就是快、 輕量。
2005 年，某個國際支付巨頭要進入中國，很多同僚很 緊張，那時陸兆禧是支付寶的 CEO。他說:這有什麼 可怕的，他們一個需求兩個月才能實作，我們支付寶 兩天就能實作，他們肯定不是我們的對手。
到2007年，公司面臨一個技術分叉點:網際網路支付一 定會成為行業非常主流的支付方式，我們已經能夠看到 業務的規模，但需要做一個判斷——該用什麼技術架構 支撐。
支付寶最早對技術架構沒有很強的要求，什麼好用就什 麼。我們既有非常網際網路的架構，脫胎于淘寶網;也有 非常金融的架構，2005 年我們敲鑼打鼓、披紅挂彩買 了一台小型機處理核心賬務。
但在 2007 年我們必須做一個判斷，未來我們更像一家 銀行，還是更像一家網際網路公司?幸好後來我們沒有走 彎路，我們判斷未來必須要用網際網路架構去解決支付相 關的問題。
于是我們決定把系統做一個面向未來的架構設計:分 布式改造。整整一年時間，我們将核心交易、核心賬務、 核心會員、核心支付，全部分布式化。
但涉及到一些核心技術如何解決的問題，比如在這麼 大的分布式系統裡，怎麼解決核心事務的問題——這 其實不容易。
2007 年某個國際支付巨頭也曾經想解這個問題，結果 系統上線後當機兩周，CTO 離職。在對這個問題的改 造過程中，我們也膽戰心驚，但最終還是把這塊硬骨 頭啃下來了。
第二個關鍵節點是 2011 年，移動業務起來了，但移 動場景下支付到底是個怎樣的形态，需要做一個非常 關鍵的判斷。當使用者拿着手機和商家支付時，到底用 什麼方式進行?
那時智能手機的格局并沒有完全定形，一些手機還沒 有攝像頭。當時公司部署了很多方案，有掃一掃的， 當時叫悅享拍，拍一下就能完成支付;有叫“咻一咻” 的，讓手機發出聲波，商家接收這個聲音;還有靠藍 牙的。幾輪下來之後，其實很多商家裝了咻一咻的設 備，很多商家用二維碼，最後發現使用者能接受的是掃 碼支付。
2013 年，也是我擔任螞蟻 CTO 的第一年，發生了很 多重要的事情。我們内部起了非常多的重要項目，編 号從 1 号到 9 号。
2013 年這一年， 1 号項目是網商銀行;2 号項目是餘 額寶上線，讓支付寶業務實作真正破圈，真正做數字 普惠金融;3 号項目是花呗。當然還有 456，我們醞 釀了很多項目，有成功的，也有不那麼成功的。
這個過程對整個技術架構造成了非常巨大的沖擊，從 原來網際網路支付脫胎的技術架構，開始往數字金融這 個方向走。在這個過程中，我反而覺得技術正好可以 發力，幫助公司技術實作變革。那一年支付寶開始正 式“去 IOE”，最後一台小型機下線。
商業與技術共同進化之旅 @ 阿裡巴巴
阿裡巴巴的技術其實非常廣，後半程的發展會以阿裡 雲為主線。
第一階段非常清楚，就是技術支撐商業發展，從淘寶網 上線開始。那時淘寶網為什麼能夠赢，除了它商業上有 很多創新之外，“快”也是非常關鍵的因素。在這個過 程中，CTO 要能在業務快速增長時，提前在技術上做布 局，讓商業成長能夠持續。2004 年，我做淘寶架構更新 外包業務的階段其實是淘寶網非常關鍵的時期，Jave EE 架構的形成對淘寶的增長奠定了非常好的基礎。
2009 年有一個神來之筆——那個時間點阿裡巴巴敢于 判斷雲是未來，敢于為雲寫下第一行代碼。阿裡巴巴 内部很多人都不看好雲，但是為什麼那時候能判斷對 呢?我覺得阿裡巴巴有一句話說的非常好:“因為相信， 是以看見”。就像電商業務也一樣，很早阿裡巴巴就 判斷電子商務一定是未來，先發先至，是以在很長的 一段時間，堅定相信這個方向、持續地走，隻要時機 到來，就自然可以取得商業上的成果。技術其實也一樣， 阿裡巴巴很早就做了一個判斷:大資料、雲計算一定 是未來，後面所有發展都以這個為主線。
現在回頭來看，後面每個關鍵節點都是和雲相關的。 比如阿裡雲 2009 年寫下第一行代碼後，内部找了一 圈都找不到客戶，這時候 CEO 就指定阿裡小貸業務 必須用阿裡雲，給阿裡雲一個場景去打磨，這才給了 阿裡雲一線生機。2010 年孫權是阿裡小貸的負責人， 後來當了阿裡雲的負責人。
我自己印象比較深的是 2013、2014 年，經過幾年和阿裡小貸的打磨，阿裡雲開始有一點技術了，大資料處理 開始慢慢成熟。當時有一個很重要的“5K 項目”，阿裡雲 開始具備 5000 台機器大叢集處理資料的能力。具備這個 能力之後，公司又做了一個重要決定，阿裡巴巴和支付寶 所有的資料全部要上到阿裡雲的大資料平台上，那時我正 好是螞蟻的 CTO，我舉雙手支援——因為我知道即使不支 持，集團也會按下來。阿裡雲也是以又上了一個台階。
2015 年，大家都聽過“大中台、小前台”，聽上去很牛。 “大中台、小前台”背後完成了一件事情:把阿裡巴巴和 支付寶所有的基礎技術全部統一到阿裡雲上，這是個重大 的技術變革，為了完成這個技術變革，阿裡巴巴做了非常 好的組織設計，讓當時的阿裡巴巴 CTO 行癫兼任阿裡雲 CTO，把技術收在一起，加強阿裡雲。“大中台、小前台” 政策執行了三年，阿裡雲整個技術架構就非常完整了。阿裡巴巴是集全公司之力支援一個技術戰略的達成。
2017 年之後，這個階段用行癫的話講，是“用技術創造新 商業”，開始去探索技術本身能不能成為商業的一個部分， 城市大腦就是典型的由技術創造的商業。2017 年達摩院成 立，同樣是“因為相信，是以看見”。因為我們判斷未來一 定是數字經濟，圍繞數字經濟所需要的核心技術達摩院要進 行布局，無論是 AI、計算，還是晶片，都是圍繞數字經濟的 核心問題的思考和布局。
2020 年，我已經是阿裡巴巴集團的 CTO 了，我們完成了 上雲的封頂，所有核心業務基本都跑在雲上，包括最具挑戰 性的業務，比如搜尋、推薦、廣告業務，雲都能支撐，我覺 得這是雲非常大的技術進步，也是集團非常重大的技術變革。
現在我們進入一個新的時代，要把雲和業務技術的邊界定 義清楚，邊界就是雲原生。我們未來業務應用全是雲原生的應用，這是一個雲原生時代。另外，雲本身也在更新， 就是大家都知道的“雲釘一體”。
不同業務階段下的三種技術上司力
三種技術上司力，我是受到俞永福的啟發，他覺得企 業發展就是這樣波浪式的發展過程:一開始要先找到 一個方向，進入一個業務的軌道;如果這個方向判斷 準了，企業就會進入快速增長階段;發展到一定階段， 就必須要脫離現有的慣性，再去找新的發展方向—— 就是這麼一波波的過程......
在波浪式發展過程中，技術在每個階段起的作用不一 樣。在入軌的階段，CTO 應該是整個公司業務一号位 班子的成員，是支援一号位的二号位，班子一起看清 方向，把業務帶入正軌。
一旦入軌之後，業務進入快速增長期，CTO 的核心不 是看方向，而是怎麼做好技術，這時首席架構師會變 得非常重要，技術讓業務更高速增長、加速成長，業務不要被技術拖慢增速。同時，組織設計在這個階段和技術架構一樣重要。然 後不能等到業務停滞時才去判斷未來，CTO 要提前判斷未來會發生什麼，第二 曲線是什麼，設計一條未來的路線。
我是覺得整體上組織需要有兩種上司力:一、專業的上司力:CTO、首席架構師、 技術總監和 VP;二、組織設計的管理上司力。CTO 在不同時候戴着不同帽子， 有時會承擔一個專業角色，有的時候會承擔一個管理的角色，有的時候會承擔 一個戰略的角色。
很難說一個 CTO 是萬能的，CTO 一定有強項和短闆。比如我自己，我的定位是 一個工程師，工程能力是我相對比較強的一項能力，組織是我的弱項。在這個過 程中，一個核心班子裡需要非常好的配合，具備不同的上司力，給不同的人戴上 不同的帽子。
CTO 的職責
1.建立商業與技術的“共振”連接配接
CTO 在一個公司中到底扮演什麼角色和 職責?
我覺得第一個非常基礎的職責，是要建立 起商業和技術連接配接。前面講到商業和技術 是共同進化的，而共同進化的過程中兩者 要發生很好的共振連接配接。為了實作社會價 值、客戶價值，企業要判斷需要怎樣的核 心能力?這個判斷不是一個純粹技術判 斷，也不是純業務判斷，而是一個公司核 心班子共同的判斷。
這個過程中，CEO 和 CTO 怎麼對話就 變得非常關鍵了，能不能說一樣的語言? CTO 要和 CEO 問清楚幾個架構性的問題:一是我們公司服務誰，要把客戶定義的非常清楚;二是我們為這些客戶創造什麼樣的核心價值、差異化價值;三是我們的商業模式，用什麼樣的商業模式實作核心價值;四是為了實作這樣的商業模式，我們需要什麼樣的能力、走過什麼路徑、建構什麼樣的組織。把這些問題了解清楚之後，技術就能了解業務要幹什麼了。
我在阿裡巴巴接到任何一個新業務，都一定要對它進行新的了解，後續可能還 會有多的問題、更深入的了解，但這是我做的第一件事情，這是 CTO 的職責。
2.一張圖、一場仗、一顆心，願景牽引前行
很多時候，牽引團隊往前是非常有挑戰的事情，小團隊還可以靠關系。大團隊 裡大部分人你都不能認識，怎麼還能“一張圖、一場仗、一顆心”?這時候就 需要有上司力了。
我分享幾個例子，比較有挑戰，也有很多不一樣的方法。
第一個例子，我在團隊裡建立上司力的方式，是跟團隊一起定義非常清晰的目 标。2013 年經過一番猶豫之後，我決定接受負責螞蟻整個技術團隊的任命。 當時我遇到的最大的挑戰就是和團隊之間的信任——本來大家都是平級，突然 我要成為這個部門的總負責人。當時大家給我的回報是，覺得魯肅做技術可以， 但不懂業務技術。
我覺得信任是要靠跟大家一起把事情做成，甚至沒有必要讓大家建立起對上司者的認同，就看大家能不能相信共同的目标，并把目标實作。2013 年，我跟 團隊共識了“1234”目标:
- 公司從網際網路平台向數字普惠金融平台轉型，我們的技術架構怎麼去支撐? 需要重新定義支撐數字普惠金融新的平台。做平台架構這件事情，至少是我的 本行，大家認同。
- 螞蟻哪些核心技術是我們今年必須要突破的?當時定了兩個核心點:一是 OceanBase 在這一年能落地;二是我們要把螞蟻的平台建在雲上。
- 我們能不能在這一年大促的時候實作 3 萬筆 / 秒的支付?大家知道從 2010 年開始，每年會有一次大考:大促能扛多高的峰值。前兩年，螞蟻都是非常吃 力的去扛。甚至 2012 年對團隊來說是個很大的恥辱——大促前 50 分鐘系統被 沖垮了，50 分鐘後才恢複。2013 年大家都想一雪前恥:2012 年時峰值是每 秒 3000 筆，已經是性能極限了。我們定一個 10 倍的目标實作 3 萬筆 / 秒!
- 因為我們的服務不僅僅是支付，還開始提供金融服務，穩定性必須像銀行一樣， 甚至比銀行更穩定。我們定下可運作目标 4 個 9(99.99%)，之前 3 個 9 都 很吃力。
這四個目标，大家非常認同，雖然都很有挑戰。年底的時候，經過大家的努力， 四個目标裡實作了三個半:完成了平台的轉型，餘額寶、花呗業務都起來了; OceanBase 在螞蟻系統裡落地了;做到 4 個 9;但我們沒有做到 3 萬筆 / 秒， 隻做到 1.5 萬筆 / 秒，是 5 倍的提升。之後大家開始建立起對我的信任。
我到了阿裡巴巴之後，第一件事情也是需要大家聚在一起，一起定下目标。 空降到一個平台，其實很難給團隊定一個全新的願景。如果新 CTO 上來就 先畫一張未來的圖，基本是不太靠譜的，還是要和團隊一起定下非常紮實的 目标、一起達成目标。于是，我選擇先在雲這個關鍵戰略上穩中有進，全面 上雲必須全部完成。二是在雲之上，如何從“上雲”到“用雲”，把雲原生 做深入，将阿裡巴巴中台做深入，包括 AI 中台、資料中台和業務中台。另 外一個目标是組織數字化，阿裡巴巴雖然生于數字時代，但也需要做數字化 更新和轉型，阿裡巴巴數字原生商業系統和數字原生組織是去年和團隊一起 确定的方向。
CTO 和團隊在一起要有一個面向未來的思考，不隻是當下與業務的連接配接。未來是什麼，關鍵的路徑是什麼，核心的幾場仗是什麼，這是 CTO 的牽引力。
- 關鍵決策，掃清前進中的障礙
CTO 需要幫團隊解決問題，掃清一些障礙，做出一些關鍵的決策。在螞蟻做 CTO 時，第一個關鍵的決策是技術架構往金融方向還是網際網路方向?最後決策 是網際網路。第二個關鍵決策是關于 OceanBase 的轉型。
2010 年，陽振坤老師帶着團隊開始打造 OceanBase。最早 OceanBase 還 不是一個真正的資料庫，當時第一個場景是解決淘寶的收藏夾問題，需要海量 資料但不需要很強的資料處理能力。但到了 2012 年，OceanBase 面臨一個 發展決策，要不要成為一個真正的資料庫。
螞蟻團隊對 OceanBase 的懷疑有合理的理由，我們現在的業務對資料庫要求 這麼高， Oracle 那麼先進的資料庫團隊打造了幾十年，才剛剛能滿足我們的 業務需求。陽老師帶着幾十個人花兩年時間打造一個資料庫，能把 Oracle 替代掉嗎?
我覺得王堅博士是很有上司藝術的，當時他做了一個選擇，他說:“把 OceanBase 送給支付寶吧。”到了螞蟻這邊就成了我當時定的“1234 目标” 中“2”的部分:看 OceanBase 能不能再往前發展。
當時我們采用了什麼辦法呢?第一先了解清楚 OceanBase 能幹什麼;第二， 既然公司整體不能做，就搞一個小場景，在螞蟻的核心交易裡切了 1% 的流量 給 OceanBase，讓它在 1% 流量裡證明能力。OceanBase 也很珍惜這個舞台， 撐住了 1% 的流量，最終在這一年完成了從非關系型資料庫向真正關系型資料 庫的轉變。2014 年我們再大膽往前邁一步，把“雙 11”大促 10% 的流量切給它， 讓它進核心賬務系統——賬務系統比核心交易系統要求更高。當時這個決策是 有一些冒險的，但現在回頭看，正是這些決策讓 OceanBase 有了不一樣的未來。
後面幾個決策也類似，作為 CTO 如何拿捏好風險和穩定，是非常關鍵的。
比如餘額寶上線的第一天我們就知道這個産品一定會成功，因為它的客戶價值 特别清晰，讓使用者每一塊錢的餘額都有收益。但我們沒有料到，它成功得那麼快， 一個月時間迅速就把原來準備的系統容量全部用掉了。我們自己還好，因為螞 蟻的平台已經完全分布式化了，可以快速擴容。但我們的合作夥伴天弘基金， 因為老系統無法支撐餘額寶這麼快速的增長，擴容成了核心難題。
于是我們做了一個非常重要的決定:把天弘的系統搬到雲上，用分布式架構重 寫一遍，三個月内必須完成。這件事也證明了金融雲的價值，金融雲的業務也 就起來了。
這些都說明，CTO 要在關鍵決策中發揮作用，幫助團隊下決心并把握好不确定性。
- 應對風險，化危為機
公司的技術風險有幾類。
第一類，技術架構不能夠支援業務發展，這是業務不能接受的風險。但這類的 風險，相對顯而易見。阿裡巴巴為什麼在 2009 年啟動“去 IOE”，就是判斷 到這個風險早晚會出現，“IOE”架構已經不能支援公司業務發展，必須去掉。 螞蟻在 2010 年開始啟動“去 IOE”，因為那一年“雙 11”大促讓我們看到原 來架構基本不能支援業務了。
2010 年的“雙 11”大促被我們稱為“人肉雲計算”。大促開始，我們看到 流量瘋漲，判斷白天肯定會沖破設計容量，就趕快把伺服器庫存全部加進去 了，結果發現還是不行，又馬上去“殺”服務，把不必要的服務全部關掉， 把容量放在核心關鍵鍊路上，結果還不夠，我們又去看關鍵服務裡還有沒有 能“殺”的。那年“雙 11”最後幾分鐘，我們的核心賬務資料庫和會計資料 庫都到了極限，還有 10 秒鐘就要挂掉了。最後關頭，團隊非常果斷，把會 計資料庫殺掉了。會計記賬本身很重要，但斷個幾分鐘還能承受，核心賬務 不能挂，否則整個業務就全部中斷了。就這樣，2010 年的“雙 11”大促是 硬撐下來的。
其實後來很長一段時間，都是“人肉雲計算”，人在做資源調配的事情，人來做 決策判斷。這太痛苦了，這一切逼着螞蟻非常堅定地擁抱雲的分布式架構，要上雲。
第二類風險不是技術架構的問題，而是穩定性出現重大問題。CTO 必須要判斷 出這個情況，CEO 一定要給 CTO 相應的資源支援。
比如螞蟻的“527”。2015 年我們實作了整個支付寶系統的異地多活，華南機 房和華東機房異地可以做分布式交易，這在金融系統裡應該是第一次。我們還 特地做了斷網演練，直接把華東區域全部關掉，華南直接接管業務，結果非常 成功，大家非常開心。我還給當時的 CEO 彭蕾發了一個戰報，說螞蟻首次實 現了異地多活，你們可以放心睡覺了，以後任何情況下系統都會穩如磐石。
2015 年 5 月 27 日，我開車在路上收到了報警，通常遇到這種情況團隊就直接 處理了，但那個報警就一直響。我就把車停在路邊，才發現光纖被挖斷了，系 統中斷将近 2 個小時。原來異地多活，光纖一斷，系統就切不過去了。從那之後， 我再也沒有發過任何一份戰報，沒有和 CEO 報過任何一次喜。
當時這個事情對螞蟻技術團隊打擊非常大，公司受到最大的打擊是客戶的信任。 外面有很多文章調侃螞蟻的技術，螞蟻的技術形象和外部的信任喪失了。内部 從我到整個團隊與 CEO 的信任也開始出現了危機——以後再講話，别人隻聽 一半，因為說的話不見得靠譜。
危機也可以是好事情。“527”之後，我們做了幾件非常關鍵的事情，第一， 開始跟公司溝通，我們需要在螞蟻成立一個專門的部門，叫技術風險部。這個 部門就一個職責，守住螞蟻技術底盤的風險，公司額外撥 10% 的技術資源給 到這個團隊。也就是說，我們願意付出額外 10% 的技術資源專門確定螞蟻系 統未來沒有風險，這件事情至少幫我們争取到這個資源。第二，立刻啟動實戰 演練，前面說其實我們做過異地多活的斷電演練，但這是有準備的演練。從那 一天開始我們要做無準備演練，一直到今天。第三，我們确定把 5 月 27 日這 一天作為螞蟻的技術日，螞蟻未來無論是存在 102 年還是更長的時間，所有技 術工程師都要記住這一天，讓我們永遠能夠記住風險。
這三件事情做完，反而讓團隊更加凝聚了，螞蟻技術的風險防控水準有很大的 提升，我覺得這是轉危為機。
第三類風險，可能是 CTO 和 CEO 都最擔心的，一個新技術出現之後會不會颠覆原有的業務模式。不僅是很多發展中的公司會擔心，即便阿裡巴巴這樣規 模的公司也非常擔心。當一個新技術出現，無論公司大小，都有被完全颠覆的 風險。螞蟻面對移動網際網路時代時，我們有一段時間很擔心，通過好幾年努力 定義移動支付，基本上算是渡過這個危機，但當時對螞蟻的挑戰還是非常大的。 當比特币開始成為一個現象時，我們也是非常擔心的:它會不會把支付完全颠 覆了? 2019 年 6 月 Libra 出現，更讓人擔心了:全球支付會不會被一種新的 貨币重新定義，這是一種降維打擊。
這時候 CTO 必須要站到一号位班子裡去，幫助 CEO 做判斷。每一次對未來危機的判斷，都可以觸發未來新的商業機會。大的政策是:面對任何技術風險不能隻是看，要親自去試，需要公司投入一些有價值的浪費。
第四類風險，是溫水煮青蛙。技術會不會反過來傷害公司，它不像風險那麼直接， 但是如果因為技術、架構或組織問題讓公司效率變慢了，公司會慢慢喪失競争力、 創新力。随着時間的推移，這是最大的危機。阿裡巴巴的中台就是一個很好的 例子，中台的優點在于可以減少很多重複建設，讓業務可以基于中台快速創新， 因為重複建設的繁忙約等于效率低下。但阿裡巴巴的中台已經非常完善了，開 始進入了另外一個階段。目前，業務中台裡有面向核心電商的中台、數字供應 鍊的中台、職能線業務中台、資料中台、AI 中台等一系列技術中台。當我做一 個新業務的時候，我需要跟這麼多中台打交道，需要他們去支撐我，過程中如 果有任何一個中台支援不能到位，我的業務可能就做不成。我們現在開始大力 推動中台能力進一步更新，改善中台的傳遞方式，把中台再更新。這裡涉及到 很多技術架構的變化。為了防止溫水煮青蛙就是要一直做系統化的梳理，再去 一個階段一個階段的解決。
- 組織設計與治理 —— 平衡秩序與創新
一個人當 CTO 的時間越長，專業能力下降得就越嚴重。我判斷自己的專業能 力大概每隔兩年會降一級。也有好處，你可以跟團隊一起做，團隊會更強。組 織設計的核心是要既有秩序又能創新。這是有沖突的，創新是在一個混亂的土 壤裡長出來的，秩序讓效率高，但會把很多創新吃掉。這個過程有點像踩鋼絲， 處理秩序和創新的平衡。
阿裡巴巴圍繞技術的組織，是有兩條線的。一條線是實的管理線，是分層分布的:
前台，面向業務的，為客戶赢;中台，是能力中心，中台的客戶是前台，讓前台 更加高效，讓前台更有競争力;底層背景，是強調技術先進性的，確定業務永續。 這個組織每一層都是獨立的業務經營單元，現在我們在做一件事情，讓每個獨 立的業務經營單元都有 CTO。這個 CTO 會對這個業務經營單元負全責。實線 管理機制的核心就是把每一層之間的界面定義清楚。
這種治理讓每一塊業務都很靈活，都可以自主發展，但又帶來了一個新問題， 我們該統一發展的技術怎麼形成合力，是以我們有另一條虛線:技術委員會，下設二三十個核心的技術小組，把所有的共性領域橫向拉通。通過技術委員會 和技術小組的專業上司力，實作政策通、人才通。這兩條線會同時運作，随着 管理線越來越清晰的分層，這條專業的虛線就會變得非常重要。比如音視訊技 術，每個業務裡都會用到音視訊技術，中台也有音視訊能力，底層需要優化 以提升音視訊技術的競争力。前台、中台和底層跟音視訊相關的技術專家組 成一個技術小組，由一個專家帶領。
這條虛線會轉化成實線的管理決策，我們必須要打通這個鍊路，這個體系的 運作會比較有挑戰。作為 CTO，我覺得要在過程中保持非常開放的心态，要 信賴每個領域技術專家的判斷。技術專家意見不一緻時要有獨立思考，做出 自己獨立判斷，要知道創新和秩序的平衡點在哪裡。
組織大到一定程度之後就會遇到這樣的問題，我确實也不建議技術組織還不 大時就把組織結構搞的太複雜，這會帶來額外的管理和溝通成本。
- 凝心聚氣、薪火相傳
凝心聚氣其實是最重要，也是最難的，這是一個技術文化的事情。每隔一段時間，我們都會聚在一起讨論阿裡巴巴的技術文化。去年我們讨論了一輪，三年前我 們也讨論過一輪。三年前定下阿裡巴巴技術的 slogan 叫“技術創造新商業”， 再之前的 slogan 是“技術拓展商業邊界”。
除了 slogan，阿裡巴巴的技術文化底色是務實、有一說一，不要打花腔，不要 做包裝，事實是什麼樣就什麼樣，用事實說話。沒有資料、沒有事實的時候， 就不要說話。如果大家都能踐行這個文化的話，很多事情會變得特别簡單，但 其實踐行文化并不容易。
我們有一些技術土話，比如“面向未來去思考”、“因為相信，是以看見”, 是 需要看準未來，敢于投入，真正做到先發先至。因為如果别人做、你再去做， 永遠是追趕者，會非常累，但看準未來、敢于投入，也不會輕松。
這些文化、願景能不能在一個大的場景裡形成共識，尤其這個組織每年都有人離開、有新同學進來，還能保證一緻的文化，其實是非常有挑戰的。但隻有文化做好，很多事情才能順理成章。
CTO 可能不是思想家，但一定是行動派
前面是我思考的 CTO 的六個職責，雖然不完整，雖然不可能每件事情都做得 非常好，但核心思考是，我是相信 CTO 或者說技術團隊需要跟着公司業務發 展不斷進化。我從螞蟻到阿裡巴巴，差不多經曆了前面六個階段，我稱之為 CTO 的六步曲:
1.跟團隊先一起定義好目标，先一起做成一些事情。
2.多了解團隊、了解業務，知道未來要去哪裡，跟團隊一起共創一個願景，把大家熱情點燃。
3.CTO 的一個核心工作，是怎麼能夠讓自己不要成為團隊的天花闆，而是把自己當成團隊的地闆，用人做事。如果 CTO 是公司技術天花闆的話，那你把 公司技術就壓在一定的高度和範圍内，公司技術永遠是在一個小的、狹窄的領域。當 CTO 的技術能力是公司的地闆時，公司可以通過新同學擴充邊界。成 為 CTO 還是用人做事為主，而不是做事用人為主。
4.一切都很好時，别忘了晴天去修屋頂，永遠居安思危。一旦危機出現，樂 觀地看待，每個危機背後都有機會，轉危為機。
5.過程中不隻看當下，也要布局未來，為公司建立技術縱深。在業務發展早期， 技術的縱深就是一個點。當發展到像阿裡巴巴現在這個規模時，技術縱深就是 一個多面體，必須有充分的、多面的布局，才能支撐一個大公司的發展。決定 布局投入多少，要和 CEO 充分對焦。
6.最後一點，人才。薪火相傳，人才才是公司未來發展的關鍵。我記得阿裡 雲曾經有一位技術負責人分享說:什麼是一家公司技術的最高境界，就是誰來 當 CTO 都能當好，我覺得這是我要努力的一件事情。
如何發展與培養 CTO
最重要的事情放在最後，就是人才。
前面講到我們的分層分布治理，每個經營單元要有一個小 CTO，這個 CTO 怎 麼培養?基本上我們讓他在戰場裡去練，為他設計發展路徑，也有“奇點營” 這樣的班專門培養業務小 CTO。
當然最難的事情就是培養接班人，自己的接班人和團隊的接班人，這件事情其 實是我上任第一天就在想的事。但選準人、選好人，有非常多的挑戰。
我有兩個小經驗:
1.CTO 發展是“Z”字型的路線。
直線成為 CTO 的人，往往會因為路徑太單一、沒有足夠磨煉而出問題。行 癫負責過淘寶的業務，負責過 B2B 業務，再做阿裡巴巴的 CTO，再做阿裡雲的總裁。我做過螞蟻的技術，做了兩年螞蟻國際業務，再做阿裡巴 巴的 CTO。做過業務再回頭看技術，跟 CEO 對話會有共同的架構， 這一點很關鍵。
- 做“L”型職責設計。
CTO 最怕做虛了，畢竟這是公司裡非常高的位置，每件具體事情都有相應 的核心骨幹幫你負責，但你手不伸下去就很容易做虛，看不到下面的實際 情況，會導緻決策出錯。
阿裡巴巴怎麼解決這個問題呢?就是給 CTO 一橫一縱:橫向管理的 CTO，也給你一個縱向的業務技術一号崗位，保持與一線的對接。比如我 現在既是阿裡巴巴集團的 CTO，又是菜鳥的 CTO。行癫也曾經既是阿裡 巴巴的 CTO，也是阿裡雲的 CTO，也是一橫一縱。
CTO 應該具備怎樣的特質?每個 CTO 都有不一樣的風格，但有幾點是共 通的:一是要求真務實，真正“No Data No BB”，永遠不是高高在上地 做決定，而是做決定時能夠看得到下面，這很重要;二是要有擔當，在做關 鍵決策時敢負曆史責任，有進取心;三是必須時時自省和開放。如果不具 備自省和開放的能力，是很難去進化的;四是一個大組織和大業務的 CTO 要有全局觀，能夠做架構，能把各方面、各種資訊形成一張大圖。
曾國藩非常懂用人之道，他這麼選人:“專從危難之際，默察樸拙之人， 則幾矣”。我特别喜歡這句話，把自己的釘釘簽名都寫為“樸拙”，這是 對自己的要求。
到現在為止，我覺得自己很多方面做得依然不夠，包括對未來的判斷。 CEO 和 CTO 實際上是要共同成長、共同進化，在工作中形成默契的，這是非常重要的。
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)