「 最近的一個業務事件，引發了一個哲學思考。」
web
咱們管理的核心繫統是一個服務於全球包括亞洲和歐洲10個國家或地區的單體應用（所謂的Global System）。編程
最近某個國家的業務接入了新的客戶，單單這個客戶增長的交易量就是咱們現有全部國家或地區的交易量的50%。服務器
面對這樣的交易量激增，做爲系統運維負責人，咱們固然要對業務提出「嚴正交涉」。因爲接入這個客戶的過程並不須要系統變動，業務並無意識到接洽這個客戶的過程須要咱們IT參與。微信
按照正常程序，這樣的交易量增長，實際上是一種變動，業務應該事前知會咱們。當咱們評估這個變動對現有系統的運能和性能有潛在風險時，咱們應該先組織全面的性能測試。這應該是業務和客戶簽署合同前就應該作的。架構
然而，此次的狀況是，當咱們獲悉這個信息時，業務和客戶的合同已經簽署，咱們也沒法叫停這個過程。只能增強性能監控。app
幸運的是，儘管實際增長的交易量比業務預估的還要高，達到80%，系統的各項性能指標並無太大波動。框架
可是，業務也預告，這個客戶將開放移動平臺，未來的交易量多是如今的100倍！運維
不過從此次觀察能夠得出一個不成熟的結論，就是因爲交易數據只是其中一種數據，如今看來，若是隻是交易數據增長，對系統的運能和性能的影響沒有咱們想象中大。微服務
這件事情給我最大的困惑是，雖然咱們說要作全面的性能測試，可是咱們是一個系統支撐全球10個國家或地區的業務。也就是說，當某個國家的業務在進行時，其餘國家或地區的業務也在進行，並且各個國家或地區在同一時點處理的具體業務是不同的。工具
咱們如何在測試環境模擬這樣的場景，從而得出讓本身信服的性能測試數據呢？我目前是沒有答案的。
而像咱們這樣的系統，一個系統支撐全球10個國家或地區的業務，是一個複雜（Complex）的系統。
01
—
支持全球業務的兩套系統方案
像咱們這樣，要支持全球10個國家或地區的業務，實際上是有兩種方案的：
方案一：像咱們如今這樣，一個系統支撐全球10個國家或地區的業務；
方案二：一個系統支持一個國家或地區，搭建和維護10個系統。
這兩套方案各有利弊。
方案一的好處：
只須要搭建、維護和監控一套服務器環境；
全球都須要的需求只須要開發一次，只須要維護一套代碼；
每次變動發佈上線只須要在一套環境作一次；
基礎設施升級，好比升級硬件、OS升級、SDK升級等，只須要在一套環境作一次。
方案一的壞處：
當系統出現嚴重故障或性能問題，全球業務都會受到影響；
當有故障或修復上線須要重啓時，全球業務都要中斷；
系統維護時間須要遷就全球各地的業務時間，致使維護時間被嚴重壓縮，難以增長上線頻率，實現按需發佈，增長實現DevOps的難度；
難以在測試環境模擬生產環境的場景，難以經過性能測試得到可信數據；
不一樣國家或地區都有本地需求和監管要求，系統代碼會愈來愈臃腫，變成「怪獸系統」，變動成本高，交付週期長，難以實現敏捷交付；
變動一旦出現Bug，可能致使全球業務受影響，變動風險高；
出現故障或性能問題時，排查難度大，難以在測試環境復現問題；
當某個變動涉及的功能是全球都要用的，上線前咱們需求收集各個國家或地區業務的測試簽署。但一般這個變動請求是來自於某一個國家或地區的，其餘國家或地區的業務沒有意願進行測試，拿簽署的過程很是困難，拉長了上線週期。
把方案一的好處和壞處反過來就是方案二的利弊。這個不難理解。
02
—
複雜（Complex）與繁雜（Complicated）
其實，這兩套方案映射的是兩類問題。方案一要面對的是複雜（Complex）問題；方案二要面對的是繁雜（Complicated）問題。
方案一中的這個「全球系統」（Global System）是一個複雜系統，其背後有很是多不可見的依賴，並且這些依賴及其關係都是變量，難以預測，難以管理。
方案二會衍生出不少系統（Local System）和不少套服務器環境，是一個繁雜的系統，須要管理的元素要比方案一多不少，但因爲每一個被管理的元素相對簡單和單純，基本上可視做常量，管理的功夫多，但難度低，也能夠經過平臺和工具減小管理的功夫。
其實，選擇方案一仍是方案二，就是選擇到底咱們要處理一個複雜問題，仍是一個繁雜問題的問題。
近年流行的微服務架構，其實就是把一個複雜問題（單體系統）轉換成一個繁雜問題（以架構的繁雜取代單個應用的複雜）。
前文提到的性能測試困惑，在方案二中，也會變得簡單不少。
業內整個運維趨勢也在從關注個體系統的健壯性過渡到業務的連續性。
以上思考也讓我聯想到了如下的Cynefin框架。
Cynefin是由Dave Snowden在知識管理和組織戰略中提出的一個概念框架，用於輔助領導者認知問題並進行決策。簡單說，這個框架將問題域進行劃分，把咱們可能會遇到的形形色色的各類問題歸類爲五種，分別是簡單，繁雜，複雜，混亂以及失序。不一樣領域的問題，應當採起不一樣的解決策略。僅供參考。
03
—
總結
面對紛繁複雜的業務，IT系統也必然會映射業務的複雜性，咱們沒法迴避。解決這種複雜性有兩種方案，也是一個拆合的問題，分別對應的是複雜（Complex）問題和繁雜（Complicated）問題，你會選擇複雜仍是繁雜呢？
相關閱讀：
關於做者
劉華（Kenneth）
就任於世界500強銀行，負責基金服務業務軟件開發與交付
敏捷、精益、DevOps專家
精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧
曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會、ArchSummit等論壇發表主題演講
著有《獵豹行動：硝煙中的敏捷轉型之旅》一書
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字「獵豹 敏捷」便可找到。點擊閱讀原文可直接購書。
有聲書已登陸喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其餘原創做品
以爲好看，點個「在看」或轉發給朋友們，歡迎你留言。
本文分享自微信公衆號 - 敏於思 捷於行（kennethz2016）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。