站點(diǎn)可靠性工程 (SRE) 和 DevOps 是兩個密切相關(guān)的 IT 實踐，可幫助團(tuán)隊創(chuàng)建更好的軟件。無論您是開發(fā)人員還是高層管理人員，了解這兩種做法之間的差異（以及它們重疊的地方）將有助于您創(chuàng)建和維護(hù)高質(zhì)量的軟件。

這篇文章解釋了SRE 和 DevOps 之間的異同。我們深入研究這兩種做法。他們的優(yōu)勢、日常任務(wù)和首選工具，以解釋他們在軟件開發(fā)生命周期 (SDLC)中的不同角色，并幫助您評估哪些值得添加到團(tuán)隊的日常運(yùn)營中。

什么是 SRE？

站點(diǎn)可靠性工程 (SRE) 是一組實踐，使團(tuán)隊能夠通過軟件工程自動執(zhí)行重復(fù)的 IT 操作任務(wù)。SRE 自動化耗時的工作（代碼部署、事件響應(yīng)、生產(chǎn)管理等），同時提高DevOps 基礎(chǔ)設(shè)施的可靠性。

SRE 背后的主要思想是，使用軟件來自動化 IT 系統(tǒng)的監(jiān)督是一種比手動執(zhí)行所有操作更具可擴(kuò)展性、成本效益和可持續(xù)性的策略。其他基本的 SRE 原則是：

• 開發(fā)按預(yù)期運(yùn)行的最簡單的系統(tǒng)。
• 接受沒有零風(fēng)險這樣的事實，因此避免追求不必要的可靠性。
• 從一開始就計劃停機(jī)時間、網(wǎng)絡(luò)延遲和可擴(kuò)展性風(fēng)險。
• 爭取最大的系統(tǒng)可觀察性。
• 使團(tuán)隊能夠以一致、穩(wěn)定和可重復(fù)的方式構(gòu)建和部署軟件。

SRE 彌合了開發(fā)和 ITOps 團(tuán)隊之間的差距，賦予兩個部門權(quán)力：

• 開發(fā)人員可以盡快將新軟件投入生產(chǎn)。
• ITOps 了解到新部署符合公司的服務(wù)水平協(xié)議 (SLA)。

SLA 是 SRE 中的一個關(guān)鍵因素，因為這些數(shù)字設(shè)定了可接受的正常運(yùn)行時間和響應(yīng)時間的基準(zhǔn)。其他重要的 SRE 指標(biāo)是：

• 服務(wù)級別目標(biāo) (SLO)：這些指標(biāo)跟蹤系統(tǒng)的服務(wù)級別（例如可用性或恢復(fù)時間）并確保您滿足基于 SLA 的期望。
• 服務(wù)水平指標(biāo) (SLI)：?SLI 使團(tuán)隊能夠評估系統(tǒng)是否滿足其 SLO。錯誤率和系統(tǒng)吞吐量是 SLI 的典型示例。
• 錯誤預(yù)算：該指標(biāo)規(guī)定了系統(tǒng)在不違反其 SLA 的情況下可以停機(jī)或運(yùn)行不佳的最長時間。錯誤預(yù)算與RTO類似，但 SRE 團(tuán)隊更主動地使用錯誤預(yù)算（通常用于決定何時將更新推送到生產(chǎn)環(huán)境）。

SRE解決什么問題？

SRE 幫助公司解決 IT 運(yùn)營和軟件開發(fā)中常見的一系列問題。以下是最值得注意的：

• 無法滿足公司 SLA 設(shè)定的 IT 標(biāo)準(zhǔn)。
• 想要將新軟件發(fā)布到生產(chǎn)環(huán)境中的開發(fā)人員與不想導(dǎo)致操作問題的 ITOps 之間的關(guān)系過于緊張。
• 難以識別和解決性能問題和瓶頸。
• 上限或低效的可擴(kuò)展性。
• 頻繁的服務(wù)停機(jī)和過多的計劃外停機(jī)。
• 缺乏系統(tǒng)或服務(wù)的可觀察性（本地或云端）。
• 慢速 MTTR（平均恢復(fù)時間，團(tuán)隊從系統(tǒng)故障中恢復(fù)所需的平均時間）和 MTTD（平均檢測時間，從事件開始到團(tuán)隊發(fā)現(xiàn)問題的平均時間）。
• 配置基礎(chǔ)設(shè)施的問題。
• 缺乏有效的事件響應(yīng)計劃或災(zāi)難恢復(fù)策略。
• 低效或不可靠的部署流程。
• 缺乏可用性管理的結(jié)構(gòu)化方法。
• 軟件開發(fā)過程中有太多容易出錯的手動過程。
• 難以識別和主動緩解安全漏洞。
• 無法滿足合規(guī)需求。
• 使用云計算服務(wù)或基礎(chǔ)設(shè)施的問題（或者僅僅是因為云賬單過于昂貴）。

SRE 職責(zé)

每家公司都會讓他們的 SRE 專家承擔(dān)不同的職責(zé)，但您會在每個團(tuán)隊中找到一些職責(zé)。以下是最常見的 SRE 任務(wù)列表：

• 使用服務(wù)器自動化來簡化重復(fù)且耗時的任務(wù)（部署服務(wù)器、設(shè)置軟件、運(yùn)行網(wǎng)絡(luò)安全檢查等）。
• 定義和實施系統(tǒng)和服務(wù)的可靠性要求。
• 衡量可靠性目標(biāo)（SLA、SLI、SLO 和錯誤預(yù)算）。
• 幫助開發(fā)人員構(gòu)建和部署高度可用、可擴(kuò)展和容錯的軟件。
• 做出有關(guān)部署新功能或應(yīng)用程序的數(shù)據(jù)驅(qū)動決策。
• 執(zhí)行容量規(guī)劃以預(yù)測未來的資源需求并確保系統(tǒng)處理不斷增加的流量或數(shù)據(jù)。
• 向上擴(kuò)展系統(tǒng)以確保最佳性能或向下擴(kuò)展以降低費(fèi)用。
• 跟蹤系統(tǒng)的性能和可用性。
• 不斷尋找改進(jìn) IT 流程和程序的方法。
• 改進(jìn)事件響應(yīng)計劃，以最大限度地減少故障的影響，并在危機(jī)時刻快速恢復(fù)服務(wù)。
• 執(zhí)行事后審查以確定故障的根本原因并防止將來發(fā)生類似事件。
• 開發(fā)（或監(jiān)督創(chuàng)建）系統(tǒng)文檔。

SRE 的好處

以下是采用 SRE 帶來的所有優(yōu)勢的概述：

• 提高系統(tǒng)和服務(wù)的正常運(yùn)行時間和可用性。
• 更好的應(yīng)用可擴(kuò)展性和性能。
• 更快、更可靠、更安全的軟件交付。
• 重復(fù)性任務(wù)和流程的自動化。
• 更多容錯服務(wù)，故障更少（影響更?。?。
• 生產(chǎn)中的錯誤明顯減少。
• 更好地了解服務(wù)運(yùn)行狀況。
• 整個 SDLC 中出現(xiàn)人為錯誤的可能性較?。由祥_發(fā)人員有更多時間進(jìn)行創(chuàng)新）。
• 深入了解產(chǎn)品生態(tài)系統(tǒng)（開發(fā)、測試、階段和生產(chǎn)）。
• 全面提高安全性（事件預(yù)防、災(zāi)難恢復(fù)計劃、風(fēng)險緩解、最新安全實踐、更多冗余等）。
• 更短的 MTTR 和 MTTD。
• 在事件發(fā)生時識別根本原因的更多上下文。
• 提高客戶滿意度和保留率。
• 由于更少的停機(jī)時間、更好的可擴(kuò)展性和資源的最佳使用，降低了運(yùn)營成本。
• 更好地控制和使用技術(shù)債務(wù)。

SRE 工具

SRE 團(tuán)隊依靠各種工具來自動化流程和管理系統(tǒng)。以下是您可能會在任何 SRE 工具堆棧中找到的內(nèi)容：

• 性能優(yōu)化工具：這些平臺幫助 SRE 團(tuán)隊識別和解決軟件系統(tǒng)中的性能瓶頸。Apache JMeter 和 LoadRunner 是最受歡迎的選項。
• 配置管理工具：?SRE 專家使用這些平臺來自動化基礎(chǔ)設(shè)施的供應(yīng)和配置。Terraform、Ansible、Puppet、Pulumi和 Chef 是最常見的選項。
• 監(jiān)控和日志記錄工具：這些平臺跟蹤軟件系統(tǒng)的性能和可用性。首選 SRE 監(jiān)控工具是Prometheus和New Relic，而Elasticsearch和Kibana是流行的日志記錄解決方案。
• 事件管理工具：?SRE 團(tuán)隊使用這些平臺來最小化故障的影響（包括對最終用戶和公司財務(wù)的影響）。PagerDuty、VictorOps 和 OpsGenie 是三個常見的選擇，而 OP5、PageDuty 和 xMatters 是首選事件警報工具。
• 容器化工具：這些平臺使團(tuán)隊能夠?qū)④浖虬饺萜髦校萜魇强梢浦驳拇a包，可以在任何環(huán)境中無縫運(yùn)行。Kubernetes、Rancher 和 Portainer是行業(yè)標(biāo)準(zhǔn)，Docker Swarm也享有相當(dāng)大的追隨者。
• 安全工具：這些平臺確保系統(tǒng)安全并符合標(biāo)準(zhǔn)和法規(guī)。一些常見的 SRE 安全工具是 Nessus、OpenVAS 和 Wireshark。
• 項目規(guī)劃和管理工具：?SRE 部門使用這些工具來協(xié)調(diào)職責(zé)并創(chuàng)建統(tǒng)一的信息源。大多數(shù)團(tuán)隊都依賴于 Jira 和 Confluence 的組合。

什么是 DevOps？

DevOps 是一組實踐和原則，使公司能夠縮短 SDLC 并提高代碼質(zhì)量。使用 DevOps，編寫代碼的團(tuán)隊還負(fù)責(zé)在生產(chǎn)中維護(hù)它，而負(fù)責(zé)后期制作職責(zé)的員工也參與開發(fā)。

DevOps 改進(jìn)了軟件開發(fā)的文化和組織方面。以下是該方法的主要目標(biāo)：

• 打破軟件開發(fā) (Dev) 和 IT 運(yùn)營 (Ops) 團(tuán)隊之間的孤島。
• 確?？焖侔l(fā)布穩(wěn)定、安全的軟件。
• 減少團(tuán)隊從構(gòu)思到代碼部署所需的時間。
• 提高軟件的整體質(zhì)量。

在日常實踐中，DevOps 遵循精益或敏捷方法論。以下是 DevOps 的主要原則：

• 確保開發(fā)和 ITOps 團(tuán)隊的任務(wù)重疊。
• 接受失敗并快速失?。ǖ肋h(yuǎn)不要重復(fù)同樣的錯誤兩次）。
• 通過小的增量更新逐步引入更改，而不是將大量更改部署到生產(chǎn)中。
• 爭取更頻繁地發(fā)布。
• 使用自動化來加速 DevOps 管道并最大限度地減少容易出錯的手動任務(wù)的數(shù)量。
• 持續(xù)衡量成功（一些典型的DevOps 指標(biāo)是更改的提前期、部署頻率、恢復(fù)服務(wù)的時間和更改失敗率）。

DevOps 解決什么問題？

DevOps 解決了大型軟件開發(fā)團(tuán)隊和項目中常見的各種問題。以下是推動公司轉(zhuǎn)向 DevOps 的最常見問題：

• 新功能和更新的上市時間較慢。
• 軟件項目中有太多的誤解、代碼返工和延誤。
• 開發(fā)人員、IT 運(yùn)營團(tuán)隊成員和業(yè)務(wù)領(lǐng)導(dǎo)者之間的溝通效率低下。
• 模糊的軟件交付流程。
• 代碼質(zhì)量和應(yīng)用程序性能差。
• 表現(xiàn)不佳的開發(fā)團(tuán)隊。
• 不必要的高 IT 成本。
• 軟件漏洞太多。
• 不穩(wěn)定和錯誤的部署環(huán)境。
• 無效的軟件測試程序。
• 整個軟件交付過程中有太多耗時的手動任務(wù)。
• 開發(fā)和 ITOps 團(tuán)隊的員工保留率低。
• 新開發(fā)人員入職緩慢，以及開發(fā)人員離開公司時出現(xiàn)的問題。

開發(fā)運(yùn)營職責(zé)

DevOps 團(tuán)隊的確切職責(zé)因組織而異，但每個團(tuán)隊都執(zhí)行一些任務(wù)。以下是常見職責(zé)列表：

• 創(chuàng)建、維護(hù)和優(yōu)化軟件創(chuàng)建管道。
• 監(jiān)督從開發(fā)到生產(chǎn)的整個軟件開發(fā)生命周期。
• 組織沖刺（每周、每兩周或每月）以管理工作流程和分配任務(wù)。
• 創(chuàng)建和配置支持軟件交付過程的服務(wù)器、網(wǎng)絡(luò)和其他組件。
• 編寫腳本并使用工具來自動執(zhí)行構(gòu)建、測試和部署軟件等任務(wù)。
• 監(jiān)控錯誤并解決管道問題。
• 優(yōu)化應(yīng)用程序和服務(wù)性能。
• 識別并解決發(fā)展瓶頸。
• 設(shè)計、實施和領(lǐng)導(dǎo)災(zāi)難恢復(fù)策略。
• 跟蹤系統(tǒng)中的所有軟件和硬件組件。
• 確保系統(tǒng)安全并且所有團(tuán)隊都遵循DevOps 安全最佳實踐。
• 執(zhí)行混沌工程（一種故意“破壞事物”并監(jiān)控系統(tǒng)如何響應(yīng)壓力的策略）。

開發(fā)運(yùn)營的好處

以下是您在組織中采用 DevOps 的主要好處列表：

• 更快的上市時間。
• 更好地使 IT 項目與業(yè)務(wù)目標(biāo)保持一致（任何合理的IT 戰(zhàn)略計劃的核心）。
• 更高效的軟件開發(fā)團(tuán)隊。
• 提高軟件質(zhì)量，減少生產(chǎn)缺陷。
• 提高業(yè)務(wù)敏捷性和響應(yīng)市場變化的能力。
• 更穩(wěn)定的應(yīng)用程序和服務(wù)。
• 大規(guī)模有效部署和管理應(yīng)用程序的能力，使 IT 能夠跟上業(yè)務(wù)增長的步伐。
• 一個運(yùn)轉(zhuǎn)良好的、計劃好的軟件交付管道（從概念和開發(fā)到后期制作監(jiān)控和升級）。
• 更短的發(fā)布周期。
• 減少對手動任務(wù)的依賴。
• 改進(jìn)性能監(jiān)控和分析。
• 由于更好的應(yīng)用程序性能、更少的錯誤和更頻繁的更新，更快樂的客戶和最終用戶。
• 提高安全性并提高識別和解決軟件相關(guān)風(fēng)險的能力。
• 由于在 SDLC 期間重復(fù)性任務(wù)減少和人工干預(yù)需求減少，因此節(jié)省了 IT 成本。
• 始終追求改進(jìn)、優(yōu)化和創(chuàng)新的團(tuán)隊文化。

開發(fā)運(yùn)營工具

以下列出了組建有效的 DevOps 團(tuán)隊所需的工具類型：

• 源代碼管理工具：這些平臺使團(tuán)隊能夠跟蹤源代碼、跟進(jìn)問題并執(zhí)行代碼審查。最流行的工具是Git和 Mercurial。
• 容器化平臺：這些工具使工程師能夠創(chuàng)建在不同 IT 環(huán)境中無縫運(yùn)行的基于容器的應(yīng)用程序。兩種常用的解決方案是Kubernetes 和 Docker。
• CI/CD 工具：?CI/CD代表持續(xù)集成和持續(xù)交付，一種通過自動化頻繁向用戶交付更新的方法。流行的CI/CD 工具的例子有Jenkins、Bamboo 和 CircleCI，
• 配置管理工具：這些平臺使 DevOps 工程師能夠自動化與基礎(chǔ)架構(gòu)相關(guān)的任務(wù)，例如配置和維護(hù)。大多數(shù)團(tuán)隊使用 Ansible、Terraform 或 Puppet。
• 監(jiān)控工具：這些解決方案幫助 DevOps 團(tuán)隊監(jiān)控應(yīng)用程序并對故障和風(fēng)險做出及時響應(yīng)。Splunk、Nagios和 Raygun 是常見的選擇。
• 協(xié)作和規(guī)劃工具：團(tuán)隊間協(xié)作是 DevOps 的核心，因此每個團(tuán)隊都有一個或多個工具來集中信息和規(guī)劃項目。與 SRE 一樣，大多數(shù) DevOps 使用 Jira 和 Confluence。

SRE 比。DevOps：關(guān)鍵區(qū)別

SRE 和 DevOps 有很多相似之處（相同的工具、對自動化的強(qiáng)調(diào)、傳統(tǒng)上獨(dú)立團(tuán)隊之間的橋梁等），但這是兩種截然不同的實踐。

下表列出了 SRE 和 DevOps 之間的主要區(qū)別：

通過 SRE 或 DevOps（或兩者）將 IT 提升到一個新的水平

SRE 和 DevOps 是現(xiàn)代軟件開發(fā)的兩個基石實踐。雖然他們側(cè)重于 IT 的不同方面，但都致力于提高軟件產(chǎn)品的可靠性和質(zhì)量。選擇這兩種做法中的任何一種都不會出錯。另外，請記住 SRE 和 DevOps 并不相互排斥。如果您擁有足夠的資源和足夠的內(nèi)部人才，那么同時采用這兩種做法始終是一個值得做出的決定。