注：以下內(nèi)容剛剛譯完，尚未定稿，會與正式版有出入。僅供參考。本頁試讀內(nèi)容的發(fā)布已經(jīng)獲得圖靈公司相關(guān)編輯的許可。
第2版贊譽
邁克是軟件行業(yè)最深刻的思想家，也是最清晰的溝通者。與第1版相比，第2版不僅同樣文筆優(yōu)美，還用現(xiàn)代技術(shù)對內(nèi)容進(jìn)行了擴(kuò)展（最顯著的是持續(xù)部署、云基礎(chǔ)設(shè)施和混沌工程），這將有助于我們構(gòu)建和運維大規(guī)模軟件系統(tǒng)。——Stitch Fix公司工程副總裁Randy Shoup
如果想要將任何類型的系統(tǒng)投入生產(chǎn)，本書應(yīng)該是案頭常備的最重要的一本書。作者將其在該領(lǐng)域所獲得的豐富經(jīng)驗，通過易讀的文字和緊湊的形式表現(xiàn)出來。本書第2版圍繞系統(tǒng)韌性這個核心模式，很好地闡釋了不同的系統(tǒng)結(jié)構(gòu)上的真實世界的服務(wù)的開發(fā)、編排、安全和部署的新方法?！狽eo4j公司開發(fā)者關(guān)系工程總監(jiān)Michael Hunger
本書討論了很多內(nèi)容，包括有關(guān)應(yīng)用程序的系統(tǒng)韌性、安全性、運維和架構(gòu)的許多模式和反模式。即便有了這樣寬的廣度，本書同時對這些內(nèi)容的討論也頗具深度。所以本書不僅值得讀，還值得研究?！?th Light公司CTO及《Mastering Clojure Macros》作者Colin Jones
對于那些想在生產(chǎn)環(huán)境運行軟件，并且仍然能夠在晚上睡個好覺的人來說，本書是必讀書。它將助你建立信心，并學(xué)會期待和接受軟件系統(tǒng)的失效?！禗eliver Audacious Web Apps with Ember 2》作者M(jìn)atthew White
我會向?qū)I(yè)從事于軟件項目的人推薦這本書。鑒于第2版內(nèi)容已全面更新，以涵蓋每日所處理的技術(shù)和內(nèi)容，我希望我的團(tuán)隊中的每個人都能人手一卷，以了解現(xiàn)代軟件開發(fā)所必須考慮的廣泛的內(nèi)容?！浖こ處熂皥F(tuán)隊負(fù)責(zé)人Andy Keffalas
對于任何想要構(gòu)建真正健壯和容量可伸縮系統(tǒng)的人來說，本書是必讀書?！浖绦騿TPeter Wood
致謝
我非常感謝許多閱讀并分享本書第1版的讀者！我很高興能有這么多人發(fā)現(xiàn)本書很有用。
多年來，有不少人催我更新這本書。感謝Dion Stewart、Dave Thomas、Aino Corry、Kyle Larsen、John Allspaw、Stuart Halloway、Joanna Halloway、Justin Gehtland、Rich Hickey、Carin Meier、John Willis、Randy Shoup、Adrian Cockroft、Gene Kim、Dan North和Stefan Tilkov，以及所有其他那些看到軟件開發(fā)方法已經(jīng)不同于2006年之前的單塊系統(tǒng)構(gòu)建方法的人們。
感謝本書所有的技術(shù)審閱者：Adrian Cockcroft、Rod Hilton、Michael Hunger、Colin Jones、Andy Keffalas、Chris Nixon、Antonio Gomes Rodrigues、Stefan Turalski、Joshua White、Matthew White、Stephen Wolff和Peter Wood。你們的努力和反饋已使本書質(zhì)量更好。
還要感謝Nora Jones和Craig Andera，你們允許我將你們的故事寫入本書。本書中的那些"戰(zhàn)爭"故事一直是我的最愛，我知道許多讀者都有同樣的感受。
最后，非常感謝Andy Hunt、Katharine Dvorak、Susannah Davidson Pfalzer以及The Pragmatic Bookshelf的整個團(tuán)隊。感謝你們的耐心和毅力。
前言
本書將探究用來架構(gòu)、設(shè)計和構(gòu)建軟件（特別是分布式系統(tǒng)）的方法，以應(yīng)對艱險難測的現(xiàn)實世界。這需要我們做好準(zhǔn)備，以對付做事瘋狂、難以預(yù)料和不合邏輯的大批用戶。從發(fā)布的那一刻起，軟件就會遭受攻擊。它既要承受像臺風(fēng)般襲來的“快閃族”{![“快閃族”（flash mob）原指一種行為藝術(shù)，其間許多人通過互聯(lián)網(wǎng)或其他方式，在一個指定的時間和地點，出人意料地同時做一系列指定的動作，然后迅速離開。——譯者注]}用戶所帶來的負(fù)載壓力，也要因為不安全的物聯(lián)網(wǎng)設(shè)備而承受DDoS（Distributed Denial-of-Service，分布式拒絕服務(wù)）攻擊所帶來的毀滅性壓力。本書會仔細(xì)研究那些沒能經(jīng)受住這番考驗的軟件，并找到一些方法，以確保軟件在上述攻擊之下，仍能幸免于難。
讀者對象
本書面向分布式軟件系統(tǒng)的架構(gòu)師、設(shè)計師和開發(fā)工程師。分布式軟件系統(tǒng)包括網(wǎng)站、Web服務(wù)和EAI（Enterprise Application Integration，企業(yè)應(yīng)用集成）項目。這些系統(tǒng)必須處于可用狀態(tài)，否則公司就會賠錢。它們也許是通過銷售以直接實現(xiàn)創(chuàng)收的商務(wù)系統(tǒng)，抑或是內(nèi)部員工用于完成工作的關(guān)鍵系統(tǒng)。如果有人因為軟件停止工作而不得不回家，那么本書就能派上用場。
內(nèi)容結(jié)構(gòu)
本書分為四個部分，每個部分都從一個案例研究說起。
第一部分展示如何使系統(tǒng)保持工作狀態(tài)，從而維持系統(tǒng)的正常運行。盡管冗余設(shè)計保證了可靠性，但是分布式系統(tǒng)所表現(xiàn)出來的可用性，更像是“兩個8”，而不是令人夢寐以求的“五個9”{![“兩個8”和“五個9”分別指系統(tǒng)能在88%和99.999%的時間內(nèi)可用?！g者注]}。穩(wěn)定性是在考慮任何其他問題之前，都必須考慮的先決條件。如果系統(tǒng)每天都會崩潰和停機，人們就不會關(guān)心其他事情了。在這種情況下，主要的工作就是進(jìn)行短期修復(fù)，目光也會變得短淺。沒有穩(wěn)定性，系統(tǒng)就沒有可行性。所以，本書會從為系統(tǒng)打造穩(wěn)定的基礎(chǔ)開始講起。
確保穩(wěn)定性之后，下一個要考慮的是持續(xù)的運維。第二部分討論系統(tǒng)在生產(chǎn)環(huán)境中運行究竟意味著什么。我們需要應(yīng)對現(xiàn)代生產(chǎn)環(huán)境的復(fù)雜性——虛擬化、容器化、負(fù)載均衡和服務(wù)發(fā)現(xiàn)的各種細(xì)節(jié)。這一部分將描述一些良好的模式，以幫助物理數(shù)據(jù)中心和云環(huán)境實現(xiàn)可控性、明晰性和可用性。
第三部分討論部署。對于將軟件部署到服務(wù)器，市面上已經(jīng)有了一些很棒的工具。但事實證明，這只解決了問題中很簡單的那部分。在將小變更頻繁地推送給消費者的同時，又不打擾他們，這讓問題變得困難了許多。這一部分先討論如何針對部署進(jìn)行設(shè)計，以及如何在不停機的情況下進(jìn)行部署，然后討論在不同的服務(wù)之間如何進(jìn)行版本控制——這總是一個棘手的問題！
第四部分從整個信息生態(tài)系統(tǒng)的視角，探究發(fā)生在其中的那些讓系統(tǒng)持續(xù)運行的活動。如果1.0版本的發(fā)布意味著該系統(tǒng)的誕生，那么之后則需要考慮其成長和發(fā)展。這一部分將討論如何構(gòu)建能隨著時間的推移不斷成長、伸展和適應(yīng)的系統(tǒng)。這包括進(jìn)化式架構(gòu)和跨系統(tǒng)進(jìn)行共享的“知識”。最后會討論如何通過新興的“混沌工程”學(xué)科，以構(gòu)建反脆弱系統(tǒng)?！盎煦绻こ獭笔褂秒S機性并通過故意地給系統(tǒng)施壓以改善系統(tǒng)。
案例研究
本書會用幾個擴(kuò)展的案例研究，以刻畫其所涉及的幾個主題。這些案例研究來自我親身觀察過的真實事件和系統(tǒng)失效。這些系統(tǒng)失效導(dǎo)致了慘重的損失，并讓那些參與其中的人們感到難堪。因此，本書特意對一些信息進(jìn)行了模糊處理，以保護(hù)牽涉其中的公司和員工。另外，其中涉及的系統(tǒng)、類和方法的名字也做了改動。然而，所有的改動僅限于這些不重要的細(xì)節(jié)。每個案例所屬的行業(yè)、事件的順序、系統(tǒng)失效方式、差錯的蔓延和后果，都原汁原味地保留下來。案例研究并沒有夸大這些系統(tǒng)失效的損失。它們都發(fā)生在真實的公司身上，損失的都是一捆捆的鈔票。之所以保留這些數(shù)字，就是為了強調(diào)本書的嚴(yán)肅性。當(dāng)系統(tǒng)出現(xiàn)失效時，真金白銀就懸了。
在線資源
在本書的網(wǎng)頁{![https://pragprog.com/titles/mnee2/46]}上，可以閱讀更詳細(xì)的信息，下載源代碼，在論壇上發(fā)帖，并可報告勘誤信息（如筆誤和對本書內(nèi)容的建議）。如果想與其他興趣相投的讀者聊天，并分享對本書的評論，那么論壇就是理想的場所。
現(xiàn)在就開始介紹生產(chǎn)環(huán)境的生存法則。
第1章 生產(chǎn)環(huán)境的生存法則
在項目上努力工作了許久，看起來所有的特性都已實現(xiàn)，甚至大多數(shù)都有了自動化測試?？梢运梢豢跉饬恕Ｍ晔聝毫?。
真的完事兒了嗎？
“特性已實現(xiàn)”是否就意味著“就緒可上線”？系統(tǒng)是否真的萬事俱備只待部署？是否真的可以放心地將系統(tǒng)移交給運維部門，并且任其面對現(xiàn)實世界中的大批用戶？此時，內(nèi)心深處是否開始泛起一股即將面臨深夜緊急電話和系統(tǒng)告警的不詳之感？事實證明，軟件開發(fā)除了添加所需特性之外，要做的事情還多著呢。
如今，學(xué)校里的那些軟件設(shè)計課程極其片面。這些課程只是討論系統(tǒng)“應(yīng)該”做什么，卻沒有解決相反的問題——系統(tǒng)“不應(yīng)該”做什么。系統(tǒng)不應(yīng)該崩潰、停止響應(yīng)、丟失數(shù)據(jù)、侵犯隱私、損失金錢、摧毀公司，或者奪去顧客的生命。
項目團(tuán)隊的目標(biāo)往往是通過QA{![QA是Quality Assurance的縮寫，即質(zhì)量保證，本書指軟件測試。——譯者注]}部門的測試，而不是通過生產(chǎn)環(huán)境的生存考驗。也就是說，團(tuán)隊的大部分工作都是想方設(shè)法地通過測試。但即使是做了敏捷的、務(wù)實的和自動化的測試，也不足以證明軟件已經(jīng)為現(xiàn)實世界做好了準(zhǔn)備。來自現(xiàn)實世界的壓力和重負(fù)，伴隨著亢奮狂熱的真實用戶、全球范圍的網(wǎng)絡(luò)流量和在聞所未聞的國家編寫病毒軟件的家伙，都遠(yuǎn)遠(yuǎn)超出了所能期望的測試范圍。
請面對現(xiàn)實：計劃再周詳，仍會出狀況。當(dāng)然，盡可能防患于未然總是好的。但是，誤以為自己已經(jīng)預(yù)見和消除了所有可能的不良事件并能萬事大吉，這是最要命的。一方面要采取行動以預(yù)防那些能夠預(yù)防的事情，另一方面要確保系統(tǒng)在整體上能夠從任何未曾預(yù)料到的重創(chuàng)中恢復(fù)過來。
1.1 瞄準(zhǔn)正確的目標(biāo)
大多數(shù)軟件都是為軟件開發(fā)實驗室或QA部門的測試工程師設(shè)計的。其設(shè)計和構(gòu)建的目的，是為了通過諸如這樣的測試——“顧客的姓氏和名字都是必需的，但中間名的首字母是可選的”。這些軟件的目標(biāo)，是能在QA所營造的人工環(huán)境中（而不是在現(xiàn)實世界的生產(chǎn)環(huán)境中）運行正確。
今天的軟件設(shè)計類似于20世紀(jì)90年代早期的汽車設(shè)計，它們都與現(xiàn)實世界脫節(jié)。那些汽車在涼爽舒適的實驗室中被設(shè)計出來，模型和CAD圖紙看起來都很絕妙。那些曲線完美的汽車，在巨型風(fēng)扇前發(fā)亮，在穩(wěn)定氣流中低鳴。處在這種寧靜空間里的設(shè)計師所做出的設(shè)計，既是那么地優(yōu)雅、復(fù)雜、精巧，又是那么地脆弱、不中用，并且最終早早夭折。如今大多數(shù)的軟件架構(gòu)和設(shè)計，都在同樣干凈和不接地氣的環(huán)境中進(jìn)行著。
一輛汽車看起來很漂亮，但它能在路上行駛的時間卻少于在店里陳設(shè)的時間，這種車有人要嗎？當(dāng)然沒人要！人們想要的是專為現(xiàn)實世界設(shè)計的汽車，它的設(shè)計師應(yīng)該知道：超過換油里程之后，司機會再繼續(xù)行駛5000公里才會去換油；磨損到只剩下最后十六分之一胎紋厚度的舊胎，必須和新胎一樣工作良好；當(dāng)一手拿著雞蛋麥滿分三明治，另一手拿著手機時，司機會猛踩剎車。
當(dāng)系統(tǒng)通過QA測試后，是否就能拍著胸脯說系統(tǒng)已為進(jìn)入生產(chǎn)環(huán)境做好了準(zhǔn)備？僅通過QA測試并不能證明系統(tǒng)在未來3～10年的適用性。這個系統(tǒng)可能是軟件中的豐田凱美瑞，可以連續(xù)正常運行數(shù)千小時；或者可能是軟件中的雪佛蘭Vega（一款在公司自家測試道路上跑得斷為兩截的汽車）；抑或是軟件中的福特Pinto（一款連平常追尾都易引爆起火的汽車）。幾天甚至幾周的測試，不可能說明該系統(tǒng)未來幾年會怎樣。
制造業(yè)的產(chǎn)品設(shè)計師一直在追求“可制造性設(shè)計”。這種設(shè)計產(chǎn)品的工程方法能夠讓人們以低成本和高質(zhì)量的方式制造產(chǎn)品。而在這個時代之前，產(chǎn)品設(shè)計師和制造商都各自生活在自己的世界里。那些無法擰動的螺釘、容易混淆的零部件，以及本可利用現(xiàn)成零件進(jìn)行替代的定制零件，都是受這兩個世界之間高墻影響的設(shè)計的具體體現(xiàn)。這些設(shè)計不可避免地導(dǎo)致了低質(zhì)量和高成本。
今天，我們正面臨類似的狀況。我們無法交付合格的新系統(tǒng)，因為我們一直在接聽請求技術(shù)支持的電話，試圖解決之前匆忙交付的系統(tǒng)所遭遇的問題。軟件行業(yè)的“可制造性設(shè)計”，就是“為生產(chǎn)環(huán)境而設(shè)計”。我們雖然不會將設(shè)計交給制造商，但會將完成的軟件交給運維部門。我們既需要設(shè)計一個個彼此獨立的軟件系統(tǒng)，也需要設(shè)計由相互依賴的系統(tǒng)所組成的整個生態(tài)系統(tǒng)，從而以低成本和高質(zhì)量的方式進(jìn)行運維工作。
1.2 應(yīng)對不斷擴(kuò)大的挑戰(zhàn)范圍
在客戶機/服務(wù)器系統(tǒng)盛行的那段輕松悠閑的日子里，系統(tǒng)的用戶也就幾十或幾百人，并發(fā)用戶最多也只有幾十個。今天，活躍用戶的數(shù)量常常大于整個大洲的人口數(shù)量。這指的可不只是南極洲和大洋洲！第一個擁有10億用戶的社交網(wǎng)絡(luò)已經(jīng)誕生，而且這也絕對不會是最后一個。
對系統(tǒng)正常運行時間的要求也提高了。相比曾經(jīng)專屬于大型機及其管理員的著名的“五個9”（99.999％），現(xiàn)在即便是最普通的商務(wù)網(wǎng)站，也期望能達(dá)到“24乘7乘365”（這個說法一直困擾著我。作為工程師，我認(rèn)為應(yīng)該要么說“24乘365”，要么說“24乘7乘52”）。顯然，考慮到軟件如今的規(guī)模，我們已經(jīng)取得了長足的進(jìn)步。但是隨著用戶觸點和系統(tǒng)規(guī)模的增加，系統(tǒng)遭到破壞的方式也會翻新，環(huán)境會變得更加惡劣，人們對缺陷的容忍度會變得更低。
這個正在不斷擴(kuò)大的挑戰(zhàn)范圍（即快速地構(gòu)建軟件，以達(dá)到低成本構(gòu)建、低成本運維，并且對用戶友好），要求我們持續(xù)改進(jìn)架構(gòu)和設(shè)計技術(shù)。當(dāng)把適用于小型WordPress網(wǎng)站的設(shè)計，應(yīng)用于大規(guī)模的事務(wù)性分布式系統(tǒng)時，會出現(xiàn)重大的系統(tǒng)失效問題。后面會談一些重大的系統(tǒng)失效案例。
1.3 多花5萬美元來節(jié)省100萬美元
很多事情都岌岌可危：項目的成功、股票期權(quán)或分紅、公司的生存，甚至手中的飯碗。那些以通過QA測試為目標(biāo)的系統(tǒng)，通常都需要高昂的持續(xù)投入，這包括運維、停機和軟件維護(hù)所帶來的成本。這樣的系統(tǒng)永遠(yuǎn)都無法實現(xiàn)盈利，更不要說幫助公司獲得凈利潤（只有當(dāng)系統(tǒng)所創(chuàng)造的收入超過其自身的構(gòu)建成本時，才能實現(xiàn)）。這些系統(tǒng)所表現(xiàn)出的低可用性，會直接導(dǎo)致公司收益受損，并間接導(dǎo)致品牌形象受損。
在忙碌的軟件開發(fā)項目中，輕易就能做出“用前期低成本開發(fā)，換取后期高成本運維”這樣的決策。但只有在團(tuán)隊的預(yù)算和交付日期都固定的情況下，這樣做才有意義；從甲方花錢開發(fā)軟件的角度看，這是一個糟糕的決策。因為如果系統(tǒng)不被取消或報廢，那么在其整個生命周期中，運維時間要遠(yuǎn)比開發(fā)時間長。為了節(jié)省一次性的開發(fā)成本，卻要耗費無盡的運維成本，這樣做沒有意義。事實上，從財務(wù)角度看，反其道而行之會更有意義。假定系統(tǒng)每次發(fā)布時都需要5分鐘的停機時間，該系統(tǒng)會使用5年，且每月發(fā)布一個新版本（雖然大多數(shù)公司希望能夠更頻繁地發(fā)布新版本，但此處僅作非常保守的假設(shè)），這樣就可以計算一下該系統(tǒng)停機時間的預(yù)期成本，并考慮未來5年的貨幣利率。這樣計算下來，成本大概為100萬美元（300分鐘的停機時間，保守地按每分鐘產(chǎn)生3000美元的成本計）。
現(xiàn)在假設(shè)可以投資5萬美元以創(chuàng)建構(gòu)建流水線和部署流程，從而實現(xiàn)不停機發(fā)布。這樣做至少可以避免100萬美元的損失，而且可以提高系統(tǒng)部署頻率，有利于占領(lǐng)更多市場份額。如果僅看其20倍的投資回報率，那么大多數(shù)首席財務(wù)官都不會介意花費區(qū)區(qū)5萬美元！
設(shè)計決策和架構(gòu)決策，也是財政決策。在做出選擇時，必須著眼于實施成本和下游成本。能同時從技術(shù)和財政的視角看問題，是本書的一大要點。
1.4 讓“原力”與決策同在
早期決策會對系統(tǒng)的最終形態(tài)產(chǎn)生巨大的影響。最早做出的決定可能是最難以反悔的。那些關(guān)于系統(tǒng)邊界和子系統(tǒng)劃分的早期決策，會影響團(tuán)隊結(jié)構(gòu)、資金分配、項目集管理結(jié)構(gòu)，甚至工時表代碼。團(tuán)隊的任務(wù)分派決定了系統(tǒng)架構(gòu)的雛形。非常具有諷刺意味的是，早期決策恰恰是在信息最不完備的時候做出的。團(tuán)隊在啟動項目時，最不了解軟件的最終架構(gòu)，卻偏偏要在那時必須做出一些最不可能更改的決定。
必須承認(rèn)，我是敏捷開發(fā)的支持者。注重盡快交付和漸進(jìn)式改進(jìn)，能讓軟件快速上線。由于只能通過生產(chǎn)環(huán)境，才能了解軟件如何響應(yīng)來自現(xiàn)實世界的請求，因此應(yīng)該提倡盡快發(fā)布軟件，以獲得反饋并從中學(xué)習(xí)。即使是在敏捷項目中，也需要有遠(yuǎn)見才能做出最好的決策。這好比設(shè)計師必須使用“原力”{![作者借用科幻電影《星球大戰(zhàn)》所虛構(gòu)的“原力”（一種超自然而又無處不在的神秘能量場），來比喻軟件發(fā)布與現(xiàn)實世界的互動關(guān)系?！g者注]}去看未來，才能選擇最穩(wěn)健的設(shè)計。雖然不同的設(shè)計方案通常具有相近的實施成本，但這些方案在整個軟件生命周期中的總成本，卻截然不同。因此重點是要考慮每個方案對系統(tǒng)可用性、容量和靈活性的影響。本書會展示數(shù)十種能對開發(fā)階段下游產(chǎn)生影響的設(shè)計方案，以及各種有益和有害方法的具體示例。這些例子都來自我所遇到過的真實系統(tǒng)。其中的大多數(shù)都曾讓我輾轉(zhuǎn)難眠。
1.5 設(shè)計務(wù)實的架構(gòu)
一般來說，存在兩種不同類型的架構(gòu)。一種類型的架構(gòu)側(cè)重于更高層次的抽象，以便于跨平臺移植，并且基本不會與諸如硬件、網(wǎng)絡(luò)、電子和光子這些混亂的細(xì)節(jié)產(chǎn)生直接關(guān)系。這種架構(gòu)的極端形式產(chǎn)生了下面描述的“象牙塔”。在極具庫布里克風(fēng)格的整潔的房間里，坐著冷漠的大人物，每面墻上都裝飾著一個個方塊和箭頭。從象牙塔中傳出來的命令降臨到一個個辛勞的程序員頭上：“中間件應(yīng)該永遠(yuǎn)用JBoss！” “所有的UI都應(yīng)該使用Angular 1.0來構(gòu)建！” “現(xiàn)在的一切，以及過去和將來的一切，都要永遠(yuǎn)保存到Oracle中！” “你不應(yīng)該搞Ruby！”如果有人曾經(jīng)咬緊牙關(guān)編寫符合“公司標(biāo)準(zhǔn)”的代碼，而用其他技術(shù)來做卻能輕松10倍，那么他就是象牙塔架構(gòu)師的受害者。沒心思傾聽程序員心聲的架構(gòu)師，肯定也沒心思聽取用戶的意見。這樣的結(jié)果已經(jīng)有目共睹：當(dāng)系統(tǒng)崩潰時，用戶會為此歡呼，因為至少他們可以有一段時間不必使用它了。
相比之下，另一種架構(gòu)師不僅會和程序員打招呼，而且也把自己當(dāng)作程序員。這種架構(gòu)師會毫不猶豫地審視一個個抽象，如果發(fā)現(xiàn)不適用就會舍棄。這樣務(wù)實的架構(gòu)師更可能討論諸如內(nèi)存使用情況、CPU的需求、帶寬的需求，以及超線程和CPU綁定的優(yōu)缺點等問題。
象牙塔架構(gòu)師最享受絕對完美的最終狀態(tài)，但務(wù)實的架構(gòu)師會不斷思考變化中的狀態(tài)：“如何在不重新啟動的情況下進(jìn)行部署？” “需要收集哪些指標(biāo)？如何對它們進(jìn)行分析？” “系統(tǒng)的哪個部分最需要改進(jìn)？”
當(dāng)象牙塔架構(gòu)師的工作完成之后，系統(tǒng)不能再做任何改進(jìn)，系統(tǒng)的每個部分都將完美地扮演自己的角色。與之相反，務(wù)實的架構(gòu)師所設(shè)計的系統(tǒng)，其中每個組件都足以滿足當(dāng)前的負(fù)荷；并且，當(dāng)負(fù)荷隨著時間的推移發(fā)生變化時，架構(gòu)師知道要替換哪些組件。
對于務(wù)實的架構(gòu)師，本書為其備好了強大的武器。對于能堅持讀到這里的象牙塔架構(gòu)師，本書或許能吸引他們?nèi)サ魩讓映橄?，以便重新獲得軟件、硬件和用戶這三者之間重要的交集：生產(chǎn)環(huán)境的生存法則。當(dāng)系統(tǒng)終于發(fā)布時，架構(gòu)師、用戶和公司都將會更加快樂！
1.6 總結(jié)
軟件只有運行在生產(chǎn)環(huán)境中才能產(chǎn)生價值。開發(fā)、測試、集成和規(guī)劃……這些在上線前所做的一切，都僅僅是前奏。從系統(tǒng)的最初發(fā)布，到持續(xù)成長，再到不斷進(jìn)化，本書會討論這些階段在生產(chǎn)環(huán)境中的生存法則。第一部分將討論穩(wěn)定性。為了更好地理解如何避免軟件崩潰所導(dǎo)致的各種問題，讓我們首先看看造成航空公司停飛的軟件缺陷。
