一千萬個為什麽

搜索

傳統的開發和運營模式與現場可靠性工程之間有什麽區別?



“當你請軟件工程師設計一個運營團隊時,SRE會發生什麽。” - Site Reliability Engineering a>

由於 Google的網站可靠性工程手冊發布後,不止一次,我被告知SRE是現有運營或應用支持模式的延伸。

我們有幾個問題來定義Sys之間的差異。管理員,DevOps工程師和現場可靠性工程師:

但是,這些問題或答案都不能描述系統管理員和站點可靠性工程師之間的區別

從更廣泛的角度來看:谷歌的Site Reliability Engineering實踐與業務中傳統的分離式開發和運營職能之間的關鍵區別是什麽?

轉載註明原文: 傳統的開發和運營模式與現場可靠性工程之間有什麽區別?

一共有 1 個回答:

值得慶幸的是,由於網站可靠性工程是在Google內部開發的,直到最近才開始進入更廣泛的社區,它的定義非常明確。然而,什麽不是是web操作(或者“系統管理” - 作為一個不清晰的例子,你在你的問題中使用了這兩個)。當你不完全確定它們是什麽時,很難討論兩件事之間的差異。

但我是一個喜歡冒險的人,所以我會給它一個機會。


在非常傳統的商店中,開發人員和系統管理員彼此相隔甚遠。開發人員構建一個應用程序,然後在他們的代碼被提交後盡快完成他們的工作。系統管理員將構建工件(可能只是代碼,如果它是解釋型語言)並將其部署到生產服務器。系統管理員的工作是讓應用程序順利運行,並且通常管理生產環境。但是,性能問題往往來自應用程序中的架構問題;系統管理員沒有編程知識來知道應用程序在做什麽,開發人員不知道應用程序如何在具有生產流量的生產拓撲中發揮作用,因此沒有人自行配備來解決問題。

此外,開發人員通常會判斷他們能夠快速生成新功能的速度,而系統管理員則根據應用程序在生產中的頻繁程度來判斷。由於變革是導致破產的主要原因之一,這使得兩個部門相互抵觸 - 這是一個傷害企業和相關人員的老對手。

在某些時候,一些以開發人員為中心的公司得到了對此感到惱火,他們開始練習“NoOps” - 他們取消了他們的運營部門以及隨之發現的障礙。實際上,這意味著開發人員扮演了操作角色,但保持了他們的舊職稱。

圍繞NoOps的討論中,John Allspaw,當時任Etsy技術運營副總裁,以及<�通過以下方式在Etsy中定義角色:http://www.ibm.com/developerworks/cn/webservices/default.asp?ht =“http://rads.stackoverflow.com/amzn/click/1449377440”rel =“noreferrer”>受人尊敬的Web操作手冊,

Etsy Operations is responsible for:

  • Responding to outages, takes on-call
  • Alerting systems thresholding, design
  • Architecture design and review
  • Building metrics collection
  • Application configuration
  • Infrastructure buildout/management

Etsy Development is responsible for:

  • Responding to outages, takes on-call
  • Alerting systems thresholding, design
  • Architecture design and review
  • Building metrics collection
  • Application configuration
  • Shipping public-facing code

Neither of those lists are comprehensive, I'm sure I'm missing something there. While Etsy Ops has made production-facing application changes, they're few but real (and sometimes quite deep). While Etsy Dev makes Chef changes, they're few but real. If there's so much overlap in responsibilities, why the difference, you might ask? Domain expertise and background. Not many Devs have deep knowledge of how TCP slow start works, but Ops does. Not many Ops have a comprehensive knowledge of sorting or relevancy algorithms, but Dev does. Ops has years of experience in forecasting resource usage quickly with acceptable accuracy, Dev doesn't. Dev might not be aware of the pros and cons of distributing workload options across all layers1-7, maybe only just at 7, Ops does. Entity-relationship modeling may come natural to a developer, it may not to ops. In the end, they both discover solutions to various forms of Byzantine failure scenarios and resilience patterns, at all tiers and layers.

在他的世界裏,開發人員和操作工程師的高級技能和責任非常相似;他們的專長不同。他們不同的專業鼓勵他們共同努力解決問題,他們共同的基本技能為他們提供了一種語言。

這通常是我在大多數情況下著陸的網絡操作的定義。所以這是我們要繼續的一個。


那麽,什麽是站點可靠性工程?

Google SRE書籍以SRE的定義開頭......然後是另一個...然後花一章繼續定義角色和整本書,涵蓋具體內容。即使在一個組織中發展起來,似乎也難以將工作壓縮成一個單一的商定定義。

首先,我們需要回到2003年,當時Be​​n Traynor加入谷歌並成立了第一個Site Reliability Engineering團隊。回想一下,在幾段前我們是在2010年初;但在2003年,該行業仍然將系統管理員/開發人員之間的鴻溝視為事情的自然方式。所以當Ben說SRE是一個軟件工程師創建一個運營團隊會發生什麽時,這是一個比現在更加激進的兩個世界融合。

前言中給出的定義分別強調三個詞的每一個:

  • Engineering - the use of computer science and engineering concepts to solve problems
  • Reliability - a focus on making systems more scalable, more reliable, and more efficient
  • Service - the later evolution of "site", emphasizing that SREs are responsible for networked services

介紹章節列出了站點可靠性工程的原則:

  • Ensuring a durable focus on engineering - taking pre-emptive action to avoid frequent pages and other "toil"
  • Persuing maximum change velocity without violating a service's SLO - a subject that can easily have its own several-hundred word answer, but roughly summarized as helping developers make changes, as long as they don't cause too many issues
  • Monitoring - automatic alerts when things go wrong
  • Emergency response - fixing things when they're broken
  • Change management
  • Capacity planning
  • Provisioning
  • Efficiency and performance - ensuring that a service performs at an expected level - bottlenecking hurts users, but excess capacity costs money

我將“站點可靠性工程”歸類為現代Web操作的一個專門子集。 SRE組織非常專註於自動化所有事情,這在相當大的公司中只有成本效益。像錯誤預算這樣的想法只能在您的服務有很多請求時才會起作用,否則就會失去粒度(對於較小的服務,特定的錯誤可能會影響您的請求的0-20%,具體取決於分鐘)。 SRE定義中缺少安全性等相關領域,因為擁有真正SRE團隊的公司都有專門的安全團隊。

Google定義的SRE程序是針對Google的特定需求開發的Web操作程序,並不一定適用於其他地方。

然而,Site Reliability Engineering最近在更廣泛的行業使用中不斷擴大。我目前的職位是SRE,盡管我在一家規模小得多的公司工作,我的工作描述非常適合John Allspaw的2012年Etsy網絡操作定義。我的理論是,我們一直在通過標題作為支持單個領域演變的簡寫:

  • 我們以系統管理員
  • 開頭
  • 然後,隨著網站變得更加“重要”,招聘信息開始引用網絡運營工程師來區分專門從事網絡工作的系統管理員和處理普通辦公室IT的系統管理員。
  • 然後, DevOps 應該將那些願意使用編程以減少網絡操作工作負載的人分開。
  • 但是,由於DevOps被缺乏明確定義混淆,我們采用了站點可靠性工程指定我們正在尋找呼叫中支持生產服務的人員。

那麽系統管理員和SRE有什麽區別?他們獲得冠軍的年份。傳統操作和站點可靠性工程有什麽區別? SRE只是使用新工具的最新版本(使用新工具(hello,containers!)),並且隨著網絡程序越來越大,越來越重要,越來越關註允許一名工程師執行的實踐 。 >。