前言
一直以为自热火锅、自热米饭的发热包仅仅是生石灰，加水之后成为熟石灰放出大量的热。至于网传的一氧化碳，我一直认为是无稽之谈，当然，真的不是一氧化碳这个原因，根本就没一氧化碳好么。很多自媒体标题党，说不要再密闭的房间吃，却不说为什么，最后一知半解说什么产生了一氧化碳。
原理
配方可能有所不同，无外乎氧化钙、铝粒、碳酸钠、碳酸氢钠，碳酸氢钠不一定会有，但是前三者一定有。
之前一直没有阅读过成分表述，因此对于一些信息也比较模糊，特地阅读了几款不同价位的自热食品自带的加热包，发现成分都是一样的，虽然所谓的执行标准代号千差万别，这应该就是厂商标准了。
氧化钙加水，得到氢氧化钙，也就是我猜测的第一步，生石灰与水生成熟石灰的过程。由于加入的为冷水，而此反应相当剧烈，表现为加入水一开始毫无波澜看似没有反应，其实已经很危险了，在这个时期内水温快速上升直至沸腾产生激烈的水蒸气喷涌而出的状态。
氧化钙吸收了水与水产生了反应，因此此时已经体积膨胀了，这个时候第一步的产物开始与碳酸钠反应，产生氢氧化钠和碳酸钙，一开始加热包只是吸水，物质与水反应后体积增加膨胀，在这一步，生成了碳酸钙，因此整个加热包开始有非膨胀导致的坚硬了。一开始是膨胀，这一步慢慢的加热包会变得坚硬。
而后，铝粒开始与第二步的产物，氢氧化钠发生反应。铝与氢氧化钠制取氢气的反应。因为是铝粒，不是铝粉，所以延缓了反应的发生速度。此时水早已沸腾，因此禁止加入热水的原因就是第一步。避免一开始因为热水的加入，导致第一步的反应过于剧烈，“根本把持不住”。
而氢气，可能会让很多半导体传感器动作，比如一氧化碳，或者可燃气体之类的传感器，因此被误认为“一氧化碳中毒”。如果非常小的房间内，使用自热包，产生氢气，确实有爆燃的可能性。氢气就是导致告警的原因，而且由于氢气的性质，更容易让传感器触发。
同时氢气燃烧充分而完美，这就是有一些自媒体在视频中，水蒸气可以被点燃的真相。一氧化碳哪有那么容易燃烧充分而无灰烬，如果有那么大量的一氧化碳，伤害事件早就产生了。毕竟只需要少量这种无色无味的气体，就会产生缺氧反应令人产生不适。
机房的气体告警有多灵敏呢？看类型。一种是传统场合的颗粒物传感器，就是日常的，具有放射性的烟雾传感器，这种类型的传感器其实实际上真的是烟能把人毒倒了，“遮天蔽日”了，才会被触发，差不多要遮住光线了，此时往往有一定的火情了。在机房的办公区域、休息区域与普通单位无异，采用这种烟雾报警器足够了。自热包产生的气体主要就是氢气和水蒸气了，显然氢气不会有遮天蔽日的效果，不会导致动作。一般宾馆房间也是烟雾报警器，因此不会有太大的问题。而厨房之类的场合，易燃气体传感器或者一氧化碳传感器，会轻易的被氢气唤醒，如果有读数的报警器，就会读出很高的数字。
但是机房内部，空气流量巨大，产生的烟雾很容易扩散在整个房间，以及被空调的HEPA滤网吸附，所以机房一般会配备独立的通道，去每个机房细微的抽取气流。根据我的经验，譬如说一根电源线因为某种原因短路烧毁，实际上不一定能监测到，但是系统的灵敏度其实还是相当高的。也有人使用质量不佳的PCIE转U.2转接卡，将U.2的固态硬盘转接为PCIE，安装在默认不支持U.2的服务器。结果这种规模的PCB起火，机房就产生了告警。当然不是我，如果我希望在服务器使用，自然是直接安装原生PCIE的固态了，更大的散热与服务器的气流风道更匹配，而且本身耐热考量就是吃尾气的，而不是吸硬盘面板凉风的。只需要一个巴掌大的PCB燃烧产生的颗粒物，就能够被机房传感器检测到，当然实际上找起来犹如大海捞针，每个机柜都有采样管道，但是都混在大管道了，客户自己不说，机房看到了这种告警，也只能是初步的多逛逛了，除非事态扩大才会被看见。
根据我对此类系统的了解，自热米饭释放的氢气量，绝对会触发这种气体分析系统的告警。本身带水和食物进机房就不对，所以不要给机房的网维添麻烦啦。几乎察觉不到的分子量，机房灵敏的传感器就能瞬间察觉。
思考
加热包的设计相当巧妙，虽然我不会去购买“自热水”这么离谱的东西，但是“再生饭”这种科技狠货，在条件有限的情况下，这口热饭真的提升了整个人的能量。如果有开水，开水泡开的方便米饭更快捷。如果没有开水的条件，只有自来水或者矿泉水，那么自热米饭也能饱餐一顿，吃饱喝足，开始全力以赴的干活。
在正确的操作方式下，先将食物都拆封搅拌妥当，加热包遇到水首先剧烈反应，产生大量的热烧开水，由于加入的是凉水，在水沸腾之前，加热包一直很平静，可能开始鼓胀，在沸腾产生大量蒸汽之前，用户有足够的时间将包装收拾妥当等待开餐。水开之后，利用前序产物引发后续缓慢的反应过程，实际上真的能够持续加热15分钟，基本上不需要扣表，水蒸气消停的时候差不多也就是说明的15分钟。
有开水泡开的拌饭，只要8分钟，有开水更方便，更环保。没条件的话，时间翻倍，选择加热包的自热米饭。两者都能吃上一口热乎乎的米饭。在用户体验的设计上，我觉得两者都还算可以。
而加热包表现出惊人的威力之前，这个积攒能量的过程也是相当危险的，自热包能不能对这个过程加以提醒？而作为一个运维，当服务器集群出现雪崩之前，如何提前更早地发现地底下的暗流？
结束
最后忠告，千万不要在机房服务器区域激活自热食材，你可能会惹上大麻烦。“火警”触动，万一有机房是自动化的，直接选择瞬间整机房断开一切服务器、空调、照明系统的供电，靠应急灯疏散人群，并且在若干秒后释放气体灭火装置，那么始作俑者会付出怎样的代价估计不下于随意触发交通工具上的应急装置。
我的座右铭，相当的运维了：稳定压倒一切，安全重于泰山。为了安全我们付出许多，包括稳定。一旦触发火警第一时间就断电，直接中断服务，相当大的代价了。
作为两年前OVH机房上“云”事件的亲历者，我也损失了接近20TB的资料，当然我有备份实际上除了中断需要重新维护，没什么损失。亲历此事件，原来“最安全”稳定的铅酸电池，也会燃烧。每一条安全规则背后都能找到许许多多严重的事故，工作中，拿出谨慎、安全的态度，当放松的时候，事故就快来了。
我见到过：小容量的铅酸电池，因为使用环境温度过高，在UPS长期浮充状态下开裂。本以为这就严重过了，直到OVH大火。
