[心得] (代PO) 90萬字鐵人賽：AWS 系統設計的哲

看板Soft_Job (軟體人)作者vansama (抽著菸斗看著書)時間3小時前 (2025/11/14 18:33)推噓1(1推 0噓 2→)

留言3則, 2人參與討論串1/1

（代po) 各位前輩大家好，今天我來忝不知恥的宣傳(? 發自內心的感謝版上的大大們，並問問看能否在致謝銘中感謝版上曾經的援手而想跟大家分享的是<AWS架構師的自我修養：30天雲端系統思維指南> https://ithelp.ithome.com.tw/users/20162031/ironman/8504 在這個AI時代中 - 相關系列文與前輩們也探討過 - 作為工程師「我們現在可以怎麼做」與「未來我們該怎麼做」而這次鐵人賽就是分享在工作中一路來被PM追著MVP、跟UIUX吵、和SA討論規格、思考QA的情境是操作者能操作豬來的嗎? 種種不知凡幾的思緒融合成整的產品級的系統設計心得。系列主要分享軟體開發者在接下來的世代中(至少是下一個10年)最好能夠具備哲學詰問思維，追問系統存在的目的第一性（即領域驅動, DDD）。系統設計可以被視為一種概念化的仿生學，有它的生老病死環節﹑具備有機性與生長性，需緊緊依循目的設計。所以本次心得是依照著我經驗中觀察到的產品開發的所有流程，只能說是主觀多數經驗了，若有與各位大大的經驗與流程不服-我菜我謙卑，求鞭小力點Orz (1)產品發想與機會探索=>(2)需求定義與優先排序=>(3)產品設計與使用者體驗=>(4)技術規劃與系統設計=>(5)軟體開發與持續整合=>(6)驗證與品質保證第一站:產品發想與機會探索-奠基哲學 (Day 1-5) - 城市的規劃藍圖在動工之前，我們先站在空地上，思考這座城市為誰而建、要解決什麼問題。 Day 1 線上服務即數位生物:系統設計不是技術堆砌，而是有目的導向的創造。 Day 2 如何將模糊的商業需求轉化為清晰的系統邊界，怎麼透過符號學與哲學中的公式工具解構抽象需求，透過現象層=>本質層=>存在層，來為我們細化並提前分析後續須亦考慮的面向。 Day 3-4 深入 DDD 的核心:如何用抽象建模識別領域邊界，如何用聚合設計保護業務不變式。 Day 5 將視角轉向使用者:User Story 與 Scenario Flow 讓我們從「市民」的角度理解城市，確保設計不是閉門造車。第二站:技術決策 (Day 6-9) - 城市的基礎建設有了藍圖，我們開始面對現實的約束:預算有限、時間緊迫、需求會變。這沒有絕對的最佳解，只有當下情境中的最適解，每一個技術選擇都伴隨著代價。 Day 6 探討 Trade-off 的藝術:在成本、性能、可維護性之間找平衡，就像城市規劃中要在地價、交通便利性、環境品質間做抉擇。Lambda、ECS、EC2 的選擇，從來不是「哪個更好」，而是「哪個最符合當下目的」。 Day 7 將領域模型映射為技術架構:單體、微服務、Serverless 對應不同業務複雜度與團隊成熟度的務實選擇。 Day 8 將前端設計系統與原子化架構引入，說明了從最小的 UI 組件到完整的業務流程，如何保持設計的一致性與可擴展性。 Day 9 面對高併發場景，如何用限流、降級、熔斷等策略保護系統，如同城市的交通管制與應急預案。第三站:數據與狀態 (Day 10-11) - 城市的記憶系統數據是系統的靈魂，同時也是我們在執行某一個動作後所被記錄下來有其意義的影響 - 交易記錄、用戶行為、系統狀態。如何存儲、如何快速檢索、如何保證一致性? 快取雪崩、數據不一致這些技術問題，本質上是我們對業務邏輯理解不夠深刻的體現。 Day 10 深入快取策略的哲學:時間與空間的權衡、一致性與性能的取捨。 Day 11 探討資料庫設計:從領域模型到 Schema 設計，從 ACID 到最終一致性，每一個選擇都反映了我們對業務本質的理解程度。核心反思:數據是系統的靈魂，而如何對待數據，體現了我們對業務的尊重程度。第四站:工程實踐 (Day 12-15) - 城市的建設流程再好的設計，如果無法安全、高效地落地，也只是空中樓閣。 Day 12 建立版本控制與代碼審查文化，確保團隊協作的品質。 Day 13 用 OpenAPI 等工具建立團隊間的契約，讓前後端、不同服務間能夠並行開發而不互相阻塞。 Day 14 將基礎設施代碼化(IaC)，讓系統的部署可重複、可追溯、可回滾。 Day 15 建立 CI/CD 流水線，讓從代碼提交到生產部署的每一步都自動化、可觀測。第五站:環境與體驗 (Day 16-18) - 城市的使用體驗系統不是孤立存在的，它運行在多個環境中，被不同角色的人使用。一個難以除錯、難以部署的系統，再性感的架構也會在長期維護中逐漸腐化。 Day 16 探討多環境治理:開發、測試、生產環境的隔離與一致性，如同城市的開發區、試驗區與成熟區的規劃。 Day 17 關注開發者體驗(DX):好的內部工具與除錯設計，能讓團隊事半功倍。 Day 18 制定系統驗收準則:如何定義「完成」，如何確保交付品質符合預期。第六站:品質保證 (Day 19-21) - 城市的安全檢驗測試不是開發完成後的附加步驟，而是設計階段就應該考慮的核心能力。可測試的系統往往也是設計良好、邊界清晰的系統。 Day 19 從使用者視角進行 UX 測試與可用性驗證，確保系統真正解決了用戶的問題。 Day 20 建立從單元測試到集成測試的完整測試策略，讓系統的每一層都有品質保障。 Day 21 進行性能與壓力測試，識別系統在極限負載下的瓶頸與風險點。第七站:安全與韌性 (Day 22-25) - 城市的防禦體系韌性不是被動的容錯，而是主動的設計選擇。系統一定會出錯，不是從不出錯(或者可能只存在印度人嘴皮子上)，我能做得是能夠主動引爆錯誤並快速恢復，從失敗中學習。 Day 22 引入零信任架構:從邊界防禦到身份驗證的思維轉變，重新定義安全邊界。 Day 23 建立可觀測性三大支柱(Logs， Metrics， Traces)，讓系統能「對自己說話」，及時發現問題。 Day 24 用 SRE 方法論定義與衡量可靠性:SLI、SLO、錯誤預算等概念，讓可靠性從口號變為可量化的指標。 Day 25 透過混沌工程主動驗證韌性，在受控環境中提前暴露系統的脆弱點。第八站:演進與持續改進 (Day 26-29) - 城市的有機成長系統不是一次性交付的產品，而是持續演進的生命體。 Day 26 建立數據驅動的產品決策機制:從 A/B 測試到北極星指標，讓每一次改進都有數據支撐。 Day 27 識別與償還技術債:用技術債象限與童子軍規則，讓系統在演進中保持健康。 Day 28 關注數據治理與隱私保護:在 GDPR 等法規要求下，如何設計合規的數據生命週期。 Day 29-1 探討架構演進的策略:用絞殺者模式與 BFF，實現從單體到微服務的平滑過渡，避免大爆炸式重寫的災難。 Day 29-2 引入 AI 協作框架:在 AI 時代，架構師如何與 AI 工具協同，放大自己的思考與決策能力。核心價值在於理解商業邏輯、業務實現(每個技術決策都涉及成本、風險和目的的權衡)，掌握領域知識是 AI 時代是我們未來的、真正的競爭壁壘。我認為未來我們會逐步朝著架構師邁進，當技術難易度水位隨著AI大爆發上升，架構的理解就像是觀察洋流的流向與水位下的暗礁，不同的Domain就像是島嶼一般，有些領域未來勢必可以用AI模型直接完整做出來，這時它就變成了水面下的暗礁了。但要看它長得對不對、有沒有什麼真實程式語言上的隱患，和未來要怎麼擴張就很考驗我們對於這個數位新生命的期許了，在現行AI的設計上還是編向於鏈式思考(Tier 1)，而非網式思考(Tier 2)，這目前也只能靠人類來進行權衡與規劃 - 哪個鏈式思考能得出龍X汽車與 114514 的關聯啊(惱我很努力縮短摘要，但真的好難(系列文章通篇快90萬字...吧?)，感謝各位看到這裡的前輩與大大們Orz，在我當初轉職的時候提供的討論與願意回覆我的詢問私訊讓我能夠成功上岸，真的是非常非常非常感謝，要謝的人太多了，謝謝如天一般的版大們 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.232.111.161 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1763116432.A.E56.html ※ 編輯: vansama (118.232.111.161 臺灣), 11/14/2025 18:35:10