零九年似乎一直都在赶项目，而这次和阿软 UED 合作的项目情况尤为特殊，但这次项目让我获得良多。

不同风格和节凑的团队如何融合一起

每天都在用阿里旺旺，这次让我更近得了解了 他们的开发团队 。 本以为阿里系 UED 都是差不多风格，但我发现还是有各自的特色。搬到阿里软件的头几天， 就碰到如何相互分工合作的问题。

首先，我们花了些时间熟悉对方的产品以及代码产出物，以便熟悉其代码和设计风格。 然后，在大范围的空间中，约定了些大框架的规范（包括视觉规范、DPL、代码规范 等）。流程方面情况比较特殊，我们尽量简化和精简了开发流程。

然后，在产品分模块以后，明确了小组对应每个模块开发的负责人。前端和视觉不同的负责 人将对应的开发模块逐渐的连线，这样在方便了各自了解进度的同时，也可以让身处不同小 组的人员相互的熟悉。

经过一段时间的磨合，两个不同的团队已经可以很默契的配合了。顺便在这里惊叹于， 在出发点以及目标一致的情况下，各小组的人员的动能是如此的强大。

人件

项目进度的瓶颈在于我看来，不是时间、不是技术而是人。天时地利，还需要人和。这里所 谓的「人和」，指的是小组各成员的士气以及状态。在这段「特殊时期」中，我能想到些措施

1. 放音乐，缓解下气氛
2. 自由上下班时间，只要不是「太过份」即可
3. 适当调整下工作内容，不要让组员太枯燥
4. 小的练手的技术点，可以使用「竞标」政策
5. 在群里贴美女照片 :^)

进度和质量之间的博弈

尤其紧急的项目，PM 和 PD 对于项目进度就抓得越紧。这有时候未必会是件好事， 开发们会以为，可以因进度就可以抛弃些更为重要的点。

我曾经不止一次在邮件列表中将这一情况加入到「风险点」中，好在经过沟通我们的 PM 站在了我们这边。项目的开发人员也逐渐明白，在核心质量的代码上现在花些时间， 对于以后维护而言是有好处的。

如何避免因赶进度而带来的产品质量下降等风险，这说到底其实是个博弈问题，这就看开发 人员以及 PM 对于该项目是如何定位的了。

对于加班的态度

几乎每个管理人员都会认为，加班是赶项目进度的救命稻草，我个人对此持保留态度。坦白讲， 每个人都不喜欢加班，尤其是无偿无理由的加班，更不期望看见因为 KPI 而加班。

让员工每天朝九晚九以及周六都过来加班，他们的个人时间受影响不说，还可能使他们的士气受 挫，甚至会因此而产生抵触情绪。长此以往，这种情况得不到解决，那么后果将会很严重。

对于管理者而言，都恨不得项目第二天就上线，但毕竟罗马城不是一天就建成的。与其做好我们 这些底层开发人员的思想工作，还不如让那些管理人员想明白些这些事理更能治本。

最后，还是期待公司能有套更为合理的奖励体系，毕竟每个员工对于公司的付出，他们总是期望能得到肯定的。

「没 Javascript 就会死」的页面通常都会加入 noscript 标签用于提示用户开启脚本支持。 然而在 IE8 下，如果在 noscript 标签上设置了 background-color 或者 border 样式，则无论脚本是否开启 IE8 还是会将其显示（还只是显示轮廓，并不显示内容）。

期前也碰到过这样的问题，不过当时 IE8 处于 RC 中，所以我直接使用脚本将其 display:none; 绕 过了这个问题。今天又在 positioniseverything.net 上看见了这个 Bug ，测试了下 Win7 RTM 上的正式版 IE8 ，发现还是存在这一问题，Sucks~

目前能想到的解决方案就是不要在 noscript 直接定义样式，可以其内部包含个 div 等块元素控制其具体样式。

IE8 正式版本推出将近半年，Buglist 也越来越完善，不知道这是件好事还是件坏事 :^(

-- EOF --

原文链接： http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

你可能对于 Linux 的负载均值（load averages）已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到，它们可能会显示成这个样子：

load average: 0.09, 0.05, 0.01

很多人会这样理解负载均值：三个数分别代表不同时间段的系统平均负载（一分钟、五 分钟、以及十五分钟），它们的数字当然是越小越好。数字越高，说明服务器的负载越 大，这也可能是服务器出现某种问题的信号。

而事实不完全如此，是什么因素构成了负载均值的大小，以及如何区分它们目前的状况是 「好」还是「糟糕」？什么时候应该注意哪些不正常的数值？

回答这些问题之前，首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明， 一台只配备一块单核处理器的服务器。

行车过桥

一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥 费 -- 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。

因此，需要些特定的代号表示目前的车流情况，例如：

• 0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。
• 1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。
• 超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。 那么情况有多糟糕？ 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。

上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。

和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。

「所以你说的理想负荷为 1.00 ？」

嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70：

• 「需要进行调查法则」： 如果长期你的系统负载在 0.70 上下，那么你需要在事情变得更糟糕之前，花些时间了解其原因。
• 「现在就要修复法则」：1.00 。 如果你的服务器系统负载长期徘徊于 1.00，那么就应该马上解决这个问题。否则，你将半夜接到你上司的电话，这可不是件令人愉快的事情。
• 「凌晨三点半锻炼身体法则」：5.00。 如果你的服务器负载超过了 5.00 这个数字，那么你将失去你的睡眠，还得在会议中说明这情况发生的原因，总之千万不要让它发生。

那么多个处理器呢？我的均值是 3.00，但是系统运行正常！

哇喔，你有四个处理器的主机？那么它的负载均值在 3.00 是很正常的。

在多处理器系统中，负载均值是基于内核的数量决定的。以 100% 负载计算，1.00 表示单个处理器，而 2.00 则说明有两个双处理器，那么 4.00 就说明主机具有四个处理器。

回到我们上面有关车辆过桥的比喻。1.00 我说过是「一条单车道的道路」。那么在单车道 1.00 情况中，说明这桥梁已经被车塞满了。而在双处理器系统中，这意味着多出了一倍的 负载，也就是说还有 50% 的剩余系统资源 -- 因为还有另外条车道可以通行。

所以，单处理器已经在负载的情况下，双处理器的负载满额的情况是 2.00，它还有一倍的资源可以利用。

多核与多处理器

先脱离下主题，我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解，一台主 机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。

但即便这些因素造成的实际性能稍有不同，其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则：

• 「有多少核心即为有多少负荷」法则： 在多核处理中，你的系统均值不应该高于处理器核心的总数量。
• 「核心的核心」法则： 核心分布在分别几个单个物理处理中并不重要，其实两颗四核的处理器 等于 四个双核处理器 等于 八个单处理器。所以，它应该有八个处理器内核。

审视我们自己

让我们再来看看 uptime 的输出

~ $ uptime
23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36

这是个双核处理器，从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7，我也从来没有考虑过它的负载问题。

那么，怎么会有三个数字的确让人困扰。我们知道，0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题：

• 我们以哪个数字为准？一分钟？五分钟？还是十五分钟？ *

其实对于这些数字我们已经谈论了很多，我认为你应该着眼于五分钟或者十五分钟的平均数 值。坦白讲，如果前一分钟的负载情况是 1.00，那么仍可以说明认定服务器情况还是正常的。 但是如果十五分钟的数值仍然保持在 1.00，那么就值得注意了（根据我的经验，这时候你应 该增加的处理器数量了）。

• 那么我如何得知我的系统装备了多少核心的处理器？ *

在 Linux 下，可以使用

cat /proc/cpuinfo

获取你系统上的每个处理器的信息。如果你只想得到数字，那么就使用下面的命令：

grep 'model name' /proc/cpuinfo | wc -l

- eof -