西方有句諺語叫做："an elephant in the room"。

用以指代那些顯而易見又容易被忽視的東西。

這些東西是什么呢？

"an elephant"：我們可以解釋為那些重要的，困難的或者棘手的。

這里我們要討論的則是架構(gòu)中的"大象"：業(yè)務(wù)價值。

通常我們做架構(gòu)評估的時候，一般會對關(guān)聯(lián)系統(tǒng)的性能，容錯彈性，業(yè)務(wù)擴展性等進行論證，但很少會考慮各個系統(tǒng)的業(yè)務(wù)價值以及這些業(yè)務(wù)價值和前述架構(gòu)特性之間的關(guān)系。

沒有這些價值關(guān)聯(lián)的理解，對于架構(gòu)設(shè)計中的一些關(guān)鍵因素選擇就會很難做決定。

交易系統(tǒng)容錯

以向交易系統(tǒng)添加容錯機制為例，通常需要花費大概幾萬到幾十萬不等。那么這筆錢到底值不值得花呢？

做這個決定的前，要先了解系統(tǒng)所承載的業(yè)務(wù)價值，如果是日億級的交易量業(yè)務(wù)，那么上面所說的花費就顯得微不足道，是否添加容錯機制這個架構(gòu)元素也就更容易做決策了。

這里舉上述這個例子，并不是為了申述架構(gòu)團隊在做決策時容易忽略業(yè)務(wù)價值因素這個問題。相反，這個點的考慮也已成為了普遍會進行考量的關(guān)鍵點。這里所要重點指出的是，很多時候，架構(gòu)團隊并不能很好的明晰各個系統(tǒng)所承載的業(yè)務(wù)價值是什么？價值的量是多少？不同系統(tǒng)模塊對業(yè)務(wù)表現(xiàn)的貢獻？

保險公司系統(tǒng)微服務(wù)化

一個保險公司確定要將公司的單體服務(wù)拆分為產(chǎn)品線維度微服務(wù)（家庭險、個人險、車險等），但是它們對不同業(yè)務(wù)線對公司利潤的貢獻比例不甚清楚。那么這種情況下需要優(yōu)先考慮哪些決策因素呢？可以肯定的是首先需要拆分出的一定不是價值最高的業(yè)務(wù)，因為第一次拆分必然會伴隨著許多不定性的風(fēng)險。前期非核心系統(tǒng)遷移的試錯，經(jīng)驗積累必不可少。

一、核查架構(gòu)價值流映射

首先要做的是針對架構(gòu)中的每一個系統(tǒng)模塊，構(gòu)建其價值映射。也就是每個系統(tǒng)對應(yīng)的業(yè)務(wù)價值映射。

企業(yè)通過業(yè)務(wù)系統(tǒng)來服務(wù)外部客戶，客戶在使用企業(yè)的服務(wù)時都會遵循特定的行為步驟。

以用戶購買商品為例，用戶通常會執(zhí)行登錄、查詢商品、對比價格、下單、支付，查看訂單、跟蹤物流，商品簽收，服務(wù)評價等一系列操作。用戶每一個操作行為都對應(yīng)于業(yè)務(wù)系統(tǒng)特定的服務(wù)模塊?；诖?，我們可以明晰每個業(yè)務(wù)系統(tǒng)模塊對于服務(wù)用戶這個商業(yè)行為的貢獻價值，以及各個環(huán)節(jié)的失敗影響。

二、考量系統(tǒng)異常的業(yè)務(wù)價值影響

我們評估一個業(yè)務(wù)系統(tǒng)模塊的價值的時候，除了有明確的其承載的業(yè)務(wù)價值的標(biāo)準(zhǔn)，對于哪些無法明確考量的（如底層數(shù)據(jù)庫，存儲等）模塊，我們可以從另外一個角度來估量：失敗異常會造成的損失。

例如，在某個重大節(jié)日大促將要到來之前，研發(fā)排期里已經(jīng)羅列很多業(yè)務(wù)功能 feature 迭代需求。此時，要如何將一個看似和業(yè)務(wù)無關(guān)的“數(shù)據(jù)庫災(zāi)備、恢復(fù)演練”需求插入到日程里呢？

此時，只需要提出如下問題即可：假如節(jié)日大促時，數(shù)據(jù)庫服務(wù)宕機了，會造成多大的損失？希望數(shù)據(jù)庫服務(wù)能在多長時間內(nèi)恢復(fù)？

在評估業(yè)務(wù)價值風(fēng)險時可以通過如下兩種方式：

1、自上而下，跟蹤業(yè)務(wù)功能流程并識別支持每個流程節(jié)點的業(yè)務(wù)系統(tǒng)。

2、自下而上，檢查各個業(yè)務(wù)系統(tǒng)，分析其失敗所影響的業(yè)務(wù)功能。

風(fēng)險考量另一個需要關(guān)注的點是：不同的失敗異常所可能引發(fā)的影響不同。不同的業(yè)務(wù)系統(tǒng)所需要的系彈性是不同的。

例如，人門對開盤日宕機的股票交易系統(tǒng)和一時無法使用的內(nèi)部報銷系統(tǒng)的容忍系數(shù)是完全不同的。達成何種彈性界別完全一種業(yè)務(wù)決策

還有常見的“數(shù)據(jù)一致性”問題也是同樣的道理，例如在對待分布式數(shù)據(jù)存儲時，相對于可用性，架構(gòu)師更傾向于追求數(shù)據(jù)一致性表現(xiàn)。但是就商業(yè)層面來看，以訂票業(yè)務(wù)為例，重復(fù)訂票反而是無傷大雅，人們更加不愿意看到的是無法訂票這種情景。

就如我們經(jīng)常會談?wù)摰降腃AP理論一樣，CP ？ 還是 AP ？ 從來都是一個業(yè)務(wù)決策，而不是技術(shù)決策。

三、基于業(yè)務(wù)價值評非功能需求

在評估功能價值時，不應(yīng)只關(guān)注單一的業(yè)務(wù)功能，還要考慮如系統(tǒng)質(zhì)量、兼容性、穩(wěn)定性等非功能性需求。

如果我們想要系統(tǒng)達到某些技術(shù)標(biāo)準(zhǔn)，那么我們就需要讓非技術(shù)人員了解到，如果達不到這些標(biāo)準(zhǔn)將會失去什么樣的業(yè)務(wù)價值。

評估非功能更性需求價值通常都比較困難，許多技術(shù)人員也常常會回避由此產(chǎn)生的爭論。但是避而不談則會產(chǎn)生比低價值技術(shù)投入更大的危害，同時也會在技術(shù)人員和非技術(shù)人員之間產(chǎn)生更大的合作障礙。

以業(yè)務(wù)價值的理解和組件靈活性需求決策為例，某個客戶的支付處理組件是由特定的支付處理供應(yīng)商提供服務(wù)的?，F(xiàn)在客戶想要將支付組件升級為可配置化，這樣就能夠更好的應(yīng)對支付供應(yīng)商的變化。要實現(xiàn)這個需要有兩種方案可選，一是將和服務(wù)提供商的交互邏輯進行硬編碼處理，二是將所有的交互邏輯可配置化。但是，交互邏輯可配置化處理必然會增加支付組件的復(fù)雜性及其它變更的成本，這也會是一個相當(dāng)大的投入。然而，通常支付提供商變更的商務(wù)談判交互會就會花費相當(dāng)長的時間，這里或許根本不需要支付組件上的快速配置變更，反而，低成本的硬編碼處理更加適合。

四、非功能性需求業(yè)務(wù)價值評估因組件而異

上述實例的闡述說明了在評估如系統(tǒng)彈性、靈活性等非功能性需求業(yè)務(wù)價值上不能單純的采取“一刀切”的統(tǒng)一標(biāo)準(zhǔn)。

例如，實現(xiàn)一個交易系統(tǒng)的5個9的可用性是合理的，但是對于一個內(nèi)部訂餐系統(tǒng)則是完全沒有必要。

對不同層級業(yè)務(wù)提供不同級別標(biāo)準(zhǔn)的服務(wù)系統(tǒng)是我們應(yīng)當(dāng)遵循的基本準(zhǔn)則。

特定服務(wù)的宕機是否會立刻影響到用戶體驗及收入？能否承受數(shù)據(jù)庫幾個小時的宕機，恢復(fù)損失？等等。

關(guān)于分析系統(tǒng)支撐業(yè)務(wù)價值，另一個需要關(guān)注的情景是：單個組件支撐多個業(yè)務(wù)價值流及不同業(yè)務(wù)價值流所需的不同級別可靠性。簡單來說就是公共服務(wù)組件問題，尤其在單體服務(wù)模式下更為明顯。這也促成了人們對微服務(wù)模式的追捧，關(guān)注核心價值業(yè)務(wù)并提供高級別服務(wù)系統(tǒng)。

五、基于監(jiān)控工具評估業(yè)務(wù)價值

監(jiān)控是必要且必需的。

隨著分布式大行其道，交互邏輯，交互流程日趨繁雜，監(jiān)控更是我們能夠把控服務(wù)健康狀態(tài)的必要工具。

監(jiān)控數(shù)據(jù)通常分為兩類：1、技術(shù)性指標(biāo)，這是術(shù)人員通常關(guān)注的；2、業(yè)務(wù)性指標(biāo)，則是我們這里所需要討論的，對評估業(yè)務(wù)價值非常有用的數(shù)據(jù)。

業(yè)務(wù)性監(jiān)控數(shù)據(jù)，如交易數(shù)據(jù)走勢，營收曲線，用戶活躍度等等，往往成為日常經(jīng)營決策基礎(chǔ)，更加科學(xué)化的以數(shù)據(jù)驅(qū)動企業(yè)發(fā)展。

六、只進行必要的核心業(yè)務(wù)上云

隨著云服務(wù)的日趨繁盛及成熟，很多企業(yè)都傾向?qū)⒆杂袠I(yè)務(wù)系統(tǒng)遷移至云上服務(wù)。遷移的過程通常會持續(xù)很長一段時間，在這段時間內(nèi)，云上，云下服務(wù)通常會并行運行。在這個過程中，人們通常會犯的一個錯誤是將所有服務(wù)完全的照搬到云上，簡單的理解為一個復(fù)制粘貼過程，這是非常不可取的。

上云應(yīng)該是一個優(yōu)化，提升的過程。我們前面論述過，核心價值的業(yè)務(wù)才是最值得關(guān)注的。另外，在歷久的業(yè)務(wù)迭代過程中，存在著許多無用的，低價值的，甚至對業(yè)務(wù)優(yōu)化形成干擾的功能。因此，上云之前應(yīng)該對整個業(yè)務(wù)系統(tǒng)進行充分的分析，拆解，提優(yōu)去糟，只將最核心，必要的的業(yè)務(wù)優(yōu)化上云。相對于完全的照搬策略，這樣反而更容易實施，roi更高。

七、業(yè)務(wù)價值重要且變化無常

架構(gòu)元素業(yè)務(wù)價值不是一成不變的，同樣一個業(yè)務(wù)，有發(fā)展，成熟，衰敗的漸變或驟變過程，因此相應(yīng)的價值映射也要做相應(yīng)的調(diào)整。

業(yè)務(wù)價值預(yù)估也是我們進行業(yè)務(wù)價值評估所必要做的工作，這其中的影響因素包括企業(yè)經(jīng)營決策，行業(yè)發(fā)展趨勢等不一而論。

比如，大數(shù)據(jù)模型由原來做推薦，然后跟隨趨勢支撐AI；核心的社區(qū)業(yè)務(wù)轉(zhuǎn)變?yōu)榉呛诵牡慕灰字螛I(yè)務(wù)等等。

八、技術(shù)職業(yè)生涯中的業(yè)務(wù)軟技能

做技術(shù)的人不能只關(guān)注技術(shù)，技術(shù)是利器，而業(yè)務(wù)知識則執(zhí)利器之手。

技術(shù)人員在掌握必要的技術(shù)技能同時，更多的應(yīng)該關(guān)注其所負(fù)責(zé)業(yè)務(wù)知識，邏輯，業(yè)務(wù)價值的產(chǎn)生，流動路線，變化發(fā)展規(guī)律，趨勢等。能夠深刻的理解怎么能用現(xiàn)有的技術(shù)更好的服務(wù)業(yè)務(wù)價值。

附：The Elephant in the Architecture

總結(jié)

以上是生活随笔為你收集整理的架构中的“大象”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。