首先，传统的存储硬件故障告警是必要的，没有必要重复发明轮子，即使再次发明，还是要参考原装的轮子然后，要用自己习惯的工具，不限于商用还是开源。用的好，顺手，才能有后续的深入最后，如果自己能做一点小工具。满足日常监控和告警，就比较理想。不要一开始就想让一个系统满足所有的要求...
TBF（无故障时长）和TTR（故障修复时长）是业务连续性管理两个重要指标，故障处置管理的目标就是为了最大限度的增加TBF和缩短TTR。在具体管理中，我们通常会根据故障应急处置时间轴扩展以下指标：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、MTTF（平均故障处理时长）、MTTR...
(more)企业IT故障定位指诊断故障直接原因或根因，故障定位有助于故障恢复动作更加有效。故障定位通常是整个故障过程中耗时最长的环节，定位的目标围绕在快速恢复的基础上，而非寻找问题根因，后者由问题管理负责。通常大部分可用性故障，要借助运维专家经验的假设判断或已知预案的执行得...
(more)一个小小的故障出现必将引起数十个甚至上百的设备报警，那么现阶段的自动化运维软件能够把故障定位精确到什么程度？还是仅仅能做到提示，真正的故障原因还需要运维人员自己去手动找？ 故障定位算法采用机器学习中的二叉决策树的方式实现: 一方面希望将故障所产生的所有告警信息...
随着系统架构不断升级，功能持续迭代，系统运行复杂性越来越高，故障的发生不可避免，且发生场景愈发无法预测。从企业角度看，系统故障影响客户体验，降低访问流量，带来交易损失，引发监管问责等；从系统架构角度看，系统故障反映的问题代表系统未来扩展性与局限性；从IT资源角度看，故障（尤其是...
(more)可以做业务全链路跟踪和监控。从数据进入交换机开始，追踪数据的流向，准实时反馈数据状态。
计算机报警种类繁，报警的厂商不同。日志格式，内容还有代码也都没有一个统一标准。想要通过机器学习实现精准的故障定位我觉得还有很长的路要走。至少要所有的厂商都开放自己的日志代码。基本实现统一的日志格式。以目前的技术来看。我觉得机器学习只能是帮助运维去简化和梳...
业务系统繁多，这时候清晰的IT架构可视化系统是很不错的选择，利用“IT架构图”与数据相互结合的方式，图可以分三类，一类是业务系统所在的网络架构，结合NPM的数据和流程数据，网络架构中的节点，可以关联CMDB的数据和NPM性能数据和告警数据等；二类是业务系统的业务逻辑架构，也就是该业...
分享几点故障诊断时的小经验：1.是否是一个普遍还是独立的问题，例如io问题例：曾经遇到一个集群环境下多节点主机io 性能下降，其中最终问题是由于ds8000 一个控制器问题导致。2.hba卡故障例：存储端出现告警灯亮，登录storage manager 查看，出现链路切换，由于有过类似经验，直接定位是...
weblogic没有用过，看是标红的部分貌似是等待从连接池中获取数据库连接，不知道现在连接池的大小是多大，另外也要关注一下数据库端的最大连接数是多大
