2012年即将过去，从毕业到现在一年半时间，在w公司的维护岗位上也工作了整一年。这一年时间里，像大多数运维人员一样，每天24小时待命，也有半夜被叫起来处理问题的苦逼，但回望这一年维护工作，更多的是为能学到知识而感到欣喜。在此记录下2012年工作、学习经历的点滴，与大家分享。
问题终结者
先说一下这一年的工作内容，我所在的部门为公司其他部门提供底层平台 (包括服务器硬件设备、suse linux操作系统、HA及其他中间件软件)，部门自身没有面向外界的产品，所在的小组负责维护线上服务器设备，我平常的工作以解决线上发生的操作系统相关问题为主。
平台支撑了很多上层业务，线上在用的设备数量也很庞大，由于基数大，即使问题发生的概率小，问题仍然很多。这一年处理了各种各样问题，从ftp、ntp配置到系统crash分析，从黑客攻击到IO性能调优，有人为误操作造成的问题，也有kernel bug导致的问题，可谓不一而足，包罗万象，偶尔还会遇到问题集中爆发的情况，这时一个人不得不同时应对3、4个问题。
问题不停地发生，从公司的角度看，解决问题是为了尽快恢复业务，而从个人角度来说，更多是通过处理问题的过程，提升个人技能。经过这一年问题处理，总结起来有以下收获：
1. 学会使用Linux各种命令，了解如何完成网络配置、启动配置、各项服务配置等，能较熟练地使用Linux
2. 了解了进程管理和调度、内存管理等内核子系统，对Linux内核有了入门的认识，整理有以下学习总结：
3. 学会使用sar、top、iostat、vmstat等工具，识别系统资源(内存、cpu、IO)瓶颈，学会使用pidstat、strace、pstack、oprofile等工具，进行基本的程序性能分析和调优
4. 掌握了一些问题处理思路与方法，学会从操作系统的角度看待和分析程序问题，因经常被别人问问题，也常向他人提问，懂得了如何更有效地发问
看不见的牢笼
列举完从工作中所学的东西，再谈一点感悟。
由于有不少问题涉及上层业务程序 (如程序的cpu占用率高、读写磁盘慢等)，对这些问题，业务开发的同事会和我们一同定位分析，与很多同事接触后发现，有相当一部分开发人员对操作系统缺乏基本的了解。
“cpu占用率统计中，sys、user、io wait各列表示什么意思？”，“调用write函数之后，程序buffer中的数据是如何最终写到磁盘的？”，“调用glibc库的malloc函数之后，程序是否就获取到了系统分配的物理内存？”，且不说这些问题，遇到过有5、6年编码经验的开发人员，尚不知道cache/buffer的作用。
"我只负责这个模块，别的我不清楚”，相信像这种只关注自己那一小块田地的程序员并不是特例，经常依赖他人解决问题、缺乏学习主动性、甘做螺丝钉，这无形中给自己建起一道与外界隔绝的墙，慢慢地，这些人的编码、分析及其他方面的技能逐渐退化，并开始习惯于推诿、扯皮、讲流程，三五年后，即使有想转身的意识，但因自己仅熟悉的那块并不能适用于其他公司、其他领域，最终会发现自己不得不依靠自己建起的牢笼生存。
为避免道路越走越窄，我们应该培养自己精专的一两个技术方向，同时广泛涉猎其他技术领域；学会熟练使用一两门编程语言，当有其他语言、框架更适合完成某个项目或功能时，不因自己不熟悉这门语言而抗拒，不参与纯粹的编程语言孰优孰劣的争论；不论是架构设计、前后端开发，还是DBA、测试、运维等，做好所在岗位，同时尝试积累其他岗位的经验。
生命不息，折腾不止
正如上面所列，这一年我工作中用到Linux操作系统相关知识比较多，几乎没有涉及开发编码。为了不让自己编码方面的技能退化，闲时走读了memcached、redis、libevent的源码，对redis、mongoDB等nosql数据库的应用场景进行了解，编写了一个以redis作数据库的用于标签管理的node.js模块，研究了一下如何使用新浪微博开放接口完成登录授权、微博数据抓取，使用新浪云计算平台sae和一份开源图站源码，部署了自己的一个关于旅行的小图站 (github地址点击这里)。
一个技术人员会什么并不能体现其价值，其价值应体现在参与了什么项目，实现了什么功能，解决了什么问题，所做的事情达到什么效果，具有什么影响。在明年我期望自己在技术技能上有更多地积累、更深地沉淀，同时能利用所学知识创造更多的价值。
最后，祝大家在2013年过得更有意义、更加精彩。
