有啥後果

1、趕緊修復系統恢復正常

2、排查故障原因及修復

3、根據排查結果，罰錢的罰錢，批評的批評，開除的開除。

如果把程式刪了或者資料庫資料庫重要資料刪了，而且無法恢復，那就辭職找下家吧，如果可以解決，晚上加班一下，問題應該不大，實際情況而定

系統掛 肯定要馬上重啟 但是如果說懲罰之類 要看是什麼原因造成的 比如程式碼上漏洞 那就趕快修復重啟 然後檢討或者扣業績之類的吧 如果有人故意把服務弄掛的話 那就是有點意思了 不過一般服務掛的重啟就好 領導一般都不會太為難 關注我 我平常會分享一些我開發經驗和總結 我是一名碼農 愛玩愛寫程式碼愛分享的碼農

作為一個程式設計師遇到系統掛機是特別平常的事情，從軟體的開發週期看在除錯過程中儘量多的暴露崩潰的問題，爭取在正式版本上線的時候能夠減少掛機的可能性，平常在除錯過程中掛機和崩潰 都是為了盡最大的可能來暴露問題，所以一款軟體產品上線之前都要經歷幾輪的測試，整體的測試透過之後才能正式推廣出來。

如果真的屬於在線上執行過程中程式崩潰了，程式設計師本身有一定的責任，但最終把關的測試部門也有一定的責任，但是由於軟體本身的複雜性不可能所有的掛機都能提前發現，正是因為存在這種可能性，所以專門會在軟體裡面設定一個崩潰收集模組，有崩潰的日誌直接上傳到伺服器上，如果是單機版本的就只能儲存在本地，等著程式設計師收集資料拿到真實的原因，由於程式本身的細節繁多，沒有一個正式的軟體能夠說不存在掛機的問題，這也是軟體本身屬性決定的。

如果因為單純的掛機就認定程式設計師的工作不到位很明顯這種認識是片面的，沒有一個程式設計師說自己寫的程式碼程式永遠不會崩潰，優秀的程式設計師只不過從軟體的架構以及設計細節上最大程度規避，但是完全的杜絕明顯不符合軟體開發的規律，很多不懂技術的老闆覺得軟體開發屬於一錘子買賣，已經開發設計完了應該就結束了，甚至有了卸磨殺驢的想法現實中很多企業都存在這種惡劣的習性，這種企業因為本身對技術的不尊重註定了企業永遠很難做強，要想把軟體做好就要尊重軟體自身的規律，否則只能適得其反。

注重程式設計基礎的積累。大多數的崩潰本身是基本功不牢固造成，很多想當然的程式碼就是這麼出來的，基礎很差的人很容易寫出掛機的程式設計師，初級小白更加容易寫出掛機的程式，對於一個程式設計師最大可能的夯實程式設計基本功是必須要做的事情。

在架構上規避。好的架構能避免很多麻煩，所以一個架構師對於一個工程顯得非常重要，在一個好的架子上寫程式碼能夠極大的減少問題的出現，很多格局不是很大的工程，在修改不同的模組程式碼的時候很容易帶動出現問題，特別的一些不是很正規的小公司經常性的出現一些重複性的錯誤，如果出現這種機率非常大就要考慮整體框架的改進了。

寫程式碼要保持嚴謹的態度。很多程式碼之所以出錯不是寫程式碼的人能力不夠，是因為在寫的過程中沒有養成良好的程式碼程式設計習慣，只是在經常天馬行空的寫程式碼，這種最容易出問題，所以無論水平如何首先必須有嚴謹的態度，寫程式碼的時候要注意力充分集中，寫過的程式碼要回過頭來好好檢查，畢竟寫程式碼是一個對細節要求極高的工種，所以保持嚴謹是必須的。