嵌入式os稳定性工作总结
前言
最近对稳定性工作慢慢积累经验丰富了，想对这个嵌入式行业我的os稳定性工作做个梳理总结。
还是那句话，我喜欢把握整体业务和架构特点，从这方面入手比较好。
os稳定性工作价值体现
1 单元测试阶段体现不了，集成测试阶段才会有
因为产品的集成测试阶段，不再是各个子模块的单元测试了，这个时候关注的是整个os的系统稳定性。
单元测试阶段，其实有bug，各个子模块工程师很容易找出原因，不需要借助什么os稳定性分析工具。
但是集成测试阶段，各个子模块如果出问题，因为被厚厚的os层包裹着，并且各个模块耦合交织在一起，所以这个时候就需要体现os稳定性工程师的价值了。
举个例子：
比如手机平板之类的嵌入式公司，里面分成触控显示，多媒体组，usb/网口外设组等多个项目组。
如果是各个模块的单元测试阶段，每个项目组各自测试各自的模块，如果有bug，就在自己模块里面，很容易看出来的。
这个时候不需要什么os稳定性分析工具，比如linux下面的分析内核崩溃的kdump+crash工具，还有ftrace,bcc等高级稳定性分析工具也不需要太多。
当然了，稳定性工程师也可以做些效率提升工作，告诉各个项目组，多用些linux下面一些稳定性分析工具，有助于提升bug解决效率。
但是至少这个阶段，不会体现os稳定性工程师的痛点价值需求。
2 demo阶段也体现不了太多价值，作成产品量产交付阶段和售后服务阶段才会体现价值
嵌入式行业，很多特别是小公司，没有好的产品销售思路和渠道，没有优质客户，所以很多时候是在搞demo或者只能小批量的出货，也就是所谓的demo厂。
这个时候也体现不了太多稳定性工作价值。
因为搞demo或者产品出货量小时，也不会有太多或者复杂难解os稳定性问题存在。这些公司很多时候是在搞产品的功能集成和驱动自身稳定性。
只有量产阶段(大批量出货)，集成化测试才能体现意义，然后稳定性工作就来了。
举个例子：
手机快量产阶段，小米有mtbf压力测试，有成熟的自动化测试脚本，每天几百台手机在压测，还有独立的测试组，雇佣大量人员给研发提稳定性bug。
而且手机软件开发版和稳定版是分开的，开发版多是小米内测手机用户会用，一些比较前沿或者激进点的手机功能开发，会先进开发版，这个时候还会再发现一些稳定性bug。
所以大厂对产品稳定性质量把关测试，还是有很多值得学习的。
还有售后服务阶段，像小米手机出货量大时，一年几亿部，手机售后软件故障处理是很忙的。
为了保住用户群体那边的口碑，大厂在这方面做了用户手机稳定性问题方面的大数据跟踪，
这样可以提前收集一些特定用户机型方面的稳定性问题特征，在用户反馈问题或者稳定性问题大规模爆发之前，就可以提前解决该问题。
3 总结：
os稳定性工作是和系统的整体表现相关的，产品的集成化测试阶段，大批量的生产交付和售后故障处理阶段，os稳定性工作才能显示出痛点价值。
所以还要去大厂，才能真正学到os稳定性工作价值。
os稳定性工作总结
小米和后来我呆的这家芯片公司，我做的稳定性工作价值还是需要梳理总结下。
1 效率提升
目标是提升问题分析解决效率。
linux下面有很多丰富的稳定性问题分析工具，比如ftrace, kprobe, bcc，perf等。这些工具充分利用起来后，
其实是可以不需要在内核里面加任何printk类似打印调试语句的，这样加打印语句，重编内核再调试也麻烦耗时。
而且动态修改内核时，也可以借助上面提的工具。
总之，稳定性工程师可以利用这些工具，在公司内部推广，提升驱动工程师解决问题效率。
我之前推广后，驱动工程师工作效率比以前至少提升了一倍多。
2 降低研发成本
芯片公司需要用到trace32调试工具，不过trace32的独特价值是体现在它解决芯片总线hung死或者cpu彻底死掉等难解硬件问题上。
很多os软件问题不需要用到trace32。
我所在的芯片公司，很多内核或者驱动问题的定位，还需要借助trace32,这样公司的trace32数量就不够用了。
我开发了arm64上self-hosted调试工具: kdb/kgdb，可以一定程序上代替trace32来做稳定性问题定位。
3 稳定性工作具体内容
1）死机崩溃问题解决
需要对os异常这块有所熟悉，对arm64体系架构异常这部分有所熟悉，知道来个异常，怎么区分是cpu取指错误(通常是非法指令或者未定义指令，可能是ddr错误)，
还是mmu错误(这个通常是软件错误，和前面取指错误一样都是同步精确异常)，还是外部硬件错误(这个通常是外部事件产生的异步异常，就是非精确异常了)。
如果是mmu类型的异常错误，还得有栈回溯推导这一基本技能，会从崩溃task栈上提取有用信息。
2)内存和存储之类问题。
内存方面通常是内存泄漏，内存踩踏。存储方面通常是文件丢失，文件损坏，文件系统挂载出问题等。