1、Openstack日常運維目錄1. 運維工作內容2. 維護與診斷3. 標準化修復與例行檢查4. 日志與監控5. 備份與恢復6. 故障解決思路運維工作內容 參與設計、審核、優化公司IT系統基礎設施以及各應用系統的體系架構； 全面負責公司運維項目的系統升級、擴容需求與資源落實，配合開發需求，測試、調整運維平臺； 負責網絡以及交換機、路由器、服務器的網絡設置、維護和優化、網絡的安全監控、系統性能管理和優化、網絡性能管理和優化； 建立面向開發部門，業務部門的服務流程和服務標準； 負責IT運維相關流程的規劃、設計、推行、實施和持續改進； 負責設計并部署相關應用平臺（包括操作系統和基礎服務組件、自動化部署

2、配置工具），并提出平臺的實施、運行報告； 負責配合開發搭建測試平臺，協助開發設計、推行、實施和持續改進； 負責相關故障、疑難問題排查處理，編制匯總故障、問題，定期提交匯總報告； 負責云服務產品監控和應急反應，以確保云服務產品有7*24小時的持續運行能力； 負責日常系統維護巡檢工作及監控，提供IT軟硬件方面的服務和支持，保證系統的穩定。維護與診斷1. 采用高可用部署2. 計劃內停機盡量采用非高峰使用停機3. 計劃外停機，提供備用機替換或利用編寫好的安裝配置腳本腳本重新部署新機上線4. 實時監測服務進程，進程當機后利用自動腳本重啟服務5. pstree -a控制節點控制節點計算節點計算節點1. 計

3、劃內停機前，將宿主機內的虛擬機進行遷移，維護完成后恢復虛機2. 檢查服務進程 ps aux|grep nova-compute3. 通過日志文件/var/log/nova/nova-compute檢查恢復問題虛擬機4. 利用qemu-nbd命令掛載虛擬機磁盤到本地設備，檢查修復失敗的虛擬機5. 利用nova volume-detach 和nova volume-attach重新掛載卷存儲6. 使用共享存儲的虛機實在無法啟動，可以新建虛機掛在其他宿主節點7. 可以利用恢復/var/lib/nova/instances恢復虛機機8. pstree -a維護與診斷ip -a檢查網卡狀態檢查網卡狀態t

4、cpdump檢查連通性檢查連通性 ping檢查網絡檢查網絡檢查檢查DHCPNova console-log ps aux|grep dnsmasqtcpdump標準化修復與例行檢查標準化修復：標準化修復與例行檢查例行檢查：日志與監控定位錯誤產生操作錯誤后，分析操作可能的API調用過程, 逐步檢查API日志定位可能的問題點日志與監控日志與監控如果查詢各個節點日志比較麻煩，最終可以建立一個專門的日志服務器集中管理日志日志與監控如果查詢各個節點日志比較麻煩，最終可以建立一個專門的日志服務器集中管理日志日志與監控預警：日志與監控日志與監控日志與監控趨勢預測：日志與監控備份與恢復數據庫備份：備份與恢復數

5、據庫備份：備份與恢復文件備份：備份與恢復文件備份：備份與恢復文件備份：備份與恢復數據恢復：1.數據庫恢復2.配置文件恢復3.其他文件恢復故障解決思路故障的表現是什么？無響應？報錯？故障是什么時候發現的？故障是否可重現？有沒有出現的規律（比如每小時出現一次）最后一次對整個平臺進行更新的內容是什么（代碼、服務器等）？故障影響的特定用戶群是什么樣的(已登錄的, 退出的, 某個地域的)?基礎架構（物理的、邏輯的）的文檔是否能找到?是否有監控平臺可用? （比如Munin、Zabbix、 Nagios、 New Relic 什么都可以）是否有日志可以查看?（比如Logstack系統筆記的云日志服務）一、盡

6、可能搞清楚問題的前因后果故障解決思路二、有誰在?$ w$ last 故障解決思路三、之前發生了什么?$ history 故障解決思路四、現在在運行的進程是啥?$ pstree -a $ ps aux故障解決思路五、監聽的網絡服務$ netstat ntlp$ netstat -nulp $ netstat -nxlp故障解決思路六、CPU 和內存$ free -m $ uptime $ top $ htop 注意以下問題:還有空余的內存嗎? 服務器是否正在內存和硬盤之間進行swap?還有剩余的CPU嗎? 服務器是幾核的?是否有某些CPU核負載過多了?服務器最大的負載來自什么地方?平均負載是多少

7、?故障解決思路七、硬件$ lspci $ dmidecode $ ethtool故障解決思路八、IO 性能$ iostat -kx 2 $ vmstat 2 10 $ mpstat 2 10 $ dstat -top-io -top-bio 這些命令對于調試后端性能非常有用。 檢查磁盤使用量：服務器硬盤是否已滿? 是否開啟了swap交換模式 (si/so)? CPU被誰占用：系統進程? 用戶進程? 虛擬機? Dstat 用它可以看到誰在進行 IO故障解決思路九、掛載點 和 文件系統$ mount $ cat /etc/fstab $ vgs $ pvs $ lvs $ df -h $ lsof

8、 +D / /* beware not to kill your box */ 一共掛載了多少文件系統?有沒有某個服務專用的文件系統? (比如MySQL?)文件系統的掛載選項是什么： noatime? default? 有沒有文件系統被重新掛載為只讀模式了？磁盤空間是否還有剩余?是否有大文件被刪除但沒有清空?如果磁盤空間有問題，你是否還有空間來擴展一個分區故障解決思路十、內核、中斷和網絡$ sysctl -a | grep . $ cat /proc/interrupts $ cat /proc/net/ip_conntrack /* may take some time on busy se

9、rvers */ $ netstat $ ss -s 你的中斷請求是否是均衡地分配給CPU處理，還是會有某個CPU的核因為大量的網絡中斷請求或者RAID請求而過載了？ SWAP交換的設置是什么？對于工作站來說swappinness 設為 60 就很好, 不過對于服務器就太糟了：你最好永遠不要讓服務器做SWAP交換，不然對磁盤的讀寫會鎖死SWAP進程。 conntrack_max 是否設的足夠大，能應付你服務器的流量? 在不同狀態下(TIME_WAIT, )TCP連接時間的設置是怎樣的？ 如果要顯示所有存在的連接，netstat 會比較慢， 你可以先用 ss 看一下總體情況。 你還可以看一下 L

10、inux TCP tuning 了解網絡性能調優的一些要點。故障解決思路十一、系統日志和內核消息$ dmesg $ less /var/log/messages $ less /var/log/secure $ less /var/log/auth 查看錯誤和警告消息，比如看看是不是很多關于連接數過多導致？ 看看是否有硬件錯誤或文件系統錯誤? 分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。如果你有多臺機器,看起來很不方便,可以事先把日志存儲在系統筆記的云日志服務器上,支持全文模糊查找故障解決思路十二、定時任務$ ls /etc/cron* + cat $ for user in $

11、(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done 是否有某個定時任務運行過于頻繁? 是否有些用戶提交了隱藏的定時任務? 在出現故障的時候，是否正好有某個備份任務在執行？故障解決思路十三、應用系統日志這里邊可分析的東西就多了, 不過恐怕你作為運維人員是沒功夫去仔細研究它的。關注那些明顯的問題，比如在一個典型的LAMP（Linux+Apache+Mysql+Perl）應用環境里: Apache & Nginx; 查找訪問和錯誤日志, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。這里查看了下,并沒有503的,只有403的錯誤.所以可以跳過 MySQL; 在mysql.log找錯誤消息，看看有沒有結構損壞的表， 是否有innodb修復進程在運行，是否有disk/index/query 問題. PHP-FPM; 如果設定了 php-slow 日志,