好文分享 — (Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup

這是 1 篇集作者 4 年創業經驗寫成的文章，該文章羅列作者「推薦」與「不推薦」的各種軟體服務，包含 AWS, GCP, Terrafrom, DataDog, JIRA, PagerDuty 等等，還有一大堆我根本沒接觸過的好服務，相當有參考價值！

作者分享的一些經驗甚至跟我先前工作的經驗相符合，作為讀者的我很有既視感，仿佛那些光怪陸離的事又重演了一遍XD

例如：

1. AWS 體驗上會比 GCP 來得好，GCP 給人的感覺確實很像拼裝車，某些改版的體驗也沒有 AWS 來得在乎客戶的感受，例如 AWS 比較少會遇到不相容的改版問題。
2. AWS premium support 很貴！沒有十分必要的話，可以不用考慮⋯⋯。
3. DataDog 好用但是很貴！如果你有成本考量，或者你的服務 instance 經常增加，那麼最好是考慮其他方案⋯⋯。
4. JIRA 太肥了！個人與其他朋友都有類似感受，不是覺得不好用，就是覺得使用上不順手，該文作者使用的是 linear 取代 JIRA, 我個人則是覺得 Asana 體驗比 JIRA 好。
5. Helm, Flux, Terraform, External Secrets, External DNS 這些都是對 K8s 相關的基礎建設蠻有用的工具，個人在先前的工作經驗就遇過 Helm, Flux, Terraform 。
6. PagerDuty, 沒人喜歡 on call, 不過如果你需要有制度的 on call 管理的話， PagerDuty 大概是首選。

其他還有一些作法蠻值得學習的：

1. 盡量別多個服務共享資料庫，出事情時很難迅速找出是哪個資料庫有問題，另外是每多 1 個服務，資料庫的負載就會增加，還有諸多管理上的問題，使得共享資料庫是 1 種對長期不好的做法。
2. 團隊效率優先於外部需求，千萬別讓你的員工覺得當你的客戶比當員工好⋯⋯。
3. 每月要開支出審視會議，如果你不重視這件事，成本就會跟沒有韁繩的馬一樣不受控，個人就曾遇過三不五時來自上層要求要降成本的要求，可是問題在於開發團隊都被迫將速度與高層需求放在優先層級，沒有將成本控制放進開發思維/文化內的話，這種事就會持續發生。
4. 善用事後剖析(post-mortem)樣板。事後剖析是事故(incidents)後很重要的步驟之一，主要目的是為了避免類案再次發生，而不是為了找戰犯（雖然很多管理階層是為了找戰犯，最後傷害團隊士氣與向心力）；不過，事後剖析這件事可以不用自己發想整個流程，可以用 PagerDuty 所提供的樣板作為基礎框架，然後改成適合你們團隊的樣子，作者也很明確指出 PagerDuty, DataDog 的 post-mortems 功能很難客製，不如用 Notion 或者其他工具比較好。

以上，這是 1 篇很有價值的好文章，推薦！

(Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup