夕雾的六年学习心得――写给初学计算机的朋友

这是我两年前写的文章，现在看来还是可以拿给初学者看看，看自己是一个什么样的位置，三五年的时间内可以努力到什么位置。

##################################################

我从业也有六年时间了，老男孩让我跟大家说说学习的经验心得，让大家共同进步。我仔细想了想，告诉大家路该怎么走的工作老男孩已经走的很多了，我想从另一个角度告诉大家，技术之路一步步走过去该是怎么样的风景。

我把技术之路大致分为四个阶段，分别是初窥门径、略有小成、返璞归真、修成正果，具体的表现如下：

初窥门径：

我们都是从这一步走过来的，从打字都磕磕巴巴的懵懂岁月走过来的，这个阶段的技术人应该做到这几点：

1， 良好的信息搜集、理解能力；

这个阶段我们什么都不懂，什么都不会，我们知识的来源都来自老师的讲解，都来自网上成千上万的教程。

我们要搭建一个DHCP服务器，我们必须先搜集信息，知道什么是DHCP服务器，然后搜到一篇比较靠谱的教程就照着去做，这就是信息搜集的过程。

我们开始搭建这个DNS服务器，老师的教程中明明提到了要用redhat 企业版，我们却在一个FreeBSD尝试安装bind*.rpm，这就是我们的理解能力出了问题。

以上还是比较简单的情况，实际上网上搜到的教程是良莠不齐的，好多教程你无法照做出来是因为作者并未说明足够完成试验的信息，甚至有可能打字都打错了。排除迷雾的干扰，乃至果断放弃一段垃圾信息，也是一种很重要的能力

2， 细至微末的执行能力；

比如说，教程上让你执行“echo $LANG”,你却执行了“echo $lang”，大小写不同的的两个英文字母代表完全不相干的两个意思。类似的事情还有很多，多一个空格，少一个分号导致试验无法完成的情况很多。Linux是用文件来定义、控制一切资源和行为的，我们必须明白，失之毫厘的输入错误，很可能会导致差之千里的执行结果。在不了解为什么教程上让你输入“$LANG”的情况下，不要自作主张的把“LANG”写成“lang”。

3， 熟能生巧，尝试缩短试验的时间；

我们的时间都是有限的，一些繁琐的、我们已经明白原理的实验是可以尽量缩短时间或者不做的。

比如说，我们要对apache进行调试，那我们可以在编译完成apache以后就做一个系统快照；每天就这么几个小时的时间能集中精力学习，我们不要把时间浪费在搭建实验环境上。

第二就是如果试验过程中有一堆繁琐、需要重复执行、但不怎么需要人工干预的操作，那我们可以将其写成一串组合的命令，或者一个脚本。例如下文：

echo  " apache  process `ps  -ef|grep "^$USER\ "|grep  httpd |grep -v grep|wc -l`" ;echo  " java  process `ps  -ef|grep "^$USER\ "|grep  java |grep -v grep|wc -l`"

4， 简单的替换试验参数、多种试验简单组合；

有句俗话叫“照葫芦画瓢”，当你能完成教程上的基本任务以后就可以“照着葫芦画类似葫芦的东西了”。

老师让你实现这个功能——“搭建apahce服务器，监听端口为80，设置虚拟主机为a.com。”，你可以逐步完成这种实验：

“搭建apahce服务器，监听端口为80，设置虚拟主机为a.com。”

“搭建apahce服务器，监听端口为90，设置虚拟主机为a.com。”

“搭建apahce服务器，监听端口为90，设置虚拟主机为b.com。”

“搭建apahce服务器，监听端口为90，设置虚拟主机为b.com，自定义输出log的格式。”

“搭建nginx服务器，监听端口为90，设置虚拟主机为b.com，自定义输出log的格式。”

在你自己一次次摸索中，自己必然能得到很多照本宣科无法得到的经验。

但是！可能这样碰出来的经验是错的，你甚至无法确定你这样碰撞是否能给别的环境套着用。所以我建议你摸索出经验以后就和别人分享一下。

除此之外，还有另外一类试验方法可以极大的提高你的能力。比如说你今天学了mysql，明天学了apache，那你学习PHP的时候就可以尝试搭建lamp环境安装个PHP论坛。这种联合试验，不仅让你复习了每个实验环节，熟悉了各个环节之间的关系，也为你能力水平的进阶打下了基础。

5， 能明白这个试验是用来解决什么技术问题的。

不要觉得这个要求很低，事实上针对不同的需求有千千万万种实现方案，但其中80%是只能是学习测试、自娱自乐用的。生产环境中可能连使用哪个版本的gcc都可能要反复斟酌;比如说现在千篇一律都是吹捧nginx的文章，但为什么还有很多人坚持用apache1.3？

现在你学的知识是一把钢刀，只有你充分试验和了解了之后，你才有能力抓住这把钢刀的刀柄而非刀刃。

略有小成：

1， 能根据自己的实际需要去规划实验方法，且侧重点发生变化；

别人发到网上的教程毕竟只是教程，实际工作中每个企业的需求都不同。比如说我们一般学习java中间件都是学习tomcat，但在新的工作环境中要用到resin；我去查阅了一些resin的资料，结合现有的apache+tomcat的方法自行完成了apache+resin的测试。

而且这个时候你做实验从过去侧重能不能试验成功已经变为能不能稳定、高效的运行。让一个apache show出来“It's work”很容易，但让一个apache能连续多年、大并发量运行，就绝不是一件容易的事情了。

2， 能看懂日志，通过看懂日志进行debug操作；

在我们能看懂日志以后，我们才算真正能明白系统和程序都做过什么。

当一个程序运行时，有运行日志，我们可以通过这些日志观察他的运行状态；

比如说apache访问日志可以让我们知道大家经常访问我们的哪个网页。

当一个程序故障的时候，有故障日志，我们可以通过这些日志观察它是因何而故障的；

比如说apache拒绝新的链接了，我们查询日志发现是超过最大连接数了。

当一个程序失去响应甚至无故退出的时候，我们可以根据系统日志乃至内存转储来搜集我们想要的信息，判断究竟出了什么故障。

比如说apache的静态文件放在一个NFS目录上，现在访问apache的时候有一段时间报“404 file no find。”，但过后又自动恢复了；OK，我查询系统日志发现故障时间点网线被人拔掉过，那NFS共享肯定就不能用了，我们也就不用从apache的角度去找问题了，直接让IDC机房调监控录像就OK了。

3， 思考数据在试验中的流动过程，思考实验的原理；

当你搭建了一个LAMP+Discuz后请你思考一下，你打开默认首页的时候数据是怎么流动的？当你打开论坛账户内的短信息的时候，数据是怎么流动的？下面我列举的对象，在这两步小小的操作中都起到什么作用哪？

用户的浏览器

服务器的域名 

IP/端口 

Apahce

PHP

Discuz 

Mysql

我们知道水流的规律是往低洼处流动，所以我们能引导江河的流向；等我们能理解数据流动的规律以后，我们也能引导计算机为我们工作。

4， 可以书写有自己见解的实验报告；

大家都不愿意写报告，但写报告有如下优点：

△ 请告诉我，下公交车后的五分钟里，你遇到了几个路人？工作过程中的每个小细节都可能被你忽略，但负责任的写下来你自己才能明白自己具体做过什么。

△ 有个孩子脾气特别坏，特别喜欢骂人，他的父亲就逼他把自己想骂人的话都写在纸上，最后这个孩子的脾气就日渐和善了。我们在上机操作的时候动作都很快，其中一些小细节的问题都会被我们忽略掉，而在尝试记录这些东西、梳理自己记忆的时候很容易被自己的鲁莽行为惊出一身冷汗。

5， 自己的实际需要去改造现有的业务方案；

接手一个旧的项目要比建立一个新的项目更难，特别在一些不够规范的企业里，前任或者没留下任何资料，或者留下的资料让你一个字都看不懂。这个时候我们就要去自己搜集自己关心的信息，从细节的服务器配置，到完整的网络规划，都要像发掘古迹一样自己慢慢去梳理。只有技术到达一定水平的人，才能知道自己想要知道什么信息，才能知道怎么找到这些信息，才能真正去分析这些信息，才能最快适应新的环境。

反问一下你自己，如果你接手一个日PV千万的网站，你应该搜集哪些信息，你应该如何搜集这些信息，你能否正确的分析这些信息哪？

返璞归真：

1， 能透事物的表面规律去思索内在的运行规则，重新去品味《计算机原理》《操作系统概论》等书中提到的一些很基础很晦涩的计算机概念；学好数学，深入了解硬件特性和软件协议，计算机，在你眼中并不比一个算盘更复杂。

CPU为什么能“思考”东西，内存为什么掉电以后就不会保存数据，网线为什么要做成双绞线的形式？make和gcc有什么关系？ssh为什么是一种几乎不可破解的加密方式？

这些很基础的概念你不必理解也能工作，但也只是个熟练工人而已。要想有质的飞跃，必须有“量”的突破，这个“量”就是你对操作系统了解的知识量。

计算机本质上来说就是一个低效高速运转的二进制算盘，如果学好数学了，就更能从一个更基础的层面去分析问题，也能从更宏观的层面去分析问题。

2， 能够从一个更高的层面同时思考多个应用之间的协调、调度，能有效、经济的消除业务中的单点故障和性能瓶颈。

到了这个阶段，单台apache并发是1500还是1000已经并不重要了，有那些中低端工程师去做精工细活，你要关心的是，这十台apache如何协同工作？这20个数据库和数据库缓存之间如何保证数据一致？这里有两个100T的磁盘阵列柜，如何将这两个存储的空间稳妥、高效、经济的分配给100台服务器？更要命的是，这两个磁盘柜共用的一个光纤交换机，如何平滑的解决这个单点故障？

3， 当别人在为如何解决这个bug而头疼的时候，你为能完美复现这个bug而欢呼；这个时候，系统的不稳定因素已经被你稳稳的抓住。

当你初窥门径的时候，apache调不通正常，调通了就是惊喜；

当你学有所成的时候，apache调不通不正常，调通了很平常；但是出故障了恢复很正常，为什么出这些故障，出了这些故障为什么采用这种方法恢复，大都停留在不求甚解的阶段。

当你到一个新的阶段以后，你已经可以从更底层更高层两个方向来考虑问题了。你就会厌倦了每次都等待服务出现故障，然后傻瓜般去重启服务，你就有能力去认真剖析故障的来龙去脉，然后能完美复现和完美解决这个故障。

4， 对具体的业务部署、参数设置并不太了解也不太关心，一旦出现故障以后知道自己该搜集哪些信息进行故障判断，以及自己在进行debug操作时对系统会有哪些影响；

当一个顾客打电话问戴尔技术支持“为什么我的电脑的USB口从开机开始就不能用了？”。戴尔技术支持并不了解你的电脑是财务用还是人事用么？就算不了解这些东西，他们也会告诉你，“只要把机箱打开，然后抠下来电池就可以恢复默认主板设置。对了，恢复初始设置以后记得调一下硬盘选项，把RAID功能关掉，否则会蓝屏。”

可能你会笑这一问一答的内容很白痴，但是在不懂电脑的人眼里，这种解决问题的速度是最快，最有效的。如果你的计算机水平高到一定程度，别人的服务器出现故障以后，根据一个简单的故障描述你就应该知道问题出现在哪个范围之内，然后搜集自己最关心的信息，最快的速度解决问题。比如说解决一个apache 403的错误，他就不会去关心硬件Raid信息，也几乎不会看access log，更多是从权限角度去搜集信息。

我能力有限，无法举出太好的例子来。但是我在向一些高手寻求技术支持的时候，对方往往能一语中的，一下就能切中问题的要害。而且他们不了解我的服务器的状况，却能准确的估算出服务器可能潜在的风险。

修成正果：

或者开发出一种新的算法、或者研发出一种新的硬件架构。我们现在做的事情只是顺着别人的路走下去，就算跑的太快，也只能是个参赛选手、是个精英教练，却无法做规则的制定者，无法做比赛的裁判。但是现在国内尚无这种能开宗立派的高人出现……

看完了上文你就知道你现在处于哪个位置，继续走下去会是一个什么样的道路了。

另外我还想谈一下做技术人该有的心态：

1， 做技术必然是先苦后甜，不要急着第一年就和别人比工资，因为你的工资应该两年翻一倍；心燥的人做不了技术，一心一意、苦心孤诣才能做好技术；

2， 当你的工资不能实现两年翻一倍的目标时，你该考虑是自己太懒了，还是真的已经做到“返璞归真”这一步，已经做到技术的顶峰了；

3， 在工作学习中，一个实验/项目里，自己创新和现有技术的比率不应低于1：9，也不应高于3：7；

4， 对于做运维的人来说，稳定和效率的比率应该是7：3或者6：4，程序员可以重视效率甚于稳定，但运维人员的眼中只有稳定是第一位的；

5， 在自己技术做到一定高度之前不要思索“只有技术在职场上解决不了问题，我们还要如何如何……”，我只能说“用技术能解决的问题都不是问题，但没有技术的人会时时刻刻遇到问题。”