運維學習和發展的一個線路：
1、搭建服務（部署並運行起來）
2、用好服務（監控、管理、優化）
3、自動化（服務直接的關聯和協同工作）
4、產品設計（如何設計一個監控系統）
運維分類
機房運維（負責設備上下架、巡檢、報修、硬件監控）
基礎設施運維（系統初始化、網絡維護）
基礎服務運維（內部DNS、負載均衡、系統監控、資產管理、運維平台）包含運維開發
系統運維（架構層面的分布式緩存、分布式文件系統、日志收集、環境規划（測試、開發、生產）、架構設計、性能優化）
安全運維（整體的安全方案、規范、漏洞監測、安全防護等）
應用運維（業務熟悉、服務部署、業務部署、版本管理、灰度發布、應用監控）
監控運維（7*24運維值班、故障處理）
雲計算的核心競爭力是運維！
運維知識
轉自：https://www.unixhot.com/page/ops
運維自動化發展
運維標准化:
- 物理設備層面：
1. 服務器標簽化、設備負責人、設備采購詳情、設備擺放標准
2. 網絡划分、遠程控制卡、網卡端口
3. 服務器機型、硬盤、內存統一。根據業務分類
4. 資產命名規范、編號規范、類型規范
5. 監控標准
- 操作系統層面：
1. 操作系統版本
2. 系統初始化（DNS、NTP、內核參數優化、rsyslog、主機名規范）
3. 基礎Agent配備（Zabbix Agent、Logstash Agent、Saltstack minion）
4. 系統監控標准（CPU、內存、硬盤、網絡、進程）
- 應用服務層面
1. Web服務器選型（Apache、Nginx）
2. 進程啟動用戶、端口監聽規范、日志收集規范（訪問日志、錯誤日志、運行日志）
3. 配置管理（配置文件規范、腳本規范）
4. 架構規范（Nginx+Keepalived、LVS+Keepalived等）
5. 部署規范（位置、包命名等）
- 運維操作層面：
1. 機房巡檢流程（周期、內容、報修流程）
2. 業務部署流程（測試、生產、回歸）
3. 故障處理流程（緊急處理、故障升級、重大故障管理）
4. 工作日志流程（如何編寫工作日志）
5. 產品上線流程（發起-> 評審 -> 測試 -> 開發 -> 部署 -> 上線 -> 監控 -> 備份）
6. 產品下線流程（誰發起，數據如何處理）
7. 運維安全規范（密碼復雜度、更改周期、VPN使用規范、服務登錄規范）
標准化（規范化、流程化、文檔化）目標：文檔化
所有問題不要成為歷史遺留問題
運維工具化
1、SHELL腳本（功能性（流程）腳本、檢查性）
2、開源工具：Zabbix、ELKStack、SaltStack、Cobbler
目標：
1. 促進標准化的實施
2. 將重復的操作，簡單化
3. 將多次操作，流程化
4. 減少人為操作的低效和降低故障率
工具化和標准化關系緊密！
痛點：
1、你至少要ssh到服務器執行，可能犯錯
2、多個腳本有執行順序的時候，可能犯錯
3、權限不好管理，日志沒法設計。
4、無法避免手工操作。
例如某天我們要對一台數據庫從庫進行版本停機升級。那么要強進行評估：
停機影響：3:00晚上有定時任務鏈接改數據庫，做數據報表統計。
1、凌晨3:00我們所有系統的定時任務有哪些 crontab
2、這些crontab哪些鏈接我們要停止的從庫
3、哪些可以停，哪些不能停（修改到主庫），哪些可以后補。
4、這些需要后補的腳本是哪個業務、誰加的、什么時候加的。
運維平台化（Web化）
1、做成Web界面
2、權限控制
3、日志記錄
4、弱化流程
5、不用ssh到服務器，減少人為操作造成的故障（web ssh）
運維服務化（API化）
DNS Web管理 bind-DLZ dns-api
負載均衡Web管理 slb-api
Job管理平台 job-api
監控平台Zabbix zabbix-api
操作系統安裝平台 cobbler-api
部署平台 deploy-api
配置管理平台 saltstack-api
自動化測試平台 test-api
1. 調用cobbler-api安裝操作系統
2. 調用saltstack-api進行系統初始化
3. 調用dns-api 解析主機名
4. 調用zabbixx-api 將新上線機器加上監控
5. 再次調用saltstack-api部署軟件
6. 調用deploy-api 將當前版本的代碼部署到服務器上
7. 調用test-api 測試當前服務運行
8. 調用slb-api 將該節點加入集群
運維智能化
智能化的自動化擴容、縮容、服務降級、故障自愈
觸發機制 --> 決策系統（決策樹） -->
1、zabbix 觸發action
觸發：
1. 當某個集群的訪問量超過最大支撐量
(1) CPU使用率達到xxx 內存使用率達到xxx
2. 並持續5分鍾
3. 不是攻擊
4. 資源池有可用資源（當前網絡帶寬使用率、如果是公有雲--錢夠不夠）
5. 當前后端服務支撐量是否超過閥值，如果超過應該后端擴容
6. 數據庫是否可以支撐當前並發
7. 當前自動化擴展隊列，是否有正在擴容的節點
8. 其它業務相關的
之前: 先判斷Buffer是否有最近X小時，已經移除的之前刪除的虛擬機
並查詢軟件版本是否和當前一致，如果一致，跳過2、3、4步驟
如果不一致，跳過2、3步驟
2、 OpenStack 創建虛擬機
3、 Saltstack 配置環境
4、部署系統、部署當前代碼
5、測試服務是否可用（注意間隔和次數）
6、加入集群
7、通知（短信、郵件）
自動化縮容：
1. 觸發條件和決策
2. 從集群中移除節點
3. 通知
4. 移除的節點存放於Buffer里面
5. Buffer里面超過1天的虛擬機，自動關閉，存放於刪除區
6. 刪除區的虛擬機，每7天清理刪除