前言
上一篇 TGONext 架構組 - 高併發高流量 分享參加架構一組的書僮筆記，這一篇則是記錄由 Taien 擔任導師的架構三組討論心得，在 TGONext 導師計畫 開學儀式當天小組內的組員有各自做簡單的自我介紹，並針對工作上的痛點做簡單討論，導師與同學分享未來五個月聚會的主題與規劃，以及推薦可以幫助到大家的書籍清單，架構3組三月份討論主題是 架構師的自我修煉，預計討論內容如下
心態與思想
深耕專業技能
團隊合作典範
如何影響團隊
這篇是根據微薄的記憶整理小組討論的筆記，部分內容為了讓初老症狀越來越嚴重的自己更好理解加上自己說明與圖片，若有問題或是錯誤的地方歡迎各位大大一同討論或給予指導
推薦書籍
在每次的聚會之前導師都有推薦的閱讀清單，清單如下
- QBQ問題背後的問題 : 這本書之前主管 gipi 就很推薦部門同事一定要閱讀，在 T社也是將這本書列為要求新人必讀書籍之一，最近在博客來發現出了30萬冊紀念版，可見其受歡迎的程度。
- 我編程，我快樂 : 談到程式猿的成長與職涯規劃之道，作者分享自己過去的經驗提醒程式猿不能只注重技術的提升，還要關注自己職涯上的發展，但礙於自己閱讀簡體字有障礙，目前只看一半還沒看完。
- 軟體架構師的12項修煉 : 作者認為軟技能是架構師的必修課，整理出 3 大方面分別是關係、個人與商務技能，教導程序猿修煉如何將三大項底下的12 項軟技能點滿，才可以算是一位合格的架構師。
除了上述提到的三本書之外，我個人也推薦 高效能程序員的修煉一書，其中一個章節提到程序猿應該培養寫作的習慣，當你學習到一技能/對某項事物有興趣/解決某個難搞的問題等事情都可以寫部落格文章，將所學到的內容消化最後在用自己理解的方式呈現出來，91哥也有寫過一篇文 我為什麼鼓勵工程師寫 blog，有興趣的朋友可以看看。
技能樹
由於組員來自四面八方每個人所擅長的技能都有所不同，組內有前端工程師、後端工程師、AI 資料工程師等，因此導師有先請同學在家整理以下資訊與同學分享
專業技能：Skill Tree
管理：Skill Tree
職涯目標
其中專業技能與管理希望同學用 Mind Map 呈現，並用顏色標示出對於技術的熟悉度，主要用意是希望大家都可以知道哪些技能是應該具備(守備範圍)，自己目前已經會了那些，而那些內容是自己還不會或是還沒有機會學到的，這些資訊可以透過整理成 Mind Map 的過程中讓自己更加清楚；由於管理的層面涵蓋很廣，像是溝通管理、時間管理..因此可以盡量延展，沒有標準的對錯與答案，以下分享小弟整理的內容，若有疑問歡迎一起討論
專業技能 Mind Map
身為一位前端低能兒因此這是以 Backend 後端工程師角度出發，如果有經驗的工程師都會知道，開發不僅僅是把 Code 寫好交付就可以，程式上線後還需要進行應用程式的監控等重要的事情，因此在整理時從幾個環節出發分別是分析、設計、Coding、測試、上線、維護與監控，從這幾點分別去整理對應到的技能或是工具，其中 CI/CD 與分散式系統設計是這一兩年希望自己加強的重點。在開發應用程式時隨著請求量的倍增，可能會從單一應用程式Scale up/out 擴充為多台應用程式，這時就需要依據當下的情境設計出合適的架構，如何在設計新架構時兼具效能與彈性讓系統可以承受高流量與高併發的考驗，亦有可能需要與舊架構為伍也就是常提到的讓飛行中的飛機換引擎，這之中有非常多的眉眉角角需要探討與研究的，也是自己覺得想挑戰的部分(自虐)。
管理 Mind Map
管理則是由架構師的角度出發，架構師除了基本要具備一定程度的技術能力，對於整個軟體開發流程從需求分析到系統上線後的監控與數據報表分析也都需要了解，從一開始的需求釐清與分析能力需要蒐集高階主管(長官)想要解決的商業問題是甚麼，才有可能在架構設計時選擇適合的方案；技術選型上需要了解選用的解決方案的本質與帶來的side effect為何，還有選用技術/產品的成熟度與穩定性，團隊的能力等多方面的考量出發，而非一昧地追求新技術而忽略帶來的成本與風險；除了技術能力之外軟技能也是不可或缺的項目之一，需要具備 Domain Knowledge 與商業思維而非一昧地以技術的角度出發來解決問題，須具備簡報技巧讓高層願意替你設計的新架構買單；高層 Buy in 後做出來的 POC 方案是否能讓團隊對於新架構是認同；最後是持續學習部分，需要持續學習與了解新技術增加自己的廣度，遇到問題時才有機會有更多解決方案而非單一解。(OS:為了不成為一位嘴砲架構師整理完發現列這麼多條件，覺得好像離架構師還有好長的路 XDDD)
導師有針對大家分享的技能與管理 Mind Map 內容給建議，另外也補充大家在還沒那麼多經驗時可以多看 Github 上比較熱門的 open source 吸取經驗，熱心的同學也在會後在群組補充覺得不錯的 github 專案 system-design-primer 以及 blog 讓大家一起學習。
HTTP Request Smuggling
在討論中導師也提醒同學資安是不可忽視的重點之一，除了可以參考 OWASP TOP 10 之外 另外提醒大家最近一種新的攻擊方式 HTTP Request Smuggling，這種攻擊方式在2005年就被發現但一直被大家所忽略，Portswigger 主管 James Kettle 於2019年再次提醒大家其影響程度，以下就根據 HTTP Desync Attacks: Request Smuggling Reborn 原文做簡單的介紹與說明
原理
當客戶在網站上操作行為時會透過 Front-end 服務器 (nginx、CDN、負載均衡或反向代理) 將 HTTP 請求發送至 Web 後端 (Back-end) 伺服器，為了提高其傳輸速度與效率，通常會經由同一個後端網路來傳送多個請求 (HTTP/1.1 提供 Keep-Alive 允許單個連接上傳送多個請求)，HTTP 會按照順序進行發送的動作，收到請求的伺服器會根據 HTTP 中 Request 表頭定義請求結束的位置 (Transfer-Encoding或是Content-Length)，如下圖所示
由上圖可以發現，Front-end 與 Back-end 是兩台不同的服務或伺服器，HTTP 請求偷渡是因為 Front-end(反向代理) 與 Back-end 後端處理請求的伺服器對於 HTTP 請求解析處理不一致，駭客可以透過不一致的差異在一個 HTTP 請求中放置 (偷渡) 另一個 HTTP 請求，後端接收到請求後會處理夾帶的攻擊內容 (橘色部分) ，直接在內部網路服務進行攻擊
HTTP Request Smuggling 將 Content-Length標頭和Transfer-Encoding 放在 HTTP 請求中，在透過 CL.TE、TE.CL、TE.TE 漏洞進行請求解析不一致的動作，詳細原理與細節可以參考下列文章有更詳細的說明與內容
Service Level
在定義服務的品質通常會提到 SLA、SLO、SLI，三個名詞的全名如下
- SLA : Service Level Agreement，服務等級協議
- SLO : Service Level Objective，服務等級目標
- SLI : Service Level Indicator，服務等級指標
舉例來說，假設今天開發的是電商系統，為了給客戶更好的品質與速度因此定義 SLA 為 Latency <= 300ms ；為了達到目標，Sevel level 可能會定義如下
- SLA : Latency <= 300ms
- SLO : latency <=200ms，會定義比承諾客戶更小數字的目標以達到 SLA 標準
- SLI : 每分鐘內 http status code 為 200 的 response，比較著重在指標的部分，常見的有throughput、latency、Availability或correctness等測量指標
有管理經驗的朋友可以發現像是在定義部門目標使用 Bottom-Up 的方式向下延伸，從下往上看就是要做到這些指標內容SLA才有可能達到，以上只是簡單的說明，更詳細的內容可以參考 Google Cloud 中的 SLOs, SLIs, SLAs, oh my - CRE life lessons 或是 Ant 大的 軟體技術架構如何正確與商業需求快速對齊：談 MAU 換算至 RPS，SLA 回推至 SLI 兩篇文章內容的詳細說明；因此在架構設計上，除了要考慮到需求情境之外，還需要考量到 SLI、SLO及SLA三者的目標，反思設計出來的架構是否都有包含上述功能性與非功能性需求，不斷反思是否有更好的解決方案。
Design Process
接著導師整理在設計架構時需要注意的的流程與議題
Defining the service (Rough, Structured design, Measurable)
3, and 4: Three-tier architecture (Data Layer[Storage], Biz logic Layer[Compute], Presentation Layer[Networking])
Resiliency, Availabilty, Scalaility, and Disaster Recovery
Security
Capacity planing and Cost Optimization
Deployment, Monitoring and Alerting, and Incident Response
比如說目標是承受同時在線 10萬人，要思考的是設計出來的系統架構可以乘載同時 10萬人的 request量；設計出來的架構是否有彈性與擴充性，遇到災難是要如何進行快速的復原；要如何確保系統的Security，像是密碼一定要做 hash之類；使用量一年會產生多少 cost 是否有 plan ?；最後是如何進行 deployment ? 如何監控線上的環境與機器服務，如何第一時間知道使用者出問題，出問題時要如何處理 ?
為了讓同學們有更好的理解，導師也分享過去工作上架構設計的專案與跟同學說明為什麼這樣設計(原由)，也提醒同學簡報技巧也是重要的技能之一，當我們想要說服老闆使用或引入新架構時，從老闆的角度來出發像是思考老闆可能最關注的點像是會增加多少預算、會帶來多少效益以及瓶頸會在那裡跟如何解決，節省老闆的時間也讓決策者方便快速做決策。
Business/Product Methodology
最後導師補充一些與 PM 比較相關的觀念，希望同學在鑽研技術之餘，多去了解或學習一些常用商業模型對架構設計也是有幫助的，由於這領域自己不太熟悉因此在介紹時會加上 wiki 連結介紹，讓有興趣的朋友請自行點擊深入了解，若對於方法論內容理解有錯歡迎糾正。
AARRR
AARRR 模型是一個有名的方法論，每個英文單字都代表指標分別是Acquisition、Activation、Retention、Revenue以及Referral，主要是在談怎麼樣獲取用戶，在導師介紹完模型的說明讓我想起(後知後覺)待過的T社部門職責分工相似，部門分別負責特定指標，公司為了協助達標每個部門都有自己的RD團隊來專心支援前線單位完成其指標，
Lean Startup
Lean Startup 精實創業 : 概念與 scrum 類似，當你今天有一個 idea 時候以最小可行產品(MVP)來實現，提早讓使用者來驗證 idea 想法是否有效，並在使用過程中加上 measure，再透過 measure 產生的 data 思考要如何調整 idea 讓它更好，試圖在 measure 的過程中尋找可能的商機(契機)。這方法論很常在創業的朋友討論中提到，在公司草創初期都希望在最短的時間找到可行的模式，早日度過黑暗期。
Scrum - Most Important is Value
Scrum 敏捷開發 是這幾年很紅的方法論，用小步快跑的方式快速提交最有價值的功能，網路上已經有非常多相關知識這不在多廢話。
另外導師還提到了像是 Steve Blank - Customer Development、Alexander Osterwalder - Business Model Canvas 與 Value Proposition 等方法論，但礙於大腦容量有極限且未接觸過，這就筆記下來日後有機會再自行研究。
心得
這是小組的第一次討論，組員分享自己的技能樹時聽到過去很多自己未接觸到的名詞，可以學到不同領域的知識感覺挺好的；在過去自己對於其守備範圍理解都是較為零碎的，可能是發現甚麼重要就盡力的去點滿其技能，在這次盤點 skill tree 的過程中才真正的去思考自己的目標(Goal)為何 ?自己希望哪些技能是應該具備的，對各技能的熟悉程度與目前還尚缺那些技能，這些資訊擁有之後或許可以訂為日後的長期目標，定期 review 自己完成百分比(自虐again)；在兩個半小時的討論過程中，導師也很熱心的與同學分享自己所了解知識與架構設計的經驗，也補充技術以外常見的幾個商業方法論，提醒大家偶爾可以跳脫技術學習不同的解決方案提升自己的商業思維；透過更多實作累積更多經驗，成為一位能夠真正解決問題不嘴砲的架構師。
參考
AARRR
Lean Startup 精實創業
Scrum 敏捷開發
The Four Steps to the Epiphany
Business Model Canvas
Value proposition
架構師的修練
深度剖析什么是 SLI、SLO和SLA？
SLOs, SLIs, SLAs, oh my - CRE life lessons
從零建立商業技術團隊
[ModernWeb2019] Taien - 高併發的道與術
HTTP-Request-Smuggling (pdf)
HTTP request smuggling
HTTP Request Smuggling (HTTP 請求走私)
軟體技術架構如何正確與商業需求快速對齊
Redis Console
