運維與自動化概述
一：運維工作內容分類：
1).機房運維（負責服務器上下架、IP配置與划分、服務器打標簽、機房定期巡檢、服務器故障報修、服務器硬件監控)
2).基礎設施運維（系統安裝及初始化、網絡維護）
3).監控運維（7×24運維值班、簡單故障處理、通知相關業務負責人）
4).基礎服務運維（包含運維開發）（內部DNS管理、負載均衡配置、系統監控報警、硬件資產管理平台、監控平台搭建、代碼發布平台）
5).應用運維（精通公司業務、各種服務系統部署、業務系統部署、版本管理、灰度發布、應用監控）
6).系統運維（架構層面的分布式緩存、分布式文件系統、日志收集與分析、業務環境規划（測試、開發、生產）、業務架構設計與規划實施、服務器系統性能調優）
7).安全運維（整體的安全方案、規范、漏洞監測、DDOS防護、病毒防護及處理、關鍵程序包更新、漏洞掃描與修補等）
二：運維的發展線路：
1).搭建服務–可以安裝服務並運行，由於是參加工作沒有相關服務安裝和部署經驗，所以此階段的主要目的是可以把服務安裝並可以運行起來。
2).用好服務–適當對服務優化，工作一兩年后可以根據業務的實際需求對服務做適當的優化，比如可以對nginx做調優和監控。
3).自動化–自動化服務的部署或監控，工作三到五年后可以結合自動化部署工具或編寫腳本實現業務的自動化部署。
4).產品設計（如何設計一個監控系統），可以根據需要設計和部署大型業務系統，現在很多公司都在用雲服務，比如阿里雲、Amazon的AWS，微軟的Azure，以及騰訊雲、青雲等等各種雲計算，雲計算的核心競爭力是運維，其始終離不開運維對業務的技術支撐，比如搭建雲服務時的服務器選型、網絡規划、物理機系統部署與優化、監控系統的安裝配置等等。
三：自動化運維之運維標准化
1.物理設備層面：
1).服務器標簽化（IP地址/與交換機接口/當前服務/）、設備負責人（管理人）、設備采購詳情（保修日期）、設備擺放標准（服務器之間間隔1U通風）。
2).網絡划分、遠程控制卡、網卡端口。
3).服務器廠商機型號同一、硬盤大小轉速同一、內存統型號大小頻率一、服務器課根據業務分類，有的要求IO高（存儲服務器），有的要求內存大（緩存服務器），有的要求CPU塊（代理服務器），有 的對CPU和IO要求CPU和內存都高（數據庫服務器）。
4).資產命名規范、編號規范、類型規范。
5).監控標准（統一閾值和監控類型）。
2.操作系統層面：
1).操作系統版本（不要混合使用linux和windows,linux發行版盡量統一）
2).系統初始化（IP、網關、掩碼、DNS、NTP、內核參數調優、rsyslog、主機名規范、任務計划）
3).基礎Agent配備（Zabbix Agent、Logstash Agent、Saltstack minion）
4).系統監控標准（CPU使用率、內存使用率、硬盤使用率、IO延時、網絡狀況、進程數與僵屍進程、運行時間等）
3.應用服務層面：
1).Web服務器選型（LNMP/LAMP/Tomcat/MySQL）
2).進程啟動用戶身份及目錄、端口監聽規范、日志收集規范（訪問日志、錯誤日志、運行日志、系統日志）
3).配置管理（配置文件規范、腳本規范）
4).架構規范（Nginx+Keepalived、LVS+Keepalived、Haproxy+Keepalived、阿里雲SLB、Ucloud ULB等等）
5).部署規范（位置、包命名等）
4.運維操作層面：
1).機房巡檢流程（巡檢周期、巡檢內容、硬件報修流程）
2).業務部署流程（先在開發環境和測試環境測試、最后后在生產環境部署、如出現問題立即回滾、出現問題先回滾再修復）
3).故障處理流程（緊急故障處理、故障升級流程及時間、重大故障管理、責任分配）
4).工作日志標准（如何編寫工作日志周報、月報）
5).業務上線流程（1.項目發起人 2.系統安裝部署優化 3.部署Nginx及相關訪問 4.備案及解析域名 5.上線測試 6.對服務和主機加監控 7.數據定期備份）
6).業務下線流程（誰發起，下線時間，服務器和數據如何處理。）
7).運維安全規范（密碼復雜度、更改周期、VPN使用規范、服務登錄規范、命令使用規范、備份還原規范）
運維標准化實現業務規范化，最終達到文檔化的目的，即所有和業務相關的都有文檔可查，包括技術文檔、升級文檔、故障文檔等，也不會導致因為某員工離職而導致業務中斷。
四：自動化運維之工具化：通過相關運維工具，替代需要人工需要多次執行單一的工作內容，如：
1).Shell或Python腳本（簡單功能配置或修改的腳本，如自動修改配置文件、流程執行的腳本，如需要先修改完配置文件才能重啟服務、檢查性，如檢查配置文件是否修改，日志是否生成、報表性的腳本，如生成自定義數據的文本文檔並自動發送到郵箱）
2).開源監控工具：Zabbix ELKStack SaltStack Cobbler
3).開源部署工具：cobbler、walle、jenkins等
4).開源跳板工具：jumperserver等
運維工具化帶來的好處：
1).促進標准化的實施
2).將重復的操作，簡單化
3).將多次操作，流程化
4).減少人為操作的低效和降低故障率
運維工具化遇到的問題：
1).你至少要ssh到服務器執行。可能犯錯
2).多個腳本有執行順序的時候，可能犯錯。
3).權限不好管理，日志沒法統計。
4).無法避免手工操作。
例子：比如某天某台Web服務器磁盤可能發生問題，要在訪問量較低的凌晨要將服務器的數據導出來放在其他服務器替代，那么需要考慮的是：
1).是否有由其他服務器連接此服務器取數據或此服務器是否到其他服務器取數據。
2).此服務器是否有定時任務計划到其他服務器執行或有其他服務器連接到此服務器執行。
3).任務計划索要涉及的內容，以及停服務是否影響其他服務器。
4).后續的代碼更新問題。
五：自動化運維之web化
公司基於php等語言自己開發的可以在web通過鼠標點擊就能實現代碼發布和回滾等功能的web界面的操作平台。
1).招聘開發運維做成Web界面。
2).web界面的登錄權限控制。
3).操作日志記錄。
4).一鍵部署所有指定服務器，弱化操作流程。
5).不用ssh到每台后端服務器，減少人為誤操作的故障率。
例如：
1).DNS Web管理 bind-DLZ
2).負載均衡Web管理
3).Job管理平台
4).監控平台 Zabbix
5).操作系統安裝平台
六：自動化運維之服務化（API化）
1).DNS Web管理 ———->bind-DLZ dns-api（bind）
2).負載均衡Web管理——>slb-api（haproxy、LVS、Nginx）
3).Job管理平台————->job-api（php自主開發）
4).監控平台 Zabbix ——->zabbix-api（zabbix、nagios、cacti）
5).操作系統安裝平台——>cobbler-api（cobbler、kickstack）
6).部署平台——————>deploy-api（安裝服務軟件nginx+php）
7).配置管理平台————>saltstack-api（saltstack、ansible）
8).自動化測試平台———>test-api（自主開發測試）
通過調用相關api實現服務器從系統安裝到上線完全自動化：
1).調用cobbler-api自動安裝指定的操作系統
2).調用saltstack-api進行系統初始化和配置
3).調用dns-api 解析域名和主機名
4).調用zabbix-api 講該新上線機器加上監控
5).再次調用saltstack-api 部署訪問軟件（安裝Nginx+PHP,Tomcat,Mysql）
6).調用deploy-api 將當前最新穩定版本的代碼部署到服務器上的指定目錄。
7).調用test-api 測試當前服務運行十分正常，如有異常，則執行報警等操作
8).調用slb-api 將該節點加入集群
七：自動化運維之智能化：
能根據一定的策略或條件，智能化的自動化擴容、縮容、（服務降級、故障自修復），包括自動發布代碼加進負載集群等一些列操作
觸發:指的是觸發事先定義的一個閾值，可能是CPU使用率80%，也可能是並發超過100000，也可能是web訪問響應時間超過5s，這是一個觸發機制，然后要定義要做的決策，如：
1).當某個集群的訪問量超過最大支撐量，比如10000
1.1 CPU使用率達到xx% 內存使用率達到xx% 響應時間> x秒
2).此狀態已經持續5分鍾。
3).判斷不是攻擊
4).擴張資源池有可用資源
4.1).當前網絡帶寬使用率
4.2).如果是公有雲(錢夠不夠)
5).當前后端服務支撐量是否超過閾值 如果超過應該后端先擴容
6).數據庫是否可以支撐當前並發
7).當前自動化擴展隊列，是否有正在擴容的節點
8).其它業務相關的。
自動化擴容機制：
1).擴容之前：先判斷Buffer區域是否有最近x小時，已經移除的之前創建的虛擬機，並查詢軟件版本是否和當前一致，如果一致，跳過 2 3 4步驟，如果不一致，跳過2 3。
2). OpenStack 創建虛擬機
3). Saltstack 配置環境—-監控
4). 部署系統部署當前代碼
5). 測試服務是否可用（注意間隔和次數）
6). 加入集群
7). 通知（短信、郵件）
自動化縮容機制：
1).觸發條件和決策
2).從集群中移除節點-關閉監控-移除
3).通知
4).移除的節點存放於Buffer里面。
5).Buffer里面超過1天的虛擬機，自動關閉，存放於xx區
6).Buffer區的虛擬機，每7天清理刪除。