前一段時間中國銀監會在“十三五”規劃當中提到銀行業應該穩步實施架構遷移並逐步過渡到雲端計算架構平臺，廣發證券在這方面做了很長時間的探索。

廣發證券於2014年Docker等容器技術尚未盛行之時開始投入容器化技術的研究，並於2015年開始大規模投入應用—成交量六百億（2015年）規模的金融電商平臺、訊息推送日均數千萬條級別的社會化投顧問答平臺以及日均流經交易量峰值近五十億的交易匯流排均被容器化；投入生產的容器化雲服務包括行情、資訊、訊息推送、自選股、統一認證、實時事件處理等。

我們研究和應用雲技術的動機，來源於對“黑天鵝”事件的應對。“黑天鵝”這一概念，是在美國學者、風險分析師、前量化交易員、前對衝基金經理塔勒布（Nassim Nicholas Taleb）的《黑天鵝》（The Black Swan – The impact of the highly improbable）一書發表後在全球被得以高度認知。

在發現澳大利亞之前，17世紀之前的歐洲人認為天鵝都是白色的。但隨著第一隻黑天鵝的出現，這個不可動搖的信念崩潰了。黑天鵝的存在寓意著不可預測的重大稀有事件，它在意料之外並且後果非常嚴重。

一個黑天鵝事件，具有這三個特點：（1）稀缺、通常史無前例（rarity），（2）影響很極端（extreme impact），（3）雖然它具有意外性，但人的本性促使我們在事後為它的發生找到理由——“事後諸葛亮”，並且或多或少認為它是可解釋和可預測的（introspective）。IT系統、尤其是資本市場裡的交易系統，所發生的各種重大問題，其實是很符合黑天鵝事件的特點的。

塔勒布用“感恩節的火雞”很形象解釋了黑天鵝的概念——直到被宰掉成為感恩節火雞晚餐前的每一天，火雞都應該是活的很不錯的，它的一生裡沒有任何過去的經驗供它預測到自己未來的結果，而後果是致命的。

一套複雜的IT系統，很有可能就是那隻火雞，例如就個人近年所遭遇的類似事件最典型的兩次，一是與某機構對接的技術介面，據稱已經存在並穩定使用近10年 – 雖然技術古老但是從未出現問題，然而在過去兩年持續創新高的交易量壓力之下，問題終究以最無法想象到的方式出現並形成系統性風險（因為對接者不僅一兩家）；

另一，則是老舊的系統因對市場可交易股票數目作了假設（而從未被發現），某天新股上市數量超過一定值而導致部分交易功能無法正常進行。

這兩個例子都符合黑天鵝特徵，一是“史無前例” （如果以前發生過，問題早就被處理了），二是可以“事後諸葛亮”（所有IT系統問題，最後不都可以歸結為“一個愚蠢的bug” ？因為開發時需求不清楚、因為開發者粗心、因為技術系統所處的生態環境已經發生變化導致原假設無效）；

三是“後果嚴重”（如果技術系統本身是一個廣被採購的第三方的商業軟體，則整個行業都有受災可能；如果是自研發的技術，則最起碼對交易投資者造成災難性損失）。

事實上，資本市場乃至金融業整體，可能都是黑天鵝最愛光顧的地方。甚至連普羅大眾都聽過的例子諸如：2010年5月6日的Flash Crash ——在三十分鐘內道瓊斯指數狂瀉近千點、1987年10月19日的Black Monday、國內著名的“烏龍指”事件導致的市場劇動……不一而足。

導致黑天鵝降臨的原因，事後分析五花八門，可能是量化交易導致的、可能是市場流動性不足引起的、也可能是市場心理（例如恐慌拋售）觸發的……無論何者，IT系統幾乎都是最後被壓垮的那隻駱駝。正如塔勒布文章中提到，高盛在2007年8月的某天突然經歷的為平常24倍的交易量，如果到了29倍，系統是否就已經坍塌了？

事實上，在這個日益數字化的世界，本身就高度數字化的證券市場，面臨的黑天鵝事件會越來越多，出於但不僅限於以下一些因素：

• 增長的交易規模。
• 更高頻、更復雜的交易演算法（《高頻交易員》一書裡指出，股票市場已經變成機器人之間的戰爭）。
• 更全球化更加波動 – 海內外政治經濟情況引起的突發變化。
• 更快速更先進的技術 – 已經出現數百納秒內完成交易處理的專門性硬體晶片，快到人類根本無法響應。

數字世界，尤其是金融業的數字世界，正好是塔勒布筆下所謂的“極端斯坦”（Extremistan），它完全不受物理世界的規律影響—— 一切極端皆有可能。例如在物理世界常識告訴我們，一個數百斤的超級胖子的體重加到1000人裡面比重依然是可以忽略不計的；但在金融世界，一個比爾蓋茨級別的富豪的財產數字，富可敵國。

金融IT，正好生存在這麼一個“極端斯坦”——這裡複雜系統內部充滿難以察覺的相互依賴關係和非線性關係，這裡概率分佈、統計學的“預測”往往不再生效。塔勒布稱之為“第四象限”，我們，作為證券交易的IT，剛好在這個象限裡謀生。

（塔勒布《黑天鵝》第四象限圖）

上述這一切，和雲端計算有什麼關係呢？ 我們覺得非常緊密，邏輯如下：

• 世界越來越數字化、更加“數目字可管理”- 一切效率更高。
• 本來就數字化的金融世界，日益是個“極端斯坦”，只能更快、更復雜，面臨更多黑天鵝事件。
• 應對數字世界的黑天鵝，只能用數字世界的手段（而不是“人肉”手工方法），就像《黑客帝國》，你必須進入Matrix，用其中的武器和手段，去解決裡面的問題（並影響外面）。
• 雲端計算，不過是世界數字化程序裡的一步 – 把承載數字世界的物理載體也進一步數字化，但是它剛好是我們應對數字黑天鵝的基本工具 – 運算資源本身也是“數目字可管理”，並且正因為如此而可以是自動的和智慧的。

即便到了今天，相信很多企業、機構的機房裡的運算資源，依然不是“數目字可管理” – 這本身真是一個諷刺。但直到雲技術出現，才解決這個問題。結合雲端計算的技術，交易系統不再是“your grandmother‘s trading system”。

黑天鵝事件是不可預測的，但是並非不可應對。《黑天鵝》的作者塔勒布，在其另一本有巨大影響力的著作《反脆弱》（Anti-Fragile）裡，提到了如何在不確定中獲益。這本閃爍著智慧之光的著作，早已超越了金融而進入到政治、經濟、宗教、社會學的思考範疇，對IT系統技術架構的設計，同樣具有啟發意義。

想想，一個經常被黑天鵝事件光顧的交易系統，如果不僅沒有坍塌、還隨著每一次的考驗而技術上變的越來越周全和強壯，這對於任何開發工程師、運維工程師來說，是不是一個夢想成真？

實際上，這個過程對於任何IT工程師而言都是非常熟悉的，因為我們中很多人每天的工作，可能就是在不斷的以各種應急手段緊急救援不堪重負的生產系統、或者線上彌補技術缺陷，在這過程中我們發現一個又一個在開發和測試時沒有發現的問題、一次又一次推翻自己在開發時的各種假設、不斷解決所遭遇到的此前完全沒有想象過的場景。如果專案、系統活下來了，顯然它變得更加健壯強韌。

只不過，這一切是被動的、低效的、“人肉”的，而且視系統架構和技術而定，變強韌有時是相對容易的、有時則是不可能的 – 正如一艘結構設計有嚴重缺陷的船，打更多的補丁也總會遇到更大的浪把它打沉。

如果基於《反脆弱》的三元論，也許大部分IT系統大致上可以這麼看：

• 脆弱類：絕大部分企業IT系統，依賴於大量技術假設與條件，不喜歡無序和不穩定環境，暴露於負面“黑天鵝”中。
• 強韌類：小部分大規模分散式系統（也許通常是網際網路應用），適應網際網路相對不可控的環境（如網路延遲與穩定性、客戶端裝置水平和瀏覽器版本、使用者量及併發請求變化），經受過海量使用者與服務請求的磨練，相對健壯。
• 反脆弱類：能捕捉到正面“黑天鵝”- 系統不僅在衝擊中存活，並且變的更加強韌，甚至在這過程中獲益。

這裡所謂的“脆弱”，並不是指系統不可靠、單薄、技術不堪一擊，而是指這類系統厭惡變化、厭惡不穩定不可控環境、本身架設在基於各種穩定性假設前提的精巧設計上，無法對抗突如其來的、此前無法循證的事件（黑天鵝），更無法從中自適應和壯大。就這個角度看，證券行業甚至整個金融業裡，大部分的系統可能都是脆弱系統。傳統IT系統有以下一些常見的技術特點，例如：

• 一切以關係型資料庫為中心（RDBMS-centric）。
• 很多歷史遺留系統（legacy system）有數以百計的表、數以千計的儲存過程。
• 業務邏輯高度依賴資料庫。
• 中間層與資料層高度緊耦合。
• 多層架構（multi-tiered architecture），層與層之間依賴於高度的約定假設（協議-protocol、介面- API、資料格式 – data format 等），並且這些約定經常來不及同步（例如某個團隊改變了維護的介面而沒有通知其他團隊、或者資料庫的表結構改變了但是中間層的物件庫因為疏忽而沒有及時步調一致的重構），有些約定甚至只存在於協作的開發者腦海中而沒有形成文件（即便形成文件也經常因需求變化頻繁而無法及時更新）。
• 應用程式依賴於某些第三方的程式碼庫，而這些程式碼庫很有可能依賴於某個版本的作業系統及補丁包，並且這種依賴關係是傳遞的 – 例如某個第三方程式碼庫依賴於另一個第三方程式碼庫而該庫依賴於某個版本的作業系統……
• 系統設計，往往沒有考慮足夠的失敗場景（因此可能完全沒有容錯機制），沒有考慮例如不穩定網路延遲對業務邏輯的影響（例如大部分企業系統都假設了一個穩定的LAN）。
• 元件、模組、程式碼庫、作業系統、應用程式、運維工具各版本之間具有各種線性、非線性依賴關係，形成一個巨大的複雜系統。

然而，以下這些變化是任何IT系統所不喜歡卻無法迴避的，例如：

• 多層架構裡，任何一個環節的約定獨立發生細微改變，必定導致系統出錯（只是嚴重性大小的差別），這幾乎無法很好的避免 – 研發團隊的素質不夠高、軟體工程的水平低、瞬息萬變的市場導致的頻繁更改等，總是客觀存在。
• 因為安全原因，需要對作業系統進行打補丁或者升級，導致應用程式所依賴的程式碼庫發生相容性問題 – 在打補丁或升級後通過測試及時發現相容問題已經算是幸運的，最怕是在生產環境執行過程中才觸發非線性關係的模組中的隱患。
• 跨系統（尤其是不同團隊、部門、組織負責的系統）的呼叫協議與介面發生變化，是一個常態性的客觀事實。
• 網際網路環境、甚至企業內部的網路環境，並不是一成不變的，網路拓撲出於安全、合規隔離、效能優化而變化，可能導致延遲、吞吐等效能指標的變化，應用系統本來沒有出現的一些問題，有可能因為執行環境的變化而浮現，而系統內部容錯機制往往沒有考慮到這些問題。
• 業務需求永遠在變，以資料庫為中心的系統，不可避免產生表結構（schema）調整，系統升級需要做資料遷移，而這總是有風險的（例如data integrity需要保證萬無一失）。

於是，傳統IT對於這些系統的運維，最佳實踐往往不得不這樣：

• 在使用壓力增大的情況下，最安全的升級手段是停機、換機器、加CPU、加記憶體，直到硬體升級、垂直擴容（vertical scale、or scale-up）手段用光。
• 維護一個龐大的運維團隊，隨時救火。
• 試圖通過軟體工程的管理，例如制定規章制度，讓協作人員、團隊之間在介面升級前走流程、互相通知，來避免隨意的系統變化導致的風險。
• 加大測試力度 – 通常很有可能是投入更多的人肉測試資源，以保證較高的測試覆蓋率和迴歸測試（regression test）能力。
• 強調“紀律”，以犧牲效率為代價，通過“流程”、“稽核”設定重重關卡以達到“維穩”效果。
• 重度隔離運維與研發，禁止研發人員觸碰生產環境，減少誤操作 – 例如隨意升級作業系統、對應用邏輯抱著僥倖心理打補丁等。

不可否定，這些“套路”在以往的時代可能是最佳實踐，也體現了一個IT組織的管理水平。但是毫無疑問，這樣研發、運維和管理的系統，是一個典型的“脆弱系統”，它依賴於很多的技術、工具、環境、流程、紀律、管理制度、組織結構，任何一個環節出現問題，都可能導致輕重不一的各種問題。

最重要一點，這樣的系統，厭惡變化、喜好穩定，無法在一個“只有變化才是唯一不變”（並且是變化越來越頻繁）的世界裡強韌存活，更無所謂擁抱變化而生長。

強韌類的技術系統，情況要好的多，起碼能“響應”變化（如後文所論述）。但是注意，在塔勒布的定義裡，“強韌”並非“脆弱”的反面，“強韌系統”只是能相對健壯的對抗更大的壓力、更苛刻的環境，它並不能從變化、不確定中獲益。

“脆弱”的反面，塔勒布在現有語言裡找不到一個合適的詞語，所以他發明了一個新概念，“反脆弱”（Anti-Fragile）。問題是，接受“變化是一種常態”、擁抱變化並從中獲益的“反脆弱”的技術系統，能被構建出來嗎？

雲端計算的出現，有利於幫助IT構建強韌系統，並且讓“反脆弱”系統成為可能。其最根本原因在於，雲端計算本身是機房物理設施數字化的過程，如上文所述，數字世界的黑天鵝 – 微秒、納秒內發生的極端事件，只能通過數字化手段才能高效解決。

伴隨雲計算出現的是DCOS（Data Center Operating System）、APM（Application Performance Monitoring）、Infrastructure As Code（基礎設施即程式碼、可程式設計運維、可程式設計基礎設施……）、DevOps等等技術方案、技術產品、技術理念和方法論。這些都是構建強韌系統的有力武器，而在雲端計算時代之前，它們嚴格意義上不曾存在過。

雲端計算也許是目前為止對於證券交易系統、甚至對於更廣義的金融技術系統而言最適合應對黑天鵝的技術手段。監管機構不應該見到“雲”字就敏感的與“公有云”、資訊保安、交易可監管性等問題聯絡起來；金融機構則需要與時俱進的學習掌握“雲化”的技術手段、架構思維 – 至於系統是執行在公有云、私有云還是混合雲，都已經是另一個故事。

雲端計算，其中一個最基本目的，是計算資源的集合管理與使用。其實IT界在計算資源的集合使用方面，過去20年起碼嘗試過三次：

• 90年代中後期，出現網格計算（Grid Computing），用於蛋白質摺疊、金融模型、地震模擬、氣候模型方面的應用。
• 本世紀初，出現效用計算（Utility Computing）- 推行運算資源按需呼叫（On-demand）、效用計費（Utility billing）、訂戶模式（Subscription model）的概念。IBM、HP、Sun這些IT公司都嘗試推動過這個領域的解決方案，雖然成效不彰。
• 10年前，亞馬遜AWS釋出，算是雲端計算的標誌性事件。雲端計算覆蓋含義更廣，網格計算可以是雲端計算平臺上的一類應用，而效用計算則可以被視為雲端計算服務商所採用的商業模式。

雲端計算和大資料技術出現後，這些技術逐漸變身“事務型記憶體資料庫”、“記憶體網格”（in-memory data-grid）、“流式計算平臺”（stream processing）等，然總體來說變的越來越小眾。

無論如何，這些技術在雲計算出現前已經幫助華爾街機構掌握了計算資源集合運用、分散式架構的一些理念和思維。而國內證券界甚至金融業IT總體來說，對這類技術是相當陌生的。

就對標華爾街同行的證券業IT而言，可以說基本上錯過了上述計算資源集合應用的三個浪潮。雲端計算興起後，OpenStack之類的技術在證券IT甚至金融界的成功落地、大規模採用的案例極其罕有（如果有的話）。

即便是近年來網際網路雲服務商興起，部分金融機構因為試水網際網路金融而開始使用公有云，很大程度上使用方式也不過是使用了一些虛擬機器執行一些網際網路邊緣（Edge）服務。

然而這個時代有趣的地方在於，一些新技術的出現可以讓“彎道超車”、“後發制人”成為可能 – 上一個階段錯過了一些東西，但是也可能下一個階段少了很多歷史包袱從而可以輕易跳進最新的技術世代。容器，恰好就是這麼一種技術 – 假如你能把握的話。

在英語裡，“容器”、“集裝箱”、“貨櫃”都是同一個字 – Container。容器技術之於軟體業，很有可能可以類比集裝箱對運輸業的巨大影響。

實際上，確實有人想過把整個機房放在集裝箱裡，例如2006年Sun Microsystems推出的Project Blackbox——剛好是亞馬遜釋出AWS的同一年。但這個集裝箱是鋼鐵的、有物理形體的、重量以噸為單位的；而其中的內容，自然也是各種物理的伺服器、網路裝置、發電機。那一年，可能誰也沒有想到，10年後有一種“數字化”的虛擬集裝箱大行其道。

技術界不乏認為容器對軟體技術產生革命性影響的觀點，本人傾向於認同這種觀點，因為：

• 容器影響開發者的開發方式、開發習慣，“強迫”他們去思考例如無狀態的服務、業務邏輯粒度的控制、資源的彈性伸縮、應用程式碼的釋出形態、系統裡面每一個細節的可監控性等等。
• 讓真正的DevOps成為可能 – 自動化測試、持續整合（CI）、持續交付（CD）、自動化部署、無人值守的運維… 開發與運維的角色差異進一步縮小，而效率則最大程度提升。
• 讓“不可變基礎設施”（Immutable infrastructure）成為可能——這將顛覆傳統軟體系統的升級釋出和維護方式。

為什麼作為金融系統、交易平臺的研發者，我們挑容器出現的時候跳進雲端計算，而在更早階段虛擬機器系列相關技術成熟時卻並沒有大的投入。

最根本原因在於，作為研發組織，我們從研發視角，基於具體應用場景去持續、積極尋覓能解決強韌性、健壯性問題的解決方案 – 這是一種“Top-Down Thinking”，例如在交易量波動過程中，我們能否有自動化的技術去可靠的應對、實現計算資源的彈性伸縮並且保持超級高效？

有什麼技術可以幫助我們解決複雜交易系統釋出、升級、打補丁的危險和痛苦？交易故障出現時系統內部防止雪崩效應保持快速響應的“熔斷”（circuit-breaker、fail-fast）機制有什麼更規範的做法？用現有云計算的理論和技術倒著去套，顯然是無解的，因為：

• 虛擬機器級別的資源排程，太沉重，可程式設計介面太弱，無法“融入”到一個高效能運算（HPC – High Performance Computing）的應用中。
• 僅僅為了資源的彈性伸縮，去引入一個第三方解決方案，例如一個PaaS（諸如CloudFoundry、OpenShift等），對於交易系統而言，代價太大、可控性太低、程式設計模型受入侵程度太高。
• 不是為了雲端計算而云計算 – 一切“革新”需要合理、充分的應用理由，場景不符合，架構就不合理。

“Bottom-up Thinking”，即從基礎設施的可管理、資源充分共享、運維更高效等角度去看問題，是一個典型的“運維”視角或者所謂CIO的視角，這種思考，關注的是TCO（Total Cost of Ownership）——成本的降低（IT在垂直行業一直被認為是一個成本中心 – 在現在這個時代這是一個錯誤觀點，但這是另一篇文章的討論範圍了）；可是和核心業務應用非常脫節。

對於一個傳統行業尤其是受監管行業的IT而言，技術氛圍往往是保守和審慎的，採用雲技術這種在網際網路界以外還很大程度被認為是“新生事物”的東西，並不是一件容易的事情：在行業繁榮、企業賺錢的時候，公司很可能並不關注運維除了穩定以外的事情 – 包括用虛擬機器還是用物理機、能否節省一點成本等等；

在市場不景氣、公司虧錢的時候，IT卻又需要以非常充分的資料來證明建立或者採用雲平臺能帶來顯著的大幅的成本節省效果，但是這往往首先涉及第三方軟體的採購、機房的改造… 這本身就是一個巨大障礙。

所以，悲觀一點的看，很大一部分傳統行業IT，很可能需要等到雲技術成熟為新世代IT系統的標配，就像mainframe時代向client-server時代轉變、client-server時代向多層架構/web技術時代切換，雲技術成為一個主流的、企業決策者不再需要加以思索的事物（“no-brainer”）時，才會順利進入企業世界。此時，運維的視角也許才能被充分接受。但是，對於以創新為本業的金融科技，那已經太遲。

早期的雲技術，從運維視角去看是自然的，因為虛擬化技術最開始是把基礎設施數字化的一個程序。容器化技術的出現，改變了這一切。容器天然與應用服務結合的更緊密、天然需要程式設計師的深度介入，“上帝的歸上帝，凱撒的歸凱撒”，容器裡面的歸程式猿（code monkey），容器外面的歸運維狗（watchdog）——不一定對，只是作為笑話簡單粗暴的類比一下，但想說明的是容器內外的關注點是不一樣的、而運維與研發的協同則是深度的。

在Docker剛出現的時候，一直帶著前述問題的我們，從其理念已經體會到容器技術對構建一個強韌交易系統的好處。

容器技術的到來，讓我們在觀念上“彎道超車”：

• 在軟體安裝、釋出方面，我們還需要去學習、模仿Oracle、IBM們研發什麼工具嗎？不需要了 – 採用容器、容器編排技術、容器映象管理技術、容器目錄（catalog），我們輕易的“一鍵釋出”，而且誰都可以執行。
• 在打補丁方面，我們還要去參考Redhat開發個升級工具嗎？沒必要了，因為我們不打補丁，已經發布的容器裡內容永遠不會改變（Immutable），需要修復缺陷或者升級版本，我們就釋出新容器 – 釋出元件乃至整個全新交易系統，成本都是很低的（並且必須永遠維持那麼低）。因此，我們也不一定需要什麼中心化的、統一的、集中的視覺化配置管理工具。
• 灰度釋出、線上升級、多版本生產環境、回滾現在都是容器化系統天然自帶的——因為整個系統的釋出、部署是低成本的和快速高效的，只要有硬體資源就再發布一套，不行就切換回舊的那套 – 技術界已經在不斷總結最佳實踐，總有一款套路適合你。基於容器的微服務，天然支援多服務版本並存；對於回滾，資料庫可能是個問題，但首先一切以資料庫為中心就是個很有可能是錯誤的觀念（當然，視應用場景而定），在分散式架構裡，關係型資料庫有可能不在系統關鍵路徑上、事務有好些辦法可以規避、通過很好的面向物件設計解耦記憶體與持久層的耦合… 實際上，經驗告訴我們，關係型資料庫被濫用是企業應用軟體的通病。

而比解決運維問題更有趣的，是這幾方面：

• Infrastructure As Code – 現在總算不是口號了，對著容器、容器編排技術進行編碼，讓“無人值守”、“智慧運維”真正成為可能。雖然Puppet、Chef、Ansible這些技術早就存在，但是它們基本上僅限於操作基礎設施的物理、虛擬資源，與一個專業應用系統通過API深度結合然後基於業務場景、系統業務指標來自我維護，是非常困難的。而容器，基本上只是一個程序，通過其API可以輕易深度整合到交易系統裡。
• 容器技術出現後，也衍生出更多其他新興技術，例如CoreOS、RancherOS、Unikernel。對於無止境追求極速效能的交易系統，交易軟體到底層硬體之間的耗損越少越好，這和我們所遵循的mechanical sympathy技術理念完全一致。類似Unikernel這樣的所謂“library OS”非常有趣，因為整個作業系統萎縮成一系列的基礎庫，由應用軟體直接呼叫以便執行在裸機（bare metal）上。想象一個超級輕量的交易中介軟體，無縫（真正意義上）執行在裸機上的毫無羈絆裸奔的“爽”…
• 在廣發證券IT而言的所謂“彎道超車”，其實更包括幾方面的含義：一是觀念上的，顛覆傳統軟體研發的思維，不必要去做追隨者；二是技術成長方面的 – 雖然有些技術如Unikernel並未成熟到可以真正運用，但是兩三年前的Docker不也一樣嗎？重要的是團隊和一個革命性技術的共同成長，前瞻性技術的研發投入終將回報（capitalize）；三是實際效果上的，雖然在雲計算髮力的前幾年，我們並未投入到IaaS、PaaS的“基建”，但是從容器化入手，忽然間就獲得了一定的“計算資源集合使用”的能力 – 此前只有技術實力較強的科技企業能做Grid Computing。

在證券業，我們不是孤獨者。華爾街投行的表率高盛，今年2月份宣佈了他們一年內把90%的運算能力容器化的計劃。

時至今天，在Docker已經被團隊廣為接受、被應用到各種業務系統中去的時候，我們從兩個方向同時繼續推進容器化技術：

• 第一個方向，繼續沿用上文所述的“Top-Down”思路，基於業務場景、具體應用需要，把容器（Docker）、容器編排管理（Rancher）的技術深度整合到交易系統中去，讓其獲得自伸縮（elastic）、自監控（self monitor）、自修復（self-healing）的自動化能力 – 這是“反脆弱”系統的一個必要非充分條件。至於什麼時候伸縮、什麼時候自修復、如何學習自己的執行行為以作自我調整、如何把低階的系統指標換算成業務級別的效能指標作為自己的健康“血壓計”… 這些是需持續學習挖掘、測試驗證的東西。
• 第二個方向，是上文所述的“Bottom-Up”思路，採用例如Kubernetes建立起一個多租戶的CaaS（容器即服務）平臺，支援非交易的應用系統（例如電商平臺、機器人投顧服務、CRM等等）的跨雲（公有云、私有云、傳統機房）容器化。

軟體工程沒有銀彈99年圖靈獎獲得者Fred Brooks（也就是Brooks’ law的發現者：“往一個已經延誤的專案里加人力資源，只能讓那個專案更延誤”）說過，軟體工程沒有銀子彈。

在各種標榜“雲”的科技公司層出不窮的今天，其實依然還沒有任何“黑科技”幫閣下把你的脆弱系統瞬間變成一個強韌系統甚至一個具備反脆弱能力的系統。所以，容器技術也不過是一個也許必要但不充分的有用工具而已。

能否釋放雲端計算的威力，取決於很多因素。到一個公有云上使用幾個虛擬機器，也算一個小小的進步，畢竟它可能（1）縮短了一些傳統企業採購硬體、機器上架等等的週期；（2）幫不擅長網際網路技術的傳統企業解決一部分“網際網路最後一公里”問題。然而，這只不過是使用了一些虛擬化基礎服務，如果部署在上面的系統本身是一個脆弱系統，那麼它在雲上依然是一個脆弱系統。

實現一個強韌甚至反脆弱的技術系統，你首先得有一個恰當的技術架構，而實現這樣的技術架構，你首先需要有研發團隊 – 不錯，個人觀點是，在現階段如果不具備軟體研發能力，那麼你的組織其實無法真正利用、享受到雲技術帶來的福利。

怎樣的架構才能利用和釋放雲端計算能力？

首先，架構設計需要遵循Reactive（響應式）原則（根據“響應式宣言”）：

• Elasticity – 彈性響應系統負載變化，基於實時效能監控指標以便通過預測性（predictive）和響應性（reactive）演算法來對系統進行擴容。
• Resiliency – 通過複製（replication）、包容（containment）、隔離（isolation）和委託（delegation）等機制，保障在故障發生時系統能繼續高度可用。
• Responsive – 系統及時探測偵察問題並解決問題，保障對外的及時響應。
• Message-driven – 採用訊息驅動的、非堵塞的非同步通訊機制，降低系統內部元件模組間的耦合度，提升吞吐量。

其次，在技術研發過程中，我們採用一系列的所謂“Cloud-native patterns”（原生，或者說“天然”的雲端計算架構模式）來實現我們的系統，以便讓系統達到Cloud-ready（具備雲感知能力 – 借用IBM與Intel相關中文版論文的概念）。

此外，“雲感知”和上述“響應式”原則，是完全一致的，雲感知也關注“故障恢復能力”、“延遲恢復能力”、“擴充套件的靈活性”。事實上，在一流的金融IT團隊裡，這些原則、實踐要求，從來都是被遵循的，因為金融的應用系統天然需要這些能力。無論是否在雲端計算時代，這些原則、要求均非常合理。

那麼容器化技術在這其中有什麼作用呢？實踐告訴我們，作用很大。最重要一點是，很多pattern的具體技術實現，可以挪到容器層面去處理。例如Circuit-breaker和Fail-fast這類模式，過去的做法，是各個具體的服務，採用自己的技術工具（例如Node.js的守護程序PM2）和辦法，基於開發者自己的理解，各自實現。

容器化的好處，是把複雜系統裡一切異構的技術（無論以Go、Java、Python還是Node.js實現）都裝載到一個個的標準集裝箱裡，然後通過排程中心基於各種監控對這些集裝箱進行排程處理。也就是說，Cloud-native的架構模式，有不少是可以在容器編排排程與協同的這一層實現的。

IT領域不知道有無類似的人物，諸如面向物件設計、架構設計模式、敏捷開發領域的大師級人物Martin Fowler等，顯然是抽象思維特別強的人，能夠對複雜的技術世界進行“模式識別”而作出一些深刻思考。

在技術世界裡，我們一向強調方法論，可是有時候也需要形成“世界觀”、“信仰”。在無數次的專案危機管理、技術故障攻堅、運維救火之後，IT人也許應該對“世間唯一不變的是變化本身”有深刻體會，從而接受“擁抱不確定”的觀念。

IT介面對變化與不確定性的態度，這十多年來看也是一個有趣的演變：

• 直到本世紀初，很多專案管理及軟體工程的方法論，依然強調所謂的“Change management”（變更管理），通過組織（“變更委員會”）、流程來“管理”業務系統需求方不斷提出的需求管理，視需求變化為專案延誤、系統不穩定的根源，以專案“按時”交付為終極目標，可以說這些方法論本質上“厭惡“變更。
• 網際網路風起雲湧後，出於應對瞬息萬變的激烈競爭、線上高效運營的剛需，接受“需求變化是常態”、對變更友好的“敏捷”（Agile）方法被自然而然引入到日常專案中，成為過去十年的主流方法論，並且終於把傳統企業IT牽引其中（例如廣發證券IT啟動金融電商系列專案研發前的第一件事就是先把敏捷實踐建立起來 – 對口的方法論才可能帶來對的結果）。
• 然而，絕大部分企業的敏捷實踐都侷限在垂直業務線的專案團隊裡，而運維作為一個維護全企業IT生產資源的橫向平臺型組織，通常被排除在敏捷實踐之外。

  敏捷迭代方法解決得了業務需求變更的問題，解決不了系統上線後各種突發性的變化 – 故障的及時解決、版本的迅速更新（業務部門總是迫不及待的）、線上經營的瞬間生效（運營人員分分秒秒催著）…

  在一切都嫌慢的“網際網路時間”裡，運維貌似成為最後掉鏈的一環，以“穩健”為主導的運維團隊與“進取”的研發、運營團隊無可避免產生衝突

• 時至今天，隨著“把基礎設施數字化”的雲端計算的普及，一個新的方法論 – DevOps，閃亮登場。之所以說這是一個方法論，是因為它絕不僅僅是“Dev + Ops”這樣簡單粗暴的把開發工程師和運維工程師捆在一起，用“同一個專案組”、“同一套KPI”來強迫他們分享“同一個夢想”了事。

  它是在APM（應用效能監控）、Infrastructure As Code（可程式設計運維）、Virtualization（虛擬化）、Containerization（容器化）等等這些雲端計算時代的產物出現後，基於新的技術工具、技術理念而自然產生的。

  持續整合（Continuous Integration）、持續交付（Continuous Delivery）、持續運維（Continuous Operation）是DevOps的具體環節和手段，它相當於把一條純數字化鏈路上不同的參與者關聯到一起 – 無論是開發工程師還是運維工程師，最終都不過是身份稍微差異的Information worker。

DevOps可能不僅僅是個概念、方法論、技術新名詞，它是伴隨雲端計算自然發生的。但它的接受與運用，對於傳統企業的IT，尤其是“維穩”為主導思想的受監管行業的IT，可能是一種文化衝擊。

傳統IT甚至是今天的很多技術相對前沿的網際網路公司，依然把團隊拆分成“運維”、“開發”，在組織結構層面建立相互制衡，以避免開發團隊的“衝動冒進”導致生產系統的不穩定，但運維職能往往變成一種“權力”（privilege）- 系統的迭代更新都需要獲得運維“審批”，這本身顯然就是一個“脆弱系統”，因為對變更是絕不友好的。在技術進步、時代變遷的大環境下，這種過去合理的做法，早晚變成一個將要被顛覆的存在。

無論如何，我們認為割裂的討論一個高效能運算（HPC）的技術系統（如證券交易系統）的容器化、“雲化”是不夠的，DevOps是構建“反脆弱”技術系統的方法論（起碼到目前為止。也許將來有新的思維出現），也是我們系統能力的天然一部分。

我們從軟體研發的視角、證券交易的視角來看待雲端計算，深感把促進基礎設施數字化、運維程式碼化的容器化技術，運用到交易系統技術中，是天作之合 – 假如運用得當的話，結合機器學習和智慧演算法，能幫助我們構建一些“反脆弱”的技術方案（既然有能下圍棋的阿爾法狗，我們是否也可以開始憧憬懂得自救的運維狗？）。

可以看到的潮流脈絡是，世界是越來越數字化的、變化是越來越頻繁的、而IT是需要擁抱變化的，雲端計算則只是這個潮流裡完全符合趨勢而自然出現的技術階段。

有一天Oracle、SAP、各種著名與非知名的專業軟體都把它們自身的產品基於容器來構建（例如一個多程序組成的資料庫例項裡的程序各自執行在自己的容器中），也許對於行業監管者、企業技術決策者而言，雲已經無需概念上的存在，而能被毫無質疑的接受。

但是這一天到來之前，大部分企業也許可以先嚐試調整一個對雲服務友好的財務制度 – 專案立項的時候，硬體預算按CPU核數、記憶體量、儲存量來報算，有形的物理機器不再作為資產稽核到各條業務線各個專案組，一切物理硬體歸IT。制度和文化，往往才是隱形的決定因素，不是嗎？

文章出處：InfoQ