这一步主要确定在不跑业务应用的情况下，系统及内核层面是否稳定运行。
正常状态下，系统负载应该处于平稳状态，如果出现过高或者忽高忽地，都属于不正常状态。这一方面可能是内核工作队列中有任务堆积，另一方面，也可能是内核调度出现了问题。
产品开发中，我们通常都会认为内核应该没有问题。但是，嵌入式开发有其特殊性，内核一般都会根据板载硬件做裁剪，也会针对板载硬件做一些驱动方面的开发，这就给内核的稳定性带来了潜在的不利因素。鉴于内核的庞大及整体的复杂性，就进一步放大了这种不利因素的影响。结果就是，开发人员能力水平是否过关、测试是否充分完备以及开发管理是否到位都会影响到内核的稳定性和系统性能的发挥。特别是驱动的修改或者增加，对驱动对象是否深入了解、对内核框架机制是否充分掌握显得尤为重要，稍有不慎，就可能对内核稳定性和性能产生不良影响。
举几个本人在实际产品开发中遇到过的例子。
第一个是一款三星芯片产品。买的开发板，前期使用中，就发现串口命令行中连续回车，比如按住回车键不放，输出#的过程中，一会就卡顿一下。刚开始还没在意，但是在后面移植应用后，产品表现不正常，之前流畅的音频，现在就总是过一会卡一下。看ALSA打印，报pipe超时错误。在整体应用负载不高的情况下，说明内核被某个东西非正常占住了，比如在驱动中不正确的使用udelay，就很可能导致这样的问题。后来换了一家的开发板，还是同一款CPU，就不存在上述问题。
第二个是一款IPTV产品。前期测试一直都正常，最后都出货了，结果在部分用户家出现联网问题。跟踪验证，发现协议栈报了一个奇怪的错误，通过分析，原因是网络数据包可以接收，但是发送错误。当问题范围缩小后，就到内核网卡驱动中查找，最后确定是驱动中发送计数有问题，运行一段时间后，导致逻辑判断出问题，数据无法发送。
第三个也是与网络有关。抓包看，数据发送是正常的，但是接收每过一段时间就会延迟几百毫秒。因为上层业务是接收后转发，这就导致转发后看到的视频画面每过一会就卡顿一下。反反复复排查，发现网络接收的中断计数会突然集中增加，最后根据这个线索，将问题锁定在了网卡驱动接收中断处理中。
通过上面几个例子，我们看到，实际产品开发中可能会遇到各种奇奇怪怪的问题，在问题源上，内核并不能想当然的排除在外。但是，话又说回来，内核的问题一般比较隐蔽，不好排查，那有没有什么比较好的办法来规避呢？或者出现问题后，有好的查找策略？
其实查找BUG就如同给人看病，找到原因，一切都好办。古代名医扁鹊声名在外，却说这是因为自己治的都是末期之病，动辄扎针放血，人们以为自己很厉害，其实不然。自己的大哥能在病未有形时就发现并除之，自己的二哥也能在疾病初起之时将其清除，所以他们才更厉害。内核的稳定性也是同样道理，与其后期辛苦治疗，不如前期选择治未病，这才是高明之举。那有哪些措施可以在前期帮助我们筛选稳定的系统或检测系统的稳定性呢？下面列举一些，供大家在实际中参考：
1 建议大家尽量选择大厂商的平台。一般大厂的产品，测试会比较完善，质量相对可靠，尤其是选择这种偏底层基础的东西。
2 如果产品比较特殊，无法选择大厂通用平台，那就需要做充分的测试，尽早暴露问题，将问题扼杀在摇篮中。否则，每往后走一步，带来的损失就可能十倍百倍的增加。所谓基础不牢，地动山摇，不要指望到最后有弥补的措施。
3 如果有驱动开发，尽量选用成熟的设备及芯片，在此基础上尽量选用设备或芯片厂家的驱动，哪怕是在demo基础上修改，也比重新从头开始写要强。当然，如果开发人员经验非常丰富，就另说了。
4 内核非常庞大、复杂，即使自己做测试验证，也要有所聚焦，收敛，避免盲目的摊开式的测试。这就需要分析业务特点，缩小范围，有重点的测试验证。比如开发一些基准测试程序，做benchmark类的测试。这种方法对专门的驱动进行验证也是很有用的。
5 通过/proc/loadavg 可以“定量”的统计系统负载，在上述基准测试中，可以以此作为系统稳定性的参考指标。
6 通过top命令可以“定量”的统计CPU占用较高的线程，在不跑任何业务程序的情况下，可以对整个系统的运行情况作一个初步的评判。
7 程序内存占用过高或者内存泄漏，也会导致系统卡顿，可以通过内存分析工具，“定量”的分析系统内存使用情况，进一步的评判系统稳定性。
8 对系统CPU和内存定量分析后，接下来就需要对IO指标进行测试。上述驱动相关、业务相关的IO，要重点测试。比如，模拟业务场景，做超压测试，最好是能做到翻倍。
9 通过内核提供的perf工具，分析热点调用，这对于降低系统负载是有很大帮助的。
10 完成系统的整体测试后，为了获取更好的可靠性，还需要做一个长时间运行测试，俗称拷机测试。通过该测试，不仅可以规避一些时间和内存相关的问题，对硬件部分也是很好的验证。