好文分享 — (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

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

追蹤新知

看完這篇文章了嗎?還意猶未盡的話,追蹤粉絲專頁吧!

我們每天至少分享 1 篇文章/新聞或者實用的軟體/工具,讓你輕鬆增廣見聞提升專業能力!如果你喜歡我們的文章,或是想了解更多特定主題的教學,歡迎到我們的粉絲專頁按讚、留言讓我們知道。你的鼓勵,是我們的原力!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!