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

鄭棋文Steven—軟體架構與DevOps筆記 外商AWS雲端架構師|優雅新手奶爸
🧑‍💻
目標 ▍一週工作4小時
期許 ▍數位遊牧新手爸媽
想辦一場最吵的讀書會(小孩友善👶)
📩:[email protected]

Hi 我是鄭棋文 Steven,這是我的技術專頁。
外商AWS雲端架構師|優雅新手奶爸
🧑‍💻
目標 ▍一週工作4小時
期許 ▍數位遊牧新手爸媽
想辦一場最吵的讀書會(小孩友善👶) 📩:[email protected]

10/09/2025

⚡ 性別標籤

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

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

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

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

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

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

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

14/08/2025

【零停機資料庫遷移案例】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 成功在數百萬資料庫的規模下,完成了幾乎無感的遷移。

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

13/08/2025

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

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

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

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

12/08/2025

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

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

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

https://slack.engineering/speedup-e2e-testing/ 🔥 減少等待!E2E測試也可以跑得又快又穩在 Slack 最近的技術分享中,提到他們如何優化 E2E 測試流程,其中一句話直接命中我的要害:每一次...
08/08/2025

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 中,還有哪些值得優化的地方?

07/08/2025

📂 關鍵優化:分表

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

👀【解法:分表】,常見有兩種方式:

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

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

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

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

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

救火時刻🧯系統出問題,使用者無法使用。這時候最重要的一件事是什麼?不是 debug,也不是究責,更不是禱告,而是:「先讓系統活起來!」很多人容易陷入以下三種誤區:1️⃣ 一頭栽進 debug,試圖找出問題根源2️⃣ 開始問是誰改的 code...
06/08/2025

救火時刻🧯

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

不是 debug,也不是究責,更不是禱告,而是:「先讓系統活起來!」

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

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

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

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

05/08/2025

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

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

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

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

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

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

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

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

🚀 快讀快寫?先搞懂讀寫分離的代價在打造高性能資料存儲架構時,「讀寫分離」是最常見的解法之一。主機處理寫入,從機負責讀取。這樣能有效分攤負載、提升效能。但你有思考過這個問題嗎?📉 主從同步的「延遲」,可能對業務造成什麼衝擊?🔸 剛註冊完帳號...
04/08/2025

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

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

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

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

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

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

📌 那怎麼解決?

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

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

🔧 架構細節才是收尾真正穩定可運作的系統,雖然必須把每個細節談清楚,這是架構設計的最後一哩路,卻往往一頭熱的在架構設計的最一開始就積極的討論,這樣會錯失全局觀。📌 三個常見的細節討論面向:1️⃣ **資料庫:**是否需要只讀副本?幾台?跨區...
01/08/2025

🔧 架構細節才是收尾

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

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

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

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

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

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

31/07/2025

🚦怎麼選架構才不後悔?

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

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

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

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

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

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

30/07/2025

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

Address

Taipei

Alerts

Be the first to know and let us send you an email when 鄭棋文Steven—軟體架構與DevOps筆記 posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to 鄭棋文Steven—軟體架構與DevOps筆記:

Share