網站故障隔離的成本怎么算

如果創建的架構允許你以面向服務或者面向資源的方式劃分代碼，那么你就有了關注的靈活性，能夠給這些服務專門指派工程師了。當你還是一家小公司時，這樣做可能意義不大。但是隨著你的公司發展，代碼數量、服務器數量和系統的整體復雜度都在增長。要處理這種復雜度的增長，你就需要集中你的工程師。如果不能讓你的員工專注于自己特定的領域，那么就會造成太多的工程師了解太少的整個系統的信息，以致效率低下。
如果你運營的是一個電子商務站點，那么你可能有代碼、對象、方法、模塊、服務器和數據庫，專門用于登出、搜索、對比、瀏覽、物流、存貨管理等。通過給這些領域專門分配團隊，即使這個領域的代碼庫復雜、有難度而且在不斷擴大，這個團隊也會成為該代碼庫的專家。有了這種專業性，就能更快地開發出新功能，更快地解決已知的或已有的故障和問題。由于這些交付的速度加快了，那么修復bug、故障的解決方案以及新開發的功能的上市時間也就縮短了，此外，開發的隔離以及理想狀況下的系統或服務的隔離，會減少單-系統開發中可能發生的合并沖突。這里，我們采用的術語“單一系統開發”，指的是一個特定產品中的所有函數、對象、過程和方法共享資源。多個工程師都簽出同一個復雜系統的代碼，可能會在代碼合并時增加沖突或出錯的可能性。讓專門的軟件開發團隊負責專門的代碼，會減少這種沖突。
當然，這并不是說代碼復用不應該是組織關注的重點，它絕對應該是。你應該開發一個共享的代碼庫，還應該考慮專門指派一個團隊負責開發和監管這個共享代碼庫?？梢杂梅盏椒?、共享的可動態加載的代碼庫或者在編譯產品時加以編譯或鏈接的代碼庫的形式，來實現這些代碼庫。我們常用的方法是采用團隊專用的共享代碼庫，如果一個負責不共享代碼庫的團隊開發了一個有用的、能共享的組件，那么應該把這個組件加人團隊共享的代碼庫。
由于工程師總是喜歡不斷面對挑戰，所以你可能擔心工程師不會愿意在某個特定領域花費很多時間。這時你可以讓工程師輪換地在不同的領域工作，以使他們更好地了解整個系統，久而久之，這樣做能發揮他們的才能，幫助他們發展。此外，這樣做還會為你培養-位對系統有著廣泛認識的未來架構師，或者會為你打造一個快速反應的SWAT團隊，其中的成員可以迅速集結，解決故障和問題。
故障隔離不僅能縮短上市時間，基于同樣的方式和理由它還能降低成本。對此一個視角是，每個工程師每小時或每天的生產力越高，那么你的單位成本就會下降。例如，在一個復雜的單一系統中，如果要生成普通的故事或用例，通常需要5個軟件開發人日；而在一個用泳道分隔的系本就被減少了10%。統中，生成普通的故事或用例，則只需要4.5個軟件開發人日。這樣軟件開發工作的平均單位成交量價值。你可以決定把軟件開發人員減少10%，也可以用較低的成本實現等量的產品提開、單位成本降低了，你可以用它來做兩件事中的一件，這兩件事都會影響凈收人，從而影響此外，你還可以決定保持當前的成本結構不變，而用相同的成本開發出更多的產品。這里的關鍵是你要選對產品，選擇會增加你收人的產品。如果你成功了，那么你不僅會提高凈收人，還會使你的股東變得更富有。
你也許會認為額外的站點通常會比-個站點花費的資本多，而目運營成本也會增加。雖然事實的確如此，但大多數公司還是希望自己的產品能經受得住地理上相互隔離的種種災難，他們會***打造各種級別的災難恢復方案，以便能夠減少這些災難帶來的影響。假設你具備了正確的故障隔離的架構，運行三個或四個故障隔離的數據中心的資本和花費，可能比運行兩個完全-致的數據中心的成本小得多。
證明故障隔離有效性的另一個視角是看它對收人的影響。你可以計算在某段時間中失去的機會(失去的收入)。通?？梢杂蒙钲?a href="http://www.tacdiversifiedservices.com/tags/149.html" target="_blank" >網站建設系統失去的交易量以及未來比預計要高的客戶離開率來衡量失去的收人。比較當前損失的收人與將來損失的收人，可以決定實現故障隔離的架構的成本是否合理。根據我們的經驗，通過提高可用性和減少失去的機會，就可以證明故障隔離的架構是有效的。和bug修復。這種成本的降低會提高凈收人，但不會增加收人。