系统管理123总结

半年来，我直接管辖的三大系统，都遭受了重创，但任然没有大事故出现，是运气好，是运气好，还是运气好呢？

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，性能并不好。2016年最后一天，我们处理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............