集中運維與分散運維的比較 - thenewstack

banq發表於2021-11-10
運維

集中操作與分散操作的概念早於站點可靠性工程(SRE) 和DevOps。
與大多數與運營和工程相關的事情一樣，一般來說，很大程度上取決於業務的規模和成熟度，以及正在執行的基礎設施（本地、公共雲、混合等）。此外，訪問共享工具對於集中式和分散式運維團隊的成功至關重要。
在集中式模型中，通常可以減輕由於擁有全部或部分堆疊以及直接訪問安全團隊而引起的安全問題，這些團隊審查工作並確保編寫程式碼時考慮了安全最佳實踐。但代價是支援應用程式的釋出和響應影響客戶和公司聲譽的隨叫隨到問題需要更長的時間。
在比較集中式和分散式運維的人為因素時，應該考慮支援每種情況的軟體架構：
例如，對於基於微服務的架構，擁有特定服務運營的各個團隊可能具有優勢——尤其是如果他們開發了服務——因為他們最瞭解其細微差別和內部動態。一般來說，在這種型別的示例中對服務進行編碼的團隊可能會更快地除錯由於軟體錯誤引起的操作問題，而在除錯由於環境問題（包括底層依賴項或基礎設施）引起的問題時可能會更慢。
從人數的角度來看，隨叫隨到的團隊應該同時擁有開發人員和運營商。但是，隨著服務的成熟，將運維轉移到中央 SRE 團隊以降低成本和倦怠可能是有意義的，並讓工程師有時間重新編碼和開發新功能，這通常是他們的首選活動。
圍繞 SRE 或 DevOps 的文化也很重要。尤其是隨叫隨到的操作人員是一項 24/7 全天候的工作，具有全天候的壓力、壓力和期望。不是每個人都適合它。但它通常至少是運營商工作的一部分，尤其適合在較小、較新或分散的組織中。
在許多情況下，隨叫隨到是痛苦的，人們在巨大的壓力和永久的壓力下工作。他們也可能正在處理過時的 wiki 或缺乏有關故障排除或解決隨叫隨到問題所需發生的事情的資訊。甚至可能不清楚誰對完全處理事情所需的某些行動負責。即使在最好的情況下，也有很多活動部分，公司依靠人來採取行動。
  • 在集中式模型中：當一個團隊擁有運維的所有責任和問責制時，團隊之間和運維管理員之間幾乎不會發生相互指責。這種結構對於運營的集中式方法更為重要，但內部團隊成員與與外部服務提供商打交道的運營商之間仍然存在裂縫。響應問題也需要更長的時間，因為有既定且嚴格的流程。

  • 在分散模式中：當部門之間的職責分工並且不清楚誰對運營要素負責和/或負責時，混亂很快就會發生，尤其是在隨叫隨到的情況下。採用這種方法通常需要具有不同經驗水平的操作員在工作中隨叫隨到學習並透過失敗收集知識。該模型還允許組織將可靠性文化傳播到整個軟體開發團隊，使其至少成為每個人工作的一部分。

無論公司是集中式還是分散式，重要的是要營造一種共同責任和問責制的文化，以支援隨叫隨到的響應、補救和常規運營工作。

 

相關文章