半个系统软件工程师的困惑

前言：这篇文章之前发布在弯曲评论，有很多大牛的评价，值得一看：

http://www.tektalk.org/2012/01/20/半个系统软件工程师的困惑/#comments

半个系统软件工程师的困惑
半个系统软件工程师，是对自己的评价，因为清楚成为一个系统软件工程师要求的掌握的知识实在太多了：OS,处理器，编译器，协议栈，硬件等，希望自己能达到半个的水平:)。
开宗明义，我是H公司的，06年进入，一直从事平台软件的开发。但现在对于如何发展却存在很大的困惑，因此，期望得到各位前辈的指点。
在公司，有幸听到了陈首席的一次讲座，题目好像叫系统软件工程师的方法论，当时印象比较深的有三点：1，在通信公司做系统软件，做好能掌握总线技术。总线技术是我的薄弱点，属于两眼一抹黑，一直心有戚戚；2，cache是最容易忽略，又是最容易犯错的。之前公关xscale的cache问题就很有印象，听了此话后，又赶紧回去翻翻arm，ppc的手册，把cache的相关章节好好过一遍；3，系统软件工程师比较容易受委屈，很多问题虽然不是你的问题，也要你去定位分析。这点特别有感触啊。
略举例一二：
有个简单的功能模块提供了索引机制，供业务模块使用，业务模块不停的有释放申请呼叫控制块的操作，通过索引功能，可以快捷的申请到控制块。有个问题发现申请到索引非值常大，超过了正常范围，经分析，为索引的数据结构被踩了（虽然有内存分段隔离机制，但还是避免不了啊），业务模块踩内存的可能性比较大，排查了好久，也没有找到。当时部门领导就说了：找不到问题就是你的问题。我在旁边听了，那个郁闷啊（此问题非我分析，由同组的另外一个兄弟操刀），但想想，还能拍桌子不成。
有一个ftp下载的问题，有个兄弟分析了几天也没用进展，我协助分析下，很快就找到原因。直接主管说了一句话：感觉你定位问题好有天分啊。虽然是表扬，但心里郁闷啊，他哪里知道以前的我，为了定位一个丢包问题（测试抱怨呼叫一晚上，总是有十几次的呼损，分析原因就是MOT（MessageOverTCP）丢包了，当时为了定位这个问题，窝在实验室抓包，分析码流，最后发现是接口板的微码做完五元组后重算校验和时，进位的那一行代码有BUG。后来其他的一些丢包断链问题，让我把红宝书翻了好几遍，TCP的实现代码也仔细分析了一把。领导只是看到了结果好像很轻松，哪里知道后面付出了多少代价。
之前的系统是基于vxworks的，为了能快速分析出现的问题，还把vxworks的源码分析了一遍，重点代码研究了好几次（任务调度切换，中断异常，信号量，内存）后，打开源码，顺着目录一个个文件的阅读。后来看到了士兵突击里许三多说按字母顺序看图书，鼻子一酸。
    这两年整linux+x86，又是一次艰巨的任务。
    抱怨了这么多，感觉走系统软件工程师这条路，实在太辛苦了，学的东西多，发展又慢，还需要给别人擦屁股，现在不知道何去何从。看着做业务的，个个上升的很快，实在是羡慕嫉妒恨啊。之前分析问题时，也浏览过部分业务软件，就是个大case啊，解析消息，回应答，心有不甘啊。
1，系统软件（偏向于OS方向）有多大的发展前途，感觉就只能在可靠性，可维护性，适配上下功夫。
2，去互联网公司（如百度，QQ，假设能去的话）整系统软件会比在H公司更有前途吗？
3，转行做APP呢？


新年来了，顺祝各位弯友龙马精神，家庭幸福。

备注：系统软件（偏向于OS方向）有多大的发展前途，感觉就只能在可靠性，可维护性，适配上下功夫。

----这里是从代码层面说的，与学界的研究不是同一个意思。