SRE — 工具與自動化
- 定義自動化
- 自動化聚焦處
- 自動化類型的層級
定義自動化
對SRE而言，自動化是一種能力增幅器，但不是萬靈丹。但自動化還是能給予SRE的效益有:
- 一致性 — 因為機器重複作業能達成的一致性比人類還高
- 一個可以建構、重複使用、能擴充的平台
- 更快的行動，更快的修復-例如一種能自我診斷與修復的系統
- 節省時間
- 解決一些問題 — 如減低過勞、優化SLO
而進行自動化需要:
- 適合組織的工具
- 技術時間的研究與投入
- 可衡量的結果
自動化聚焦處
下圖為一個典型DevOps交付流水線。如圖我們都知道的，這一類的交付流水線應該是要自動化的(除了最後一步進到Production)。
由SRE所主導的服務自動化則會在此交付流水線的幾個Stage由SRE負責建立其環境(如下圖)，通常會使用到IaC與CaC。IaC與CaC能帶給我們環境的一致性與合規性。自動化作業由「維運」主導（左移），可確保可靠性工程優先等級。
使用IaC與CaC來建立環境
所有的代碼都應該儲存在一個Central repo，以便是需求重建環境。
要使用IaC(Infrastructure as Code)與CaC(Configuration as Code)這一類的實踐，我們就需要工具，IaC與CaC的聚焦處在於:
IaC聚焦於Server/Networks/storage這一類的基礎設施。可用的工具有Terrasform/AWS CloudFormation/Azure Resoure manager等。
CaC則聚焦於Software/Dependencies/containers。可用的工具有CHEF/Ansible/Puppet等。
在生產環境的自動化功能性與非功能性測試
SRE通常也需要對生產環境進行測試，包含功能性與非功能性而且是自動化的。而測試日誌都會存放流水線日誌中。
自動化功能性測試(Extend build pipeline)的工具有Selenium/Cucumber/Jasmine/Mocha/Zephyr/Mockito。
自動化非功能性測試的工具有Jmeter/Sonatype/Nexus/Lifecycle/SoapUI/WhiteSource/Veracode/Nagios。
用於部署系統組件的版本化與簽章的工件(Artefacts)
版本化與簽章過的工件確保我們佈署的組件是"正確且安全的"。
工件的版本化需要具有語意，也就是團隊看得懂的並且是帶有組織規則的。可用的工具有Nexus/Artifactory。而對工件使用簽章是為了安全性與可被稽核，可用的工具有Nexus/Artifactory。
量測工具到位以使服務具觀測性
我們需要考量到的有
- SLI — 要看到甚麼呈現出來。工具有OpsGenie
- 量測工具 — 提供額外的資料與分析。工具有Nagios/Dynatrace/AppDynamics/Prometheus
- 日誌檔案 — 聚合資料以供查閱。工具有Splunk/LogStash
概述了未來的成長範圍
針對未來服務的成長，我們需要考量的有:
- Autoscaling — 這要在對的地方發生。可用工具有AWS Auto Scaling/K8s Pod Scaling等
- 管理活動 — 這需要能夠自動化。
- 資料庫 — 這需要有擴展能力。如AWS RDS，NO-SQL例如MongoDB等
清楚的反脆弱策略
我們的服務要能夠有反脆弱的特性來增加系統的韌性。需要考量的有:
- DR(Disaster Recovery) — 這需要完整的測試。通常使用演習的進行
- 混沌工程(Chaso engineering) — 這需要實際演練過。可以用Chaso Monkey來進行
- On-Call機制 — 要到位。工具有PagerDuty/VictorOps/Squadcast
自動化類型的層級
我們以DB為例
層級1 : 沒有自動化
主要資料庫如果發生問題需要手動進行處理
層級2: 外部維護的”特定位置”自動化
當發生問題時，在SRE的個人電腦中有用來做failover的腳本可以拿來用
層級3: 外部維護的”通用”自動化
當發生問題時，SRE 將該腳本放在一個可以支援資料庫的一個系統中。讓該腳本變成通用的，當出現問題時每個人都會使用該腳本
層級4: 內部維護的”特定位置”自動化
failover腳本放置在資料庫系統本身之中
層級5: 不用人為介入的
資料庫注意到自己發生了問題。並且將自己執行failover腳本
自動化的安全
自動化移除了人為錯誤(或者是內賊的故意破壞)與強化了服務的安全。我們可以確保流水線中的自動化程序安全，但我們無法證明確保人工作業的程序安全。
自動化可以驗證和檢查流水線中產生和使用的工件是否符合要求。而DevSecOps 會將安全性引入建置/測試/部署的生命週期以確保整個交付流水線是安全的，而SRE則會聚焦於生產環境的安全。
保護構建流程
擁有正確的配置管理在組織的合規中佔了很大的重要性。保護我們的build流程透過以下方式進行:
- 應用程式、基礎設施和配置代碼變更透過檢查安全性問題的代碼分析工具進行
- 對建置工件進行數位簽章可避免出現「假」代碼的可能性
- 具有存取控制的安全代碼儲存庫
- 根據團隊/部門的回饋公開性地完成編碼
保護測試流程
世界上唯一真正安全的系統是拔掉插頭的系統。但即便如此，我們也不要用我們的職涯去賭。所以我們要做的事是優化其安全性:
- 當基礎設施或配置發生變更時，測試環境不會變動，它們是「不可變的immutable」並被建立時，保證並符合代碼儲存庫的合規性
- 我們將工程師建置的工件安全性部署到我們的測試環境中
- 為測試安全性而建構的測試資料和測試場景
保護Staging環境
Staging環境就像模擬一樣 — — 充其量是對生產環境的模仿，並且可能是最糟糕的確認偏誤形式。這是因為生產環境的資料在不斷變動並且持續與使用者互動。而Staging環境應該是不可變的。
相同的工件會被佈署到Staging/Pre-pord環境中，當我們導入類似與生產環境的資料時也同時導入了資料的安全性(例如GDPR or PCI)。所以在這一類的環境中持續的掃描來照出安全弱點是必要的。Staging環境與其他服務的相依姓與整合也可能帶來安全弱點，有時利用proxy這一類的機制可以減緩其弱點。
