目前先进的UPS采用ABM三阶段智能化电池管理方案，较早阶段是恒流均衡充电，将电池容量充到90%；第二阶段是浮充充电，将电池容量充到100%后停止充电；第三阶段是电池利用自身的漏电流放电到电压下限。

然后再重复这三个阶段。

这种方式电池不再处于一天24小时的浮充状态，延长了电池的寿命。

在这次事件中，UPS只坚持了6秒钟，导致数据中心崩溃。

电力在大约20秒之后就恢复了，但损失无法弥补。

一个数据中心垮掉后，在没有人工备份的情况下，完美恢复是不容易实现的。

此外，存储阵列要在服务器尝试加载组件后才能进行初始化，而DNS服务器正在启动，某些服务器会无法访问DNS，这又导致其他问题的出现，结果是一片混乱。

幸运的是，较终数据没有损坏，所有的服务器以及各项服务也恢复了正常。

下面我们来搞清，为何一个大容量UPS在44%负载的情况下只坚持了几秒钟的时间。

　　在垮掉之前，UPS除了自检失败以外，其他项目全部显示正常。

之前我已经注意到了自检失败，但看上去UPS不存在任何问题，日志也没有给出任何自检失败的原因。

所有的监控项目――电池、智能模块、电源供应器等状态显示正常，而且在管理状态页面中电池容量显示是100%。

以当时44%的负载量来推算，UPS应该能保证19分钟的运行时间。

而事实上它只坚持了6秒钟的时间。

　　在IT行业，我们对设备监控的依赖性很强，因此当监控出现问题时，我们会手足无措。

在本次事件中，UPS没有给出任何性能方面的预警，这无疑会导致我们怀疑其他监控项目的准确性，这种信任风险在设备监控中总是存在的。

　　我想，唯一的方法就是像一句俗语所说的：在它出问题之前开除它(Fire it before it can quit)，诸如硬盘、电池以及IT系统管理员等都适用此方法。

电池的电量可能一直显示为满，但事实上它们工作三年，就应该考虑更换。

APC给出过确定电池载荷下降的方法，当电池进行无负载自检时电力输出若出现严重下降，就需要更换设备了。

这可能是电池的问题，也可能是UPS中的监控代码的问题。

无论是何种原因，所造成的结果都是一整天的混乱，以及时间和人力的浪费。

因此，无论你的监控做得多到位，即使系统中较微小的部分都在监控范围内，也还是要注意，在某些情况下，为了避免问题的发生，你能够做的事情只有适时地更换那些看上去工作得很好的部件。