一、運維分類
基礎運維：IDC、上架服務器、網絡
應用運維：Web
運維開發：運維工具開發、系統開發
監控組：服務器監控、網絡流量、網站訪問量監控
二、運維架構
1）硬件標准化——包括服務器、內存、系統版本等 —》Cobbler
2）軟件標准化——應用軟件版本 —》Puppet
3）運維自動化——包括監控、發布、CMDB。
三、自動化運維
把運維中大量日常重復性工作使用工具讓其自動運行，減少人的參與。
1）監控報警——系統數據，應用指標的監控，和出錯時及時報警。
2）發布系統——代碼發布，發布后的檢查，代碼的回滾，灰度發布。
3）服務器標准化——Cobbler裝機加上Puppet，可以做到硬件、軟件的標准化。
4）CMDB——配置管理數據庫，存儲了所有運維相關數據，包括服務器硬件信息、域名和服務器的關系、IDC容量等。它是運維的心臟，所有的系統都依賴於它。
四、監控系統的理想化模樣（選擇zabbix的理由）
1、監控數據收集及可視化
1）監控系統能夠自定義監控的內容，可以自己寫腳本來收集需要的數據——Zabbix支持任何自定義的監控腳本，只要輸出需要的值就可以。
2）數據要保存在數據庫中，這樣以后需要的時候可以對這些數據進行分析計算——Zabbix在數據庫中的表結構雖然有些復雜，但邏輯很清晰。
3）能夠方便、快速地將監控加入到服務器上，不需要煩瑣的操作——Zabbix的模版可以方便地將一組Item進行統一操作。
4）數據可視化不要很花哨，但要直觀好用——Zabbix每一個Item都可以看到其歷史，Web界面可拖動，界面友好。
2、異常數據報警
1）可以定義復雜的報警邏輯，可以做到Item之間的關聯報警，而不是只能針對一個——Zabbix強大的Trigger定義，幾乎可以滿足所有規則組合。
2）報警需要被確認，讓運維人員知道多少報警已經有人認領並開始處理了——Zabbix對於報警，有ACK機制。
3）報警方式要能夠自定義，可以發郵件和短信，如果能夠在IM上通知別人就更好了——Zabbix支持郵件，Jabber。
4）報警內容要可以自行設置，在報警郵件中加入一些簡單的分析，而不是讓運維人員上服務器敲命令來獲取基本的信息——Zabbix自定義了一套宏可以在報警郵件中引用，如果要更復雜的功能，可以通過遠程調用命令實現。
5）報警后可以自動跑一些命令。這些命令可以是獲取需要的信息，也可以是自動修復，比如重啟服務等——觸發報警后，Zabbix可以遠程調用命令實現。
3、和其他系統協同工作
1）有強大的API可以使用，可以讓其他系統調用完成工作——Zabbix支持RestAPI，幾乎所有的操作都可以通過API實現。
2）監控數據是開放的，數據庫中的數據結構不要太復雜，讓人無從下手——監控數據就在Zabbix數據庫中，可以方便地進行分析。
3）監控可視化的圖可以方便地引用，而不是要用一大串JavaScript——Zabbix使用PHP原生的繪圖模塊，如果要引用Zabbix的圖表，只需要引用圖表的URL即可，非常方便。
五、Zabbix名詞
- Zabbix Server：Zabbix的控制中心，收集數據、寫入數據庫都是它的工作。
- Zabbix Agent: 部署在被監控服務器上的一個進程，負責和Zabbix Server交互，執行命令。
- Host：廣義上的服務器，大多數情況指代的是刀片機這類，在少部分時間會指代包括交換機在內的，被Zabbix監控的實體。
- Item: 對於某一個指標的監控，對應的是Items，比如某台服務器的CPU負載就是一個Item。
- Trigger: 一些邏輯規則的組合，它有三個值：正常、異常、未知。
- Action: 當Trigger符合某個值的時候，Zabbix會進行的操作，比如最常見的發郵件。