要能勝任，或者為架構中的每個組件購買能勝任的解決方案。任何因特網(wǎng)服務或電子商務解決方案。為基礎設施中的每個組件，標識出團隊對它應負的責任以及應該具備的能力水平。對客戶來說，每個問題都是你的問題。你你不能責備供應商。你提供的是服務，不是軟件。

不要把能否勝任與自己開發(fā)還是外部購買或者與核心決策還是上下文決策的問題相混淆。你可以購買解決方案，但仍然要能勝任去部署和維護它們。事實上，客戶也要求你如此做。

也許你認為這條原則是不言而喻的:“對于我們所做的來說，我們當然是能勝任的，否則我們?nèi)绾伪３謽I(yè)務?”為了說明這個原則，我們假設你有一個因特網(wǎng)產(chǎn)品，如某種SaS平臺、電子商務產(chǎn)品或其他在因特網(wǎng)上交付的解決方案。



你的團隊對你采用的負載均衡器真正了解多少呢?你多久請求一次外部幫助來解決這些負載均衡器的問題或者實現(xiàn)新功能呢?你的數(shù)據(jù)庫又如何呢?你的開發(fā)人員或DBA知道如何判斷哪些表需要索引，哪個查詢運行得比夢愒四?你知道如何擔表移到文件系統(tǒng)上，減少爭用，提高整體生產(chǎn)力嗎?你的應用服務器又如何?誰是處理這些問題的專家?也許，你對所有這些問題的反應是，你并不需要親自做這些事情。你可能從其他人寫的書中讀到過，應該發(fā)現(xiàn)自己具有與眾不同的能力的領域，并專注于這些領域。然而判定一個組件是否“非核心”或者該組件究竟應該從外部購買還是自己開發(fā)，這并不應該與判斷團隊是否有相應的能力來掌控所購技術相混淆。使用第三方或開源數(shù)據(jù)庫絕對沒有問題，但這并不意味著你就不必了解數(shù)據(jù)庫，不必具備對它進行操作和故障檢修的相應能力。

你的客戶期望你交付給他們的是一個服務，而你開發(fā)一個獨一無二的軟件來創(chuàng)建這個服務只是實現(xiàn)目的的手段。歸根結(jié)底你是在一個服務業(yè)，這一點不要理解錯了。這是一種必需的心態(tài)，如果缺乏這種心態(tài)，事實證明這會造成公司退化甚至毀滅。 Friendster過于關注“朋友圈”(F-graph)，這是一種用來計算社交網(wǎng)絡中人際關系的復雜解決方案，可能是它在個人社交網(wǎng)絡竟爭中敗給 Facebook的原因之一。這種關注背后是一種態(tài)度，一種許多軟件商店都持有的態(tài)度，即“朋友圈”所提出出的難題必須得到解決。這種關注會造成站點服務中斷或者響應緩慢，因為系統(tǒng)在實時計算人際關系時會變得緩慢乃至停止運行。與之相反的是關注服務，即可用性和響應時間比任何特殊功能都重要。軟件只不過是提供服務的一種手段而已。

但在我們的世界中，你所需要的不只是軟件。基礎設施對以高可用性的方式按時處理事務來說也很重要。就像我們可能會過于關注解決方案中的一個問題一樣，我們也可能會忽略用來提供服務的架構中的其他組件。如果說，為了順利提供服務，我們必須在軟件方面能勝任，同樣我們必須在與此相關的其他方面也做到如此?？蛻羝谕玫降氖莾?yōu)秀的中的組1件出了故障，他們不會體諒你并不是井友者也不是這方面的專家，而且也不會關心這些。

因此，雖然你不必開發(fā)解決方案中的每一部分(事實上我們也不應該開發(fā)每一部分)，但卻要對每一部分都有所了解。對于我們采用的任何東西，我們都要能夠正確地加以使用和維護，并在它們發(fā)生故障時，能夠迅速地予以恢復。通過在自己的網(wǎng)站設計團隊內(nèi)發(fā)展這些技能或者尋求合作伙伴的支持，可以幫助我們做到這一點。團隊越大，對某個組件依賴越多，我們就越應該具有自己的專家。而團隊越小，相應組件的重要性越低，我們就越應該將事情交付給外包專家去做。但如果依賴合作伙伴提供幫助，那么你們之間的關系就應該不止于大多數(shù)設備供應商所提供的。這些服務供應商必須與你共擔風險。換句話說，他們需要在你的服務發(fā)生故障時，切身感受到你和你的客戶的痛苦。當客戶因為服務出現(xiàn)問題而對你大吼大叫時，你絕不能讓自己陷入這樣的境地，一方面要在這些供應商的等待隊列中苦苦等待，另一方面最終等到的卻不是高水準的支持。