鄭棋文Steven—軟體架構與DevOps筆記

⚡ 性別標籤

在閱讀《朋友與敵人》後，內心感觸良多。
同樣的行為，男性可能被解讀為「自信」，女性卻常常被認為「囂張跋扈」。
這就是社會裡普遍存在的「雙重標準」。

對一位父親來說，這令人心痛。擔心女兒在未來的道路上，會因為性別而遭受不公平的評價。

書中舉例：
想像一下以下的情境，你觀察一場面試。
面試官問：「你喜歡在高壓環境下工作嗎? 」

求職者回答：「在高壓環境能讓我拿出更好的表現，高中的時候我是校刊編輯，永遠得趕在期限之前交出每週的專欄文章。我每次都順利完成任務 有時連自己都很吃驚。指導老師也發現這件事，很稱讚我。」

研究發現，如果這個面試者是男性，觀察者會想要雇用這個人，但如果是女性，觀察者認為她的性格不討喜，判斷不適合做這份工作。

然而，這也提醒了我三件事：
1️⃣ 教育下一代：自信不是錯，勇敢不是錯。
2️⃣ 改變日常對話：避免無意中複製偏見。
3️⃣ 成為改變的一份子：在職場與社群中挑戰標籤。（前提你需要先掌握權力）

性別，不該成為限制成長與表達的枷鎖。
💬 你是否也觀察過這種不公平的現象？

【零停機資料庫遷移案例】Atlassian 的 AWS RDS → Aurora 實戰
在筆者過去的經驗中，資料庫遷移通常是 dump → 停機 → 恢復。這種方式雖然簡單，但對 24/7 全球用戶的 SaaS 平台，幾乎不可能接受長時間中斷。

Atlassian 的解法如下：
1️⃣ Replication：先在 PostgreSQL RDS 上建立 Aurora 讀複本，進行即時同步
2️⃣ Lockout：將 RDS 寫入鎖定到新的 Aurora DB上，讀取流量暫時仍在 RDS
3️⃣ Promotion：將 Aurora 晉升為主要資料庫，短暫中斷數秒到數分鐘
4️⃣ Unlock：將所有讀寫流量切換至 Aurora

透過分階段切換、精密控制流量方向，Atlassian 成功在數百萬資料庫的規模下，完成了幾乎無感的遷移。

你覺得這套方法可以應用在你們的系統中嗎？

🔍 近期發現一個非常實用的工具 —— eslint-seatbelt
由 Notion 團隊開發，專門解決 大型 JavaScript / TypeScript 專案在更新 ESLint 規則時的痛點。
在維護大型專案時，如果一次性套用或更新 ESLint 規則，常會遇到這種窘境：
一堆舊程式碼被 ESLint 攔下，修改起來痛苦又耗時。
想快速部署卻被阻塞，只有兩條路：

1️⃣ 先全部修 ESLint，再加入新功能（專案停滯）
2️⃣ 直接加新功能，把 ESLint 修正丟到「某一天再說」（但大家都知道，那一天永遠不會來）

eslint-seatbelt 的解法是引入 Ratchet（棘輪）機制：
舊程式碼可以暫時跳過 ESLint 驗證
新增或修改的程式碼，必須符合 ESLint 規則
讓專案能持續開發的同時，逐步提高符合規範的程式碼比例
這種漸進式的控制，對大型團隊特別友善。非常聰明的作法。

📌 這樣的漸進策略，能讓團隊維持開發效率，同時不犧牲程式碼品質。
值得馬上試試！
.js

讀完謝文憲憲哥的《極限銷售》最深的提醒：想成為優秀業務，先學做人
我自己最有感觸的是：做人第一步，就是「記住對方的名字」。
卡內基說：「一個人的名字，是他耳中最悅耳的聲音。」這是尊重、信任與關係的起點。
曾經在參與演講後，過去的學生主動跟我打招呼；臉熟，卻喚不出名字，也想不起他的工作與公司。那份慚愧，成了最直接的學費。

而記住他人的名字有以下小技巧：
1. 名字＝尊重與記憶點
— 初次互動 30 秒內確認發音；談話中至少重複 2 次；道別再稱呼一次。
2. 在學生報名的時候，先過目所有的名單
— 到現場之後，就可以將名字對上人臉。
3. 情境（講師/顧問/業務都實用）
— 生日/里程碑設提醒，簡短的生日祝福就可以維繫關係

你呢？只要想好好做人，不管是擔任技術架構師、顧問、講師，其實都需要具備這個能力。
#極限銷售 #卡內基 #業務技巧 #人際溝通 #客戶關係

https://slack.engineering/speedup-e2e-testing/
🔥 減少等待！E2E測試也可以跑得又快又穩

在 Slack 最近的技術分享中，提到他們如何優化 E2E 測試流程，其中一句話直接命中我的要害：

每一次 PR 都要重新 Build 前端，平均就要花 5 分鐘。

這個狀況我自己也遇過，有些前端專案 Build 起來甚至要等超過 10 分鐘，真的令人頭痛。

🔧 他們的解法簡單卻非常有效：

1️⃣ 先判斷該 PR 是否有前端程式變更
2️⃣ 若有，就重新 Build
3️⃣ 若無，就直接重用上一次的前端 Build 成果，進行 E2E 測試

光這樣就省下大量的時間與雲端資源。聽起來簡單，實作起來也不算難，但最難的反而是「願不願意改」。（對，就是在說我自己）

很多時候 CI/CD pipeline 只要能跑、能過測試就滿足了，但如果想要打造真正高效的開發流程，這類優化絕對值得投資。

💬 你的 CI Pipeline 中，還有哪些值得優化的地方？

📂 關鍵優化：分表

當資料表太大，查詢慢、索引重、效能差，這時該怎麼辦？

👀【解法：分表】，常見有兩種方式：

1️⃣ 垂直切割
👉 解決欄位過大問題。像是「會員地址」這類欄位文字長、又不常用，可以獨立成表，讓主要表查詢更快。

2️⃣ 水平切割
👉 針對資料列數太多的情況，譬如交易表超過千萬筆時，可按主鍵或時間區間切分成多張子表，分攤壓力。

💡通常資料量破億才會有明顯效能問題，但提早設計，也能避免系統演化過程中的痛點。

👉下一篇，我們會分享「水平分表要注意什麼」，別錯過！

📣 你們的系統目前是單表設計？還是已經分表了呢？歡迎留言交流！

救火時刻🧯

系統出問題，使用者無法使用。這時候最重要的一件事是什麼？

不是 debug，也不是究責，更不是禱告，而是：「先讓系統活起來！」

很多人容易陷入以下三種誤區：
1️⃣ 一頭栽進 debug，試圖找出問題根源
2️⃣ 開始問是誰改的 code，想找戰犯
3️⃣ 不知所措，期待別人來解決

請記得：「救火」的第一步，是止血，不是開刀。

這就是工程師應具備的關鍵心態。
當系統異常時，應先想方設法讓服務恢復可用，後續才是修復與反省。

你的團隊有建立這樣的應變流程嗎？

🔥 提升效能這樣做：分庫架構

當資料越來越大、查詢越來越慢，該怎麼辦？「分庫」是一個常見的解法，將不同業務邏輯，儲存在不同資料庫中。

但這招不是萬靈丹，反而可能出現以下問題：

1️⃣ 【JOIN困難】
以前不同表之間可以輕鬆 JOIN，分庫後跨資料庫 JOIN 幾乎無法使用，只能靠應用層處理。

2️⃣ 【業務複雜化】
若一個流程需要從不同庫拿資料，IO 請求變多，效能反而變差。

3️⃣ 【成本上升】
每個資料庫都要獨立管理、備份，資源使用與維運成本大幅增加。

✅ 所以，在分庫之前，一定要先釐清：資料的邊界與業務的核心需求在哪裡？

你們團隊目前有導入分庫策略嗎？又遇過哪些挑戰？

🚀 快讀快寫？先搞懂讀寫分離的代價

在打造高性能資料存儲架構時，「讀寫分離」是最常見的解法之一。

主機處理寫入，從機負責讀取。這樣能有效分攤負載、提升效能。

但你有思考過這個問題嗎？
📉 主從同步的「延遲」，可能對業務造成什麼衝擊？

🔸 剛註冊完帳號卻無法登入
🔸 商品剛上架但頁面顯示「無此商品」
🔸 訂單剛完成卻無法查詢紀錄

這些情境都來自於「主機資料尚未同步至從機」，導致讀取端看不到最新資料。

📌 那怎麼解決？

以下是常見的三種處理方式：
1️⃣ 將「登入」等關鍵讀取請求，送至主機處理
2️⃣ 從機沒查到資料時，自動 fallback 到主機
3️⃣ 重要的業務場景不使用讀寫分離，直接在主機進行完整讀寫操作

⚠️「效能」與「一致性」永遠是權衡。你會怎麼設計這道平衡？

🔧 架構細節才是收尾

真正穩定可運作的系統，雖然必須把每個細節談清楚，這是架構設計的最後一哩路，卻往往一頭熱的在架構設計的最一開始就積極的討論，這樣會錯失全局觀。

📌 三個常見的細節討論面向：

1️⃣ **資料庫：**是否需要只讀副本？幾台？跨區同步？
2️⃣ **負載均衡：**隨機分配 or 權重設定？支援 sticky session 嗎？
3️⃣ **實體資源：**EC2 規格如何？是否使用 Spot？有沒有 auto scaling？

📚 完整的架構設計流程回顧：
1. 識別複雜度
2. 提出備選方案
3. 透過最優先考量，選出主方案
4. 細節討論與建立
5. 最後定案、交付與執行

每個選擇，都是系統穩定性的伏筆。

👀 你所在的團隊，是誰來拍板這些細節？又是依據什麼決策依據來做選擇的呢？

🚦怎麼選架構才不後悔？

有個部落客，原本只靠一台小機器跑 WordPress，結果人氣一高，網站慢得跟不上了。
提供兩個方案給他參考：

🅰️ 單體升級：CPU & RAM 加大
🅱️ 加上 Redis 快取熱門內容

分析給你看：
1. 性能：Redis > 單體升級
2. 成本：Redis < 單體升級
3. 可維護性：Redis 難度高
4. 可擴展性：差不多
5. 可用性：Redis 表現更穩

📌那怎麼選？別用「加權打分」，因為——
🔑 重點在「最優先是什麼」？

如果最優先是「可維護性」，就該選最簡單的「單體擴容」。
能穩定運作、不搞砸就好。等有餘力了，再來升級複雜架構。

🤔 你在實務上是怎麼做架構選擇的？選最強？還是選最簡單？

看完鈴木一郎的名人堂演說。
「在高處看見別人，在低處看見自己。」
這真的是郎神受人尊敬的地方。
在前面感謝引領他進入MLB的所有球隊朋友與經理
在最後感謝永遠的隊友，他的太太。