一千萬個為什麽

搜索

全自動化仍然能夠在小規模提供更好的投資回報率嗎?



顯然,當您需要管理數百個服務器並且您需要將這些服務器完全相同地配置為一致的標準時,自動配置管理和部署在大規模時才有意義。

但是,在系統規模較小並且只需要2,3或4臺服務器的情況下,建立時間通常可以更快,以便立即實現第一個實例並克隆後續實例 - 手動更改IP地址和主機名。

The theoretical advantage to automated deployment and configuration management is that code can be deployed faster, tested faster and services are provided more reliably by automating out the problem of human error. Future upgrades of the underlying OS (eg, CentOS 6 -> CentOS 7) are better/faster and in the long run the above benefits outweigh the initial larger investment of programmatically automating deployments using a configuration management system?

是否有任何真實的非軼事性研究和數據點將上述各項優勢支持到需要管理的服務器數量很少的小商店?

轉載註明原文: 全自動化仍然能夠在小規模提供更好的投資回報率嗎?

一共有 3 個回答:

在使用代碼完成配置管理的自動化手動任務和配置系統方面有明確的價值,而不是使用紙張和人工幹預。

一個巨大的好處是減少了返工量。您可以考慮由於人為錯誤而導致的任何問題,以重復相同的順序進行返工。以及需要不止一次修復的任何錯誤。

Rework is costly, and there has been some research done to quantify its cost. You can read about it in this whitepaper - https://devops-research.com/roi/

同一份白皮書還量化了服務/系統故障的成本,以及解決故障的緩慢時間。所有這些都通過強大的自動化流程大大減少,可以防止人為錯誤終止於生產系統。

2013年以來每年發布的DevOps報告中都會對自動化手動任務的主題進行調查。其中大多數可在 https://devops-research.com/research.html (2013年除外)。在每一份報告中,它都被認為是各種規模的高績效企業的最佳驅動力。有很多理由和解釋可以用來證明你的情況。

我遇到的最困難的事情之一就是節省重復工作的工時通常只是自動化價值的一小部分。更大的部分往往難以衡量,並且幾乎不可能估計什麽時候首次實現自動化:它如何改變您的工作方式。與開發人員交談時,這會更容易,因為他們知道測試自動化(單元測試),並且這是一個簡單的比較。它是這樣的:

  • How does your workflow change when you can do X as often as you want with negligible costs and in very little time?
    • For unit tests, it means bugs get caught much, much earlier - you can test everything multiple times per day, instead of shipping something to QA once a week. Turnaround on iterations gets orders of magnitude shorter.
    • For infrastructure, it means that doing a short-lived test environment or proof of concept is a non-event, as is scaling out, as is replacing an unhealthy instance. The LoE nears zero.
  • How does your workflow change when you think about automation as part of your process?
    • For unit tests, this means you design your code differently, to facilitate automation, which (often) leads to better, cleaner code.
    • For infrastructure, this encourages you to develop a standard plan for how you're going to automate things - when a new service is being developed, you know what questions you need to ask about it.
    • Developers start to change the way they develop as well, thinking about keeping stateless, graceful shutdown, fast restarts, how configuration is handled, keeping log or data file paths configurable, thinking about what paths the application user needs access to and what access it needs, etc.

“寵物與牛”的轉變主要由自動化驅動;當創建工作服務器是非事件時,服務器變得完全可替代,您不再需要關心各個實例。

自動化的主要優勢不僅在於自動化本身,還在於它為您提供了跨所有資源的相同配置。

比方說,舉個例子,你站在一個托管你的應用程序和所有相關配置的網絡服務器上。然後,您將其註冊為Amazon AMI,以便可以部署多個副本(例如,一個用於dev,一個用於測試,另一個用於生產)。您將其推出後,以及AWS的工作原理,您甚至不需要手動更改任何IP。

幾周後,您意識到您需要更改nginx中的SSL會話緩存大小,否則應用程序的用戶無法上傳大文件。

由於你只有幾個盒子,你可以手動更新。您可以再進行一次這些配置更改並妥善記錄它們。

然後一個星期後,你部署一個新的盒子(一個客戶要求UAT環境來測試他們的整合)。你病了,所以別人站在服務器而不是你。或者也許你的AWS實例死亡,所以你必須在一個良好的狂歡之後在半夜重建生產。一切都很完美......除了一個特定的配置相關功能。 Cue浪費了兩個小時的時間,弄清楚為什麽會發生這種情況,因為一名客戶經理正在駕駛你的屁股,只有在意識到其他管理員在部署新服務器時忘記了一個愚蠢的配置設置。

這種情況發生在你身上幾次,你會想找到一種方法來最大限度地減少這些問題。

那麽,為什麽不花幾天時間,用Ansible或Puppet寫出一個簡單的部署管道,並將其放入git?從那時起,任何配置更改只是一個推開,你很少會擔心發生類似的事件。

現在,它不是由同行評審的,你要求的APA引用的研究論文,但是指出我的系統管理員從來沒有遇到過這種情況,而我的公司可能會給他們帶來一份非常好的簽名獎金。