写给初学计算机的朋友（2）

 略有小成：

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