Target如何提前阻止大規模事故？從POS失效徵兆學到4大SRE教訓

2020年，全球疫情爆起的一年，卻也是美國零售巨頭Target營收大爆發的一年，營收足足比前一年成長了20％，數位通路的銷售更是驚人，一口氣爆增了150%。

但在2020年3月13日這一天，如果SRE工程師沒有盡責的察覺到監控儀表板上那個異常訊號，恐怕到了周末復活節大特價活動，不只線上商店，Target全美近2千家賣場，都難以順利進行任何一筆結帳，Target年營收就不可能達到20%如此高的成長幅度。

那一天，一位SRE工程師發現，有家Target賣場，結帳櫃檯的POS系統掃碼速度慢了，「嗶」聲出現的時間，比慣常的時間還要久。意識到不對勁的工程師主動清查，一查才發現，不只一家，而是有好幾家分店都出現了POS機掃碼速度變慢的徵兆。

「店內系統掃碼服務當機，轉移到總部機房內的備援服務接手，才出現了掃碼速度變慢的徵兆。」Target的SRE總監Kathryn Blanchard直到2021年4月自家技術研討會中，也就是事發一年後，才敢對外公開了這起差點造成Target營運全面中斷的事故。

SRE主動追查掃碼服務失效異常，先緩解影響再尋找根本原因

當時，Kathryn Blanchard所率領的SRE團隊才剛成立3個月，後續追查事故問題後發現，那些部署在店內機房提供掃碼功能的服務當機了，系統自動轉移給總部的備援掃碼服務來接手，支援分店內櫃檯的作業，但遠端連線的網路延遲，讓掃碼速度慢了一些，不過，這些店的顧客沒有察覺異常，而是SRE團隊從監測工具上看到掃碼時間的變化，發現了這個結帳服務失效的徵兆。

SRE工程師第一時間先啟動暫時性對策，進行系統復原，回到前一個正常運作的系統版本，讓這些店內結帳服務功能恢復運作，不用靠遠端的備援服務，避免繼續發生結帳延遲的情況。第一時間緩解問題後，SRE團隊再展開調查，要找出造成服務當機的事故根源。

美國每年3月到4月初，是百貨零售上半年競爭最激烈的復活節折扣月活動，這是每年兒童用品銷量暴衝的關鍵時刻。2020年3月13日是星期五，隔天就是民眾大搶購的周末熱門時段。

尤其，美國疫情在3月17日開始大爆發，50州都出現了確診病例，民眾不敢出門，大舉湧向線上電商搶購。發生掃碼問題的這套商店平臺系統，不只支援實體賣場POS，還支援了Target線上電商平臺的購物車作業，如果沒有找出事故根源徹底解決，一旦在周末搶購潮發生延遲，甚至因爆量採購而塞爆系統服務，恐怕會引起大量顧客抱怨和負評聲浪，甚至可能讓Target錯過復活節搶購潮的商機。

花了一段時間，SRE工程師才發現，這起失效事故與前一周有次系統更新的異動有關。原來，3月8日有次系統更新後，導致部署在分店的商店平臺系統出現了記憶體資源占用問題，占用情況累積一段時間後，虛擬機器上可用的記憶體越來越少，就會造成部分吃重的服務先當機。因為這不是POS系統的直接問題，而是來自環境資源排擠而造成的問題，得經過一段時間發酵才會出現當機情況，而且是越早用光記憶體的環境，就會越快會出現問題。

3月13日少數分店出現掃碼速度變慢，正因為分店機房內邊緣主機上的記憶體即將耗盡，導致掃碼微服務當機，才轉由遠端備援服務接手的情況。

不盡快解決，全美2千店和線上商城都會受影響

若是沒有盡快解決問題，將會有越來越多分店的系統面臨同樣的困境，不只實體賣場，連Target線上商城的結帳交易都可能會受到波及而變慢，甚至中斷。SRE團隊連忙通知開發部門，緊急修復程式錯誤，重新發布系統更新，逐步部署到全美2千家分店內的系統，才順利避開了可能的大災難。

這個過程說來簡單幾段話，其實做起來非常複雜。對Target來說，不只要在顧客察覺、災情擴大前及早發現問題是挑戰，在修復系統錯誤後，釋出修補程式，要部署到2千家分店的系統時，還得做到營運不中斷。若對2015年時還沒展開數位轉型的Target而言，幾乎是不可能的任務。為何如此困難？這得從Target企業資訊架構設計說起。

徹底分散式架構的複雜考驗，IT得管2千座機房和2大公雲環境

「複雜性是Target服務穩定性最大的敵人。」Kathryn Blanchard指出。為了就近服務全美各地的1.7億名顧客，Target有一個高達4千人的IT團隊，不論是底層的資訊基礎架構或是上層的應用系統架構，也採取了徹底的分散式架構的IT設計。可是，這個IT架構越是分散，就越複雜，Target維運的考驗也會越大。

Target的IT架構有多複雜？Target從2014年開始嘗試上雲，最先使用的是AWS公雲，2015年轉為押寶IBM雲，而且採取雲地混合架構，展開大規模上雲。不只如此，Target也同步重新改造自家應用系統，連核心平臺關鍵功能都重寫。在2016年時，Target更大舉擁抱各項雲原生開源技術、敏捷開發、DevOps等，系統架構也全面轉換成微服務架構。

2018年時，Target進一步從單朵公雲混合雲，轉為使用多朵公雲的雲地混合架構，公雲供應商則改用GCP和微軟Azure，前者負責消費者端服務，後者則用於企業端應用的部署。

根據2021年4月時揭露的資料，Target除了使用2朵公有雲服務，還擁有2座大型資料中心，更有42個分散各地的小型資料中心，另外他們也在每一家賣場中設置了微型邊緣機房，就近提供落地的運算服務。換句話說，Target要管理的大小實體機房，接近2千個。

這麼龐大又複雜的運算環境，帶來了嚴峻的維運考驗，根據Target統計，55%的維運事件來自如此複雜的IT環境，而另外有45%的維運事件，則來自DevOps部署的複雜性挑戰。

每周3萬次更新，微服務架構部署百萬VM的DevOps難題

原本Target的應用系統採取大型單體式架構設計，約有30套大型單體系統，在2015年之前，只能每年部署一次新版，每季執行一次小更新，但是，每次更新或部署時，都得停機才行，這就讓賣場營運和線上服務都出現了空窗期。

2016年擁抱雲端原生技術後，Target將IT架構轉換成微服務架構，Target三大核心平臺，包括商店平臺、促銷平臺和供應鏈平臺，再加上10個不同即時任務的Runtime引擎，都採取微服務架構，光是商店平臺就有4百隻不同任務的微服務，其中有70隻是共用服務，而整個Target.com網站所用的微服務更是多達1千隻。不論是實體商店系統或是線上電商平臺的維運，都由同一組基礎架構團隊來負責。

Target在2018年轉為多雲架構之際，也發展出一套自助式的內部應用平臺TAP（Target Application Platform）。這是一套利用K8s打造的應用系統管理叢集，一方面可以提供一站式的自助應用程式部署服務，讓開發團隊使用一套標準化的部署範本，就能自己將程式碼輕鬆部署到各種不同類型的公雲或機房執行環境中，不用自行針對不同的環境進行配置與設定。

另一方面，也可以透過叢集架構，針對2千個機房內的系統，進行輪流更新，來確保全美各分店面對顧客的服務不會因系統更新而中斷。

因為在IT基礎架構中，Target擁有多達2千座的機房環境和多朵公雲，凡是分店內的商店系統有一隻微服務的程式碼要更新，就得進行2千次部署作業。TAP這套平臺提供了一套通用的標準化部署作業方式，不論是開發團隊、儲存團隊、網路團隊或SRE團隊都共用這一套簡單容易上手的CI/CD工具。

在2020年需求爆量時期，Target幾乎每2到3周，基礎架構的容量需求就會暴增一倍，而且都遠超過壓力測試的模擬規模，但是，「IT仍然可以管理這樣的擴充力，沒有為了大規模成長，忙到滿身大汗，只需按幾個按鈕，就能完成基礎架構的部署。」Target資訊長Mike McNamara這樣形容這套關鍵平臺對IT的效益。「要真正善用多雲架構，得有一套部署多雲的好方法，」他說：「對Target而言，這就是TAP，可以讓我們管理不斷擴充的能力。」

2021年時，Target多數微服務會每周部署一次，甚至有些是每天部署新版，正式環境平均一天就會有6千次異動，平均每周需要進行3萬次更新作業。這些發布和部署，全都靠TAP的CI/CD機制自動化部署到上百萬個不同環境上的VM中，更新升級過程完全不需要關機。

另外，為了因應線上線下的爆量需求，Target的微服務也啟用了大量副本，一款微服務，可能就得啟用數百個副本服務。Target光是在正式環境中的微服務ID總數，高達76萬個（每一隻微服務，不論正副本都會有各自獨立的ID編號），測試環境中也有16萬支微服務正在執行。

這些都是Target擁抱微服務架構後衍生的維運複雜度。

過去，要執行一項業務所需的相關系統服務，大約150～200個，但在2016年，Target轉換成微服務架構後，一項業務相關的微服務往往會高達2萬個（包括大量副本服務），要從中分辨出是哪一個微服務發生問題，又是另一個複雜的維運挑戰。

SRE目標：事故頻率最少化、影響最小化

為了迎戰這些複雜性，Target在2020年導入了SRE（網站可靠性工程），花了一個月先組成SRE團隊專門，負責監控和因應所有系統和微服務的運作，第一步先開始搜集關鍵系統的Log數據，來累積長期的維運數據。

Target基礎架構副總裁Hari Govind表示，希望透過擁抱SRE，讓Target的服務更聚焦關鍵的顧客體驗，例如商店結帳速度、線上數位流程、送貨數位化流程等。「因為各種大大小小的事故就是我們的日常，希望透過SRE來強化大規模架構的分散容錯能力。」他指出，Target SRE的目標是，減少事故發生的頻率，將事故影響最小化，在做中學，盡可能減少當機時間。就在SRE團隊累積了差不多2個月日常維運資料後，就發生了這起掃碼失效事件。

Kathryn Blanchard指出，這次事件能夠順利解決，有兩個關鍵，一是事先搜集了系統服務端到端的詳細數據，其次是針對顧客歷程建立了服務基準參考數據。也就是說，若沒有一套持續監控的機制，事先搜集平時不同業務、各種微服務的維運log數據，累積長期資料，來建立一套服務運作數據的基準參考值，就無法知道正常結帳掃瞄商品的時間多久，更是難以判斷掃碼速度是否「變慢」，在問題擴大前採取行動。