《SRE生存指南—系統中斷響應與正常運營時間最大化》一書其作者為美國人Nat Welch，他在谷歌做過四年SRE。之後，他在各種規模的公司工作過，並一直致力於提高網站的可靠性，以幫助開發人員構建可靠的系統。翻譯者是馮文輝，他是知名軟件設計公司ThoughtWorks的諮詢顧問。
業內評價，此書是SRE工程師、DevOps工程師、運維工程師和系統管理員不可或缺的參考資料；軟件架構師、軟件工程師、用戶體驗設計師也能從本書中獲取關於SRE的相關知識。
看了這本書之後，我覺得書中有一些不錯的文字（段落），我也趕趕時髦，叫他們金句吧。下面我就把這些金句寫出來，與各位朋友分享。
1、SRE是一個令人興奮的領域。為了定義這個領域，我們可以從它的全稱“站點可靠性工程Site Reliability Engineering”中學到很多東西。
- Site：一個網站。
- Reliability：被定義為“值得信賴的質量或一貫可靠的質量”。
- Engineering：被定義為“熟練地運用技巧以達到某種目的的行動”。
2、事故是指一些重要的事情發生，它迫使你改變正常的行為。例如，一杯咖啡灑在你身上，你需要去更換衣服；在通勤的路上發生了意外，使你不得不更換路線；你可能會摔斷胳膊，不得不在接下來的三個月裡打著石膏。所有這些事故都要求你立馬做出應對，甚至往往使你的計劃發生長期的改變。
3、事故響應通常包括以下幾個動作：
- 關注，注意到有些東西不對勁。
- 交流，告訴別人哪些東西不對勁。
- 恢復，糾正不對勁的東西。
4、如果工程師知道他們每天早上三點肯定會被叫醒，那麼可能會很快就離職了，或者只是把手機警報停掉，而不做任何響應。
5、測試和發佈流程通常在項目早期建立，然後被逐步遺忘。
6、在大型組織中，你也可能會發現自己被限定在一個專門的角色上。你可能感覺測試不是你的責任。但請記住，不僅“滅火”是你的工作，“防火”也是你的工作。
7、另一個經常被忽略的領域是數據恢復測試：
- 有常規的數據備份嗎？
- 對數據備份的過程有常規的測試嗎？
- 對備份的數據有驗證嗎？
8、追求完美的發佈不再是目標，相反，我們只想要一個好的發佈，這樣就可以繼續迭代和完善產品了。
9、SRE的目標是將50%的時間用於編寫代碼，30%的時間用於與人打交道，20%的時間用於應對緊急情況。
10、如果我們不需要人類來完成任務，那麼就編寫代碼，這樣人類就不需要參與其中了。
11、軟件的第一個實現將採用儘可能短的路線，重點在於交付而不是長期的可維護性。之後花時間把一個粗糙的產品打造成更穩定和持久的東西是很重要的工作。
12、SRE存在一種風險，就是SRE工程師有可能成為只負責配置管理或只負責事故響應的人員或團隊。騰出時間進行軟件開發可以幫助你的團隊避免這種命運。軟件開發在金字塔中的地位很高，作為一個團隊，你不應該忘記它的重要性。
13、用戶體驗位於Mikey金字塔的頂部，不是因為它不重要（或最重要），而是因為它需要其它層次才能發揮作用。
14、站會形式多種多樣，可以是聊天、電子郵件，或現場舉行，無論什麼形式，能達到效果就行。
15、重新造輪子是指人們只想使用由其組織中的人員編寫的軟件，並且缺乏對那些不在那裡工作的軟件開發人員構建的任何東西的信任。這非常危險，因為它可能會導致你編寫的軟件數量超出組織能夠維護的範圍。中肯的建議是，你應該構建的軟件是你的核心競爭力，你應該讓其他人構建你的非核心區域的代碼。
備註：下圖是作者在本書中引用的Mikey金字塔。
本文為東方瑞通祝文彬老師原創，祝老師為北京航空航天大學碩士，是東方瑞通創始人之一。20多年IT行業從業經驗，17年IT服務管理經驗，12年高校工作經驗。全球ITIL 4開發小組成員，國內首批ITIL 4 初、中級課程認證講師，曾主持海信集團、鏈接地產、北京地稅、中航技、用友集團等單位的ITSM諮詢項目，對IT服務管理和DevOps體系有很深入的理解。
