半年來，我直接管轄的三大系統，都遭受了重創，但任然沒有大事故出現，是運氣好，是運氣好，還是運氣好呢？
2016.12.19 erp （sap ecc6 ehp7 oracle aix） 伺服器硬體主機板故障， 我迅速切換到備機，系統服務沒有中斷。
2017. 2.17 mes （rockwell ftpc oracle） 資料庫伺服器 log日誌4g滿故障，系統中斷1-2小時。
2017. 5.2 eai （資訊系統整合中介軟體） 應用伺服器**內部bug, 乙方顧問處理24小時恢復。
總的來說，eai的故障時間是最長的，原因如下：
我們沒有完全控制或掌握eai，乙方並沒有給我們源**，而我也沒有去學過mq的開發，這次故障正好就出在**上，只有乙方開發顧問才能解決。
這裡還暴露了一些問題：
1、eai不被我們所控制或掌握。
雖然我已經對eai的應用和資料庫伺服器都做了多個vm的副本，但是故障切換時這些之前的vm並沒有使eai服務正常，這是乙個很詭異的問題？
我們也沒有準備去從**層面掌握eai，這樣對eai的控制就差了很多，比如這次問題出現在**層，我們只能靠外部顧問。
sap 和 mes 相比eai就好很多：
sap系統架構高可用，我也有10年以上的管理經驗。
mes也是單點系統+vm備份，但我們對它的了解已經到了**層，在上面開發了不少應用。（不過它的架構也不簡單）
2、eai是否有存在的必要。
為了聯通各個資訊系統，我們使用了eai（企業資訊整合），eai封裝了ibm的mq，mq的初衷是實現應用程式之間的通訊。
eai的功能問題：eai只能搬運資料，沒有做到etl中介軟體的資料轉換。
eai的效能問題：資訊系統a---eai---mq--xml---資訊系統b， 資料全部都轉換成xml，效能並不好。2023年最後一天，我們處理800個訂單（erp到mes）eai 用了6個小時。
eai的致命單點：eai目前的架構只有單機，各個資訊系統都是通過eai傳遞資料，eai一旦死掉，全部資訊系統也基本只剩半條命。 eai就像赤壁裡的連環計，把戰船都連鎖起來，但是一旦出現問題，就是全都被燒起來。
eai專案之後，我逐漸發現，現在的資訊系統都是基於關係型資料庫的，資料庫和資料庫互動用中間表就可以做得很好，sap也有jco或nco。何必要做乙個eai用mq來搞呢？
程式大道至簡就應該出現在這裡，用中間表會給後面的運維工作帶來諸多便利。
我準備用我的sapsender乙個輕連線的etl工具，首先實現erp到mes的生產工單和bom資料傳輸，以應對於下一次eai危機。
to be continue............
Linux Solaris系統管理總結
隨著linux應用的擴充套件許多朋友開始接觸linux，根據學習windwos的經驗往往有一些茫然的感覺 不知從何處開始學起。作為乙個 linux系統管理員，我看了許多有關linux的文件和書籍，並為學習linux付出了許多艱苦的努力。當真正獲得了乙份正式的linux系統管理工作後，我更加深刻地理解...
linux系統管理總結
0 系統管理就是如何使用各種軟體來達到我們的目的。1 簡單的一些軟體 uname a 查詢作業系統資訊 poweroff 關機 pwd 顯示當前所在目錄 cd 定位到目錄 注 代表當前目錄的上級目錄，代表當前目錄，代表使用者主目錄 cd和cd一樣效果 ls 列出目錄內容 f 區分檔案型別 a 所有檔...
SAP BASIS系統管理
系統監控 1 sm51 2 sm50 3 sm66 系統日誌 1 sm21 sap ccms 1 rz20 2 st06 作業系統監視器 operating system monitor 用於分析整個sap技術棧的效能 4 ssaa 用於執行常規的日 周和月的系統管理功能。5 smlg 用於監控sa...