moonla
計科專業從事嵌入式軟件開發多年，最近因為公司需要搞後臺研發，經常選擇升級的時機放在凌晨，而且大型的數據處理也是放在這個時間段內，經常發生的服務器宕機也是在這個時段。都是在用戶使用少的時候開始折騰，折騰的次數多也就容易出現服務器問題。由於做的是物聯網設備，在工作中遇到的宕機主要有這麼幾種情況，對大量數據的操作導致CPU佔比在一段時間內驟增從而導致數據接收模塊出問題，導致系統監控出現問題，很多設備信息檢測不到了。
對數據庫的操作太頻繁導致效率的下降，也是影響系統性能很重要的一部分，其實服務器也是普通電腦的構成，主要的資源是CPU和內存，這兩個因素無論是哪種都有可能導致系統的崩盤，如果是CPU被佔滿了，系統的反應會變得異常緩慢，時間長了可能還會慢慢緩過勁來，內存如果佔滿了那麼會導致系統的崩潰，直接運行不下去了，其實宕機核心點不會跑出這兩種因素。
現在就常見的服務器宕機問題做個歸納總結：
1.磁盤空間被佔滿，現在程序員運行的時候都習慣於帶上log打印，如果時間長了加上沒有清理的機制早晚會出問題，這個錯誤在平時運行過程中經常出現，如果使用的雲計算服務器通常在系統崩盤之前都會發個短信，通知你的系統處於崩潰的邊緣。
2.併發性能問題，如果多個人同時操作一個數據庫或者數據塊，會導致系統假死狀態，這種屬於爭搶CPU資源問題，可以通過增加硬件配置以及優化軟件代碼的效率去解決，數據量如何足夠大就可以考慮分佈式的管理
3.數據受損或者被破壞導致系統崩盤，所以常見的做法是都會配置備份盤，出現問題抓緊拿到備份盤來頂上，現在公司使用的是阿里雲的服務器，穩定性相比之前好太多了，中間換過電信雲，騰訊雲雖然價格低點，最後受不了直接換成阿里雲，再也不想換回去了，數據的穩定性永遠是第一位的。
4，一些沒有必要的誤操作，很多時候是因為程序員或者運維人員的誤操作大致服務器大面積的宕機，這種事件在很多雲服務提供商身上都發生過，根本層面還是管理問題。後臺管理的任何細節都有可能
服務器宕機查找問題的幾個線索：
1.看看服務器是不是存在內存洩漏問題，有些時候重啟機器開始還能正常運行弄了一段時間之後就會變得非常緩慢，十有八九都是內存的問題
2.是否有黑客入侵造成，有些非常關鍵重要的數據也是黑客最感興趣的，一般來講這種概率不是很高
3.是不是數據庫死鎖導致的，訪問量過大導致，連接數過多造成的。
服務器宕機一旦發生就會引起用戶的無數的投訴，無論在什麼情況下穩定永遠是第一位，現在大的功能升級除非已經百分百驗證成功，否則引起的後果不堪設想。
希望能幫到你。
大學生編程指南
作為一個運維人員，我想聲明一下，我認為你說的這個問題沒有什麼道理... 這件事存在偶然性
之前我們單位夜晚有一臺設備down了，這臺設備做的堆疊，而不是備份，所有下聯線路全部連接在主設備上。結果當晚凌晨，主設備的電源模塊損壞了！這... 你能看出規律嗎？我也想知道為什麼它偏偏凌晨損壞了！
所以說，偶然性事件，不能說大部分！
但是夜間割接倒是正常，選擇在用戶最少的時候做可能影響業務的必要事情是常識。
網工碾壓機
雖說在凌晨的時候，使用系統的用戶非常少，但是服務器在這個時候要做的工作可能一點兒也沒有少：
數據批處理操作通常會集中在凌晨進行：例如很多公司都會在晚上進行對賬操作，或為第二天的業務操作做一些預處理；或批量把業務系統的數據抽取到分析系統進行數據分析等等；
很多公司都做不到在線升級和灰度發佈，所以系統升級經常安排在半夜，升級完只能做一些簡單的驗證，測試覆蓋度的不足，也可能會導致遺漏一些BUG，最常見的一個問題是忽略了生產環境和測試環境數據量的差距，導致出現性能問題；
服務器操作系統、軟件的升級通常也會在晚上進行，這些操作也會帶來宕機的風險。
再說一個很久以前看到的，同行們分享的服務器宕機的經歷，有些經歷非常之神奇，大家就當段子看吧（為了方便，我就按照第一人稱來講述）。
我們服務的甲方是一家醫院，機房就在醫院的樓中，最近機房的服務器經常性的發生宕機，公司的工程師去了幾次也沒有發現問題；後來公司被折騰的沒辦法了，決定讓一個工程師晚上住在機房，看看半夜機房中究竟發生了什麼事兒，想著就算找不到原因，也能在服務器宕機後第一時間重啟。
後來發現原因，到了凌晨三四點的時候，機房門打開了，進來一個值夜班的小護士，看了一眼說：“又沒有人，開著空調不浪費電麼？”然後就把機房的空調關掉了，然後氣溫上升...
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
這裡需要說明一下，服務器宕機是什麼意思呢？我們日常說的“宕機”中的“宕”其實指的是英文“down”，宕機表示當前服務器或服務無響應或者不在線狀態。
服務器的宕機可分為人為控制的宕機、不可控的宕機。這兩者有什麼區別呢，下面來具體說明一下：
1、人為可控的宕機行為
服務器長時間的運行可能會帶來一些（非致命性）問題，又或者我們需要對服務器進行軟/硬件的升級維護時，可能需要停機或者重啟操作。這種情況下的宕機是可控的，在我們的計劃之內。
2、不可控宕機行為
這種因素就很多了，比如說服務器突然藍屏、服務異常崩潰、突然斷電斷網了，這時候服務(器)就無法正常提供服務，這些都是不可控因素導致的。
而在我們的日常運維工作中，計劃性的宕機維護一般都選擇在半夜來做這些事，為什麼呢，原因主要有這幾點：
1、減少對用戶的影響
凌晨大家基本上都休息了，用戶量較白天來說小得多，所以選擇在此時進行系統及硬件的維護導致的宕機對用戶的影響較小，就算有影響也只是影響小部分用戶。
2、有足夠的時間來處理故障
在凌晨進行維護，就算有問題，技術人員也有足夠的時間（比如說：00~05點）去處理故障。如果換成在日間維護，服務(器)宕機1小時以上投訴單全都過來了，壓力很大的。
以上就是我的觀點，對於這個問題大家是怎麼看待的呢？歡迎在下方評論區交流 ~ 我是科技領域創作者，十年互聯網從業經驗，歡迎關注我瞭解更多科技知識！
網絡圈
原理其實很簡單：這就如同我們白天忙碌著很多事物性的工作，就如同搬運工一樣，不停的搬運物品入庫，只有在物品都搬運完了的時候，我們才能開始整理這些物品，整理倉庫，。
其二，服務器在白天的時候，其實都在實時處理數據的“搬運工”狀態，只有在實時性數據處理工作（搬運工作）完成以後，才有機會或才能騰出手來去做數據的歸納和整理。所以，服務器的宕機時間，通常會發生在使用率最低的時間段。僅此。
北京得明
正常跑穩的業務，一般很難因為正常業務操作造成服務器宕機的。服務器資源問題大部分情況下是可預測，可控制的。
最容易造成宕機的事情，反而是開發/運維的不當操作造成的。比如更換服務器硬件，升級/安轉os程序包，發佈新代碼，批量更新數據等等，這些事一般都是半夜業務量小的時候做。
瘔集滅道
(눈_눈)我是金融行業的IT從業者，從銀行這方面而言，平時用戶使用佔用的服務器資源是不及晚上跑批調用資源的
省略浩1
1凌晨升級版本，容易出問題。
2程序很多數據清理維護多在凌晨負載低時處理。
3數據庫統多在凌晨統計
4數據
阿狸策略的樣子
因為凌晨是最困得時候，服務器一打盹就宕機了。
圍觀路人乙
有一個原因 ，白天運行的更多的是針對單個的處理 ；晚上的時候不僅會有針對單個的處理 ，還有一些批處理和程序的更新；批處理可能會導致運行緩慢甚至內存不夠，程序的更新可能會出現一些預料以外的事情發生。純個人理解，如若不對，敬請諒解。
