安全架構

Web 攻擊與防護

XSS 跨站點腳本攻擊 (Cross-Site Scripting)

攻擊一

• 用戶登錄到一個正常的服務器，在登錄狀態中

• 惡意者推送一個惡意的腳本

• 通過瀏覽其他頁面，此頁面包含攻擊腳本

• 通過郵件注入攻擊腳本

• 用戶在自己的瀏覽器執行攻擊腳本

• 以用戶登入的帳號執行

• 執行後將惡意腳本擴散出去

攻擊二

• 攻擊者直接攻擊目標服務器

• 攻擊者直接發布含有惡意腳本的請求

• 惡意腳本存除在網站的數據庫

• 其他用戶瀏覽相關信息時，在自身的瀏覽器不經意執行惡意腳本

防禦手段

• 消毒處理：對某些 HTML 危險字符進行轉義

• ">" --> &gt

• "<"  --> &lt

• 避免對不必要的內容進行轉義造成錯誤，需要先進行文本匹配後再轉義

• 3 < 5 中的  "<"

• "<" 有 "<img src=" 上下文時，才進行轉義

• 原理

• 顯示時，還是會顯示 "<"，">" 符號，但無法在瀏覽器中執行

• XSS 攻擊一般都是通過在請求中嵌入惡意腳本

• 這些腳本是一般用戶輸入中不使用的

• 進行過濾和消毒，就可以防止大部分攻擊

• 消毒是所有網站最必備的XSS 防攻擊手段

SQL 注入攻擊

攻擊

• 攻擊者提交的請求字符串裡面，包含 SQL 命令內容

• 在服務器端執行這些非法的 SQL 命令

• 攻擊者必須知道數據庫的表結構

攻擊者獲取數據表結構信息的手段

• 開源

• 網站使用開源軟件搭建 (如 Discuz)，數據庫結構是公開的

• 錯誤回應

• 網站開啟錯誤回顯

• 攻擊者故意製造非法參數

• 服務端異常訊息輸出到瀏覽器端

• 攻擊者根據回顯訊息，猜測數據庫表結構

• 盲注

• 網站關閉錯誤回顯

• 攻擊者根據頁面變化，猜測判斷SQL語句執行情形

• 據此猜測數據表結構

防禦手段

• 請求參數消毒處理:

• 通過正則匹配，過濾請求數據中可能注入的 SQL 文

• 如 : drop table”、“\b(?:update\b.*?\bset|delete\b\W*?\bfrom)\b”等

• 插入 &amp (空白)，顯示時會顯示空白，但已非正常SQL命令

• 是比較簡單粗暴又有效的手段

• SQL 預編譯參數綁定

• 攻擊者的惡意 SQL 會被當作 SQL 的參數，而不是 SQL 命令被執行

• 是最好的防 SQL 注入方法

CSRF 跨站請求偽造攻擊

攻擊

• 用戶登錄到一個正常的服務器，在登錄狀態中

• 用戶又訪問攻擊者的服務器

• 用戶收到攻擊者服務器的請求返回響應

• 用戶端執行返回響應，此響應中包含一個新的請求至正常服務器

• 在用戶端不知情的情況下，向正常服務器發請求

• 與XSS相異的地方

• XSS 透過腳本攻擊

• CSRF 透過釣魚網站，誘導用戶去訪問

• 更有針對性的對用戶攻擊

防禦手段

表單 Token

• 在頁面表單應加一個隨機數 Token

• 每次請求的 Token 都不相同

• 請求提交後檢查 Token 的值是否正確，以確定請求提交者是否合法

• 有些會根據裝置的指紋，用戶的資訊，透過簽名產生 Token

原理

• CSRF 是一個偽造用戶請求的操作，需要構造用戶請求的所有參數

• 表單 Token 就是阻止攻擊者獲得所有請求參數的可能

驗證碼

• 請求提交時，需要用戶輸入驗證碼

• 手機驗證碼

• 圖形驗證碼

原理

• 避免用戶在不知情的情況下被攻擊者偽造

優點

• 簡單有效

• 也可以防爬蟲、機器人操作

缺點

• 是一個糟糕的用戶體驗，在必要時才使用

• 如支付交易

Referer Check

• 在 HTTP 請求頭的 referer 域中記錄請求來源

• 通過檢查請求來源，驗證是否合法

缺點

• 有一定的侷限性

• referer 並不依定總是能得到

其他需要關注的攻擊和漏洞

Error Code 錯誤回顯

• 許多 Web 服務器默認是打開異常信息輸出

• 將未處理的異常堆棧信息直接輸出到用戶端瀏覽器

• 當成 Debug 信息

• 攻擊者故意製造非法輸入，獲得異常信息，尋找系統漏洞進行攻擊

防禦手段

• 在生產環境的應用，最好關閉錯誤回顯

• 配置 Web 服務器參數，跳轉 500 頁面到專門的錯誤頁面即可

• HTTP 響應碼 500，表示服務器內部錯誤

• 各個功能，Web 常用的 MVC 框架也可以做到

HTML 注釋

• 使用 HTML 注釋語法對程序進行注釋

• HTML 注釋會顯示在客戶端瀏覽器，給攻擊者造成便利

防禦手段

• 最終發布前須進行代碼 review

• 自動掃描，避免 HTML 注釋漏洞

文件上傳

• 攻擊者利用網站上傳文件功能，上傳可執行程序

• 通過該程序獲得服務器端命令執行能力

• 攻擊者也可以此為跳板攻擊集群環境的其他機器

防禦手段

• 設置上傳文件白名單

• 只允許上傳可靠的文件類型

• 修改上傳文件名

• 使用專門的存儲

路徑遍歷

• 攻擊者在請求的 URL 中使用相對路徑，遍歷系統未開放的目錄和文件

防禦手段

• 將 Javascript、CSS 等資源文件，使用獨立服務器、獨立域名

• 其他文件不使用靜態 URL 訪問

• 動態參數不包含文件路徑信息

• 利用文件ID，代替路徑

通用的防禦

Web 應用防火牆

• 利用應用防火牆統一攔截、過濾用戶請求

• 識別攻擊內容，並進行消毒、過濾處理

ModSecurity

• 開源的 Web 應用防火牆

• 可以嵌入到 Web 應用服務器中，也可以以獨立程序啟動

• 支援多種語言版本

• 採處理邏輯與規則集合分離的架構模式

• 處理邏輯

• 負責請求和響應的攔截過濾，規則加載執行

• 規則集合

• 對具體攻擊的規則定義、模式識別、防禦策略訂定

網站安全漏洞掃描

• 根據內置規則，模擬攻擊者行文

• 用以發現網站安全漏洞

• 可以自行開發，也有商用網站安全漏洞掃描平台

加密與解密

• 攻擊者主要目的: 獲得用戶敏感訊息

防禦

• 第一道門檻: Web 防護

• 第二道門檻: 將敏感信息加密處理

信息加密技術

單向散列加密

加密是單向的

• 從明文加密成密文

• 不能從密文反算或解密出明文

• 加入 salt 原因

• 算法不多且公開

• 如果有明文-密文映射表，可以得知明文

• 故加入特別的信息與明文一起加密

• 特別的字符串

• 或用戶的其他資訊

• 攻擊者無法猜測映射出來的哪一部分屬於明文，哪一部分屬於 salt

針對不需要知道明文的應用

• 如用戶的密碼

• 不存儲明文，只存儲密文

Example

• 註冊

• 用戶註冊

• 系統將密碼利用單向散列加密成密文

• 存儲密文至數據庫

• 驗證

• 用戶利用密碼登入

• 將密碼利用單向散列加密成密文

• 將密文與數據庫中的密碼密文比對

對稱加密

• 可以由密文反解出明文

• 加解密演算法使用相同的密鑰

• 加密

• 明文 + 密鑰 ---(加密演算法) ---> 密文

• 解密

• 密文 + 密鑰 ---(解密演算法) ---> 明文

非對稱加密

• 可以由密文反解出明文

• 加解密演算法使用不同的密鑰

• 得知加密密鑰不能推算解密密鑰

• 反之亦然

• 加密

• 明文 + 加密密鑰 ---(加密演算法) ---> 密文

• 加密密鑰 --> 公鑰

• 解密

• 密文 + 解密密鑰 ---(解密演算法) ---> 明文

• 解密密鑰 --> 私鑰

• 應用

• HTTPS 加密: 加密密鑰公開給所有用戶

• 數位簽章

• 用私鑰進行加密

• 私鑰只有個人知道

• 用公鑰進行解密

• 公鑰大家都知道

• 如果成功，代表此訊息真的是由私鑰擁有人發出

密鑰安全管理

• 對密鑰進行分片存儲

• 對外部攻擊者

• 外部攻擊者無法得到所有密鑰

• 對內部員工

• 每個員工不知道所有密鑰分片

• 分擔密鑰管理責任

• 單一員工無法洩漏所有密鑰

• 加密技術要能成功防止攻擊者取得敏感信息，密鑰的保護是一個關鍵

• 演算法是公開的

• 只有密鑰是私密的

• 密鑰安全管理及加解密服務系統

• 密鑰安全存儲服務

• 加解密服務

• 應用程序不用知道密鑰及加解密算法

• 只需透過服務接口進行加解密

反垃圾與風控

反垃圾郵件

手段

訓練分類算法

• 將一批量郵件區分垃圾郵件與正常郵件

• 進行分類模型訓練

• 得到正常及垃圾郵件的特徵

識別

• 將待處理郵件輸入分類算法

• 分類算法利用分類模型進行分類

• 分出正常及垃圾郵件

• 輸出是正常或垃圾郵件的概率值

貝葉斯分類算法

• 後驗概率

• 一號箱子放有紅色、白色球各20個，二號箱子放有白色球10個、紅色球30個，隨機挑選一個箱子，取出一個球的顏色是紅色，請問這個球來自一號箱子的概率是多少

• 正常郵件有若干特徵值及其概率，垃圾郵件有若干特徵值及其概率，現在隨便給一份文件，從裡面取出來的特徵值有若干，請問此特徵屬於正常郵件或垃圾郵件的概率是多少

公式

• P(B | A) = P( A | B) * P(B) / P(A)

• A 發生的條件下，B的概率是多少

• P(B | A) : 球是紅色(A)的情況下，是一號箱(B)的概率

• P(A | B) : 在一號箱內，紅色球的概率

• P(B) : 選擇一號箱的概率

• P(A) : 紅色球會出現的概率

• ex

• P( B | A) : 包含 "茶葉" 這個特徵值的情況下，是垃圾郵件的概率是多少

• P( A | B) : 在垃圾郵件中，"茶葉" 這個特徵值的機率

• P(B) : 垃圾郵件出現的機率

• P(A) : "茶葉" 這個特徵出現的機率

執行過程

• 分模型訓練及樣本分類兩階段

布隆過濾器

用較少的空間，存儲大量的信息

• 如垃圾郵件來源 E-mail address 黑名單

• 標註黑名單

• 準備 16 G bit 空間

• 將每一個在黑名單中的 email ，通過 8 個函數計算出8 個值

• 每一個值介於 0 ~ 16G - 1

• 將 8 個值 mapping 至這 16 G bit 的位置，將此位置 set to 1

• 辨識黑名單

• 將 email 透過相同 8 個函數計算出 8 個值

• 如果每個值在16G中對應位置的值均為 1 -->黑名單

• 只要有一個位置不是 1 --> 不是黑名單

布隆過濾器

• 只會出現錯判的情況

• 錯判: 不是黑名單，卻判成是黑名單

• 不會出現漏判的情況

• 漏判: 是黑名單，卻沒有判斷出來

電子商務風險控制

電子商務網站

• 代理購物交易

• 有 B2B、B2C、C2C多種形式

• 買賣商方信息不對等，交易本來就存在風險

• 交易安全是電子商務網站的底線

風險分類

• 帳戶風險

• 帳戶盜用

• 惡意註冊帳戶

• 買家風險

• 買家惡意下單，占用庫存

• 黃牛利用促銷，搶購低價商品

• 良品拒收，詐欺退款

• B2B交易中虛假詢盤

• 賣家風險

• 不量賣家進行惡意詐欺

• 貨不對板

• 虛假發貨

• 炒作信用

• 發布違禁、侵權商品

• 交易風險

• 信用卡盜刷

• 支付欺詐

• 洗錢套現

風險控管

• 大型電商網站都配備有專門的風控團隊

• 風控手段

• 機器自動辨識高風險交易

• 高風險交易由風控審核人員進行人工審核

機器自動風控技術手段

規則引擎

• 當交易的某些指標滿足一定條件，會被認為是有高風險詐欺的可能性

• 用戶來自詐欺高發地區

• 交易金額超過某個數值

• 登陸地址距離差距過大

• 用戶登陸地與收貨地不符

• 用戶第一次交易

• 等等

• 網站在運營過程中，結合業界最新發現，會總結出數以千計的高風險交易規則

• 將這些規則通過編程代碼實現這些規則

• 缺點

• 不斷發現新的交易風險類型

• 不斷調整規則

• 不斷修改代碼

• 出現規則衝突

• 規則越多，性能越差

機器學習

• 利用數據採集，收集資料

• 對資料進行加工處理

• 處理後訓練分類模型

• 由分類算法加上分類模型進行風險分值

高可用

可用性度量

可用性指標

一個客觀指標來衡量系統的可用性

• 定量的可用性測試結果

• 通常以 "年" 為時間單位來進行度量

網站年度可用性指標

• ( 1 - 網站不可用時間 / 年度總時間) * 100%

網站不可用時間 (故障時間)

• 故障修復時間點 - 故障發現 (報告) 時間點

• 修復時間

• 系統 bug 解決，重新上線的時間

• 發現(報告)時間

• 客服報告時間

• 系統報警時間

可用性的定性描述

• 基本可用 : 兩個 9 (99%)

• 年度停機時間小於 88 小時

• 較高可用 : 3 各 9 (99.9%)

• 年度停機時間小於 9 小時

• 具有自動恢復能力的高可用 : 4 個 9 (99.99%)

• 年度停機時間小於 53 分鐘

• 極高可用性 : 5 個 9 (99.999%)

• 年度停機時間小於 5 分鐘

• 通常一般互聯網應用通常是 4 個 9

• 再高: 挑戰和難度更大、投入成本更高

• 再低: 不可用的用戶體驗會變差

• 但也根據應用的不同有不同的需求

• 對金融業應用需要更高些，如 99.995~99.997%

• 對信息發布類容忍度會更高，可以低一些

• 要看系統的目標是甚麼

• 在投入成本和帶來回報之間權衡

• 在用戶可以接受的範圍之內，投入成本最小即可

故障分管理

系統可用性必須和個人職責考核連結

• 這樣才有動力去提升可用性

• 代碼質量、開發責任心才會提高，架構設計才會更完善

• 遇到系統問題，才會積極參與修復問題

• 讓每個部門、團隊、個人對系統的高可用負責

故障分

• 根據故障的等級進行等級分類

• 人為定義

• 定義每個等級的權重

• 人為定義

• 可以根據事故等級及權重算出一個故障分數

• 將故障分具體核算給每個團隊或個人

管理流程

• 年初時訂定可用性等級即故障總分數

• 將故障總分數分配給每個部門

• 每個部門再將分配到的分數，分配給每一個小組

• 每個小組再分配給每個個人

• 故障發生時，根據故障等級權重及故障時間計算出一個故障分數

• 權重 * 故障時間

• 將故障分數依故障責任百分比分配給引發故障的團隊或個人

• 由年初分配分數中扣除

• 年終結算時，計算剩下的分數

• 若為負分，則影響 KPI 的達成

故障處理流程及考核

• 重要是最後覆盤

• 決定故障等級及權重

• 通常由業務部門依對公司產生的影響程度決定

• 故障責任的界定

• 決定責任百分比

引起故障的原因

• 硬件故障

• 軟件 bug

• 系統發布

• 並發壓力

• 網路攻擊

• 外部災害

提升系統可用性的架構方案

解耦

• 高內聚、低耦合的組件設計原則

• 面向對象基本設計原則

• 面向對象設計模式

• 領域驅動設計建模

隔離

• 業務與子系統隔離

• 買家子系統

• 賣家子系統

• 前提是業務解耦合

• 微服務與中台架構

• 將系統的服務拆分，部署在不同的服務器上

• 服務的故障，不會影響到整體系統

• 生產者消費者隔離

• 利用消息對列隔離

• 虛擬機與容器隔離

• 不同服務部署在不同虛擬機或容器內

異步

• 多線程編程

• 反應式編程

• 異步通信網路編程

• 事件驅動異步架構

備份

集群設計

• 將服務部署在多台服務器上

• 再利用負載均衡分配用戶請求

• 多台服務器互為備份

數據庫複製

• CAP原理

• 主從複製

• 主主複製

失效轉移 (Failover)

• 備份後，遇到失效，轉移至其他服務器

• 數據庫主主失效轉移

• 負載均衡失效轉移

• 設計無狀態的服務

冪等

• 與失效轉移相關，調用服務失敗後，重新發送請求給其他服務器

• 服務重複調用有時候無法避免

• 比如服務處理成功，但應用沒有收到響應，導致應用重新提交請求

• 必須保證服務重複調用和調用一次產生的結果相同

• 通過交易編號信息進行服務調用有效性校驗

• 有效的操作才繼續執行

事務補償

• 傳統事務 ACID

• 分布式事務 BASE

• 分布式的環境中比較難保證事務的一致姓

• 可能是不同程序對數據庫發出同一事務中的請求

• 也可能對不同數據庫發出同一事務中的請求

• 通過執行業務邏輯逆操作，使事務回滾到事務前狀態

重試

• 通過重試的方式修復單次調用故障

• 注意上游調用者超時時間要大於下游調用者超時時間總和

熔斷

• 當某個服務出現故障、響應延遲或失敗率增加，繼續調用這個服務會出現服務級聯失效

• 因為請求阻塞、資源消耗增加

• 級聯失效：因服務失效造成系統失效的連鎖反應

• 緩存失效--> 資料庫調用失效 --> 系統崩潰

• 使用斷路器阻斷對故障服務的調用

• 監控服務的響應失敗率或延遲率

• 動態決定斷路器的關閉、打開、半開的狀態

限流

• 對進入系統的用戶請求進行流量限制

• 超過系統最大處理能力，則丟棄一部分的用戶請求，保證整個系統可用

限流算法

計數器算法 (固定窗口、滑動窗口)

• 固定窗口

• 方法

• 使用計數器，在週期內累加訪問次數

• 當達到設定的限流值時，觸發限流策略

• 下一個周期開始，計數器清成零，重新記數

• 臨界點問題

• 當訪問請求集中在前一個週期後半及這一周期的前半時

• 請求沒有超過每一個周期的限制量

• 但請求仍然會超過系統最大處理能力

• 滑動窗口

• 將時間周期分成N個小周期，分別記錄每個小周期內的方問次數

• 並根據時間滑動，刪除過期小周期次數

• 根據窗口內各小周期次數總和決定是否觸發限流策略

令牌統算法

• 以固定速度向令牌桶增加令牌，直到令牌桶滿

• 請求到達時向令牌桶請求令牌

• 取到令牌，請求通過

• 否則觸發限流策略

漏桶算法

• 將訪問請求到達時，放入漏桶

• 漏桶以固定速率進行訪問請求釋放

• 依系統最大可處理的速率

• 如果當前漏桶容量已滿則觸發限流策略

自適應限流

• 使流量跟系統能力自動的匹配

• 對系統實時處理能力進行監控採集

• 實時自動評估 QPS (Queries per second)

• 將採集結果反饋給 PID 控制演算法進行決策

• 業務流量的不確定性與技術方案的自適應性天生一對

降級

• 系統高並發的時候，將非核心的功能關閉，提高核心功能的處理能力

• 某些非核心功能會給系統產生非常大的壓力

• 如確認收貨，對數據庫產生很大的壓力

• 更改訂單狀態

• 完成支付確認

• 進行評價

• 非核心功能通常不需要即時處理

異地多活

• 將數據中心分布在多個不同地點的機房

• 每個機房都可以對外提供完整的系統服務

• 用戶可以連接任何一個機房進行訪問

• 是高可用的最高顯示，投入成本也最多，部署難度最大

• 異地多活的難點在保持數據的一致性及同步

架構運維方案

發布

• 發不需要在服務器上關閉原有的應用、重新部署、再啟動新的應用

• 整個過程要求不影響用戶的使用

• 網站的發布過程與服務器當機效果相當

• 設計高可用架構需考慮服務器的當機概率為每周一兩次

• 考慮新應用的發布

• 服務器分批發布流程

• 同一時間中，有新、老的應用服務代碼同時存在

自動化測試

• 即使是系統功能小幅度的增加，仍然需要對整個網站功能進行

• 全面性的回歸測試

• 各種瀏覽器的兼容性測試

• 保證系統沒有引入未預料的 bug

• 在發布頻繁的網站應用中使用人工進行測試，成本和時間都難以承受

• 人工測試也無法保證測試的結果和質量

• 採用Web 自動化測試技術，使用自動測試工具及腳本完成測試

• 如 ThoughtWorks開發的 Selenium

• 運行在瀏覽器中，模擬用戶操作

• 同時完成 Web 功能及瀏覽器兼容測試

手工測試與自動化測試的成本比較

手工測試

• 網站剛開始發布時，功能少，成本比較小

• 每次開發新功能，除了新功能外，舊功能也需要測試

• 隨著軟件規模的增長，測試需要越來越多時間

• 每次發布的測試成本會比前一次發布來的更高

自動測試

• 需要一切前置投資，成本比較高

• 安裝自動化測試工具

• 部署持續集成服務器

• 準備測試腳本及測試內容、預期的結果等

• 後續投入相對便宜，只需要為新功能創建新測試即可

• 最後會達到一個平衡點，然後自動化測試總體成本會低於手工測試成本

• 自動化測試與單元測試

• 自動化測試

• 測試工程師的測試

• 保證整個系統的功能完整性

• 保證線上系統的正確性

• 單元測試

• 開發工程師的測試

• 測試具體程序內部的方法

• 保證自己開發的代碼正確性

自動化部署

手工

• 開發工程師開發代碼提交

• 測試工程師完成系統測試

• 運維工程師打包發布

自動化

• 開發工程師提交代碼，觸發自動測試

• 測試結果通過，觸發自動發布

• 加快代碼上線的過程

• 用自動化的手段，管理全部的發布過程

持續部署

三步驟

• 持續集成

• 允許工程師隨時向公共分支提交代碼

• 立即對系統進行自動化測試

• 持續交付

• 跑單元測試

• 軟件打包

• 將軟件部屬到各種測試環境中

• 持續部署

• 代碼在沒有人工干預的情況下被測試、構建、部署並推送到生產環境

沒有廣泛實行的原因

• 對大公司而言，開發工程師多，可能會產生一些不可控的因素

• 各團隊開發時間不一致

• 還是要控制發布的時間節點

• 對小公司而言，沒有技術力量去推行

• 主要推動者為雲服務的廠商

預發布驗證

• 即使嚴格測試，軟件部署到生產環境後，經常出現各種問題

• 某些問題無法在測試環境中測出

• 主要原因是測試環境與線上生產環境不相同

• 線上環境依賴

• 其他服務，如數據庫、緩存、公用業務服務

• 第三方服務

• 在測試環境中，這些服務可能都是只是假接口模擬

• 預發布服務器

• 特殊用途的服務器

• 與線上正是服務器唯一的差別是沒有配置在負載均衡服務器上

• 只有內部開發工程師可以訪問，外部用戶無法訪問

• 網站發布時，先發布到預發布機器上

• 進行預發布驗證

• 執行典型的、關鍵的業務流程，確認系統沒有問題後才正式發布

• 不是全量的功能測試

• 主要在驗證新應用程序在線上環境上執行是否正確

• 測試正確後在同步到其他真正的應用服務器上

代碼版本控制

• 對於大型互聯網系統，涉及許多團隊和工程師

• 需要對相同代碼庫進行共同開發和維護

• 各團隊開發周期和發布時間各不相同

• 要進行代碼管理

• 保證代碼發布版本穩定正確

• 保證不同團隊開發不受影響

• 對於互聯網快速迭代和快速版本更新的開發模式非常重要

方式

主幹開發、分支發布

• 修改在主幹上進行

• 需要發布時，從主幹拉一個分支進行發布

• 此分支成為一個發布版本

• 若此版本有 bug，繼續在此分支修改發布

• 並將修改 merge 回主幹

• 優點

• 主幹代碼反映目前整個應用的狀態

• 便於管理和控制，也利於持續集成

分支開發、主幹發布

• 需要開發一個新功能或修復一個bug時，從主幹拉一個分支進行開發

• 開發完成並通過測試後，merge 回主幹

• 從主幹進行發布

• 主幹上的代碼，永遠是最新發布的版本

• 優點

• 各分支獨立開發，互不干擾

• 可以使不同發布周期的開發在同一個應用中進行

• 缺點

• 分支開發一段時間後與主幹的代碼不太一樣

• 造成 merge 時產生大量的衝突

• 需在開發過程中不斷地與主幹合併

目前互聯網應用主要使用分支開發，主幹發布的方式

自動化發布

• 與自動化部署不同

• 自動化部署：無須人工的干預下，自動將代碼部署上線

• 自動化發布：發布還是人工控制，但是發布的過程是自動的

• 發布過程自動化的管理

• 剔除不符合規定、確認失敗項的代碼

• 使其他正常的代碼可以完成發布

灰度發布

• 針對集群規模龐大的系統

• 將集群服務器分成若干部分

• 每天只發布一部分服務器，觀察運行狀況

• 隔天繼續發布另外一部分服務器

• 持續幾天時間才會把整個集群全部發布完畢

• 期間若有故障，只需要回滾已發布的一部份服務器即可

• 原本運用在大規模服務器的發布，但現在也被利用在一些新業務功能測試的發布

• 將新功能發布在一部分服務器上

• 觀察業務指標、性能指標等等

• 再決定要不要繼續發布或直接回滾

網站運行監控

• 不允許沒有監控的系統上線

• 對於網站運維和架構設計優化至關重要

監控數據採集

• 涵蓋所有非直接業務行為的數據採集與管理

網站用戶行為日誌

• 用戶在瀏覽器上所做的所有操作及其所在的操作環境

• 包括

• 用戶操作系統

• 瀏覽器版本訊息

• IP地址

• 頁面訪問路徑

• 頁面停留時間

• 這些數據對下列很重要

• 統計網站 PV/UV指標

• 分析用戶行為

• 優化網站設計

• 個性化營銷與推薦

• 收集手段

• 服務器端日誌收集

• 大多數Web服務器都具備日誌記錄功能

• 缺點是可能出現信息失真

• IP地址是代理服務器地址，而不是用戶真實IP

• 多個鍵結指向同一個頁面的情況下，無法分辨訪問路徑

• 客戶端日誌收集

• 瀏覽器可以收集用戶真實的操作行為

• 缺點是麻煩，需要再頁面嵌入特定的 JS 腳本

業務運行數據

• 具體業務場景相關的技術和業務指標

• 緩存命中率

• 平均響應延遲時間

• 每分鐘發送郵件數目

• 待處理任務數

• 需要在具體程序中採集並報告，彙總後統一顯示

系統性能數據

• 收集服務器性能指標

• 盡早做出故障預警

• 即時判斷應用狀況

• 根據性能監控數據

• 運維工程師可以合理安排服務器集群規模

• 架構師及時改善系統性能及調整系統伸縮性策略

• 開源工具 : Ganglia

• 支持大規模服務器集群

• 支持以圖形的方式在瀏覽器展示實時性能曲線

監控管理系統

架構

• 被監控系統

• 執行代理進程

• 收集服務器上各項指標

• 將指標推送給監控服務

• 監控服務

• 存儲各項指標資料

• 對收集的各項指標，進行大數據計算分析

• 進行報警、自動化控制

監控系統功能

• 系統性能評估

• 集群規模伸縮性預測

• 根據實時監控數據進行

• 風險預警

• 失效轉移

• 自動負載調整

• 最大化利用集群所有機器的資源

• 報警

• 配置報警閾值

• 值守人員聯繫方式

• 報警方式

• 郵件

• 即時通訊工具

• 手機短信

• 語音報警

• 自動控制

• 自動失效轉移

• 應用程序訪問失敗時進行失效轉移

• 發現故障時，主通通知應用，進行失效轉移

• 自動擴容

• 訪問壓力大時，導致服務性能指標下降

• 自動觸發服務及群擴容

• 自動限流

• 根據監控指標，自動控制訪問流量

高可用價值觀

• 保持簡單，使問題易於被發現，快速解決

• 架構簡單

• 程序設計簡單

• 直接調用依賴關係簡單

• 數據代表的意思是簡單的

• 目標明確，解決特定環境下的具體問題

• 解決系統上具體的問題

• 達成系統高可用的目標

• 而不只是引進高大上的技術

• 價值回歸，成本收益要合理