記一次redis key丟失的問題排查

最近測試環境的redis常常性發生某些key丟失的問題，最終的找到的問題讓人大吃一驚。
覆盤一下步驟：
一、發現問題
不知道從某天開始，後臺常常報錯，緣由是某些key丟失，一開始不在乎，覺得是小bug，後來愈來愈頻繁。
二、檢查代碼
看看是否是有誤刪除的狀況，這些key的訪問範圍很小，壓根沒有刪除的邏輯，也沒有設置過時時間，經過ttl命令檢查也是如此。
三、實在沒轍，開啓monitor監控
本覺得終極大招確定能發現問題，陸續抓取了幾個出問題時段的所有redis指令序列，沒有發現任何可疑的指令，心裏奔潰。
四、檢查redis.log
終於發現了這樣一段

29014:M 25 Apr 00:10:47.906 - DB 0: 4121 keys (4061 volatile) in 8192 slots HT.
29014:M 25 Apr 00:10:47.906 - 100 clients connected (0 slaves), 4476640 bytes in use
29014:M 25 Apr 00:10:48.038 - Accepted xx.xx.xx.xx:57998
29014:M 25 Apr 00:10:48.119 # Failed opening the RDB file backup.db (in server root dir /etc/cron.d) for saving: Permission denied
29014:M 25 Apr 00:10:48.279 # Failed opening the RDB file root (in server root dir /etc/cron.d) for saving: Permission denied
29014:M 25 Apr 00:10:48.358 # Failed opening the RDB file root (in server root dir /etc/cron.d) for saving: Permission denied
29014:M 25 Apr 00:10:48.385 - Client closed connection
29014:M 25 Apr 00:10:48.397 - Accepted xx.xx.xx.xx:52018
29014:M 25 Apr 00:10:52.915 - DB 0: 2 keys (0 volatile) in 4 slots HT.

在00:10:48.119 這個時刻，嘗試從/etc/cron.d下面的backup.db恢復數據，而後出錯，而後就數據庫被清空。
整個過程速度很是快，客戶端都沒有感受。

咱們內部沒有人會在這個時刻去執行這個操做，redis的配置文件裏面也不會有相似的配置。
網上搜索了一下，相似的狀況說明，這是有人在嘗試經過redis來攻擊你的服務器。

因爲機房設備不足，臨時在騰訊雲服上搭建了測試環境，沒有作過多的安全性設置，redis也沒有設置密碼。
接下來作了兩個設置：
一、redis設置了一個較爲複雜的密碼；
二、禁用了config指令
接下來幾天，再也不有相似問題。

折騰了幾天，一開始徹底沒往安全這個方向去考慮，充分說明專業的事情還得專業的人來幹，我這個運維臨時工是不行的。