[[204814]]

主要結(jié)論

• 在評(píng)估新技術(shù)的過程中進(jìn)行缺口分析（Gap analysis）
• 可通過持續(xù)部署和持續(xù)集成模型緩解并預(yù)防安全弱點(diǎn)
• 通過為部署流程提供工具實(shí)現(xiàn)自動(dòng)化的安全掃描
• 快速部署模型需要相應(yīng)范圍的測(cè)試并鼓勵(lì)測(cè)試驅(qū)動(dòng)的開發(fā)（TDD）
• 客戶端 Web 框架能跨越 Web、iOS 及 Android 等多種客戶端架構(gòu)提供更一致的 API

2008 年到 2014 年間，LinkedIn 全球用戶數(shù)從約 1600 萬增長(zhǎng)至約 3.3 億，短時(shí)間內(nèi)爆發(fā)式增長(zhǎng)為基礎(chǔ)架構(gòu)造成了重重壓力。隨著用戶數(shù)持續(xù)增長(zhǎng)，我們需要更深入地了解用戶對(duì)我們平臺(tái)的使用方式，以及通過哪些新產(chǎn)品線能更好地滿足全球職場(chǎng)專家的需求。

超高速增長(zhǎng)過程中的縮放

因此我們開發(fā)了多個(gè)內(nèi)部使用的 Web 應(yīng)用程序，工程師、產(chǎn)品經(jīng)理、高管、運(yùn)維團(tuán)隊(duì)會(huì)使用這些工具執(zhí)行從 A/B 測(cè)試、應(yīng)用程序開發(fā)和生命周期管理，到報(bào)表和分析在內(nèi)的各種任務(wù)。隨著新應(yīng)用快速變得充實(shí)，我們也開始通過新方法解決技術(shù)問題，陸續(xù)引入并推廣了更多不同類型的語言、框架和工具。這樣的增長(zhǎng)和實(shí)驗(yàn)最終導(dǎo)致不同部門的技術(shù)和解決方案間缺乏統(tǒng)一性，隨著越來越多新入職工程師組建新團(tuán)隊(duì)，造成了不小的壓力。

諸如 Python、Ruby、Java、Scala、JavaScript 等語言出現(xiàn)在各種工作任務(wù)中，此外還有不停的收購(gòu)，導(dǎo)致整個(gè)生態(tài)內(nèi)包含大量相互無法兼容，但又必不可少的解決方案。別忘了，這種探索的本意是好的，是為了針對(duì)面臨的問題尋找最棒的長(zhǎng)期解決方案。我們鼓勵(lì)不同團(tuán)隊(duì)尋找自己認(rèn)為能為組織帶來價(jià)值的技術(shù)，而這種探索過程本身也可以幫助我們確定可以在長(zhǎng)期范圍內(nèi)依賴的技術(shù)，進(jìn)而在硅谷和全球范圍內(nèi)快速縮放，始終保持領(lǐng)先地位。

2015 年中期，數(shù)十個(gè)依然處于活躍狀態(tài)的項(xiàng)目已經(jīng)使用了不同實(shí)現(xiàn)、框架以及庫。由于方法各不相同，團(tuán)隊(duì)間代碼分享很麻煩，需要通過不同代碼庫和工作成果來體現(xiàn)，并且實(shí)現(xiàn)結(jié)果本身也缺乏統(tǒng)一性。例如僅就 JavaScript 來說，有些團(tuán)隊(duì)同時(shí)使用了庫和 jQuery 以及 Backbone.js 等微庫（Micro-library），一些團(tuán)隊(duì)使用了主流框架，一些團(tuán)隊(duì)開發(fā)了自己的框架。通過何種方法為應(yīng)用構(gòu)建前端，開發(fā)者如何跨團(tuán)隊(duì)共享通用邏輯，從開發(fā)者的工效和滿意度方面來說如何提供更流暢的最佳實(shí)踐，這些方面逐漸開始面臨不確定性。

你可能已經(jīng)想到了，從長(zhǎng)期角度來看，所用技術(shù)的數(shù)量不斷增長(zhǎng)也會(huì)造成安全債。由于使用了大量框架、語言和組件，我們?cè)絹碓诫y以評(píng)估在這基礎(chǔ)上開發(fā)出的應(yīng)用程序的安全狀況。此外這也削弱了我們發(fā)布通用框架級(jí)安全解決方案，借此緩解某些類型安全漏洞危害的做法所能實(shí)現(xiàn)的效果。

緩慢的部署流程所產(chǎn)生的影響

與此同時(shí)，僅 LinkedIn.com 網(wǎng)站本身，復(fù)雜的基礎(chǔ)架構(gòu)就已包含超過 3,000 個(gè)子模塊，代碼總量超過 6 百萬行，所有這些內(nèi)容都包含在一個(gè)代碼庫主干（Trunk）中。這個(gè)主干通過一種乏味的月度發(fā)布周期進(jìn)行管理，有多個(gè)團(tuán)隊(duì)的數(shù)百位工程師參與其中。每次發(fā)布前需要選擇一個(gè)發(fā)布候選版（RC），隨后將該版本交給測(cè)試團(tuán)隊(duì)進(jìn)行為期四天的手工回歸測(cè)試。如果發(fā)現(xiàn)任何 Bug，會(huì)對(duì) RC 版本開發(fā)熱修復(fù)程序，以避免對(duì)部署流程產(chǎn)生影響。為避免再等一個(gè)月才能向用戶提供新功能或 Bug 修復(fù)，工程師們往往會(huì)“疲于奔命”趕在截止期限前將自己的代碼簽入。

(點(diǎn)擊放大圖像)

圖 1：我們?cè)镜牟渴鹆鞒?/p>

這種循序漸進(jìn)，對(duì)時(shí)間要求極為嚴(yán)格的流程要求產(chǎn)品經(jīng)理和營(yíng)銷合作伙伴必須共同就工作時(shí)間做出非常細(xì)致的安排，雙方必須針對(duì)新功能的發(fā)布制定一致的規(guī)劃。但是針對(duì)用戶反饋進(jìn)行迭代的過程也變得非常困難，因?yàn)槲覀兊陌l(fā)布工作每年只能進(jìn)行十二次。

此外，為了預(yù)防和緩解潛在安全漏洞，也對(duì)部署和發(fā)布流程提出了更高要求。我們必須做到：一旦確定某個(gè)需要的修復(fù)程序，必須盡快部署到生產(chǎn)環(huán)境。這通常意味著安全問題的修復(fù)程序必須獨(dú)立于發(fā)布周期實(shí)現(xiàn)熱修復(fù)。通常來說，在相對(duì)隔離的情況下部署安全補(bǔ)丁是一種好的實(shí)踐，例如在部署安全更新過程中，不同時(shí)部署與安全性無關(guān)的 Bug 修復(fù)程序。這主要是為了降低當(dāng)非安全更新影響到網(wǎng)站功能而需回滾時(shí)，重新暴露出安全漏洞的可能性。

飛快增長(zhǎng)伴隨著一個(gè)不那么明顯的副作用：發(fā)布節(jié)奏變長(zhǎng)，不同技術(shù)混用造成了“斑駁”不一致的用戶體驗(yàn)（UX）。隨著 LinkedIn 開始在產(chǎn)品開發(fā)過程中進(jìn)行用戶調(diào)研，我們發(fā)現(xiàn)很多用戶覺得網(wǎng)站體驗(yàn)開始變得支離破碎，不同頁面看起來感覺截然不同。因?yàn)椴煌瑘F(tuán)隊(duì)都在通過各自周期發(fā)布，導(dǎo)致有關(guān) UI 變更的反饋環(huán)路延遲，進(jìn)而在長(zhǎng)期范圍內(nèi)影響到變更質(zhì)量。

我們采用了 3×3 方法論

2014 年 ，LinkedIn 移動(dòng)工程團(tuán)隊(duì)進(jìn)行的一次實(shí)驗(yàn)最終催生了目前我們使用的發(fā)布模型。這種被稱之為 Train Release 的方法將原本每月發(fā)布一次的節(jié)奏變?yōu)橐环N名叫 3×3，每天發(fā)布三次的方法，借此可將提交后的代碼在三小時(shí)內(nèi)發(fā)布給用戶。

這種想法并非僅適用于 Web 相關(guān)的開發(fā)。我們的最終目標(biāo)是讓包括 iOS、Android、API，以及組成 LinkedIn.com 網(wǎng)站體驗(yàn)，以及其他擴(kuò)展產(chǎn)品線和服務(wù)在內(nèi)的其他后端服務(wù)，所有平臺(tái)都使用這樣的發(fā)布節(jié)奏。

向這種發(fā)布模型的轉(zhuǎn)變過程充滿了挑戰(zhàn)，需要所有工程人員，尤其是工具和基礎(chǔ)架構(gòu)團(tuán)隊(duì)的參與。這也意味著現(xiàn)有的內(nèi)部應(yīng)用和工具需要革新，以確保開發(fā)者可以針對(duì)部署流程的狀態(tài)變更獲得更及時(shí)的信息，而他們?cè)疽呀?jīng)通過必要的腳本和系統(tǒng)對(duì)流程中的大部分任務(wù)實(shí)現(xiàn)了自動(dòng)化，同時(shí)需要通過必要的端到端測(cè)試確保實(shí)現(xiàn)足夠的代碼覆蓋面。

由于新方法的發(fā)布周期間時(shí)間窗口大幅縮短，短時(shí)間內(nèi)可能無法對(duì)所有變更進(jìn)行測(cè)試，這也更進(jìn)一步增加了對(duì)測(cè)試技術(shù)和自動(dòng)化技術(shù)的依賴。此外結(jié)合其他方面的挑戰(zhàn)，使得我們需要通過客戶端技術(shù)加強(qiáng)對(duì)開發(fā)生命周期內(nèi)測(cè)試工作的重視，畢竟從歷史上來看，整個(gè)業(yè)界都不認(rèn)為測(cè)試工作應(yīng)該是客戶端工程領(lǐng)域需要考慮的，Web 領(lǐng)域更是如此。這個(gè)問題與上文提到的其他痛點(diǎn)結(jié)合在一起，使得我們決定不僅需要對(duì) LinkedIn.com 體驗(yàn)做出改變，同時(shí)也要改變基礎(chǔ)架構(gòu)和應(yīng)用程序?qū)蛹夹g(shù)棧的結(jié)構(gòu)。

這意味著平臺(tái)方面發(fā)現(xiàn)的安全問題現(xiàn)在可以在極端時(shí)間里修復(fù)，同時(shí)也意味著隨著代碼的更快速部署，也會(huì)更快速遇到安全問題。當(dāng)組成 LinkedIn 生態(tài)的上百個(gè)應(yīng)用開始采用這種模型后，我們的安全技術(shù)也需要更進(jìn)一步的自動(dòng)化。

我們的“下一步”措施

為了實(shí)現(xiàn)安全的 Web 應(yīng)用程序，一種簡(jiǎn)單但強(qiáng)大的方法是選擇本身就具備相應(yīng)安全特性的框架。當(dāng)然，框架的選擇不能只從安全性著手，性能、易用性，以及其他因素同樣重要。

我們的基礎(chǔ)架構(gòu)團(tuán)隊(duì)與其他合作伙伴團(tuán)隊(duì)攜手，開始廣泛研究并評(píng)估不同語言、框架，以及庫，針對(duì)不同技術(shù)進(jìn)行缺口分析，這些工作完整涵蓋了服務(wù)器端，以及當(dāng)前和未來產(chǎn)品線與內(nèi)部平臺(tái)中充當(dāng)各類工具的應(yīng)用程序。

此外我們的用戶體驗(yàn)研究團(tuán)隊(duì)也邀請(qǐng)用戶參與焦點(diǎn)小組討論和反饋工作，更好地了解用戶對(duì) LinkedIn.com 訪問體驗(yàn)的看法和感受。

產(chǎn)品、設(shè)計(jì)、工程，多方聯(lián)手努力催生了 Voyager 項(xiàng)目，這是一個(gè)移動(dòng)為先，跨平臺(tái)（iOS、Android、Web）的一致用戶體驗(yàn)（UX）。移動(dòng)為先，這種思路使得我們有機(jī)會(huì)隨后擴(kuò)展至桌面應(yīng)用端，并能沿用相同的界面模式和主題，跨越所有平臺(tái)提供一致的體驗(yàn)。

(點(diǎn)擊放大圖像)

圖 2：“Voyager”項(xiàng)目

通過這些努力，我們選擇用兩個(gè)框架構(gòu)建 API 和 Web 客戶端：面向 Java 的 Play Framework，以及面向 Web 的 Ember 框架，這兩個(gè)框架已成為我們構(gòu)建 Web 應(yīng)用的事實(shí)標(biāo)準(zhǔn)。在設(shè)立這個(gè)新項(xiàng)目前，LinkedIn 就已在 Play Framework 方面投入了大量精力，我們的安全團(tuán)隊(duì)就這些框架目前具備的安全特性，結(jié)合我們希望自己的技術(shù)棧具備的特性進(jìn)行了全面的缺口分析。

分析發(fā)現(xiàn) Play Framework 提供了一種“默認(rèn)安全”的方法，同時(shí)還有著負(fù)責(zé)任的安全團(tuán)隊(duì)，活躍的核心開發(fā)者社區(qū)，豐富的文檔，以及穩(wěn)定的發(fā)布周期。

Ember 也具備上述所有特征。作為一種單頁應(yīng)用（SPA）框架，Ember 還提供了：

• 通過 Fastboot 等技術(shù)為服務(wù)器端渲染（SSR）提供后續(xù)支持，
• 側(cè)重于開發(fā)者，基于 CLI 的工效，如生成器和藍(lán)圖，以及加載項(xiàng)社區(qū)，
• 活躍的核心開發(fā)者社區(qū)，
• 通過清晰強(qiáng)大的抽象基元（Primitive）專注于新興行業(yè)標(biāo)準(zhǔn)的影響和 Polyfill，
• 一個(gè)妥善開發(fā)，可用于 UI 組件測(cè)試的語義學(xué)方法。

通過將 Web 轉(zhuǎn)變成一種客戶端應(yīng)用，我們已經(jīng)可以為所有客戶端（iOS、Android、Web）建立一套統(tǒng)一的內(nèi)部 API，將整個(gè)基礎(chǔ)架構(gòu)更好地與不同平臺(tái)相匹配，減少為了提供數(shù)據(jù)而需要的應(yīng)用程序數(shù)量。

Ember 對(duì)測(cè)試工作的專注使得我們實(shí)現(xiàn)了更進(jìn)一步的自動(dòng)化部署，這有助于 3×3 方法的推廣。該框架提供了三種不同類型的測(cè)試：集成測(cè)試、接受度測(cè)試，以及單元測(cè)試。集成測(cè)試使得我們可以對(duì)數(shù)據(jù)的流動(dòng)以及應(yīng)用程序內(nèi)部不同組件的交互進(jìn)行測(cè)試，接受度測(cè)試使得我們可以進(jìn)行用戶交互測(cè)試，單元測(cè)試為我們提供了測(cè)試應(yīng)用程序邏輯所需的方法。隨著開發(fā)者逐漸發(fā)布新組件，該框架也能生成所需的測(cè)試文件，借此開發(fā)者可以更專注于編寫代碼并在測(cè)試中驗(yàn)證代碼功能，而不像以前只能在瀏覽器中執(zhí)行這些操作。

縱深安全

LinkedIn 安全團(tuán)隊(duì)執(zhí)行的縱深設(shè)計(jì)審查需要對(duì)所有面向用戶的產(chǎn)品/特性以及功能進(jìn)行滲透測(cè)試。我們還在安全自動(dòng)化方面進(jìn)行了巨大的投入，然而對(duì)于 3×3 部署架構(gòu)，我們無法對(duì)所有構(gòu)建進(jìn)行規(guī)?；氖止B透測(cè)試，因此就更有必要采用安全自動(dòng)化技術(shù)。一旦發(fā)現(xiàn)可以更自信地檢測(cè)出某類弱點(diǎn)，我們會(huì)為此類弱點(diǎn)構(gòu)建自動(dòng)化檢查。合作伙伴產(chǎn)品安全工程團(tuán)隊(duì)也會(huì)幫助我們構(gòu)建、維護(hù)、縮放這種自動(dòng)化機(jī)制。借此可以更加專注于應(yīng)用程序/底層框架中更重要的領(lǐng)域，并且能獲得更多時(shí)間深入研究這些領(lǐng)域的安全弱點(diǎn)。

在向應(yīng)用程序中增加 API 端點(diǎn)后，需要通過安全分析防止出現(xiàn)弱點(diǎn)。以前這一過程在操作上極為笨重，畢竟每個(gè)應(yīng)用程序包含大量路由（指向資源或 URL 的路徑），同時(shí)系統(tǒng)中存在大量此類應(yīng)用程序。我們的安全團(tuán)隊(duì)構(gòu)建了一套工具，可以檢測(cè)應(yīng)用程序中新的變更并通知我們，按照變更的本質(zhì)對(duì)其進(jìn)行分解（外部 API 路由的增減、應(yīng)用程序重要代碼的改動(dòng)等），借此協(xié)助對(duì)應(yīng)用程序中此類情況進(jìn)行評(píng)估。因此我們可以通過最新審閱確定應(yīng)用程序的狀態(tài)。借此可以進(jìn)行有針對(duì)性的審閱，確保更廣泛的覆蓋面，同時(shí)應(yīng)用程序的評(píng)估可以實(shí)現(xiàn)更快速的周轉(zhuǎn)時(shí)間。

我們通過縱深防御的原則建立了一套安全評(píng)估方法，畢竟誰也不想因?yàn)槟硞€(gè)特定安全能控制的失敗導(dǎo)致整個(gè)鏈條的失敗。我們樂于為開發(fā)者提供他們需要的工具，幫助他們避免在代碼中產(chǎn)生安全弱點(diǎn)。我們的產(chǎn)品安全團(tuán)隊(duì)開發(fā)的工具可以掃描代碼變更中可能存在的弱點(diǎn)，如果發(fā)現(xiàn)任何反模式或不建議使用的實(shí)踐，開發(fā)者在提交代碼前就可以獲得通知，并通過這些工具提供的代碼修復(fù)建議，妥善解決存在的問題。一旦順利通過代碼審查流程，變更還會(huì)被進(jìn)一步分析，如果發(fā)現(xiàn)可能的弱點(diǎn)，會(huì)通過自定義的提交前鉤子，直接在部署流程的提交前階段直接拒絕這樣的代碼。

一旦通過任何渠道檢測(cè)到平臺(tái)存在安全問題，隨后我們的目標(biāo)是防止未來繼續(xù)出現(xiàn)相同問題。因此為了避免問題回歸，我們構(gòu)建了工具和測(cè)試用例，并針對(duì)已部署的服務(wù)持續(xù)運(yùn)行，以檢測(cè)特定類型的安全弱點(diǎn)是否會(huì)再次出現(xiàn)，并會(huì)向安全團(tuán)隊(duì)發(fā)送警報(bào)協(xié)助他們調(diào)查。

(點(diǎn)擊放大圖像)

圖 3：掃描潛在 XSS 的提交前鉤子工具

2014 年 1 月，該系統(tǒng)上線之前，我們通過代碼掃描發(fā)現(xiàn)了超過 5,000 個(gè)潛在的 XSS 弱點(diǎn)；2016 年 1 月，這一數(shù)量降低至不到 500 個(gè)。這段時(shí)間里，我們觀察到由于不恰當(dāng)?shù)奶峤粚?dǎo)致的提交前故障的數(shù)量也穩(wěn)步地大幅降低。通過這種系統(tǒng)化的安全自動(dòng)化方法，潛在安全弱點(diǎn)的產(chǎn)生和存在數(shù)量幾乎減少了 90%。

(點(diǎn)擊放大圖像)

圖 4：我們目前的（3×3）發(fā)布周期

目前我們?cè)?Web 客戶端方面平均每天進(jìn)行大約 50-75 次提交，這些工作是由超過 100 位 UI 工程師通過同一個(gè)代碼庫進(jìn)行的。每個(gè)提交都會(huì)經(jīng)歷代碼審查系統(tǒng)的檢查，需要開發(fā)者通過訪問控制列表（ACL）進(jìn)行多次相互獨(dú)立的批準(zhǔn)，借此確保代碼始終保持最高質(zhì)量。同時(shí)這些代碼還會(huì)針對(duì)最佳實(shí)踐風(fēng)格指南進(jìn)行評(píng)估，并使用不同語言的 Linter 進(jìn)行掃描，以確保開發(fā)者編寫的代碼能夠與同事保持一致。如上所述，這些代碼變更還會(huì)進(jìn)行自動(dòng)化的自定義安全掃描，檢查其中可能包含的已知類別弱點(diǎn)，包括但不限于 XSS、CSRF，以及訪問控制問題。一旦開發(fā)者獲得了所需的審批，并解決了任何可能存在的問題，即可通過一系列系統(tǒng)順利提交自己的代碼，在確保代碼健康度的同時(shí)等待下一次部署。

這些系統(tǒng)會(huì)執(zhí)行一系列不同任務(wù)，針對(duì)應(yīng)用程序運(yùn)行各種測(cè)試。如果測(cè)試未通過，提交會(huì)被拒絕并會(huì)通知開發(fā)者。如果提交通過，即可進(jìn)入應(yīng)用程序主干，隨后會(huì)運(yùn)行一系列單獨(dú)的測(cè)試以確保代碼不會(huì)造成性能退化或超出應(yīng)用程序負(fù)責(zé)人所指定的其他閾值。假設(shè)所有這一切均能順利通過，提交過程順利結(jié)束，代碼會(huì)在下一次部署時(shí)進(jìn)入生產(chǎn)環(huán)境。如果兩次部署之間沒有產(chǎn)生任何提交，那么依然會(huì)使用相同版本進(jìn)行重新部署，這也是 3×3 方法論的一部分，可以確保代碼能夠進(jìn)行嚴(yán)格的測(cè)試。

借此形成的全新發(fā)布模型使得我們可以按照組織規(guī)模的增長(zhǎng)順利縮放，同時(shí)大幅改進(jìn)了代碼質(zhì)量、安全性、生產(chǎn)力，以及用戶滿意度?，F(xiàn)在我們可以更好地為用戶提供更安全、更快速、更現(xiàn)代化的體驗(yàn)，快速解決發(fā)現(xiàn)的問題或 Bug，以更快的速度進(jìn)行創(chuàng)新。

關(guān)于本文作者

[[204815]]James Baker 是 LinkedIn Feed（首頁）團(tuán)隊(duì)的資深軟件工程師，致力于為全球數(shù)百萬 LinkedIn 用戶提供卓越的使用體驗(yàn)。James 從 2009 年開始積極從事 Web 工程方面的工作，而他早在 2004 年就開始投身 IT 行業(yè)。他住在硅谷，熱衷于開發(fā)企業(yè)級(jí)、高性能、安全、易于訪問的 Web 應(yīng)用程序。

[[204816]]Mira Thambireddy 是 LinkedIn 的信息安全工程師，隸屬于 LinkedIn 的應(yīng)用程序安全和滲透測(cè)試團(tuán)隊(duì)。之前 Mira 曾作為安全顧問在硅谷工作，她持有卡耐基·梅隆大學(xué)（Carnegie Mellon University）信息安全碩士學(xué)位。

作者： James Baker 、 Mira Thambireddy ， 閱讀英文原文 ： Developing a Secure and Scalable Web Ecosystem at LinkedIn