[[204814]]

主要結論

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

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

超高速增長過程中的縮放

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

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

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

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

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

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

(點擊放大圖像)

圖 1：我們原本的部署流程

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

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

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

我們采用了 3×3 方法論

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

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

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

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

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

我們的“下一步”措施

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

我們的基礎架構團隊與其他合作伙伴團隊攜手，開始廣泛研究并評估不同語言、框架，以及庫，針對不同技術進行缺口分析，這些工作完整涵蓋了服務器端，以及當前和未來產(chǎn)品線與內部平臺中充當各類工具的應用程序。

此外我們的用戶體驗研究團隊也邀請用戶參與焦點小組討論和反饋工作，更好地了解用戶對 LinkedIn.com 訪問體驗的看法和感受。

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

(點擊放大圖像)

圖 2：“Voyager”項目

通過這些努力，我們選擇用兩個框架構建 API 和 Web 客戶端：面向 Java 的 Play Framework，以及面向 Web 的 Ember 框架，這兩個框架已成為我們構建 Web 應用的事實標準。在設立這個新項目前，LinkedIn 就已在 Play Framework 方面投入了大量精力，我們的安全團隊就這些框架目前具備的安全特性，結合我們希望自己的技術棧具備的特性進行了全面的缺口分析。

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

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

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

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

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

縱深安全

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

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

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

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

(點擊放大圖像)

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

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

(點擊放大圖像)

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

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

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

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

關于本文作者

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

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

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