這本書應該是devops的必看了。許多其它的書或想法都是或多或少受這本書影響，很多devops的落地實踐也都可以從這本書裡找到理論支援。這本書來自於一系列的devops報告。 作者的團隊做了大量的實驗、追蹤了長時間的資料，查詢實踐或者指標和公司業績的關聯，是非常嚴謹的。
這本書主要分成三部分，第一部分就是報告的主體，分享了他們研究多年的關於devops的發現；第二部分講他們是如何採集資料、如何分析資料以及資料分析背後的理論支撐；第三部分是書中報告在業界落地操作的乙個具體例子。我的讀書筆記只focus在第一部分，也就是這本書的主體內容。
這本書指出考慮軟體交付能力時(software delivery performance)，不管是後端、前端、工具還是其他的，leader要考慮的是架構和流程等的能力，而不是成熟程度。這是因為軟體的架構和流程是乙個持續優化的過程，context會不停的在變化，現在架構的成熟不代表將來架構的成熟。這本書經過多年對業界的研究和分析，認為有24種能力會影響軟體交付的效能，這24種能力有可以歸類為5個領域：
要研究軟體交付能力，首先得有度量指標。傳統的一些指標經常有各種各樣的問題，比如專注在輸出而不是專注在結果（乙個典型例子就是**行數）。這本書指出，以下四個指標在實際業界實踐中被發現和軟體交付能力有強相關：
交付速度
交付頻率
穩定性
故障恢復速度
部署失敗率
調研表明，團隊的疲憊(burnout)程度、效能、工程能力和文化健康狀況和團隊的持續交付能力密切關聯，要做好持續交付，有以下5個原則：
提公升質量。高速度是通過高質量來實現的，犧牲質量最終只會犧牲速度。
小批量迭代。比如原子性**提交、高頻發布。
自動化。重複性活動應該交給電腦，人是用來解決問題的而不是做重複性勞動的。
持續迭代。上文說的，不應該追求乙個「成熟」的狀態，而是持續提公升。
全員有責。
而為了具備持續交付的能力，需要先做到以下三點：良好的軟體配置管理、持續整合、持續測試。作者團隊的調研表明高效能1
團隊水平
新工作計畫外的工作或者返工
其它非創造性工作（開會、流成性工作等）
高效能團隊
49%21%
30%低效能團隊
38%27%
35%架構師最終需要關注的不是具體的工具或者技術，而是在架構上做事的工程師和創造的結果。重要的是去賦能，讓工程師可以以更小的代價、更高效的創造更大的價值；減少團隊和系統間不必要的依賴。因此架構師需要了解他們的目標使用者（工程師），經常和他們溝通，了解他們的痛點，為他們賦能。
)。比如如果乙個開發團隊沒有任何方式可以影響產品決策，那麼他們不停的去和客戶交流就沒多少意義了。
流程上則應該保持簡約，能不要的就不要，同時應該減少團隊同時展開的任務數，不要同時做太多的事情。
書中將文化分成了三個型別3：型別
特點pathological culture
權利優先
bureaucratic culture
規則優先
generative culture
效能優先
不同型別或多或少都有各自適用的場景（比如銀行，可能規則優先是最穩妥的）；但最為前沿科技公司，快速適應市場變化非常關鍵，一般來講是最後一種文化最為合適。而效能優先的公司，有乙個突出的特點就是資訊流動快速高效，由此帶來：
當然要影響文化不是一朝一夕的事情，你需要改變的不是人們怎麼思考（你也改變不了），而是改變人們怎麼做事。
書中專門提到了團隊的疲憊程度（burnout），要減少burnout，公司需要做以下幾點：
至於作者如何定義團隊效能以及如何獲取和分析資料的，均在書中有介紹，還是很嚴謹的。 ↩︎
↩︎
mysql運維 讀書筆記 Mysql 讀書筆記
mysql儲存時間有兩種型別 datetime和timestamp。分別說一下兩者的區別。datetime，以8位元組儲存時間，理論上可以從0000年儲存到9999年。並且沒有時區的概念，它儲存的就是乙個時間點的概念。timestamp和datetime最主要的不同就是，它是以4個位元組儲存，由19...
struts in action讀書筆記
struts in action 學習筆記 一 struts的控制流 因為web 應用是動態的，所以很難表現 乙個真正固定的控制流 取決於環境，不同的方式下有很多不同的事情發生 特別是在web 應用中。但是事情仍然有乙個通用的秩序。如果你是個struts，應用框架，甚至web 應用的新手，這些流程剛...
中 斷（讀書筆記）
裝置的中斷會打斷核心中程序的正常排程和執行，系統對更高吞吐率的追求勢必要求中斷服務程式盡可能地短小精悍。但是這個良好的願望往往與現實並不吻合。在大多數的系統中，當中斷到來時，要完成的工作往往並不是短小的，它可能要求進行較大量的耗時處理。為了在中斷執行時間盡可能短和中斷處理需要完成大量工作之前找乙個平...