鐵人賽 系統維運 - Jian-Min-Huang/tech-note GitHub Wiki
前言
其實今天這篇，跟 DevOps 有很大的關係，因為系統維運不脫幾個面向，環境管理、版本升級、監控和告警。而他的難度其實也是隨著系統架構而提高，以前單體架構使用的軟體與工具如今在大型分散式系統顯得過時，於是又有許多眼花的撩亂的工具一個個冒出來，有些人覺得是負擔，但以這點來說我卻覺得很吸引人。
在長大之前
任何事情還是要總簡單的入手，你想想如果是一台 VM，一到多個 Tomcat，一切你都還能手動，雖然我不鼓勵，但環境手控、版本手控、監控告警裝個 nagios 和開個 jmx，的確是可行的方式。
那如果 VM 開始擴展，變成多台 VM，如果幾台內也許你還能手動，越疊越多，如果你還手動很明顯就是是不想睡覺了。於是 Infrastructure as Code (IaC) 相關的生態系開始紅起來，包含 Puppet、Chef 和 Ansible 這類工具讓你在預配置好的狀況下，可以直接控制操作多台 VM，所以概念單純，就是搞了一個工具把剛剛本來在單台做的事一次做到多台去。
長大之後
雖然說理論你家的業務長到一個程度就不會再長，所以很多人不會碰到大量水平伸縮的場景，更甚者，你家的業務是用幾台超強的機器搞垂直擴展就結束了。不過我們還是要來談談這個狀況會怎樣，基本上跟上面不會差多少，但因為數量級超過一個程度，除卻超大軟體巨頭，多半還是會選擇托管在雲端上面，而像是 AWS、GCP、Azure 還加上有自己的生態系與工具，整體管理起來會更方便。舉例來說 AWS EC2 配上 ELB 去因應流量做動態擴展，SLA 夠，服務齊備，是很成熟的作法。不過要注意到一個重點就是這個維度還是以 VM 為主。當然我這邊少講一個輕鬆簡單的解，就是用 PAAS，有興趣的人可以參考 AWS Elastic Beanstalk 和 Google App Engine 等等。
再來是 K88888888s，其實概念跟上面一樣，但目標從 VM -> Container，所以雖然我們主戰場換成 K8s，但我必須說大家不要怕！以前我們做的事還是要做，只是他幫你做了，理論上你應該開心而不是害怕。不過因為架構的不同，所以周邊生態系跟工具又跟著變化，環境用 K8s 相關工具、版本用一些先進的手法 (金絲雀或是灰度發佈)，日誌指標監控告警可以選擇像現在火紅的 efk stack、prometheus、grafana 或是一些整合好的工具 datadog、zabbix、splunk 等等。
感覺無窮無盡，名詞框架如雨後春筍般的一個個冒出來，但這行就是這樣，大家一起加油吧！
About Me
Jian-Min Huang
wide range skill set backend engineer
Research, Architecture, Coding, DB, Ops, Infra.
mainly write Java but also ❤️ Scala, Kotlin and Go