運維不難？...
...恐怕有人要扔鞋子了
1、系統不是我們開發的，維護中很多東西搞不定要找開發、實施的
2、找他們，要麼忙，要麼說幾句，搞得似懂非懂...
3、開發中的遺留問題導致重大事件，運維成了替罪羊...
4、客戶口頭說了兩句，日後有事就怪執行規範
5、客戶要提數、臨時安排任務、開發實施要做緊急配合，忙得不可開交...
運維人員一天到晚做過不停，還不斷受到責難，苦啊，還在這裡說什麼運維不難？
我也是做了多年運維的，我當然知道運維兄弟很辛苦，但我還是要說運維不難！呵呵！
最直接的理由是：有成功的案例。至少周圍有朋友確實做得不錯。我之前帶乙個團隊做移動客服專案運維，團隊成員工作很努力但不覺得很苦，客戶對我們的滿意度也不錯。前段時間在乙個保險公司做運維梳理，開始的時候確實很辛苦，但苦盡甘來，局面也逐漸扭轉。
不是說辦法比問題多嗎？相信這話也適用於it運維。沒找到辦法前，it運維難！找到辦法了，運維就不難了（是這個理吧）！
it運維為什麼難？
如何找到解決運維難題的「鑰匙」，接下來我會以我的經歷、經驗和教訓、思考...和你一起**！有任何想法都歡迎，呵呵！
KMP 其實也不難
引入 尋找子串在源串中的起始位置。傳統c 如下 include includeusing namespace std kmp 常規操作 int find substr location string str,string pattern else if flag true else return 1...
Spring實現AOP 其實不難
aop實戰之旅 不基於註解 ioc 控制反轉 ioc 通俗點來講，就是把物件的建立交給spring容器來管理，不用我們手動new aop 定義乙個切面，在切面中執行特定 實現 增強，常用於日誌列印，異常處理，效能耗時計算，事務處理，安全驗證等等，每個方法都要寫記錄日誌的 多，工作量大 日誌統一交給某...
遞迴函式其實不難理解
遞迴函式就是直接或者間接的呼叫自己本身。比如 include includevoid fun int main 但是這個程式執行起來後會怎樣呢？這就是因為剛剛使用的遞迴不能停止呼叫自己本身，每次在呼叫的時候在棧上都要開闢空間，作為函式執行時堆疊所使用，一直呼叫自然會導致棧溢位！所以使用遞迴函式的時候...