1.1 概述

作為開篇，首先讓我們來熟悉一下運維全平臺的規劃體系吧，如圖1-1所示。

圖1-1 運維全平臺規劃體系

很多人看到這樣一個架構圖，可能會納悶，難道對于一個小型企業來說，也要實施如此復雜的運維自動化體系嗎？其實，對于不同規模的企業來說，對運維自動化的訴求的確是不同的。對于大規模企業，如BAT，這些能力基本上都是必不可少的；而對于小型互聯網企業，比如說App開發公司，則核心的自動化訴求可能更多的是配置管理工具，比如說Puppet、SaltStack或Jenkins+Rsync等。

我們不禁要問，有什么樣的準則可以讓我們作為依據來判斷何時該如何導入自動化？應該導入自動化的哪些部分？當你需要持續、頻繁地進行一些事情時，此時就需要引入自動化，比如說版本發布，如果這個時候你感覺到很痛苦，那么此時就需要引入自動化了。關于應該導入自動化的哪些部分，我個人的經驗是根據角色去梳理他的工作現狀（持續、頻繁的工作），然后引入自動化的能力，再根據角色人數的多與少來確定事情的優先級，比如說系統管理和業務發布，很明顯業務發布的優先級更高，因為它的自動化所帶來的人力解放的收益更大。當然還有一種更理想的情況，那就是根據整體業務交付流來構建，以它的全流程自動化為目標，此時引入的是該交付鏈上所有的自動化能力，當然對于很多企業來說，這種自動化實現的代價很高，而得到的收益卻很小。