來點 SRE - 從 ChatGPT 停機公告,學維運事後剖析

來點 SRE - 從 ChatGPT 停機公告,學維運事後剖析

Overview 概述

ChatGPT 在美國時間 3/24(週五) 發布了新的一篇 blog,解釋 3/20(週一) ChatGPT 停機的來龍去脈。

每一次的緊急維修,對於系統維運 SRE 來說都是意義非凡。因為這代表你的服務

  1. 重要到用戶會關注
  2. 必要到每分每秒都在產生價值 (不修復會造成損失)

對於很多企業來說,停機好像是永遠不該發生的事。多半是偷偷改掉不讓用戶發現就過了,怎麼可能大張旗鼓地還發部落格?

從這點就可以看出決定性的差異。

🔎 透明度,及其帶來的信任是關鍵。「我們正在修,出於什麼原因-人事時地物,之後能怎麼避免」。好用,相信你能夠盡快修復的信任感 (Trust),奠基於系統服務的穩定 (Reliability)

❓ 提問: 你的團隊在意這些服務體驗嗎? 一起來看 OpenAI 怎麼示範 SRE 中的 Postmortem (事後剖析)。

什麼是 SRE 網站可靠性工程

SRE (網站可靠性工程, Site Reliability Engineering) 是 Google 早在十年前就提出並且應用的一種維運管理方法論:

SRE is what happens when you ask a software engineer to design an operations function. – Benjamin Treynor Sloss (Vice President, Engineering, Google)

SRE 就是當你去問一個軟體工程師如何設計一套維運方法的表現。

Google 有兩本 SRE 的免費電子書,非常推薦維運工程師好好研究。

OpenAI 不是第一個這麼做的單位,事實上這已經是西方主流企業的顯學之一。

ChatGPT 3/20 停機剖析

ChatGPT 在美國時間 3/24(週五) 發布了新的一篇 blog,解釋 3/20(週一) ChatGPT 停機的來龍去脈。

Situation Analysis 狀況說明

3/20(週一) ChatGPT 存在開源庫 redis-py 快取的漏洞,導致

  1. 部分用戶會看到別人的聊天標題
  2. 少了幾個小時的歷史訊息
  3. 在某 9 小時裡,1.2% 的活躍用戶中,ChatGPT Plus 訂閱者的付款相關資訊被意外洩露
  4. 包含: 名字、email、付款地址、信用卡號碼末四碼及信用卡到期日。完整的信用卡號碼並未曝光。

發現狀況當下 OpenAI 立刻停機進行調查與修復,包括如何復現此狀況,並聯繫受影響的使用者。

Tech Details 技術細節

簡單來說是 ChatGPT 採用的 Redis Cluster 的 Asyncio redis-py 客戶端,在異常處理時會導致連線返回錯誤資料

Redis 是一個 Cache 快取機制,在後端資料庫 (DB, Database) 跟用戶中間,讓你不用一直去跟 DB 拿資料,這樣 DB 就不會太忙,用戶的存取速度也會大幅提昇。在這個例子中,理應該被拒絕的 request,卻意外發給了不對的用戶。如今已透過開源社群的快速 patch 修復。

Actions 採取措施

OpenAI 也條列了他們已經採取的措施:

  1. 大量測試,以確保修復。
  2. 增加冗餘檢查,以確保 Redis Cache 返回給正確的用戶。
  3. 改善日誌 Log,以識別問題並確認已停止。
  4. 識別受影響的用戶,以便通知他們。
  5. 增加 Redis cluster 的穩定性和可擴展性,減少在極端負載下,連線錯誤的可能性。

身為 IT 從業人員,我只能說望塵莫及。

你說差別在哪?基本上光是這 5 個項目,我只能說在我的周遭觀察過的,多半只做了修復單點 bug。「解完就沒事了」「祈禱他不要再發生」。

  • 至於要多少測試?「我先手動測一測就好了」
  • 回頭改善 Log?「那是別人的事」
  • 通知受影響用戶?「我趕快修一修就好」
  • 增加穩定性?「那個很複雜現在沒時間作」

如此簡單易懂的道理,實行起來就是如此困難。而我們能做的只是每一次都盡可能引導身邊的同事,一起加入更有系統、有效率解決問題的行列。

Incident Managment 事件處理

像是 status page 狀態頁面這類非常常見的可觀測性服務,若沒有將自己的服務視為重要的,那就很可能會忽略掉。

Status Page

我們很常去談 monitoring 監控的重要性,什麼服務掛了我要自動知道。但是卻很少去談「服務掛了我要怎麼處理、甚至自動修復」。這就牽涉到 “Incident Managment 事件處理” 與 “Self Repairing 自我修復”。一個是讓事件受影響的人與環節能被充分討論,找出根因並徹底防範;另一個是如何減少人為操作成分,盡可能自動化。這些都是 SRE 裡會談的東西,也是我們能真正意義上讓服務自動維運的關鍵。

運用工程手段,積極尋求解法

一週內修復,並公開事後剖析報告,擬定下一步防範措施。我想這應該比刻意隱瞞,被抓到了之後再「謝謝指教」來得有說服力的多。

人非聖賢,孰能無過。關鍵是如何不二過。坦然面對,運用工程手段,積極尋求解法,這些都是再簡單不過的道理,但能如此自然採取行動的,卻總是少數。

有效的維運管理需要有 “主動和解決問題的思維"。我想,關鍵在於心態:

Take ownership and get things done.

你怎麼看?

留下你的想法一起討論吧! 🥳

延伸閱讀

  1. 2022 TSMC IT Day - 看台積電 CIO 如何以矽谷軟體公司思維打造 IT 數位轉型之路
  2. DevOpsDays Taipei 2022 - 企業 IT 數位轉型投資成長 + 持續交付高品質可用產品
  3. AIGC 浪潮翻騰 15 週後的 6 大行為改變

Murmur

  • 2023-03-25: 態度決定高度、心態決定境界。
    • 這次還是寫了好久(2.5 hr) 😂, 下次再想想看怎麼拆解加速…

其他相關