躍遷：從技術到管理的矽谷路徑【筆記】

09-12

躍遷：從技術到管理的矽谷路徑【筆記】

來自專欄 ZyBlog

技術管理

1.技術管理包含兩層含義：

* 一層是管理自己和團隊的技術，進行技術選型，在正確的場景使用最適合的技術，保證程序簡捷、強壯、可維護，最終完成產品的上線
* 另一層是管理技術團隊，幫助團隊成員成長，把事情做成

2.「你不能每次都給答案，你應該試著用引導的方式讓對方學會自己找答案」

3.從給答案到做引導：

* 1）什麼時候適合直接給答案，什麼時候適合給線索讓對方自己找答案
* 新人進入全新領域，或者所問問題的答案就是某些知識點時，直接給出答案或知識點
* 對方已經有一定的積累和經驗後，可以讓他自己去探求解決方案了，需要給出一些提示
* 2）如何引導
* 問對方正確的問題，通過問題去引導對方進行深入思考，找到解決方案
* 3）引導的好處是什麼
* 解決類似問題的能力會提升

4.技術經理必須停止只思考自己的狀態，把更多精力放到其他人和團隊上面

5.一名優秀技術管理者應該做哪些工作呢？

* 幫助團隊成員迅速成長
* 明確地分解與布置任務

* 建立有效的合作關係

6.大公司如何幫助成員成長：

* 對每個級別在各個方面設定一些標準
* 一個人是不是可以被提升，標準就是，是不是已經在過去的半年到一年裡，按照下一個級別的標準在工作。換句話說，不是覺得你可以達到下一個級別的標準就提升你，而是你已經達到下一個級別的標準，並在這個標準上穩定地保持了一段時間，你才會被提升

7.做到下面4點，有很大機率成為一個優秀的管理者：

* 和自己對話，想想自己哪些時候、在哪些方面會用靜態的眼光去看待別人的能力
* 把自己有這種心態的時的表現或內心的想法寫出來
* 再遇到類似的情況，停下來，想一想自己是不是可以有所改變
* 誠懇地告訴組員希望幫助他成長，多交流並聽取對方的想法

8.一名技術管理者的成功並不在於自己寫的代碼多好、能力多強，其成功一定建立在團隊成功的基礎之上

9.盡最大可能避免延期問題的發生：

* 建立一定的流程
* 在整個項目計劃中，要有明確的優先順序。知道哪些任務是非做不可的，哪些任務是需要提前完成的

* 製作一個共享的項目狀態表，讓團隊成員可以一眼就看清楚項目進展，並保持該圖表的更新
* 不要漏掉任何一個人。不要覺得暫時還沒有他的活，可以先不用與他溝通
* 提供一個有效的反饋渠道

10.期望值差異很多時候都是一種很自然的存在。原因也很簡單，因為每個人都或多或少高估自己

11.90%以上的創業公司都會失敗，但這些創業都在初期無一不認為：「我有優秀的團隊、廣大的市場、敏銳的產品意識和絕妙的創意，怎麼可能不成功呢？」

12.儘可能地校準管理者和被管理者對彼此的期望值：

* 最重要的一點是增加對彼此的了解
* 每半年或一年進行一次關於期望值的深度對話
* 有了這樣的約定，還需要持續跟進

13.一般情況下，管理者會傾向於把重要、困難的工作交給自己信任的人。這種信任，包含了對對方的了解程度，對其工作態度和能力水平的肯定

14.在沒有建立起充分信任的情況下，我們該如何分配工作：

* 1）建立參考基線

* 2）問對問題比給出正確答案更重要：告訴他任務的詳細情形，看他會問出什麼樣的問題，提出哪些想法
* 3）工期估算
* 讓接受任務的員工試著去估算：需要多久完成，大概什麼時候完成，需要什麼樣的資源等
* 開發工作量有多大，會不會依賴其他人的工作，有多少溝通成本，技術難點是什麼，有沒有現成的方案，系統框架是什麼，後期集成和測試的時間成本有多少
* 如果一個人不能花費足夠的時間去了解自己未知的部分，我們也很難放心地把任務交給他獨立完成
* 4）執行力
* 5）後期維護：需要觀察，一個人是不是可以自覺地維護產品，有沒有責任感，會不會推卸責任，出了問題能不能第一時間衝到一線解決
* 6）注意一些細節問題：
* 學會如何對待職場新人：不要輕易地否定他們。他們可以快速地學習並且進步
* 了解如何針對不同類型的員工分配工作：分配任務的時候，你需要揚長避短，根據每個人的特點安排不同類型的任務，並提供相應的支持和幫助，以發揮人員的最大效力

* 還要注意大項目的工作分配：如果你希望承擔更重要的任務，成為有擔當的人，一方面需要提高自身的能力，發揮自己的特長，另一方面就是要成為一個有態度的人

15.一個技術方案如果自己不參與就會擔心執行效果，兩個誤區：

* 事情能不能做好和完全按照你自己的方式做好，是兩碼事
* 介入和不介入並不是非黑即白的，用什麼方式介入，在哪些地方介入才是關鍵

16.在授權和分配任務的時候應該注意以下方面：

* 1）讓對方明確目標，知道最終要得到的結果是什麼，對這個任務完成的期望值是什麼樣的
* 如果有取捨，哪些是重要的，哪些是次要的，哪些是可以妥協的
* 2）制訂一個計劃，並保持跟進
* 跟進不是指導，而是需要你在對方對某個環節有疑問的時候，能夠隨時提供幫助
* 3）給出反饋，尤其是下面的反饋

17.管理者不用親力親為，關鍵就在於學會授權和任務分配，兩個重點：

* 第一，我們要有效地把任務分配出去
* 第二，我們要保證分配出去的任務能夠被圓滿地完成

18.項目管理中三個技巧：

* 1）我們在制訂項目計劃的時候，要對多個項目進行細分重組
* a）需要考慮的因素：
* 先評估能力，再分配任務
* 每個人完成任務所需的時間要盡量平等
* 有挑戰性的工作和「臟活累活」的比例要大致相等
* 任務要有足夠的挑戰
* 不同人的任務之間如果有依賴性，在分配任務時要安排合理的順序，確保不會有人被其他人或事阻塞（Block）
* 每個人的任務都應該有一個主題，就好像故事有一條主線
* b）細分重組兩個階段：
* 第一個階段，需要把所有要做的事細分為一個個的小任務，每個任務的大小，完成需要的時間都大致相同

* 第二個階段，把這些大小均勻的任務塊，按照上面提到的因素，分裝到幾個虛構的「箱子」里，然後分配給團隊成員
* 2）工期估算
* 很多工程師在做時間預算的時候，會過於樂觀
* 往往需要技術領導者給出參考性的意見和建議，最好留出一些緩衝時間
* 3）實時跟蹤，並準備好B計劃
* 設立各種里程碑，有一些長期的大里程碑，也有一些為期一周到兩周的小里程碑
* 一旦出現延遲，管理者要和任務的負責人一起分析原因，詢問對方能否追上進度，會不會對整個項目的進程有重大影響

19.管理者需要把握幾個方面的度：

* 1）因人而異
* 最大程度調動並發揮每個人的長處，並且幫助他在欠缺的方面獲得更快的成長
* 2）因事而異

* 在介入之前，你需要讓對方理解為什麼需要頻繁溝通
* 如果單個任務是在整個項目中有一定試錯空間，或者不在時間線的關鍵路徑上，這時，你不妨試著放手讓組員嘗試獨立完成
* 3）跟進的粒度
* a）兩種極端的做法：
* 只設計目標，然後完全放手
* 每個細節都按照你的想法去推進，這就無法讓員工發揮自己的能力
* b）應該做到以下幾點：
* 確立目標，確保傳達：非常清楚地說明你想要的最終結果是什麼樣子，並明確地告訴員工
* 多給指導，少親手做
* 設定頻率，保持跟進：定期跟進，儘可能給對方足夠的決定權

* 交流難點，給出建議：可以給出一些建設性的建議和意見，但不要直接上手幫忙完成任務
* 4）交流的重要性

20.為什麼要保持員工組成的多樣化：

* 互聯網時代的市場組成是多樣化的
* 產品的用戶也是多種多樣的

21.如何才能保持員工的多樣化：

* 多樣化可以體現在員工的國籍、人種和性別這樣的外部特性上
* 員工的多樣化也可以體現在團隊的內部差異上
* 員工的多樣化也體現在團隊的創新思維上

22.《包容性領導的六個特徵》：

* 堅定的承諾
* 謙卑的勇氣
* 正確的認知
* 開放的心態
* 高情商
* 合作的意願

23.責任心是一種抽象的概念，很難去培養，即使可以培養，也是個漫長的過程

24.如何去激發團隊人員的責任心：

* 1）我們要明確責任制，適當地放權，讓他們去主導一些事情，適當的獎勵機制
* 2）要讓責任制變得有效而不是形同虛設
* 讓責任人意識到承諾了就要努力做到，承諾的事沒做到是需要承擔後果的，不是沒人在意
* 有效的責任制，需要在開始的時候就讓所有人明確責任與權利，而不是事後追究責任
* 多花時間，讓對方自己認識到問題所在，而不要把你的主觀感覺強加於人，用引導的方式才能更好地激發團隊成員的責任心
* 3）儘可能讓團隊成員充滿歸屬感
* 在有利公司發展的基礎上建立獨特的企業文化
* 管理者還應該以身作則，讓員工看到自己的努力，對公司目標的追求，對企業文化的踐行

25.看別人的設計文檔，或是自己憑空想像，都沒有應對實際系統中的問題更能讓自己長經驗

26.績效評估都解決了哪些問題：

* 績效評估的出發點，就是建立一個獎罰機制
* 保證公平
* 這樣一個明文列出規則的系統又可以在一定程度上讓所有人的期望值趨於一致

27.績效評估可能存在的問題：

* 每次績效評估後，必定是換組甚至離職的高峰期
* 必定每個人都可能會有一些偏見，每個人主觀判斷的標準也可能有偏差，甚至難免會由於個人情緒和私心影響結果
* 公司把哪些內容列入評估，其實就是引導員工更多地在這些方面花時間精力
* 當一些項目或者工作的周期長於評估周期時，評估機制就很難準確反映每個人就得的獎懲

28.對於工程師來說，尤其是職場生涯偏早期的工程師，能夠加入一家快速增長的公司其實是最好的選擇和機會

29.Jeff Bezos提出過一個Pizza原則：「如果兩張Pizza不能餵飽一整個組，那就說明這個組已經太大了」，而一個組太大，在決策和所有權方面就很容易生產比較大的資源或時間開銷

30.每個小組都有自己很明確的職責範圍，這是所有跨組協作的基礎

31.跨組項目時間線，如何保證項目按期完成：

* 在項目期限規划上，組裡的資深工程師還是很有話語權的
* 每次的討論和會議，盡量保證小而精，切實解決一個問題
* 後期執行中，如果產品有需求上的改動，會影響之前的計劃，那麼或者適量延期，或者把部分需求置後，或者增加有效工程師資源
* 跨組項目的時間線很大程度上取決於每個小組是否能夠按期完成各自的任務定額，因此合理設定每個小組的時間線，對保證跨組項目的期限和里程碑有著很重要的作用

32.「高層」技術領導者很重要，但是「一線」技術領導者更直接影響工程師的生產力

33.一線技術管理者，指的是可以帶5-20人甚至更多的人的技術團隊，直接管理工程師，或者每天都需要和工程師交流和溝通的那些技術領導者

34.一線技術管理者兩個十分關鍵的能力：

* 利用自己能了解到的有限情況做出最正確的決定
* 利用組裡有限的工程師資源高質量完成最關鍵的項目

35.一個優秀的領導者，在並不親自寫代碼的情況下，應該了解到所有方案的優缺點，考慮到所有技術和非技術因素，迅速在給定限制條件下做出最正確的決定。這是很重要的技能

36.如何利用組裡有限的工程師資源，高質量完成最關鍵的項目：

* 1）挖坑，也就是定義項目，決定要做什麼，具備長期的戰略眼光
* 2）充分調動每個工程師的潛力，給他們成長的機會和空間，在任何一個團隊中，如果每個工程師的效力都得到最大化，這個團隊的執行力便能超出每個個體簡單相加的總和
* 3）幫組員摸清路障，最關鍵的貢獻，應該是全局掌控，提前清楚項目可能遇到的障礙

技術實踐

1.A/B測試是一種數據分析手段，它可以對產品特性、設計、市場、營銷等方面進行受控實驗

2.A/B測試要注意的問題：

* 永遠不要過分相信你的直覺
* 實驗樣本的數量和分配很重要：分配演算法不會對兩個組的數據產生額外的干擾
* 分析的維度要儘可能全面
* 其他組的改動對A/B測試產生的影響
* 比較值的趨勢必須收斂的，而不是發散的
* 數據埋點：前端埋點一般可以採集實時數據，後端埋點可以採集實時事件，也可能是一些聚合數據
* 形成一個流程，或者設計一個工具
* 試圖給每個結果一個合理的解釋
* 必要的時候重新設計實驗
* 不同客戶端分開進行實驗

3.冪等：一個操作如果多次任意執行所產生的影響，均與一次執行的影響相同，我們就稱為冪等

4.冪等兩個關鍵因素：冪等令牌（Idempotency Key）和確保唯一性（Uniqueness Guarantee）

5.冪等系統的常見問題：

* 冪等令牌什麼時候產生，怎樣產生
* 令牌有沒有被誤刪的可能
* 各種競爭條件
* 對請求重試的處理，大部分是伺服器端要做的工作
* 系統中需要多層冪等

6.學習演算法的用處：

* 1）演算法是面試的敲門磚
* 2）編程時用到更多的是演算法思想，而不是寫具體的演算法
* 如果工作中需要讀的一段代碼中包含一些基本演算法思想，你會比不懂演算法的人更快理解代碼含義
* 3）不精通演算法的工程師永遠不是好工程師

7.在建表時需要考慮所有可能的高頻查詢，切忌過度地「為未來設計」，不要增加許多可能根本不常用的索引，這樣反而會增加寫數據時的成本和負擔

8.NULL在資料庫里常常被解釋為「不確定」而不是空

9.過度使用事務的問題：

* 事務中封裝的代碼邏輯太長太複雜，甚至調用了別的函數
* 事務中封裝了與資料庫改動無關的邏輯
* 事務中有不可逆的操作，例如發送電子郵件給用戶、發布到一個Job隊列等
* 事務中包含了不同資料庫中的事務，也就是分散式事務，這種情況需要單獨處理
* 事務中嵌套了事務，不同情況下可能會有不同的結果，如果沒搞清楚，就可能出現意外

10.業務拆分時的注意事項：

* 測試會變得異常複雜
* 與介面相關的改動需要大量協調
* 報錯的處理
* 日誌的完整性
* 超時設置
* 代碼自由

11.業務拆分綜合考慮：

* 1）你的業務是否足夠大，邏輯是否足夠複雜，以至於必須進行系統拆分？水平擴展是不是已經不起作用了？代碼的相互影響、部署時間過長真的是系統的切膚之痛嗎？如果答案都是肯定的，那麼你就應該進行系統拆分了
* 2）對於服務化的架構，你的開發人員有多少經驗，能否正確駕馭
* 3）系統拆分是一個「從一到多容易，從多到一困難」的過程，這個過程幾乎是不可逆的。所以在做拆分的時候一定要慎之又慎

12.一家公司早期的代碼會因為各種歷史原因而不是那麼完美，但是在特定的時間點，那就是當時最優的方案

13.在設計API的時候，就應該做到用最簡單直觀的格式支持所有的需求

14.API設計原則：

* 保證API RESTful和程度是100%
* 在請求和響應中，應該儘可能地保持參數的結構化
* 有關鑒權和安全的考慮，始終應該放在首位
* API本身應該是與客戶端無關的
* 儘可能讓API是冪等的

15.API設計中的平衡：

* 1）自由總是相對的
* 2）為當前設計，還是為未來設計
* 要考慮未來的場景，在設計時留有餘地，但永遠只實現當前產品真正要用的功能
* 3）可維護性和效率
* 4）是否採用面向切面編程
* AOP的理念是從主關注點中分享出橫切關注點
* 分享關注點使解決特定領域問題的代碼從業務邏輯中獨立出來，業務邏輯的代碼中不再含有對特定領域問題代碼的調用，業務邏輯同特定領域問題的關係通過側面來封裝、維護，這樣原本分散在整個應用程序中的變動就可以很好地管理起來

16.支付系統在處理各種交易時，不僅僅是處理交易，也需要對其他功能的支持，其中包括了確定規範和程序、處理異常，還有收費的標準、一筆交易應該保證多久完成等

17.每位工程師都應該在他已有的水平上盡全力追求完美。我們應該具有工匠精神——為我們的工作而驕傲，不斷打磨工具、流程和技術，打造出具有最高品質的作品

18.說得理想主義一點，軟體質量最基本的保證應該來自於程序員的素養

19.很多寫代碼的技巧、風格或習慣都得益於以前工作中在代碼審核環節同事給出的建議。這比看書或者讀別人的代碼學習來的要有效得多

20.參與審核的人要多存質疑的態度，不明白的或者覺得有問題的地方都直接說出來，這樣對雙方都有益

21.Monitoring和Alerting

* Syslog或Kibana Log
* 基於BD Trigger的Auditing Trail

22.一個項目的推進，通常有4種情況：

* 1）負責的程序員 vs 緊張的進度
* 2）不負責的程序員 vs 緊張的進度
* 3）負責的程序員 vs 不緊張的進度
* 4）不負責的程序員 vs 不緊張的進度
* 第一種和第三種都是比較理想的結果
* 如果上層的態度不明確，那麼做不到第三種，就不妨做第四種。而最吃力不討好的，就是第一種
* 如果根本沒有人在乎代碼質量，只在乎進度，那麼就做到第二種

矽谷文化

1.矽谷互聯網公司的開發流程

* 1）OKR的設立
* a）矽谷公司的OKR（Objectives and Key Results，目標和關鍵成果）一般都是自頂向下的，也就是說，先有整個公司的OKR，然後有每個部門的OKR，繼而是大組的OKR，再到小組的OKR，確保整個公司有一致的目標
* b）技術驅動反映在哪些方面？
* 確定演進線路圖的過程中，我們會採用調查模式，確保工程師的聲音可以準確地觸達管理層
* 項目怎麼做，怎麼規劃，一般是由工程師來決定的
* 估算OKR里的目標工期時，我們會除去一些用於技術創新和技術支持的時間
* 2）主項目及其子項目的確立
* a）主項目是主要的技術或商業產品，一般由產品經理、技術經理和一些技術骨幹經過對產品需求的討論之後，確定要做什麼（Scope），不做什麼（Non Scope）以及大的里程碑（Milestone）
* b）一般團隊協作有兩種方式：一種是每個人負責一個子項目，從始至終；另一種是大家先一起完成基本框架，然後逐個需求、逐個模塊去推進，最終一起完成整個項目
* 3）確立每個子項目的生命周期
* a）開發初期的設計文檔
* 組內工程師和產品經理審核，然後進入大組評審（包括Legal、Compliance、Finance等），涉及公司的整體架構，還需要發給全公司審核
* 文檔中不僅包括怎麼實現，還有選型的理由、考慮的因素、支持和不支持的屬性、時間線等
* b）設計測試實驗，這是可選的，也就是A/B測試
* c）設計文檔鎖定，就可以開始實施了。每次代碼提交要寫清除代碼改動外的摘要和測試，並通知不同的工程師審核
* d）所有的實現都要加入監控、日誌、預警代碼
* e）所有的實現都隱藏在一個開頭（Trebuchet）後，當代碼就位後，就開始進行灰度發布
* 推送的過程中會結合A/B測試，只有測試結果顯示對用戶體驗、公司主要指標沒有明顯的負面影響，才會正式發布給所有用戶使用
* f）對一些需要重構的關鍵產品鏈路，有時候也會使用雙重寫入的方法，就是將新特性和舊特性都寫入資料庫，並通過不同方式比較兩個實現的結果
* g）最後是一些掃尾工作，移除用來做A/B測試和灰度發布的代碼開頭等，有時候還包括一些次要需求的實現
* 4）確立主項目的生命周期
* a）項目開始都有一個整體設計文檔
* b）在所有子項目進行的過程中，共同需要的架構或者服務，可以將其單獨提取為公共服務或庫
* c）給相關人員做進度報告，包括主項目的里程碑
* d）由於眾多子項目的完成時間可能不一樣，因此需要進行人員的重新配置
* e）在開發過程中不斷更新文檔
* f）因為不確定的需求變動，有時會取消或者生成新的子項目
* g）有時候也會因為公司的方向變化或戰略調整，對主項目進行比較大的變更，同時對應調整相關的子項目
* h）在項目開始和結束的時候，需要做好對外的交流和溝通
* 5）收尾、維護、復盤
* a）進行代碼清理和文檔更新，有時還需要寫新的用戶手冊或Wiki等
* b）一些基本的錯誤和異常處理要寫到運維手冊里，便於以後負責運維的人知道如何處理一些已知的問題
* c）每個項目結束時都會進行復盤，總結整個項目的經驗和教訓

2.Code Review要清楚的兩個概念：

* Commit：Github上的一次「Commit」行為，這是可以單獨保存的源代碼的最小改動單位
* PR：也就是Pull Request，是指一次代碼提交請求。一次PR可以包含一次Commit，也可以是多次

3.一般情況下，所有的PR都必須有至少一個人認可（stamp），才能進行合併（merge）。如果改動的內容涉及多個項目，則需要每個項目都有相關人員認可才能合併

4.幫助他人成長，而不是幫他寫代碼：

* 從對方的角度來說，代碼寫不好，可能是對業務不熟悉，對編程語言不熟悉，也可以是對公司代碼的整體架構不熟悉
* 幫別人寫代碼的方式可擴展性很差。你不能什麼都自己寫，尤其是開始帶項目、帶新人時。每天審核五個人的代碼和幫五個人寫代碼，長期而言哪個更划算呢？答案顯然是前者
* 寫代碼是一個學習過程，怎麼成為一個好的代碼審核人更是一個學習和成長的過程

5.一般將提交的代碼分成4類：

* Bug修復。獨立的Bug追蹤和管理系統，每個Bug都有一個票據（ticket），代碼提交的PR一般和票據是關聯的
* 代碼優化。文件的移動和拆分，部分函數的重構等
* 系統遷移。包括代碼庫拆分，用另一種語言重寫等
* 實現新系統和新功能。新功能在實現之前都需要進行設計審核，最終版本的設計文檔會包括資料庫的Schema、API的簽名、代碼的流程和模塊等內容，相關代碼的提交，也就是PR，一般是和設計文檔相關的

6.Code Review的注意事項：

* 為什麼要進行PR？原因一定要在提交的時候寫得非常清楚，才能幫助審核者判斷這個改動是不是合理
* 除非是極其明顯的單詞拼寫問題，否則盡量不要引入不是這個PR目前的改動。PR要儘可能保持目標的單一性
* 一定要確保所有的改動都是測試過的，無一例外

7.Code Review從代碼審核者的角度要注意：

* 如果時間足夠，自然是看得越細越好。如果特別忙的時候，則可以做一些篩選
* 如果是新人寫的代碼，儘可能地在代碼風格、性能等各方面都加以審查。如果是老員工，這些方面則可以給予更多信任

8.Code Review具體哪些地方需要審核：

* 代碼格式方面
* 代碼可讀性方面
* 業務邊界和邏輯死角問題
* 錯誤處理
* 確保測試用例覆蓋到了所有的功能路徑。嚴格來說，每段代碼都應該有測試用例
* 代碼質量和規範
* 代碼架構

9.公司層面對Code Review的支持：

* 統一代碼提交和審核的流程與工具，並確保大家使用同樣的工具，遵循相同的流程
* 鼓勵員工幫助別人審核代碼，甚至可以列入績效評估中
* 制定統一的編程規範和代碼風格，尤其是在有爭議的地方，這樣可以解決由於程序員的偏好而帶來的矛盾

10.對於Bug導致的錯誤，應該採取什麼態度和措施：

* 追究責任，但不是懲罰
* 對事不對人
* 反覆問「為什麼」，從根本上發現問題
* 員工關係的建立也很關鍵

11.矽谷的溝通

* 1）每兩周會有一次到兩次的一對一面談，經理人會和每位團隊成員進行一次大約二三十分鐘的跟進談話，這個行為差不多成了矽谷所有公司的傳統
* 2）談話的內容其實沒有定式，一般會談到最近的項目進展如何，有沒有什麼阻力，最近的生活和家庭狀況如何，有沒有出遊或其他特別的計劃等
* 3）如果想讓一對一溝通真的有益、有效，管理者應該學會聆聽
* 4）好的溝通：
* 找一個適合談話的場所
* 彼此百分百專註
* 要有一定程度的眼神交流
* 不會收到批判性的反饋，哪怕是表情或者肢體語言的暗示
* 有一定程度上的交流
* 所有的對話，如果自己有保密要求，可以保證對話內容不會被傳播出去

12.關於On Call

* 1）監控和報警
* a）監控：
* 將系統和使用的監控工具集成
* 在代碼中加入各種instrumentation向監控發送數據
* 在監控系統中設置閾值，當某項指標出現異常時，通過特定的方式通知預設的組或者工程師
* b）監控工具：PagerDuty、Slack
* c）報警工具：Nagios、Graphite、New Relic
* d）很多公司都不會只用一種監控工具，通常是兩到三種並用，因為工具都有出問題的時候
* 2）系統檢查
* a）檢查到底哪裡出了問題
* b）日誌系統：Kibana
* 3）系統控制：包括關閉部分系統或者系統的部分功能，重啟系統，以及啟動某項特定的服務等

13.本地化：是指在移植產品時為其加上與特定區域設置有關的信息和語言習慣、用戶習慣等，使得產品在該地區有很強的可用性和粘滯性

14.Coupon（優惠券）設計：

* 無論最開始設計Coupon系統的人，以及後來在上面加新需求的人，是產品經理還是技術領導，他得真的知道或者了解所有Coupon可能出問題的地方，應該怎麼統一設計
* 一定要有統一的文檔，並保持更新
* 為所有用法編寫測試用例，包括上面所有場景的各種組合

個人成長

1.四類錯誤

* 1）伸展錯誤（The stretch mistakes）
* 當你嘗試去進行能力之外的挑戰時，因為自身能力或其他條件的束縛做得不夠好而犯的錯
* 獲得學習的機會成本很高，一旦經歷過一次，就可能有長足的進步
* 2）無知錯誤（The aha-moment mistakes）
* 當你發現自己為什麼犯錯的時候，你會發出「噢，原來是這樣的」的感慨
* 一般是因為你不知道或忘記考慮某些特殊情況而導致的，也可能是因為你做了錯誤的假設
* 3）粗心錯誤（The sloppy mistakes）
* 你明明知道怎麼回事，但是因為不小心或者忘記了而導致的
* 4）高風險錯誤（The high-stakes mistakes）
* 主動去做事情，但風險很高，是否會犯錯不受自己的控制

2.避免錯誤：

* 為了避免伸展錯誤，儘可能提供一些培訓機會
* 為了避免無知錯誤，要做好信息的透明共享
* 為了避免粗心錯誤，要設置一定的復盤機制
* 為了避免高風險錯誤，為所有的決定儘可能準備一個備用方案

3.要對更多的工作說「不」，需要搞清楚兩件事：

* 分清事情的輕重緩急，有些緊急的事情和優先順序高的事情很難拒絕
* 正確評估自己的能力和時間資源

4.什麼時候可以說「不」：

* 正確評估需求後，如果事情沒有那麼緊急，或者這件事別人也能完成，並且你手頭正好有更重要的事情在做，告訴對方，這個需求現在做不了，需要完成當前任務後才能考慮
* 如果某件事的處理已經遠遠超出了你的能力，甚至職責範疇，不要只是為了讓別人高興而充當濫好人，攬下來又做不了，或者達不到對方的預期，不僅會耽誤別人的事，還會丟失自己的信用分。這時候要學會說「不」
* 如果某件事你可以做，但是因為各種原因，覺得有些難處又不願意解釋，就勉強答應下來，最後的結果可能是事情做了，卻做得心不甘情不願，完成度也不夠。這時候也可以考慮說「不」

5.聽取意見時有幾點很重要：

* 盡量排除情緒以及偏見對我們的干擾，這一點，需要我們有意識地去克服
* 假定對方是善意的
* 了解意見的具體細節，把關注點放在對方的出發點，以及對方希望我們改進的地方
* 對意見里的信息進行分類和過濾，思考一下：哪些是誤解，哪些是自己的不足，哪些是自己可以通過溝通去改變的，哪些是自己需要嘗試改進的

6.關於學習的焦慮感：

* 1）快速甄別，決定哪些事情值得花費時間
* 鍛煉自己不要在無用的事情上花費時間
* 2）對於需要學的，考慮自己的時間，衡量時間成本的性價比
* 評估掌握一項技能在短期和長期內對你有多重要
* 時間成本本身的評估
* 信息獲取是不是可以利用時間碎片來完成或者處理呢，還是需要用連續的時間去持續學習？
* 3）對需求和時間成本評估，決定要不要學，確定學習目標
* 4）計劃學習前要想清楚，一旦開始執行，就不要想太多

7.「一個團隊應該有一些稍微激進但又可行的里程碑，而且大里程碑又應該分成小的，儘可能讓每兩個里程碑之間的間隔時間不要過久。這樣，每隔一段時間，大家就會完成一個目標，就會有成就感。最糟糕的就是定一些不切實際的目標，或是不斷放棄預定的目標。這樣的話，每個人都會開始疲憊和迷惘，很難看清楚自己到底做成了什麼」

8.管理自己精力的法則，就是找到對自己來說重要的和困難的那些任務，不僅要為期預留時間，而且要預留自己精力最充沛的時間