前一段時(shí)間中國銀監(jiān)會(huì)在“十三五”規(guī)劃當(dāng)中提到銀行業(yè)應(yīng)該穩(wěn)步實(shí)施架構(gòu)遷移并逐步過渡到云計(jì)算架構(gòu)平臺(tái),廣發(fā)證券在這方面做了很長(zhǎng)時(shí)間的探索.

廣發(fā)證券于2014年Docker等容器技術(shù)尚未盛行之時(shí)開始投入容器化技術(shù)的研究,并于2015年開始大規(guī)模投入應(yīng)用—成交量六百億(2015年)規(guī)模的金融電商平臺(tái)、消息推送日均數(shù)千萬條級(jí)別的社會(huì)化投顧問答平臺(tái)以及日均流經(jīng)交易量峰值近五十億的交易總線均被容器化；投入生產(chǎn)的容器化云服務(wù)包括行情、資訊、消息推送、自選股、統(tǒng)一認(rèn)證、實(shí)時(shí)事件處理等.

我們研究和應(yīng)用云技術(shù)的動(dòng)機(jī),來源于對(duì)“黑天鵝”事件的應(yīng)對(duì).“黑天鵝”這一概念,是在美國學(xué)者、風(fēng)險(xiǎn)分析師、前量化交易員、前對(duì)沖基金經(jīng)理塔勒布(Nassim Nicholas Taleb)的《黑天鵝》(The Black Swan – The impact of the highly improbable)一書發(fā)表后在全球被得以高度認(rèn)知.

在發(fā)現(xiàn)澳大利亞之前,17世紀(jì)之前的歐洲人認(rèn)為天鵝都是白色的.但隨著第一只黑天鵝的出現(xiàn),這個(gè)不可動(dòng)搖的信念崩潰了.黑天鵝的存在寓意著不可預(yù)測(cè)的重大稀有事件,它在意料之外并且后果非常嚴(yán)重.

一個(gè)黑天鵝事件,具有這三個(gè)特點(diǎn)：(1)稀缺、通常史無前例(rarity),(2)影響很極端(extreme impact),(3)雖然它具有意外性,但人的本性促使我們?cè)谑潞鬄樗陌l(fā)生找到理由——“事后諸葛亮”,并且或多或少認(rèn)為它是可解釋和可預(yù)測(cè)的(introspective).IT系統(tǒng)、尤其是資本市場(chǎng)里的交易系統(tǒng),所發(fā)生的各種重大問題,其實(shí)是很符合黑天鵝事件的特點(diǎn)的.

塔勒布用“感恩節(jié)的火雞”很形象解釋了黑天鵝的概念——直到被宰掉成為感恩節(jié)火雞晚餐前的每一天,火雞都應(yīng)該是活的很不錯(cuò)的,它的一生里沒有任何過去的經(jīng)驗(yàn)供它預(yù)測(cè)到自己未來的結(jié)果,而后果是致命的.

一套復(fù)雜的IT系統(tǒng),很有可能就是那只火雞,例如就個(gè)人近年所遭遇的類似事件最典型的兩次,一是與某機(jī)構(gòu)對(duì)接的技術(shù)接口,據(jù)稱已經(jīng)存在并穩(wěn)定使用近10年 – 雖然技術(shù)古老但是從未出現(xiàn)問題,然而在過去兩年持續(xù)創(chuàng)新高的交易量壓力之下,問題終究以最無法想象到的方式出現(xiàn)并形成系統(tǒng)性風(fēng)險(xiǎn)(因?yàn)閷?duì)接者不僅一兩家)；

另一,則是老舊的系統(tǒng)因?qū)κ袌?chǎng)可交易股票數(shù)目作了假設(shè)(而從未被發(fā)現(xiàn)),某天新股上市數(shù)量超過一定值而導(dǎo)致部分交易功能無法正常進(jìn)行.

這兩個(gè)例子都符合黑天鵝特征,一是“史無前例” (如果以前發(fā)生過,問題早就被處理了),二是可以“事后諸葛亮”(所有IT系統(tǒng)問題,最后不都可以歸結(jié)為“一個(gè)愚蠢的bug” ?因?yàn)殚_發(fā)時(shí)需求不清楚、因?yàn)殚_發(fā)者粗心、因?yàn)榧夹g(shù)系統(tǒng)所處的生態(tài)環(huán)境已經(jīng)發(fā)生變化導(dǎo)致原假設(shè)無效)；

三是“后果嚴(yán)重”(如果技術(shù)系統(tǒng)本身是一個(gè)廣被采購的第三方的商業(yè)軟件,則整個(gè)行業(yè)都有受災(zāi)可能；如果是自研發(fā)的技術(shù),則最起碼對(duì)交易投資者造成災(zāi)難性損失).

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

導(dǎo)致黑天鵝降臨的原因,事后分析五花八門,可能是量化交易導(dǎo)致的、可能是市場(chǎng)流動(dòng)性不足引起的、也可能是市場(chǎng)心理(例如恐慌拋售)觸發(fā)的……無論何者,IT系統(tǒng)幾乎都是最后被壓垮的那只駱駝.正如塔勒布文章中提到,高盛在2007年8月的某天突然經(jīng)歷的為平常24倍的交易量,如果到了29倍,系統(tǒng)是否就已經(jīng)坍塌了?

事實(shí)上,在這個(gè)日益數(shù)字化的世界,本身就高度數(shù)字化的證券市場(chǎng),面臨的黑天鵝事件會(huì)越來越多,出于但不僅限于以下一些因素：

• 增長(zhǎng)的交易規(guī)模.
• 更高頻、更復(fù)雜的交易算法(《高頻交易員》一書里指出,股票市場(chǎng)已經(jīng)變成機(jī)器人之間的戰(zhàn)爭(zhēng)).
• 更全球化更加波動(dòng) – 海內(nèi)外政治經(jīng)濟(jì)情況引起的突發(fā)變化.
• 更快速更先進(jìn)的技術(shù) – 已經(jīng)出現(xiàn)數(shù)百納秒內(nèi)完成交易處理的專門性硬件芯片,快到人類根本無法響應(yīng).

數(shù)字世界,尤其是金融業(yè)的數(shù)字世界,正好是塔勒布筆下所謂的“極端斯坦”(Extremistan),它完全不受物理世界的規(guī)律影響—— 一切極端皆有可能.例如在物理世界常識(shí)告訴我們,一個(gè)數(shù)百斤的超級(jí)胖子的體重加到1000人里面比重依然是可以忽略不計(jì)的；但在金融世界,一個(gè)比爾蓋茨級(jí)別的富豪的財(cái)產(chǎn)數(shù)字,富可敵國.

金融IT,正好生存在這么一個(gè)“極端斯坦”——這里復(fù)雜系統(tǒng)內(nèi)部充滿難以察覺的相互依賴關(guān)系和非線性關(guān)系,這里概率分布、統(tǒng)計(jì)學(xué)的“預(yù)測(cè)”往往不再生效.塔勒布稱之為“第四象限”,我們,作為證券交易的IT,剛好在這個(gè)象限里謀生.

(塔勒布《黑天鵝》第四象限圖)

上述這一切,和云計(jì)算有什么關(guān)系呢? 我們覺得非常緊密,邏輯如下：

• 世界越來越數(shù)字化、更加“數(shù)目字可管理”- 一切效率更高.
• 本來就數(shù)字化的金融世界,日益是個(gè)“極端斯坦”,只能更快、更復(fù)雜,面臨更多黑天鵝事件.
• 應(yīng)對(duì)數(shù)字世界的黑天鵝,只能用數(shù)字世界的手段(而不是“人肉”手工方法),就像《黑客帝國》,你必須進(jìn)入Matrix,用其中的武器和手段,去解決里面的問題(并影響外面).
• 云計(jì)算,不過是世界數(shù)字化進(jìn)程里的一步 – 把承載數(shù)字世界的物理載體也進(jìn)一步數(shù)字化,但是它剛好是我們應(yīng)對(duì)數(shù)字黑天鵝的基本工具 – 運(yùn)算資源本身也是“數(shù)目字可管理”,并且正因?yàn)槿绱硕梢允亲詣?dòng)的和智能的.

即便到了今天,相信很多企業(yè)、機(jī)構(gòu)的機(jī)房里的運(yùn)算資源,依然不是“數(shù)目字可管理” – 這本身真是一個(gè)諷刺.但直到云技術(shù)出現(xiàn),才解決這個(gè)問題.結(jié)合云計(jì)算的技術(shù),交易系統(tǒng)不再是“your grandmother‘s trading system”.

黑天鵝事件是不可預(yù)測(cè)的,但是并非不可應(yīng)對(duì).《黑天鵝》的作者塔勒布,在其另一本有巨大影響力的著作《反脆弱》(Anti-Fragile)里,提到了如何在不確定中獲益.這本閃爍著智慧之光的著作,早已超越了金融而進(jìn)入到政治、經(jīng)濟(jì)、宗教、社會(huì)學(xué)的思考范疇,對(duì)IT系統(tǒng)技術(shù)架構(gòu)的設(shè)計(jì),同樣具有啟發(fā)意義.

想想,一個(gè)經(jīng)常被黑天鵝事件光顧的交易系統(tǒng),如果不僅沒有坍塌、還隨著每一次的考驗(yàn)而技術(shù)上變的越來越周全和強(qiáng)壯,這對(duì)于任何開發(fā)工程師、運(yùn)維工程師來說,是不是一個(gè)夢(mèng)想成真?

實(shí)際上,這個(gè)過程對(duì)于任何IT工程師而言都是非常熟悉的,因?yàn)槲覀冎泻芏嗳嗣刻斓墓ぷ?可能就是在不斷的以各種應(yīng)急手段緊急救援不堪重負(fù)的生產(chǎn)系統(tǒng)、或者在線彌補(bǔ)技術(shù)缺陷,在這過程中我們發(fā)現(xiàn)一個(gè)又一個(gè)在開發(fā)和測(cè)試時(shí)沒有發(fā)現(xiàn)的問題、一次又一次推翻自己在開發(fā)時(shí)的各種假設(shè)、不斷解決所遭遇到的此前完全沒有想象過的場(chǎng)景.如果項(xiàng)目、系統(tǒng)活下來了,顯然它變得更加健壯強(qiáng)韌.

只不過,這一切是被動(dòng)的、低效的、“人肉”的,而且視系統(tǒng)架構(gòu)和技術(shù)而定,變強(qiáng)韌有時(shí)是相對(duì)容易的、有時(shí)則是不可能的 – 正如一艘結(jié)構(gòu)設(shè)計(jì)有嚴(yán)重缺陷的船,打更多的補(bǔ)丁也總會(huì)遇到更大的浪把它打沉.

如果基于《反脆弱》的三元論,也許大部分IT系統(tǒng)大致上可以這么看：

• 脆弱類：絕大部分企業(yè)IT系統(tǒng),依賴于大量技術(shù)假設(shè)與條件,不喜歡無序和不穩(wěn)定環(huán)境,暴露于負(fù)面“黑天鵝”中.
• 強(qiáng)韌類：小部分大規(guī)模分布式系統(tǒng)(也許通常是互聯(lián)網(wǎng)應(yīng)用),適應(yīng)互聯(lián)網(wǎng)相對(duì)不可控的環(huán)境(如網(wǎng)絡(luò)延遲與穩(wěn)定性、客戶端設(shè)備水平和瀏覽器版本、用戶量及并發(fā)請(qǐng)求變化),經(jīng)受過海量用戶與服務(wù)請(qǐng)求的磨練,相對(duì)健壯.
• 反脆弱類：能捕捉到正面“黑天鵝”- 系統(tǒng)不僅在沖擊中存活,并且變的更加強(qiáng)韌,甚至在這過程中獲益.

這里所謂的“脆弱”,并不是指系統(tǒng)不可靠、單薄、技術(shù)不堪一擊,而是指這類系統(tǒng)厭惡變化、厭惡不穩(wěn)定不可控環(huán)境、本身架設(shè)在基于各種穩(wěn)定性假設(shè)前提的精巧設(shè)計(jì)上,無法對(duì)抗突如其來的、此前無法循證的事件(黑天鵝),更無法從中自適應(yīng)和壯大.就這個(gè)角度看,證券行業(yè)甚至整個(gè)金融業(yè)里,大部分的系統(tǒng)可能都是脆弱系統(tǒng).傳統(tǒng)IT系統(tǒng)有以下一些常見的技術(shù)特點(diǎn),例如：

• 一切以關(guān)系型數(shù)據(jù)庫為中心(RDBMS-centric).
• 很多歷史遺留系統(tǒng)(legacy system)有數(shù)以百計(jì)的表、數(shù)以千計(jì)的存儲(chǔ)過程.
• 業(yè)務(wù)邏輯高度依賴數(shù)據(jù)庫.
• 中間層與數(shù)據(jù)層高度緊耦合.
• 多層架構(gòu)(multi-tiered architecture),層與層之間依賴于高度的約定假設(shè)(協(xié)議-protocol、接口- API、數(shù)據(jù)格式 – data format 等),并且這些約定經(jīng)常來不及同步(例如某個(gè)團(tuán)隊(duì)改變了維護(hù)的接口而沒有通知其他團(tuán)隊(duì)、或者數(shù)據(jù)庫的表結(jié)構(gòu)改變了但是中間層的對(duì)象庫因?yàn)槭韬龆鴽]有及時(shí)步調(diào)一致的重構(gòu)),有些約定甚至只存在于協(xié)作的開發(fā)者腦海中而沒有形成文檔(即便形成文檔也經(jīng)常因需求變化頻繁而無法及時(shí)更新).
• 應(yīng)用程序依賴于某些第三方的代碼庫,而這些代碼庫很有可能依賴于某個(gè)版本的操作系統(tǒng)及補(bǔ)丁包,并且這種依賴關(guān)系是傳遞的 – 例如某個(gè)第三方代碼庫依賴于另一個(gè)第三方代碼庫而該庫依賴于某個(gè)版本的操作系統(tǒng)……
• 系統(tǒng)設(shè)計(jì),往往沒有考慮足夠的失敗場(chǎng)景(因此可能完全沒有容錯(cuò)機(jī)制),沒有考慮例如不穩(wěn)定網(wǎng)絡(luò)延遲對(duì)業(yè)務(wù)邏輯的影響(例如大部分企業(yè)系統(tǒng)都假設(shè)了一個(gè)穩(wěn)定的LAN).
• 組件、模塊、代碼庫、操作系統(tǒng)、應(yīng)用程序、運(yùn)維工具各版本之間具有各種線性、非線性依賴關(guān)系,形成一個(gè)巨大的復(fù)雜系統(tǒng).

然而,以下這些變化是任何IT系統(tǒng)所不喜歡卻無法回避的,例如：

• 多層架構(gòu)里,任何一個(gè)環(huán)節(jié)的約定獨(dú)立發(fā)生細(xì)微改變,必定導(dǎo)致系統(tǒng)出錯(cuò)(只是嚴(yán)重性大小的差別),這幾乎無法很好的避免 – 研發(fā)團(tuán)隊(duì)的素質(zhì)不夠高、軟件工程的水平低、瞬息萬變的市場(chǎng)導(dǎo)致的頻繁更改等,總是客觀存在.
• 因?yàn)榘踩?需要對(duì)操作系統(tǒng)進(jìn)行打補(bǔ)丁或者升級(jí),導(dǎo)致應(yīng)用程序所依賴的代碼庫發(fā)生兼容性問題 – 在打補(bǔ)丁或升級(jí)后通過測(cè)試及時(shí)發(fā)現(xiàn)兼容問題已經(jīng)算是幸運(yùn)的,最怕是在生產(chǎn)環(huán)境運(yùn)行過程中才觸發(fā)非線性關(guān)系的模塊中的隱患.
• 跨系統(tǒng)(尤其是不同團(tuán)隊(duì)、部門、組織負(fù)責(zé)的系統(tǒng))的調(diào)用協(xié)議與接口發(fā)生變化,是一個(gè)常態(tài)性的客觀事實(shí).
• 互聯(lián)網(wǎng)環(huán)境、甚至企業(yè)內(nèi)部的網(wǎng)絡(luò)環(huán)境,并不是一成不變的,網(wǎng)絡(luò)拓?fù)涑鲇诎踩⒑弦?guī)隔離、性能優(yōu)化而變化,可能導(dǎo)致延遲、吞吐等性能指標(biāo)的變化,應(yīng)用系統(tǒng)本來沒有出現(xiàn)的一些問題,有可能因?yàn)檫\(yùn)行環(huán)境的變化而浮現(xiàn),而系統(tǒng)內(nèi)部容錯(cuò)機(jī)制往往沒有考慮到這些問題.
• 業(yè)務(wù)需求永遠(yuǎn)在變,以數(shù)據(jù)庫為中心的系統(tǒng),不可避免產(chǎn)生表結(jié)構(gòu)(schema)調(diào)整,系統(tǒng)升級(jí)需要做數(shù)據(jù)遷移,而這總是有風(fēng)險(xiǎn)的(例如data integrity需要保證萬無一失).

于是,傳統(tǒng)IT對(duì)于這些系統(tǒng)的運(yùn)維,最佳實(shí)踐往往不得不這樣：

• 在使用壓力增大的情況下,最安全的升級(jí)手段是停機(jī)、換機(jī)器、加CPU、加內(nèi)存,直到硬件升級(jí)、垂直擴(kuò)容(vertical scale、or scale-up)手段用光.
• 維護(hù)一個(gè)龐大的運(yùn)維團(tuán)隊(duì),隨時(shí)救火.
• 試圖通過軟件工程的管理,例如制定規(guī)章制度,讓協(xié)作人員、團(tuán)隊(duì)之間在接口升級(jí)前走流程、互相通知,來避免隨意的系統(tǒng)變化導(dǎo)致的風(fēng)險(xiǎn).
• 加大測(cè)試力度 – 通常很有可能是投入更多的人肉測(cè)試資源,以保證較高的測(cè)試覆蓋率和回歸測(cè)試(regression test)能力.
• 強(qiáng)調(diào)“紀(jì)律”,以犧牲效率為代價(jià),通過“流程”、“審核”設(shè)置重重關(guān)卡以達(dá)到“維穩(wěn)”效果.
• 重度隔離運(yùn)維與研發(fā),禁止研發(fā)人員觸碰生產(chǎn)環(huán)境,減少誤操作 – 例如隨意升級(jí)操作系統(tǒng)、對(duì)應(yīng)用邏輯抱著僥幸心理打補(bǔ)丁等.

不可否定,這些“套路”在以往的時(shí)代可能是最佳實(shí)踐,也體現(xiàn)了一個(gè)IT組織的管理水平.但是毫無疑問,這樣研發(fā)、運(yùn)維和管理的系統(tǒng),是一個(gè)典型的“脆弱系統(tǒng)”,它依賴于很多的技術(shù)、工具、環(huán)境、流程、紀(jì)律、管理制度、組織結(jié)構(gòu),任何一個(gè)環(huán)節(jié)出現(xiàn)問題,都可能導(dǎo)致輕重不一的各種問題.

最重要一點(diǎn),這樣的系統(tǒng),厭惡變化、喜好穩(wěn)定,無法在一個(gè)“只有變化才是唯一不變”(并且是變化越來越頻繁)的世界里強(qiáng)韌存活,更無所謂擁抱變化而生長(zhǎng).

強(qiáng)韌類的技術(shù)系統(tǒng),情況要好的多,起碼能“響應(yīng)”變化(如后文所論述).但是注意,在塔勒布的定義里,“強(qiáng)韌”并非“脆弱”的反面,“強(qiáng)韌系統(tǒng)”只是能相對(duì)健壯的對(duì)抗更大的壓力、更苛刻的環(huán)境,它并不能從變化、不確定中獲益.

“脆弱”的反面,塔勒布在現(xiàn)有語言里找不到一個(gè)合適的詞語,所以他發(fā)明了一個(gè)新概念,“反脆弱”(Anti-Fragile).問題是,接受“變化是一種常態(tài)”、擁抱變化并從中獲益的“反脆弱”的技術(shù)系統(tǒng),能被構(gòu)建出來嗎?

云計(jì)算的出現(xiàn),有利于幫助IT構(gòu)建強(qiáng)韌系統(tǒng),并且讓“反脆弱”系統(tǒng)成為可能.其最根本原因在于,云計(jì)算本身是機(jī)房物理設(shè)施數(shù)字化的過程,如上文所述,數(shù)字世界的黑天鵝 – 微秒、納秒內(nèi)發(fā)生的極端事件,只能通過數(shù)字化手段才能高效解決.

伴隨云計(jì)算出現(xiàn)的是DCOS(Data Center Operating System)、APM(Application Performance Monitoring)、Infrastructure As Code(基礎(chǔ)設(shè)施即代碼、可編程運(yùn)維、可編程基礎(chǔ)設(shè)施……)、DevOps等等技術(shù)方案、技術(shù)產(chǎn)品、技術(shù)理念和方法論.這些都是構(gòu)建強(qiáng)韌系統(tǒng)的有力武器,而在云計(jì)算時(shí)代之前,它們嚴(yán)格意義上不曾存在過.

云計(jì)算也許是目前為止對(duì)于證券交易系統(tǒng)、甚至對(duì)于更廣義的金融技術(shù)系統(tǒng)而言最適合應(yīng)對(duì)黑天鵝的技術(shù)手段.監(jiān)管機(jī)構(gòu)不應(yīng)該見到“云”字就敏感的與“公有云”、信息安全、交易可監(jiān)管性等問題聯(lián)系起來；金融機(jī)構(gòu)則需要與時(shí)俱進(jìn)的學(xué)習(xí)掌握“云化”的技術(shù)手段、架構(gòu)思維 – 至于系統(tǒng)是運(yùn)行在公有云、私有云還是混合云,都已經(jīng)是另一個(gè)故事.

云計(jì)算,其中一個(gè)最基本目的,是計(jì)算資源的集合管理與使用.其實(shí)IT界在計(jì)算資源的集合使用方面,過去20年起碼嘗試過三次：

• 90年代中后期,出現(xiàn)網(wǎng)格計(jì)算(Grid Computing),用于蛋白質(zhì)折疊、金融模型、地震模擬、氣候模型方面的應(yīng)用.
• 本世紀(jì)初,出現(xiàn)效用計(jì)算(Utility Computing)- 推行運(yùn)算資源按需調(diào)用(On-demand)、效用計(jì)費(fèi)(Utility billing)、訂戶模式(Subscription model)的概念.IBM、HP、Sun這些IT公司都嘗試推動(dòng)過這個(gè)領(lǐng)域的解決方案,雖然成效不彰.
• 10年前,亞馬遜AWS發(fā)布,算是云計(jì)算的標(biāo)志性事件.云計(jì)算覆蓋含義更廣,網(wǎng)格計(jì)算可以是云計(jì)算平臺(tái)上的一類應(yīng)用,而效用計(jì)算則可以被視為云計(jì)算服務(wù)商所采用的商業(yè)模式.

云計(jì)算和大數(shù)據(jù)技術(shù)出現(xiàn)后,這些技術(shù)逐漸變身“事務(wù)型內(nèi)存數(shù)據(jù)庫”、“內(nèi)存網(wǎng)格”(in-memory data-grid)、“流式計(jì)算平臺(tái)”(stream processing)等,然總體來說變的越來越小眾.

無論如何,這些技術(shù)在云計(jì)算出現(xiàn)前已經(jīng)幫助華爾街機(jī)構(gòu)掌握了計(jì)算資源集合運(yùn)用、分布式架構(gòu)的一些理念和思維.而國內(nèi)證券界甚至金融業(yè)IT總體來說,對(duì)這類技術(shù)是相當(dāng)陌生的.

就對(duì)標(biāo)華爾街同行的證券業(yè)IT而言,可以說基本上錯(cuò)過了上述計(jì)算資源集合應(yīng)用的三個(gè)浪潮.云計(jì)算興起后,OpenStack之類的技術(shù)在證券IT甚至金融界的成功落地、大規(guī)模采用的案例極其罕有(如果有的話).

即便是近年來互聯(lián)網(wǎng)云服務(wù)商興起,部分金融機(jī)構(gòu)因?yàn)樵囁ヂ?lián)網(wǎng)金融而開始使用公有云,很大程度上使用方式也不過是使用了一些虛擬機(jī)運(yùn)行一些互聯(lián)網(wǎng)邊緣(Edge)服務(wù).

然而這個(gè)時(shí)代有趣的地方在于,一些新技術(shù)的出現(xiàn)可以讓“彎道超車”、“后發(fā)制人”成為可能 – 上一個(gè)階段錯(cuò)過了一些東西,但是也可能下一個(gè)階段少了很多歷史包袱從而可以輕易跳進(jìn)最新的技術(shù)世代.容器,恰好就是這么一種技術(shù) – 假如你能把握的話.

在英語里,“容器”、“集裝箱”、“貨柜”都是同一個(gè)字 – Container.容器技術(shù)之于軟件業(yè),很有可能可以類比集裝箱對(duì)運(yùn)輸業(yè)的巨大影響.

實(shí)際上,確實(shí)有人想過把整個(gè)機(jī)房放在集裝箱里,例如2006年Sun Microsystems推出的Project Blackbox——?jiǎng)偤檬莵嗰R遜發(fā)布AWS的同一年.但這個(gè)集裝箱是鋼鐵的、有物理形體的、重量以噸為單位的；而其中的內(nèi)容,自然也是各種物理的服務(wù)器、網(wǎng)絡(luò)設(shè)備、發(fā)電機(jī).那一年,可能誰也沒有想到,10年后有一種“數(shù)字化”的虛擬集裝箱大行其道.

技術(shù)界不乏認(rèn)為容器對(duì)軟件技術(shù)產(chǎn)生革命性影響的觀點(diǎn),本人傾向于認(rèn)同這種觀點(diǎn),因?yàn)椋?/p>

• 容器影響開發(fā)者的開發(fā)方式、開發(fā)習(xí)慣,“強(qiáng)迫”他們?nèi)ニ伎祭鐭o狀態(tài)的服務(wù)、業(yè)務(wù)邏輯粒度的控制、資源的彈性伸縮、應(yīng)用代碼的發(fā)布形態(tài)、系統(tǒng)里面每一個(gè)細(xì)節(jié)的可監(jiān)控性等等.
• 讓真正的DevOps成為可能 – 自動(dòng)化測(cè)試、持續(xù)集成(CI)、持續(xù)交付(CD)、自動(dòng)化部署、無人值守的運(yùn)維… 開發(fā)與運(yùn)維的角色差異進(jìn)一步縮小,而效率則最大程度提升.
• 讓“不可變基礎(chǔ)設(shè)施”(Immutable infrastructure)成為可能——這將顛覆傳統(tǒng)軟件系統(tǒng)的升級(jí)發(fā)布和維護(hù)方式.

為什么作為金融系統(tǒng)、交易平臺(tái)的研發(fā)者,我們挑容器出現(xiàn)的時(shí)候跳進(jìn)云計(jì)算,而在更早階段虛擬機(jī)系列相關(guān)技術(shù)成熟時(shí)卻并沒有大的投入.

最根本原因在于,作為研發(fā)組織,我們從研發(fā)視角,基于具體應(yīng)用場(chǎng)景去持續(xù)、積極尋覓能解決強(qiáng)韌性、健壯性問題的解決方案 – 這是一種“Top-Down Thinking”,例如在交易量波動(dòng)過程中,我們能否有自動(dòng)化的技術(shù)去可靠的應(yīng)對(duì)、實(shí)現(xiàn)計(jì)算資源的彈性伸縮并且保持超級(jí)高效?

有什么技術(shù)可以幫助我們解決復(fù)雜交易系統(tǒng)發(fā)布、升級(jí)、打補(bǔ)丁的危險(xiǎn)和痛苦?交易故障出現(xiàn)時(shí)系統(tǒng)內(nèi)部防止雪崩效應(yīng)保持快速響應(yīng)的“熔斷”(circuit-breaker、fail-fast)機(jī)制有什么更規(guī)范的做法?用現(xiàn)有云計(jì)算的理論和技術(shù)倒著去套,顯然是無解的,因?yàn)椋?/p>

• 虛擬機(jī)級(jí)別的資源調(diào)度,太沉重,可編程接口太弱,無法“融入”到一個(gè)高性能運(yùn)算(HPC – High Performance Computing)的應(yīng)用中.
• 僅僅為了資源的彈性伸縮,去引入一個(gè)第三方解決方案,例如一個(gè)PaaS(諸如CloudFoundry、OpenShift等),對(duì)于交易系統(tǒng)而言,代價(jià)太大、可控性太低、編程模型受入侵程度太高.
• 不是為了云計(jì)算而云計(jì)算 – 一切“革新”需要合理、充分的應(yīng)用理由,場(chǎng)景不符合,架構(gòu)就不合理.

“Bottom-up Thinking”,即從基礎(chǔ)設(shè)施的可管理、資源充分共享、運(yùn)維更高效等角度去看問題,是一個(gè)典型的“運(yùn)維”視角或者所謂CIO的視角,這種思考,關(guān)注的是TCO(Total Cost of Ownership)——成本的降低(IT在垂直行業(yè)一直被認(rèn)為是一個(gè)成本中心 – 在現(xiàn)在這個(gè)時(shí)代這是一個(gè)錯(cuò)誤觀點(diǎn),但這是另一篇文章的討論范圍了)；可是和核心業(yè)務(wù)應(yīng)用非常脫節(jié).

對(duì)于一個(gè)傳統(tǒng)行業(yè)尤其是受監(jiān)管行業(yè)的IT而言,技術(shù)氛圍往往是保守和審慎的,采用云技術(shù)這種在互聯(lián)網(wǎng)界以外還很大程度被認(rèn)為是“新生事物”的東西,并不是一件容易的事情：在行業(yè)繁榮、企業(yè)賺錢的時(shí)候,公司很可能并不關(guān)注運(yùn)維除了穩(wěn)定以外的事情 – 包括用虛擬機(jī)還是用物理機(jī)、能否節(jié)省一點(diǎn)成本等等；

在市場(chǎng)不景氣、公司虧錢的時(shí)候,IT卻又需要以非常充分的數(shù)據(jù)來證明建立或者采用云平臺(tái)能帶來顯著的大幅的成本節(jié)省效果,但是這往往首先涉及第三方軟件的采購、機(jī)房的改造… 這本身就是一個(gè)巨大障礙.

所以,悲觀一點(diǎn)的看,很大一部分傳統(tǒng)行業(yè)IT,很可能需要等到云技術(shù)成熟為新世代IT系統(tǒng)的標(biāo)配,就像mainframe時(shí)代向client-server時(shí)代轉(zhuǎn)變、client-server時(shí)代向多層架構(gòu)/web技術(shù)時(shí)代切換,云技術(shù)成為一個(gè)主流的、企業(yè)決策者不再需要加以思索的事物(“no-brainer”)時(shí),才會(huì)順利進(jìn)入企業(yè)世界.此時(shí),運(yùn)維的視角也許才能被充分接受.但是,對(duì)于以創(chuàng)新為本業(yè)的金融科技,那已經(jīng)太遲.

早期的云技術(shù),從運(yùn)維視角去看是自然的,因?yàn)樘摂M化技術(shù)最開始是把基礎(chǔ)設(shè)施數(shù)字化的一個(gè)進(jìn)程.容器化技術(shù)的出現(xiàn),改變了這一切.容器天然與應(yīng)用服務(wù)結(jié)合的更緊密、天然需要程序員的深度介入,“上帝的歸上帝,凱撒的歸凱撒”,容器里面的歸程序猿(code monkey),容器外面的歸運(yùn)維狗(watchdog)——不一定對(duì),只是作為笑話簡(jiǎn)單粗暴的類比一下,但想說明的是容器內(nèi)外的關(guān)注點(diǎn)是不一樣的、而運(yùn)維與研發(fā)的協(xié)同則是深度的.

在Docker剛出現(xiàn)的時(shí)候,一直帶著前述問題的我們,從其理念已經(jīng)體會(huì)到容器技術(shù)對(duì)構(gòu)建一個(gè)強(qiáng)韌交易系統(tǒng)的好處.

容器技術(shù)的到來,讓我們?cè)谟^念上“彎道超車”：

• 在軟件安裝、發(fā)布方面,我們還需要去學(xué)習(xí)、模仿Oracle、IBM們研發(fā)什么工具嗎?不需要了 – 采用容器、容器編排技術(shù)、容器鏡像管理技術(shù)、容器目錄(catalog),我們輕易的“一鍵發(fā)布”,而且誰都可以執(zhí)行.
• 在打補(bǔ)丁方面,我們還要去參考Redhat開發(fā)個(gè)升級(jí)工具嗎?沒必要了,因?yàn)槲覀儾淮蜓a(bǔ)丁,已經(jīng)發(fā)布的容器里內(nèi)容永遠(yuǎn)不會(huì)改變(Immutable),需要修復(fù)缺陷或者升級(jí)版本,我們就發(fā)布新容器 – 發(fā)布組件乃至整個(gè)全新交易系統(tǒng),成本都是很低的(并且必須永遠(yuǎn)維持那么低).因此,我們也不一定需要什么中心化的、統(tǒng)一的、集中的可視化配置管理工具.
• 灰度發(fā)布、在線升級(jí)、多版本生產(chǎn)環(huán)境、回滾現(xiàn)在都是容器化系統(tǒng)天然自帶的——因?yàn)檎麄€(gè)系統(tǒng)的發(fā)布、部署是低成本的和快速高效的,只要有硬件資源就再發(fā)布一套,不行就切換回舊的那套 – 技術(shù)界已經(jīng)在不斷總結(jié)最佳實(shí)踐,總有一款套路適合你.基于容器的微服務(wù),天然支持多服務(wù)版本并存；對(duì)于回滾,數(shù)據(jù)庫可能是個(gè)問題,但首先一切以數(shù)據(jù)庫為中心就是個(gè)很有可能是錯(cuò)誤的觀念(當(dāng)然,視應(yīng)用場(chǎng)景而定),在分布式架構(gòu)里,關(guān)系型數(shù)據(jù)庫有可能不在系統(tǒng)關(guān)鍵路徑上、事務(wù)有好些辦法可以規(guī)避、通過很好的面向?qū)ο笤O(shè)計(jì)解耦內(nèi)存與持久層的耦合… 實(shí)際上,經(jīng)驗(yàn)告訴我們,關(guān)系型數(shù)據(jù)庫被濫用是企業(yè)應(yīng)用軟件的通病.

而比解決運(yùn)維問題更有趣的,是這幾方面：

• Infrastructure As Code – 現(xiàn)在總算不是口號(hào)了,對(duì)著容器、容器編排技術(shù)進(jìn)行編碼,讓“無人值守”、“智能運(yùn)維”真正成為可能.雖然Puppet、Chef、Ansible這些技術(shù)早就存在,但是它們基本上僅限于操作基礎(chǔ)設(shè)施的物理、虛擬資源,與一個(gè)專業(yè)應(yīng)用系統(tǒng)通過API深度結(jié)合然后基于業(yè)務(wù)場(chǎng)景、系統(tǒng)業(yè)務(wù)指標(biāo)來自我維護(hù),是非常困難的.而容器,基本上只是一個(gè)進(jìn)程,通過其API可以輕易深度整合到交易系統(tǒng)里.
• 容器技術(shù)出現(xiàn)后,也衍生出更多其他新興技術(shù),例如CoreOS、RancherOS、Unikernel.對(duì)于無止境追求極速性能的交易系統(tǒng),交易軟件到底層硬件之間的耗損越少越好,這和我們所遵循的mechanical sympathy技術(shù)理念完全一致.類似Unikernel這樣的所謂“l(fā)ibrary OS”非常有趣,因?yàn)檎麄€(gè)操作系統(tǒng)萎縮成一系列的基礎(chǔ)庫,由應(yīng)用軟件直接調(diào)用以便運(yùn)行在裸機(jī)(bare metal)上.想象一個(gè)超級(jí)輕量的交易中間件,無縫(真正意義上)運(yùn)行在裸機(jī)上的毫無羈絆裸奔的“爽”…
• 在廣發(fā)證券IT而言的所謂“彎道超車”,其實(shí)更包括幾方面的含義：一是觀念上的,顛覆傳統(tǒng)軟件研發(fā)的思維,不必要去做追隨者；二是技術(shù)成長(zhǎng)方面的 – 雖然有些技術(shù)如Unikernel并未成熟到可以真正運(yùn)用,但是兩三年前的Docker不也一樣嗎?重要的是團(tuán)隊(duì)和一個(gè)革命性技術(shù)的共同成長(zhǎng),前瞻性技術(shù)的研發(fā)投入終將回報(bào)(capitalize)；三是實(shí)際效果上的,雖然在云計(jì)算發(fā)力的前幾年,我們并未投入到IaaS、PaaS的“基建”,但是從容器化入手,忽然間就獲得了一定的“計(jì)算資源集合使用”的能力 – 此前只有技術(shù)實(shí)力較強(qiáng)的科技企業(yè)能做Grid Computing.

在證券業(yè),我們不是孤獨(dú)者.華爾街投行的表率高盛,今年2月份宣布了他們一年內(nèi)把90%的運(yùn)算能力容器化的計(jì)劃.

時(shí)至今天,在Docker已經(jīng)被團(tuán)隊(duì)廣為接受、被應(yīng)用到各種業(yè)務(wù)系統(tǒng)中去的時(shí)候,我們從兩個(gè)方向同時(shí)繼續(xù)推進(jìn)容器化技術(shù)：

• 第一個(gè)方向,繼續(xù)沿用上文所述的“Top-Down”思路,基于業(yè)務(wù)場(chǎng)景、具體應(yīng)用需要,把容器(Docker)、容器編排管理(Rancher)的技術(shù)深度整合到交易系統(tǒng)中去,讓其獲得自伸縮(elastic)、自監(jiān)控(self monitor)、自修復(fù)(self-healing)的自動(dòng)化能力 – 這是“反脆弱”系統(tǒng)的一個(gè)必要非充分條件.至于什么時(shí)候伸縮、什么時(shí)候自修復(fù)、如何學(xué)習(xí)自己的運(yùn)行行為以作自我調(diào)整、如何把低級(jí)的系統(tǒng)指標(biāo)換算成業(yè)務(wù)級(jí)別的性能指標(biāo)作為自己的健康“血壓計(jì)”… 這些是需持續(xù)學(xué)習(xí)挖掘、測(cè)試驗(yàn)證的東西.
• 第二個(gè)方向,是上文所述的“Bottom-Up”思路,采用例如Kubernetes建立起一個(gè)多租戶的CaaS(容器即服務(wù))平臺(tái),支持非交易的應(yīng)用系統(tǒng)(例如電商平臺(tái)、機(jī)器人投顧服務(wù)、CRM等等)的跨云(公有云、私有云、傳統(tǒng)機(jī)房)容器化.

在各種標(biāo)榜“云”的科技公司層出不窮的今天,其實(shí)依然還沒有任何“黑科技”幫閣下把你的脆弱系統(tǒng)瞬間變成一個(gè)強(qiáng)韌系統(tǒng)甚至一個(gè)具備反脆弱能力的系統(tǒng).所以,容器技術(shù)也不過是一個(gè)也許必要但不充分的有用工具而已.

能否釋放云計(jì)算的威力,取決于很多因素.到一個(gè)公有云上使用幾個(gè)虛擬機(jī),也算一個(gè)小小的進(jìn)步,畢竟它可能(1)縮短了一些傳統(tǒng)企業(yè)采購硬件、機(jī)器上架等等的周期；(2)幫不擅長(zhǎng)互聯(lián)網(wǎng)技術(shù)的傳統(tǒng)企業(yè)解決一部分“互聯(lián)網(wǎng)最后一公里”問題.然而,這只不過是使用了一些虛擬化基礎(chǔ)服務(wù),如果部署在上面的系統(tǒng)本身是一個(gè)脆弱系統(tǒng),那么它在云上依然是一個(gè)脆弱系統(tǒng).

實(shí)現(xiàn)一個(gè)強(qiáng)韌甚至反脆弱的技術(shù)系統(tǒng),你首先得有一個(gè)恰當(dāng)?shù)募夹g(shù)架構(gòu),而實(shí)現(xiàn)這樣的技術(shù)架構(gòu),你首先需要有研發(fā)團(tuán)隊(duì) – 不錯(cuò),個(gè)人觀點(diǎn)是,在現(xiàn)階段如果不具備軟件研發(fā)能力,那么你的組織其實(shí)無法真正利用、享受到云技術(shù)帶來的福利.

怎樣的架構(gòu)才能利用和釋放云計(jì)算能力?

首先,架構(gòu)設(shè)計(jì)需要遵循Reactive(響應(yīng)式)原則(根據(jù)“響應(yīng)式宣言”)：

• Elasticity – 彈性響應(yīng)系統(tǒng)負(fù)載變化,基于實(shí)時(shí)性能監(jiān)控指標(biāo)以便通過預(yù)測(cè)性(predictive)和響應(yīng)性(reactive)算法來對(duì)系統(tǒng)進(jìn)行擴(kuò)容.
• Resiliency – 通過復(fù)制(replication)、包容(containment)、隔離(isolation)和委托(delegation)等機(jī)制,保障在故障發(fā)生時(shí)系統(tǒng)能繼續(xù)高度可用.
• Responsive – 系統(tǒng)及時(shí)探測(cè)偵察問題并解決問題,保障對(duì)外的及時(shí)響應(yīng).
• Message-driven – 采用消息驅(qū)動(dòng)的、非堵塞的異步通訊機(jī)制,降低系統(tǒng)內(nèi)部組件模塊間的耦合度,提升吞吐量.

其次,在技術(shù)研發(fā)過程中,我們采用一系列的所謂“Cloud-native patterns”(原生,或者說“天然”的云計(jì)算架構(gòu)模式)來實(shí)現(xiàn)我們的系統(tǒng),以便讓系統(tǒng)達(dá)到Cloud-ready(具備云感知能力 – 借用IBM與Intel相關(guān)中文版論文的概念).

此外,“云感知”和上述“響應(yīng)式”原則,是完全一致的,云感知也關(guān)注“故障恢復(fù)能力”、“延遲恢復(fù)能力”、“擴(kuò)展的靈活性”.事實(shí)上,在一流的金融IT團(tuán)隊(duì)里,這些原則、實(shí)踐要求,從來都是被遵循的,因?yàn)榻鹑诘膽?yīng)用系統(tǒng)天然需要這些能力.無論是否在云計(jì)算時(shí)代,這些原則、要求均非常合理.

那么容器化技術(shù)在這其中有什么作用呢?實(shí)踐告訴我們,作用很大.最重要一點(diǎn)是,很多pattern的具體技術(shù)實(shí)現(xiàn),可以挪到容器層面去處理.例如Circuit-breaker和Fail-fast這類模式,過去的做法,是各個(gè)具體的服務(wù),采用自己的技術(shù)工具(例如Node.js的守護(hù)進(jìn)程PM2)和辦法,基于開發(fā)者自己的理解,各自實(shí)現(xiàn).

容器化的好處,是把復(fù)雜系統(tǒng)里一切異構(gòu)的技術(shù)(無論以Go、Java、Python還是Node.js實(shí)現(xiàn))都裝載到一個(gè)個(gè)的標(biāo)準(zhǔn)集裝箱里,然后通過調(diào)度中心基于各種監(jiān)控對(duì)這些集裝箱進(jìn)行調(diào)度處理.也就是說,Cloud-native的架構(gòu)模式,有不少是可以在容器編排調(diào)度與協(xié)同的這一層實(shí)現(xiàn)的.

IT領(lǐng)域不知道有無類似的人物,諸如面向?qū)ο笤O(shè)計(jì)、架構(gòu)設(shè)計(jì)模式、敏捷開發(fā)領(lǐng)域的大師級(jí)人物Martin Fowler等,顯然是抽象思維特別強(qiáng)的人,能夠?qū)?fù)雜的技術(shù)世界進(jìn)行“模式識(shí)別”而作出一些深刻思考.

在技術(shù)世界里,我們一向強(qiáng)調(diào)方法論,可是有時(shí)候也需要形成“世界觀”、“信仰”.在無數(shù)次的項(xiàng)目危機(jī)管理、技術(shù)故障攻堅(jiān)、運(yùn)維救火之后,IT人也許應(yīng)該對(duì)“世間唯一不變的是變化本身”有深刻體會(huì),從而接受“擁抱不確定”的觀念.

IT界面對(duì)變化與不確定性的態(tài)度,這十多年來看也是一個(gè)有趣的演變：

• 直到本世紀(jì)初,很多項(xiàng)目管理及軟件工程的方法論,依然強(qiáng)調(diào)所謂的“Change management”(變更管理),通過組織(“變更委員會(huì)”)、流程來“管理”業(yè)務(wù)系統(tǒng)需求方不斷提出的需求管理,視需求變化為項(xiàng)目延誤、系統(tǒng)不穩(wěn)定的根源,以項(xiàng)目“按時(shí)”交付為終極目標(biāo),可以說這些方法論本質(zhì)上“厭惡“變更.
• 互聯(lián)網(wǎng)風(fēng)起云涌后,出于應(yīng)對(duì)瞬息萬變的激烈競(jìng)爭(zhēng)、在線高效運(yùn)營(yíng)的剛需,接受“需求變化是常態(tài)”、對(duì)變更友好的“敏捷”(Agile)方法被自然而然引入到日常項(xiàng)目中,成為過去十年的主流方法論,并且終于把傳統(tǒng)企業(yè)IT牽引其中(例如廣發(fā)證券IT啟動(dòng)金融電商系列項(xiàng)目研發(fā)前的第一件事就是先把敏捷實(shí)踐建立起來 – 對(duì)口的方法論才可能帶來對(duì)的結(jié)果).
• 然而,絕大部分企業(yè)的敏捷實(shí)踐都局限在垂直業(yè)務(wù)線的項(xiàng)目團(tuán)隊(duì)里,而運(yùn)維作為一個(gè)維護(hù)全企業(yè)IT生產(chǎn)資源的橫向平臺(tái)型組織,通常被排除在敏捷實(shí)踐之外.

  敏捷迭代方法解決得了業(yè)務(wù)需求變更的問題,解決不了系統(tǒng)上線后各種突發(fā)性的變化 – 故障的及時(shí)解決、版本的迅速更新(業(yè)務(wù)部門總是迫不及待的)、在線經(jīng)營(yíng)的瞬間生效(運(yùn)營(yíng)人員分分秒秒催著)…

  在一切都嫌慢的“互聯(lián)網(wǎng)時(shí)間”里,運(yùn)維貌似成為最后掉鏈的一環(huán),以“穩(wěn)健”為主導(dǎo)的運(yùn)維團(tuán)隊(duì)與“進(jìn)取”的研發(fā)、運(yùn)營(yíng)團(tuán)隊(duì)無可避免產(chǎn)生沖突

• 時(shí)至今天,隨著“把基礎(chǔ)設(shè)施數(shù)字化”的云計(jì)算的普及,一個(gè)新的方法論 – DevOps,閃亮登場(chǎng).之所以說這是一個(gè)方法論,是因?yàn)樗^不僅僅是“Dev + Ops”這樣簡(jiǎn)單粗暴的把開發(fā)工程師和運(yùn)維工程師捆在一起,用“同一個(gè)項(xiàng)目組”、“同一套KPI”來強(qiáng)迫他們分享“同一個(gè)夢(mèng)想”了事.

  它是在APM(應(yīng)用性能監(jiān)控)、Infrastructure As Code(可編程運(yùn)維)、Virtualization(虛擬化)、Containerization(容器化)等等這些云計(jì)算時(shí)代的產(chǎn)物出現(xiàn)后,基于新的技術(shù)工具、技術(shù)理念而自然產(chǎn)生的.

  持續(xù)集成(Continuous Integration)、持續(xù)交付(Continuous Delivery)、持續(xù)運(yùn)維(Continuous Operation)是DevOps的具體環(huán)節(jié)和手段,它相當(dāng)于把一條純數(shù)字化鏈路上不同的參與者關(guān)聯(lián)到一起 – 無論是開發(fā)工程師還是運(yùn)維工程師,最終都不過是身份稍微差異的Information worker.

DevOps可能不僅僅是個(gè)概念、方法論、技術(shù)新名詞,它是伴隨云計(jì)算自然發(fā)生的.但它的接受與運(yùn)用,對(duì)于傳統(tǒng)企業(yè)的IT,尤其是“維穩(wěn)”為主導(dǎo)思想的受監(jiān)管行業(yè)的IT,可能是一種文化沖擊.

傳統(tǒng)IT甚至是今天的很多技術(shù)相對(duì)前沿的互聯(lián)網(wǎng)公司,依然把團(tuán)隊(duì)拆分成“運(yùn)維”、“開發(fā)”,在組織結(jié)構(gòu)層面建立相互制衡,以避免開發(fā)團(tuán)隊(duì)的“沖動(dòng)冒進(jìn)”導(dǎo)致生產(chǎn)系統(tǒng)的不穩(wěn)定,但運(yùn)維職能往往變成一種“權(quán)力”(privilege)- 系統(tǒng)的迭代更新都需要獲得運(yùn)維“審批”,這本身顯然就是一個(gè)“脆弱系統(tǒng)”,因?yàn)閷?duì)變更是絕不友好的.在技術(shù)進(jìn)步、時(shí)代變遷的大環(huán)境下,這種過去合理的做法,早晚變成一個(gè)將要被顛覆的存在.

無論如何,我們認(rèn)為割裂的討論一個(gè)高性能運(yùn)算(HPC)的技術(shù)系統(tǒng)(如證券交易系統(tǒng))的容器化、“云化”是不夠的,DevOps是構(gòu)建“反脆弱”技術(shù)系統(tǒng)的方法論(起碼到目前為止.也許將來有新的思維出現(xiàn)),也是我們系統(tǒng)能力的天然一部分.

我們從軟件研發(fā)的視角、證券交易的視角來看待云計(jì)算,深感把促進(jìn)基礎(chǔ)設(shè)施數(shù)字化、運(yùn)維代碼化的容器化技術(shù),運(yùn)用到交易系統(tǒng)技術(shù)中,是天作之合 – 假如運(yùn)用得當(dāng)?shù)脑?結(jié)合機(jī)器學(xué)習(xí)和智能算法,能幫助我們構(gòu)建一些“反脆弱”的技術(shù)方案(既然有能下圍棋的阿爾法狗,我們是否也可以開始憧憬懂得自救的運(yùn)維狗?).

可以看到的潮流脈絡(luò)是,世界是越來越數(shù)字化的、變化是越來越頻繁的、而IT是需要擁抱變化的,云計(jì)算則只是這個(gè)潮流里完全符合趨勢(shì)而自然出現(xiàn)的技術(shù)階段.

有一天Oracle、SAP、各種著名與非知名的專業(yè)軟件都把它們自身的產(chǎn)品基于容器來構(gòu)建(例如一個(gè)多進(jìn)程組成的數(shù)據(jù)庫實(shí)例里的進(jìn)程各自運(yùn)行在自己的容器中),也許對(duì)于行業(yè)監(jiān)管者、企業(yè)技術(shù)決策者而言,云已經(jīng)無需概念上的存在,而能被毫無質(zhì)疑的接受.

但是這一天到來之前,大部分企業(yè)也許可以先嘗試調(diào)整一個(gè)對(duì)云服務(wù)友好的財(cái)務(wù)制度 – 項(xiàng)目立項(xiàng)的時(shí)候,硬件預(yù)算按CPU核數(shù)、內(nèi)存量、存儲(chǔ)量來報(bào)算,有形的物理機(jī)器不再作為資產(chǎn)稽核到各條業(yè)務(wù)線各個(gè)項(xiàng)目組,一切物理硬件歸IT.制度和文化,往往才是隱形的決定因素,不是嗎?

文章出處：InfoQ

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4407.html