1. 背景
京東的期中考試：618即将到來，各個團隊都在進行期中考試前的模拟考試：軍演壓測，故障演練，系統的梳理以檢測系統的穩定性以應對高可用，高性能，高并發。我們知道系統的穩定性建設是貫穿整個研發流程：需求階段，研發階段，測試階段，上線階段，運維階段；整個流程中的所有參與人員：産品，研發，測試，運維人員都應關注系統的穩定性。業務的發展及系統建設過程中，穩定性就是那個1，其他的是1後面的0，沒有穩定性，就好比将萬丈高樓建于土沙之上。本篇文章主要從後端研發的視角針對研發階段和上線階段談下穩定性建設，希望起到抛磚引玉的作用，由于本人的水準有限，文中難免有了解不到位或者不全面的地方，歡迎批評指正。
2. 研發階段
研發階段主要參與人員是研發，主要産出物是技術方案設計文檔和代碼，一個是研發階段的開始，一個是研發階段的結束，我們要把控好技術文檔和代碼品質，進而減少線下bug率及線上的故障；
2.1 技術方案
2.1.1 技術方案評審
技術文檔的評審需要有本團隊的架構師和相關研發，測試，産品，上下遊系統的研發同學參與，這樣能夠最大限度的保證技術方案的實作和産品需求對齊，上下遊系統同學也知道我們的實作，采取更加合理的互動方式，測試同學也可以從測試視角給出一些風險點建議，架構師可以確定我們的實作和業界最佳實踐的差異，確定合理性，避免過度設計；我們所要做的是開放心态采取大家的意見，嚴控技術文檔的品質；
技術文檔的評審可以采用提問的方式，會議開始前可以将技術文檔分享給大家，讓大家先閱讀10分鐘，所有同學開始提問，技術文檔設計人其實不用讀自己的技術文檔給大家介紹，隻要将大家的問題回答完，并能夠思考下大家的建議，合理的采納後，其實技術文檔的品質就有了很大的保證，有的同學在技術文檔評審時，比較反感大家的提問，總感覺在挑戰自己，有些問題回答不上來，其實可以換種思路：有些問題回答不上來是正常的，可以先将大家的建議采納了，會後再思考下合理性；大家對自己技術方案是建言獻策，是保證自己技術方案的品質，避免在技術方案階段就存在重大的線上隐患。
2.1.2 技術方案關注點
當我們遇到一個問題的時候，首先要思考的這是一個新問題還是老問題，99.99%遇到的都是老問題，因為我們所從事的是工程技術，不是科學探索；我們所要做的就是看下國内外同行針對這個問題的解法，learn from best practices；是以技術方案的第一步是對标，學習最佳實踐，這樣能讓我們避免走彎路；
同時根據奧卡姆剃刀原理，我們力求技術方案簡單，避免過度設計，針對一個複雜的問題，我們的技術方案相對複雜些，簡單的問題技術方案相對簡單些，我們所要追求的是複雜的問題通過拆解劃分，用一個個簡單的技術方案解決掉。同時技術文檔不僅關注功能的實作，更重要的是關注架構，性能，品質，安全；即如何打造一個高可用系統。打造一個高可用的系統是進行系統穩定性建設的前提，如果我們的系統都不能保證高可用，又談何系統穩定系建設那，下面介紹下進行系統穩定性建設我們在技術方案中常用的方法及關注點。
2.1.2.1 限流
限流一般是從服務提供者provider的視角提供的針對自我保護的能力，對于流量負載超過我們系統的處理能力，限流政策可以防止我們的系統被激增的流量打垮。京東内部無論是同步互動的JSF, 還是異步互動的JMQ都提供了限流的能力，大家可以根據自己系統的情況進行設定；我們知道常見的限流算法包括：計數器算法，滑動時間視窗算法，漏鬥算法，令牌桶算法，具體算法可以網上google下，下面是這些算法的優缺點對比。
2.1.2.2 熔斷降級
熔斷和降級是兩件事情，但是他們一般是結合在一起使用的。熔斷是防止我們的系統被下遊系統拖垮，比如下遊系統接口性能嚴重變差，甚至下遊系統挂了；這個時候會導緻大量的線程堆積，不能釋放占用的CPU，記憶體等資源，這種情況下不僅影響該接口的性能，還會影響其他接口的性能，嚴重的情況會将我們的系統拖垮，造成雪崩效應，通過打開熔斷器，流量不再請求到有問題的系統，可以保護我們的系統不被拖垮。降級是一種有損操作，我們作為服務提供者，需要将這種損失盡可能降到最低，無論是傳回友好的提示，還是傳回可接受的降級資料。降級細分的話又分為人工降級，自動降級。
人工降級：人工降級一般采用降級開關來控制，公司内部一般采用配置中心Ducc來做開關降級，開關的修改也是線上操作，這塊也需要做好監控
自動降級：自動降級是采用自動化的中間件例如Hystrix，公司的小盾龍等；如果采用自動降級的話；我們必須要對降級的條件非常的明确，比如失敗的調用次數等；
2.1.2.3 逾時
分布式系統中的難點之一：不可靠的網絡，京東物流現有的微服務架構下，服務之間都是通過JSF網絡互動進行同步通信，我們探測下遊依賴服務是否可用的最快捷的方式是設定逾時時間。逾時的設定可以讓系統快速失敗，進行自我保護，避免無限等待下遊依賴系統，将系統的線程耗盡，系統拖垮。
逾時時間如何設定也是一門學問，如何設定一個合理的逾時時間也是一個逐漸疊代的過程，比如下遊新開發的接口，一般會基于壓測提供一個TP99的耗時，我們會基于此配置逾時時間；老接口的話，會基于線上的TP99耗時來配置逾時時間。
逾時時間在設定的時候需要遵循漏鬥原則，從上遊系統到下遊系統設定的逾時時間要逐漸減少，如下圖所示。為什麼要滿足漏鬥原則，假設不滿足漏鬥原則，比如服務A調取服務B的逾時時間設定成500ms，而服務B調取服務C的逾時時間設定成800ms，這個時候回導緻服務A調取服務B大量的逾時進而導緻可用率降低，而此時服務B從自身角度看是可用的；
2.1.2.4 重試
分布式系統中性能的影響主要是通信，無論是在分布式系統中還是垮團隊溝通，communication是最昂貴的；比如我們研發都知道需求的傳遞有一半以上甚至更多的時間花在跨團隊的溝通上，真正寫代碼的時間是很少的；分布式系統中我們檢視調用鍊路，其實我們系統本身計算的耗時是很少的，主要來自于外部系統的網絡互動，無論是下遊的業務系統，還是中間件：Mysql, redis, es等等；
是以在和外部系統的一次請求互動中，我們系統是希望盡最大努力得到想要的結果，但往往事與願違，由于不可靠網絡的原因，我們在和下遊系統互動時，都會配置逾時重試次數，希望在可接受的SLA範圍内一次請求拿到結果，但重試不是無限的重試，我們一般都是配置重試次數的限制，偶爾抖動的重試可以提高我們系統的可用率，如果下遊服務故障挂掉，重試反而會增加下遊系統的負載，進而增加故障的嚴重程度。在一次請求調用中，我們要知道對外提供的API，後面是有多少個service在提供服務，如果調用鍊路比較長，服務之間rpc互動都設定了重試次數，這個時候我們需要警惕重試風暴。如下圖service D 出現問題，重試風暴會加重service D的故障嚴重程度。對于API的重試，我們還要區分該接口是讀接口還是寫接口，如果是讀接口重試一般沒什麼影響，寫接口重試一定要做好接口的幂等性。
2.1.2.5 相容
我們在對老系統，老功能進行重構疊代的時候，一定要做好相容，否則上線後會出現重大的線上問題，公司内外有大量因為沒有做好相容性，而導緻資損的情況。相容分為：向前相容性和向後相容性，需要好好的區分他們，如下是他們的定義:
向前相容性：向前相容性指的是舊版本的軟體或硬體能夠與将來推出的新版本相容的特性，簡而言之舊版本軟體或系統相容新的資料和流量。
向後相容性：向後相容性則是指新版本的軟體或硬體能夠與之前版本的系統或元件相容的特性，簡而言之新版本軟體或系統相容老的資料和流量。
根據新老系統和新老資料我們可以将系統劃分為四個象限：第一象限：新系統和新資料是我們系統改造上線後的狀态，第三象限：老系統和老資料是我們系統改造上線前的狀态，第一象限和第三象限的問題我們在研發和測試階段一般都能發現排除掉，線上故障的高發期往往出現在第二和第四象限，第二象限是因為沒有做好向前相容性，例如上線過程中，發現問題進行了代碼復原，但是在上線過程中産生了新資料，復原後的老系統不能處理上線過程中新産生的資料，導緻線上故障。第四象限是因為沒有做好向後相容性，上線後新系統影響了老流程。針對第二象限的問題，我們可以構造新的資料去驗證老的系統，針對第四象限的問題，我們可以通過流量的錄制回放解決，錄制線上的老流量，對新功能進行驗證。
2.1.2.6 隔離
隔離是将故障爆炸半徑最小化的有效手段，在技術方案設計中，我們通過不同層面的隔離來控制影響範圍：
2.1.2.6.1 系統層面隔離
我們知道系統的分類可以分為：線上的系統，離線系統（批處理系統），近實時系統（流處理系統），如下是這些系統的定義：
線上系統：服務端等待請求的到達，接收到請求後，服務盡可能快的處理，然後傳回給用戶端一個響應，響應時間通常是線上服務性能的主要衡量名額。我們生活中在手機使用的APP大部分都是線上系統；
離線系統：或稱批處理系統，接收大量的輸入資料，運作一個作業來處理資料，并産出輸出資料，作業往往需要定時，定期運作一段時間，比如從幾分鐘到幾天，是以使用者通常不會等待作業完成，吞吐量是離線系統的主要衡量名額。例如我們看到的報表資料：日訂單量，月訂單量，日活躍使用者數，月活躍使用者數都是批處理系統運算一段時間得到的；
近實時系統：或者稱流處理系統，其介于線上系統和離線系統之間，流處理系統一般會有觸發源：使用者的行為操作，資料庫的寫操作，傳感器等，觸發源作為消息會通過消息代理中間件：JMQ, KAFKA等進行傳遞，消費者消費到消息後再做其他的操作，例如建構緩存，索引，通知使用者等；
以上三種系統是需要進行隔離建設的，因為他們的衡量名額及對資源的使用情況完全不一樣的，比如我們小組會将線上系統作為一個服務單獨部署：jdl-uep-main, 離線系統和近實時系統作為一個服務單獨部署：jdl-uep-worker；
2.1.2.6.2 環境的隔離
從研發到上線階段我們會使用不同的環境，比如業界常見的環境分為：開發，測試，預發和線上環境；研發人員在開發環境進行開發和聯調，測試人員在測試環境進行測試，營運和産品在預發環境進行UAT，最終傳遞的産品部署到線上環境提供給使用者使用。在研發流程中，我們部署時要遵循從應用層到中間件層再到存儲層，都要在一個環境，嚴禁垮環境的調用，比如測試環境調用線上，預發環境調用線上等。
2.1.2.6.3 資料的隔離
随着業務的發展，我們對外提供的服務往往會支撐多業務，多租戶，是以這個時候我們會按照業務進行資料隔離；比如我們組産生的物流訂單資料業務方就包含京東零售，其他電商平台，ISV等，為了避免彼此的影響我們需要在存儲層對資料進行隔離，資料的隔離可以按照不同粒度，第一種是通過租戶id字段進行區分，所有的資料存儲在一張表中，另外一個是庫粒度的區分，不同的租戶單獨配置設定對應的資料庫。
資料的隔離除了按照業務進行隔離外，還有按照環境進行隔離的，比如我們的資料庫分為測試庫，預發庫，線上庫，全鍊路壓測時，我們為了模拟線上的環境，同時避免污染線上的資料，往往會建立影子庫，影子表等。根據資料的通路頻次進行隔離，我們将經常通路的資料稱為熱資料，不經常通路的資料稱為冷資料；将經常通路的資料緩存到緩存，提高系統的性能。不經常通路的資料持久化到資料庫或者将不使用的資料結轉歸檔到
2.1.2.6.4 核心，非核心隔離
我們知道應用是分級的，京東内部針對應用的重要程度會将應用分為0，1，2，3級應用。業務的流程也分為黃金流程和非黃金流程。在業務流程中，針對不同級别的應用互動，需要将核心和非核心的流程進行隔離。例如在交易業務過程中，會涉及到訂單系統，支付系統，通知系統，那這個過程中核心系統是訂單系統和支付系統，而通知相對來說重要性不是那麼高，是以我們會投入更多的資源到訂單系統和支付系統，優先保證這兩個系統的穩定性，通知系統可以采用異步的方式與其他兩個系統解耦隔離，避免對其他另外兩個系統的影響。
2.1.2.6.5 讀寫隔離
應用層面，領域驅動設計（DDD）中最著名的CQRS（Command Query Responsibility Segregation）将寫服務和讀服務進行隔離。寫服務主要處理來自用戶端的command寫指令，而讀服務處理來自用戶端的query讀請求，這樣從應用層面進行讀寫隔離，不僅可以提高系統的可擴充性，同時也會提高系統的可維護性，應用層面我們都采用微服務架構，應用層都是無狀态服務，可以擴容加機器随意擴充，存儲層需要持久化，擴充就比較費勁。除了應用層面的CQRS，在存儲層面，我們也會進行讀寫隔離，例如資料庫都會采用一主多從的架構，讀請求可以路由到從庫進而分擔主庫的壓力，提高系統的性能和吞吐量。是以應用層面通過讀寫隔離主要解決可擴充問題，存儲層面主要解決性能和吞吐量的問題。
2.1.2.6.6 線程池隔離
線程是昂貴的資源，為了提高線程的使用效率，避免建立和銷毀的消耗，我們采用了池化技術，線程池來複用線程，但是在使用線程池的過程中，我們也做好線程池的隔離，避免多個API接口複用同一個線程。
2.2 代碼Review
codeReview是研發階段的最後一個流程，對線下的bug率和線上品質及穩定性有着重要的作用，針對于代碼如何review，談一些自己的看法：
•形成團隊代碼風格：首先一個團隊的代碼應該形成該團隊的代碼風格，這樣能夠提高codeReview的效率及協作的效率，作為新加入的成員，應該遵循團隊的代碼風格規範。
•Review的關注點：代碼review切記不要陷入細節，主要以review代碼風格為主，如果一個團隊形成統一的代碼風格，我們通過review風格就能将大部分問題發現，在關注功能的同時，再關注下性能，安全。
•結對程式設計：在代碼編寫過程中，我們要培養結對程式設計的習慣，這樣針對某次需求，codeReview時，熟悉該子產品的同僚把控下細節，架構師把控風格。
•控制每次review代碼量：每次送出代碼進行review時，不要一次性送出review大量的代碼，要将review的内容細分，比如一個方法的實作，一個類等。
•開放心态：review的過程其實是學習提升的過程，通過代碼review，虛心接收别人的意見，學習優雅代碼的編寫方式，提高自己的代碼水準。
3 上線階段
我們可以看下公司的故障管理平台白虎所記錄的故障：發生系統故障一般都是外部對系統做了改變，往往發生在上線階段：代碼的部署，資料庫的更改，配置中心的變動等；上線階段是故障的高發期；一個系統不可能不出線上問題，我們所要追求的是，降低線上的故障頻率，縮短故障恢複時間。針對上線過程出現問題，我們知道業界有著名的上線過程三闆斧：可監控，可灰階，可復原。
3.1 上線三闆斧
3.1.1 可監控
上線的過程中，我們的系統要做到可監控，如果沒有監控，上線過程中我們對系統的狀态是一無所知，是很可怕的。監控什麼東西那，其實監控的就是名額。這就涉及到名額的定義，名額我們分為業務名額和技術名額，技術名額又分為軟體和硬體。業務名額一般是我們定義的觀測業務變化情況的度量，例如訂單量，支付量等。技術層面的軟體名額：可用率，TP99, 調用量，技術層面的硬體名額：cpu 記憶體 磁盤 網絡IO。目前我們二級部門在做OpsReview，主要review的是可用率，TP99，調用量這幾個名額，分别對應系統的可用性，性能，并發。
做好這些名額的監控後，我們接下來需要做的是針對這些名額做好告警，如果某個名額突破設定的門檻值後，需要進行告警通知給我們，針對監控告警名額門檻值的設定，建議先嚴後松，即系統建設初始階段設定的嚴格些，避免遺漏告警，出現線上問題，後續随着系統建設的疊代需要設定更合理的告警門檻值，避免告警泛濫，造成狼來了的效應。總之上線釋出過程的一段時間是事故和問題發生的高峰，這塊一定做好名額監控，日志監控，對報警要敏感。
3.1.2 可灰階
上線過程中，我們要做到可灰階，通過灰階執行變更以限制爆炸半徑，降低影響範圍，同時灰階過程要做好相容。灰階分為不同次元的灰階：機器次元，機房次元，地域次元，業務次元：使用者，商家，倉，承運商等。
機器次元：我們用行雲部署時，可以每個分組先部署一部分機器進行灰階，灰階一段時間比如：24小時沒什麼問題後，再部署剩餘的機器。
機房次元：微服務架構下，我們的應用會部署在不同的機房中，可以按照機房次元灰階，比如先部署釋出代碼在某個機房分組下，觀察一段時間再按照比例擴大灰階機房範圍直至全量。例如先部署中雲信的機房，灰階一段時間後，再逐漸灰階有孚的機房。
地域次元：現在的部署架構都是多機房互為災備，異地多活，單元化部署，例如業界美團的外賣業務非常适合做異地多活，單元化部署，因為外賣業務的商戶，使用者，騎手天然具有聚合性，北京的使用者大機率不會在上海點外賣，這樣根據業務的屬性，在系統建設的時候，從應用層到中間件層，再到存儲層可以單元化部署在上海地域的機房和北京地域的機房，功能釋出的時候可以灰階某個地域，做到地域級别的容災。
業務次元：在上線過程中，我們也可以根據業務屬性進行灰階，例如上線了某個功能或者産品，根據使用者次元灰階，某些使用者或者某些商戶才能使用該功能，産品。
3.1.3 可復原
線上出現問題時，我們應該優先止損，其次才是分析根因。止損的最快方式就是復原，復原分為代碼復原和資料復原，代碼復原即将我們代碼恢複到原有的邏輯，代碼復原有兩種方式：開關控制和部署復原。最快捷的方式是開關控制，一鍵開關打開或者關閉就可以實作復原到原有的邏輯，操作成本最低，止損最快速。第二種方式就是部署復原，通過釋出平台，例如行雲将代碼復原到上個穩定運作的版本。有時候我們代碼復原完，如果沒有做好向前相容性，系統應用依然有問題，例如上線過程中産生了新資料，復原完後，代碼不能處理新的資料。是以這個時候又涉及到資料的復原，資料的復原涉及到修數：将産生的新資料無效掉，或者修改為正确的資料等，當資料量比較大時，資料的復原一般耗時費力，是以建議做好向前相容性，直接代碼復原。
3.2 線上問題應對
3.2.1 常見問題分類
針對線上的問題，我們第一步是識别出是什麼問題，然後才能解決問題，針對線上各種各樣的問題我們可以進行聚合，歸并分類下，針對每種問題去參考業界的處理方法和團隊的内的緊急預案，做到臨陣不亂。
3.2.2 問題生命周期
當出現問題時，我們也需要清楚一個線上問題的生命周期：從問題發生，到我們發現問題，進而進行響應處理，觀測問題是否修複，服務是否恢複正常，到最終針對該問題進行複盤，當發生系統發生問題時，我們越早發現問題，對業務的影響越小，整個流程如下圖所示。
3.2.3 如何預防問題
就像人的身體生病一樣，當問題發生已經晚了，我們要投入更多時間和精力到如何預防中，就像扁鵲的大哥一樣治未病，防患于未然。根據破窗原理，一個問題出現了，如果放任不管，問題的嚴重性會越來越大，直到不可挽回。我們可以從研發的規範，研發的流程，變更流程這幾個方面進行預防。
3.2.4 如何發現問題
對于一個系統，如果外界不對其做功，根據熵增原理，其會越來越混亂，直到出現問題，外界對其做功，就涉及到改變，因為改變是人在操作，由于各種不可控的因素，也會導緻各種線上問題，是以我們可以看到對于一個系統上線後不出現問題是不可能的，當出現問題時，我們第一步是如何快速的發現問題？對于問題發現的管道，工作中接觸到的有如下幾種：自我意識，監控告警，業務回報；
自我意識：我們C2部門每周有一個重要會議OpsReview，各個C3團隊會對個團隊的核心接口的不規律跳點，毛刺進行可用率，性能，調用量的review，以通過這種主動的，自我意識行為發現潛在的線上問題。同時我們組每天早會的重要一項：UMP監控全域看闆的review，我們會對昨天核心接口的可用率，TP99，調用量，進行分析的，對于可用率降低，TP99有毛刺，不規範的流量調用會進行排查原因，盡早自我發現問題，同時也會對機器的CPU, 記憶體使用率，Mysql, redis , es各種存儲進行review。
監控告警：這是我們發現問題最常用的管道，通過主動的監控名額，被動的接收告警來發現問題，告警名額我們分為業務名額和技術名額，具體分類可詳見3.1.1可監控部分
業務回報：這種發現問題的方式是我們最不願意看到的，如果等到業務回報，說明線上問題已經影響到使用者，我們常常因為監控告警的缺失，漏報而導緻落後于業務發現問題，是以我們最希望每個人，團隊都有這種自我意識，将線上問題提早發現，防患于未然。
3.2.5 如何響應問題
出現線上問題後，我們個人對問題的認知是非常有限的，并且這個時候人處于一種高度緊張的狀态，是以這個時候一定要群裡周知自己的leader，将情況如實表達，不要誇大和縮小問題的範圍和影響，同時将問題進行通告。整個問題的響應過程包含以下幾步：
1.保留現場：問題發生的現場是我們排查問題的依據，是以要将現場的日志，資料等資訊儲存好，比如記憶體dump, 線程dump，避免機器重新開機後這些資訊的丢失。
2.提供資訊：提供自己所知道的資訊，協助排查，不要擴大和縮小問題
3.恢複服務：當出現線上問題是，我們追求的是以最快的速度恢複服務，快速止損，業界有快速止血，恢複服務的幾闆斧：復原：服務復原，資料復原，重新開機，擴容，禁用節點，功能降級
4.雙重确認：服務恢複後，我們需要确認是否恢複了，可以通過觀察：業務名額是否正常，技術名額是否正常，資料是否正常，日志是否正常等來觀測問題的恢複情況
5.故障通告：确認問題沒有什麼問題後，需要再應急群中周知大家：業務人員，産品經理，系統的上下遊，測試人員，SRE等。并讓産品和業務進行确認，然後周知使用者。
3.2.6 如何定位問題
服務恢複後，我們可以回過頭來細緻的分析下到底是什麼原因導緻了線上的問題。定位問題也要講究方法論，這就涉及到定位問題三要素：知識，工具，方法。
知識：相對其他行業，計算機行業應該是知識更新疊代最快的行業，是以我們需要不斷的去學習，更新自己的知識庫，不給自己設限。例如你想解決FullGC問題，你必須對JVM進行系統的學習，想解決慢sql，必須對Mysql進行系統的學習，現在AI大模型這麼火，我們也需要對prompt engineering， RAG ， Agent, 多模态等進行學習了解。有了知識我們才能遇到問題時，知道是什麼，為什麼？
工具：工欲善其事，必先利其器，工程師要善于借助公司工具來提高解決問題的效率，熟練使用公司各種中間件工具，公司已經有的中間件，優先使用公司的中間件，公司内一個中間件團隊維護的中間件工具要優于業務研發小組内維護的中間件工具，不要小組内部，或者團隊内部重複造輪子，并且小組内人員的流動變更，容易造成中間件沒人維護。下圖是公司常用的中間件工具：
方法：解決問題我們要講究方法，選擇正确的方法可以事半功倍，提高我們定位問題及解決問題的效率，下面是我們研發人員常見的排查問題的方法
3.2.7 如何修複問題
有了知識，工具和方法後，其實我們很快的就定位到問題了，定位到問題後，我們就要想辦法如何去把問題修複了，以下是問題修複的流程：
3.2.8 如何複盤問題
問題發生後，我們需要從此次問題中分析根因，并汲取教訓和經驗，避免犯同樣的錯誤。這就涉及到問題的複盤，如何進行問題的複盤那，一般會經過如下幾個步驟：回顧目标，評價結果，分析原因，總結經驗。例如我們C2部門每周的opsReview會議上都會有線上問題的複盤：coe，如何進行coe複盤談一些自己的思考。
•參考業界的5WHY分析法剖析問題的根因
•5WHY分析法：5代表的是問題的深度，而不是問題的數量
•基于問題的答案繼續進行提問，5個問題是有關聯的，層層遞進的，找到問題的根因
4 參考資料
•https://itrevolution.com/articles/20-years-of-google-sre-10-key-lessons-for-reliability/
•https://learn.microsoft.com/en-us/previous-versions/msp-n-p/jj591573(v=pandp.10)?redirectedfrom=MSDN
•https://sre.google/books/