基於聊天討論
最近，關於 DevOps 和 SRE 的定義爆發了真正的爭論。
儘管事實上，從很多方面來說，關於這個主題的討論已經讓我（包括我自己）感到緊張，但我決定將我對這個主題的看法帶到哈布拉社區的法庭上。 有興趣的朋友，歡迎關注貓。 並讓一切重新開始！
底
因此，在古代，軟體開發人員和伺服器管理員團隊是分開居住的。 第一個成功地編寫了程式碼，第二個對第一個使用了各種熱情、深情的話語，設定了伺服器，定期與開發人員聯繫並收到全面的回應「一切都在我的機器上運行」。 業務正在等待軟體，一切都閒置了，定期出現故障，每個人都很緊張。 尤其是那個為這一切亂七八糟買單的人。 輝煌的燈時代。 好吧，您已經知道 DevOps 從何而來。
DevOps 實踐的誕生
然後嚴肅的人過來說——這不是一個行業，你不能那樣工作。 他們引入了生命週期模型。 例如，這裡是 V 模型。
那我們看到了什麼？ 企業有了一個概念，架構師設計解決方案，開發人員編寫程式碼，然後就失敗了。 有人以某種方式測試產品，有人以某種方式將其交付給最終用戶，而在這個奇蹟模型的輸出的某個地方，坐著一位孤獨的商業客戶，等待著海邊承諾的天氣。 我們得出的結論是，我們需要能夠建立這個流程的方法。 我們決定創建實踐來實施它們。
關於實踐是什麼的抒情題外話
我所說的實踐是指科技與紀律的結合。 一個例子是使用 terraform 程式碼描述基礎架構的實務。 紀律是如何用程式碼描述基礎設施，它在開發人員的腦海中，而技術就是地形本身。
他們決定將其稱為 DevOps 實踐 - 我認為他們的意思是從開發到營運。 我們想出了各種聰明的辦法——CI/CD 實踐、基於 IaC 原則的實踐，數以千計。 接下來，開發人員編寫程式碼，DevOps 工程師將程式碼形式的系統描述轉換為工作系統（是的，不幸的是，程式碼只是一個描述，而不是系統的體現），交付繼續，等等。 昨天的管理員掌握了新的實踐，自豪地接受了 DevOps 工程師的再培訓，一切都從那裡開始。 有晚上，也有早晨……抱歉，不是從那裡開始的。
感謝上帝，一切不再美好
一切一平靜下來，各種狡猾的「方法論者」開始寫厚厚的關於DevOps實踐的書籍，關於臭名昭著的DevOps工程師是誰、DevOps是一種生產文化的爭議又悄然爆發，不滿情緒再次出現。 突然發現軟體交付絕對是一項不平凡的任務。 每個開發基礎設施都有自己的堆疊，在某個地方你需要組裝它，在某個地方你需要部署環境，這裡你需要Tomcat，這裡你需要一種狡猾而複雜的方式來啟動它——總的來說，你的頭很暈。 奇怪的是，問題主要出在流程的組織上──這種交付功能就像瓶頸一樣，開始阻礙流程。 此外，沒有人取消行動。 在V模型中看不到，但右側仍然有整個生命週期。 因此，有必要以某種方式維護基礎設施、監控監控、解決事件以及處理交付。 那些。 一隻腳同時涉足開發和運營 - 突然變成了開發和運營。 然後是對微服務的普遍炒作。 有了他們，本地機器的開發開始轉移到雲端——嘗試在本地調試一些東西，如果有數十個、數百個微服務，那麼持續交付就成為一種生存手段。 對於一家「規模不大的公司」來說這還可以，但仍然如此嗎？ 谷歌呢？
Google 的 SRE
Google來了，吃了最大的仙人掌並決定 - 我們不需要這個，我們需要可靠性。 並且必須管理可靠性。 我決定我們需要能夠管理可靠性的專家。 我稱他們為SR工程師，並說，就這樣吧，照常做好吧。 這裡是 SLI，這裡是 SLO，這裡是監控。 他還涉足營運。 他稱之為「可靠的 DevOps」SRE。 一切似乎都很好，但谷歌可以承受一個骯髒的黑客攻擊——對於 SR 工程師的職位，僱用那些合格的開發人員，並且做了一些功課並了解工作系統的功能。 而且，谷歌本身在僱用這樣的人方面也存在問題——主要是因為它在這裡與自己競爭——有必要向某人描述業務邏輯。 交付被分配給發布工程師，SR——工程師管理可靠性（當然不是直接管理，而是透過影響基礎設施、改變架構、追蹤變化和指標、處理事件）。 不錯，你可以 。 但是，如果您不是 Google，但可靠性仍然是一個問題怎麼辦？
DevOps 理念的發展
就在此時，Docker 出現了，它是從 lxc 發展而來的，然後是 Docker Swarm 和 Kubernetes 等各種編排系統，DevOps 工程師長嘆了一口氣——實踐的統一簡化了交付。 它將其簡化到了甚至可以將交付外包給開發人員的程度——什麼是deployment.yaml。 容器化解決了這個問題。 CI/CD 系統的成熟度已經達到了編寫一個文件就可以了——開發人員可以自己處理。 然後我們開始討論如何與…或至少與某人一起創建我們自己的 SRE。
SRE 不在 Google 上
好吧，好吧，我們交付了交付，似乎我們可以鬆口氣，回到過去的美好時光，當時管理員觀察處理器負載，調整系統，並安靜地從杯子裡啜飲一些難以理解的東西…停下來。 這不是我們開始一切的原因（這很遺憾！）。 突然發現，在Google的方法中，我們可以輕鬆地採用優秀的實踐——重要的不是處理器負載，也不是我們更換磁碟的頻率，也不是優化雲端中的成本，但業務指標同樣臭名昭著。SLx 。 沒有人從他們手中取消基礎設施管理，他們需要解決事件、定期值班，並且通常掌握業務流程。 夥計們，開始一點一點地編程，達到一個好的水平，Google 已經在等著你了。
總結一下。 突然，你已經讀膩了，迫不及待在文章評論中吐槽寫信給作者。 DevOps 作為一種交付實踐一直如此，將來也將如此。 而且它不會去任何地方。 SRE 作為一組操作實踐使這種交付非常成功。
來源： www.habr.com