架构研究室

[转]提问的艺术

Johnny Woo — Tue, 18 Nov 2008 06:47:49 +0000

提问是一门艺术，需要充分的思考、技巧和练习，你不能帮助别人理解你的问题，就别想让别人帮助你。好的提问才能得到预期的答案。 lifehacker.com的一篇文章谈到如何在问问题时，无论被问的人是上司、同事、朋友，还是google，注意哪些方面才能尽最大可能得到你所需要的帮助：

问题要确定、具体
模糊、问不到点子上的问题别人无法回答。是什么东西不工作了？现象和结果是什么？出什么样的错误？具体的情况是怎样的？问别人之前先问自己一遍，把这些想清楚了再问别人，节省大家的时间。

提问之前自己先研究调查一下
问别人之前最好自己先找找答案。对于显而易见的问题，不调查一下就随便去问很招人讨厌，尤其是在一些论坛里。至少你应该先看看用户手册，搜一搜 google再去麻烦别人。搜不到再去问别人，可以告诉别人“我查过手册，但是没有”或者“我搜了google，但是没有找到”，至少你努力过，别人帮助你的几率也会大很多。

问正确的人
有时候抓到一个人恨不得什么问题都问他，就好像在论坛里乱发帖子问问题，对别人有时候也是一种困扰。找到正确的人，去正确的地方，你的问题才有可能得到回答，放过其他可怜的群众吧。

让被问的人觉得值得回答你的问题
“你做的这个软件根本不工作！我都快疯了！马上帮我解决这个问题！”
你可能是快疯了，可是如果把你的这种情绪传达给别人，未必有什么正面影响。
“你好，我对你的软件很有兴趣，正准备在我的blog里宣传一下，可是我碰到了一些问题。。。”
这样别人多半有兴趣帮你解决问题，并且很愿意和你这样一个热心的测试人员合作。

PS: 希望有些人能知道google怎么用.或者至少用用百度然后再问问题.

书评: Linux操作系统之奥秘

Johnny Woo — Thu, 13 Nov 2008 03:49:58 +0000

一直在买书看书
但是好久没有写书评了
可能是因为书太多.所以交叉着看都没来得及读完
从Feng的网站上看到推荐了一本[Linux操作系统之奥秘](免费给amazon做下广告.免运费送书,使我这个china-pub的4星会员不得不跳槽了)
看到一条 把硬件和操作系统结合起来讲
引起我的兴趣了.赶快买来一本.
心中抱着希望是那种会从硬盘引导开始一直讲到init启动的书.而且会很细.很全的那种
拿到手之后.我满足了
不仅从硬盘引导.还是从BIOS开始.一直到把控制权交给init
以前读过一本[Linux 0.01内核分析与操作系统设计--创造你自己的操作系统]
这本书就是从最原始的bootloader开始从头分析.
不过对于没有汇编基础或者C语言基础的人来说.这本书未免太底层了一点
而且即便是有基础的人.看起来也会很累.因为我们只要知道原理.不需要知道那么细节的内容
而我一直想要的一本书就是讲一些比较底层.能说明原理和过程的书.也就是知其然也知其所以然的的书.
这本书的序也提到,市面上的linux书籍,要不就在于管理或者建站,要不就是直接kernel源码分析.而没有讨论linux本身概念的书.中间其实是个真空地带.
简直是一语中的.目前linux书籍的现状就是如此.两个极端.要不就是只讲些鸡毛蒜皮的命令.要不就是直接把kernel源码拿出来给你看.而整个系统的概念.流程.都没有书提及.也一直是我觉得linux类书籍无书好看的原因.
1.命令我自己会去man,参数我自己会help,只要有些英文水平.根本用不到买书.
2.我不是开发驱动,裁剪内核的开发人员.给我看了内存调度算法.于系统管理来说有一定助益,但是成本太高.
读过一半之后.我觉得这才是一本可以真正给广大linux用户推荐的好书
一本能让新手管理员更了解linux整个体系和概念的书.
当然对于linux老手
这些概念早已经在多年的摸爬滚打中混熟了.
但是有人能够从头一点点的打散理顺.还是很有帮助的
特别是看了之后再去看那本linux 0.01内核分析
嘿嘿.自己搞搞实验还是非常有意思的.

MySQL performance tuning primer script 中文注释版

Martian Guo — Tue, 11 Nov 2008 03:43:17 +0000

mysql tuner-primer 是一个比较简单好用的检查mysql运行状态的shell脚本，它主要通过查询mysql中的variables设定和status 并结合当前系统情况给出mysql运行的状态和建议，主要包括以下内容的检查
slow query慢速查询
binlog 二进制日志
max connections 最大连接数
threads 线程数
key buffer size 关键字缓冲
query cache 查询缓存
sort operations 排序
join operations 多表联接
tmp tables 临时表
open files 打开文件数
table cache 表缓存
table locking 锁表
table scans 表扫描
innodb status
total memory used 内存使用

文件下载：tuning-primer

postfix 发信邮件服务器设置

Martian Guo — Thu, 06 Nov 2008 09:25:07 +0000

以下设置针对需要大量外发邮件的服务器，如果你的邮件服务器是专门用来发垃圾邮件的，那么下面这些设置恐怕也没有太多作用，下面的这些设置也仅仅是让我们发出的邮件更符合发送规则，当然了，如果滥发，不管你设置怎么样的策略，一旦超过了邮件运营商的限制，封你还是没商量的。

安装djbdns
djbdns 是一個由Qmail 的作者所设计的一个轻量级DNS server，我们使用它提供的dnscache服务作为本地邮件发送的DNS查询缓存，用于加快邮件的转发速度。
ucspi-tcp软件包由一组工具组成。它们用来简单的建立客户机－服务器tcp后台程序。TcpServer是一个比inetd安全性更好的选择。它内建有基于规则的连接控制，能完善地在达到预定义的最大系统负载时将连接推迟

shell>wget http://www.qmailtoaster.org/download/develop/ucspi-tcp-toaster-0.88-1.3.5.src.rpm
shell>wget http://www.qmailtoaster.org/download/develop/daemontools-toaster-0.76-1.3.3.src.rpm
shell>wget http://www.qmailtoaster.org/download/develop/djbdns-1.05-1.0.5.src.rpm
Shell >yum -y install rpm-build
shell>rpm -vih daemontools-toaster-0.76-1.3.3.src.rpm
shell>rpm -ivh ucspi-tcp-toaster-0.88-1.3.5.src.rpm
shell>rpm -ivh djbdns-1.05-1.0.5.src.rpm
shell>cd /usr/src/redhat/SPECS
shell>rpmbuild --bb daemontools-toaster.spec
shell>rpmbuild --bb ucspi-tcp-toaster.spec
shell>rpmbuild --bb djbdns.spec
shell>cd /usr/src/redhat/RPMS/i386
shell>rpm --ivh daemontools-toaster-0.76-1.3.3.i386.rpm ucspi-tcp-toaster-0.88-1.3.5.i386.rpm
shell>rpm --ivh djbdns-1.05-1.0.5.i386.rpm djbdns-localcache-1.05-1.0.5.i386.rpm
shell>rm {/var/djbdns/,/}service/{axfrdns,tinydns} // 我们只需要dnscache 服务
shell>echo -n 10000000 >/var/djbdns/dnscache/env/CACHESIZE // 修改DNS内存cache大小10M
shell>echo -n 30000000 >/var/djbdns/dnscache/env/DATALIMIT
shell>echo nameserver 127.0.0.1 >/etc/resolv.conf
shell>/etc/init.d/djbdns start

安装domainkey
雅虎的这项技术被称之为“DNS端的电子签名（DomainKeys）”，专门对付各种各样经过改头换面的垃圾邮件。垃圾邮件经常通过改动电子邮件的发送着对用户进行欺骗，用户往往会误以为这不是垃圾邮

件，因而打开查看的可能性加大。雅虎的“DomainKeys”允许接受电子邮件的系统对邮件进行检查，以确定邮件发送者的身份是不是假的。“DomainKeys”通过使用加密技术完成电子邮件发送者身份的
验证。外发的邮件通过私人密码进行数字签名，而接受电子邮件的系统则使用公共密码对签名进行核实。

shell>wget http://nchc.dl.sourceforge.net/sourceforge/dk-milter/dk-milter-1.0.1.tar.gz
shell>yum -y install sendmail-devel // dk-milter编译需要
shell>yum -y install csh
shell>tar -zxvf dk-milter-1.0.1.tar.gz
shell>cd dk-milter-1.0.1
shell>sh Build -c
shell>sh Buld install
shell>cd dk-filter
shell>chmod +x gentxt.csh
shell>./gentxt.sh default hiadmin.com // 保存输出的文字
shell>cp default.private /etc/postfix/hiadmin.com.key.pem // 拷贝私钥到/etc/postfix
shell>chmod 600 /etc/postfix/hiadmin.com.key.pem
shell>/usr/bin/dk-filter -A -l -p inet:8891@localhost -d hiadmin.com \ // 启动dk-filter签名服务
-s /etc/postfix/hiadmin.com.key.pem -S default

dk-filter 命令说明：

-a peerlist # 那些 host 不做 DKIM check
-A # dk-filter 死掉時自動重啟
-b modes # s (singer) / v (verify) 預設為 sv
-c canon # 預設是 simple (表頭不改變),
# 另外為 relaxed (表頭可能修正,去除空白,不換行等等)
-C config # 設定檔,詳見下述
-d domlist # 要 sign 的 domain 列表,以逗號區隔
-D # 一併 sign -d 之下 domain 的 sub-domain
-f # 前台執行
-h # 會在 Mail Header 中加入 X-DomainKeys 資訊
-H # DomainKey-Signature 中說明 sign 的 header 資訊
-i ilist # 只做 sign, 不做 verify,預設為 127.0.0.1
-I elist # 透過此主機轉信之來源做 sign,不做 verify
-l # log 必要訊息到 maillog
-m mtalist # MTA 名字,也就是 DaemonPortOptions 中的 Name,預設是全部
-M macrolist # MTA macros which enable signing
-o hdrlist # 哪些 Header 不 sign,Ex: -o to,subject,date , From 一定要 sign
-P pidfile # pid file 路徑
-s keyfile # private key
-S selector # selector,會以 selector._domainkey.Domain 進行 type=TXT 查詢
-u userid # 以什麼身份執行
-V # 版本資訊

将以下公匙记录到DNS Server 上
例：

default._domainkey IN TXT "k=rsa; t=y; p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALxzF8xb/uXCnC58p/kCLtxW5tm/xrR905O6X0C6Ydohw574EsimbCaeqsCtqm+3IKyrnBj3JeShbEGBJN5HEF0CAwEAAQ==" ;

----- DomainKey default for hiadmin.com

分别建立记录：

default._domainkey.hiadmin.com
_domainkey.hiadmin.com

设置一条txt记录：

k=rsa; t=y; p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALxzF8xb/uXCnC58p/kCLtxW5tm/xrR905O6X0C6Ydohw574EsimbCaeqsCtqm+3IKyrnBj3JeShbEGBJN5HEF0CAwEAAQ==

设置 SPF
Sender Policy Framework。SPF可以防止别人伪造你来发邮件，是一个反伪造性邮件的解决方案。当你定义了你的domain name的SPF记录之后，接收邮件方会根据你的SPF记录来确定连接过来的IP地址是

否被包含在SPF记录里面，如果在，则认为是一封正确的邮件，否则则认为是一封伪造的邮件。
例：

hiadmin.com. 466 IN TXT "v=spf1 ip4:61.xx.xx.xx ip4:61.xx.xx.xx mx ~all"

61.152.246.24-25 和 MX 记录中设置的主机为信任邮件发送服务器，其他全部不信任
修改 /etc/postfix/main.cf
增加

smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

测试
发一封信到google 检查邮件头是否包含了 DomainKey-Signature
如下所示

Received-SPF: pass (google.com: domain of public@hiadmin.com designates 61.xxx.xxx.xx as permitted sender) client-ip=61.xxx.xxx.xxx;
DomainKey-Status: good (test mode)
Authentication-Results: mx.google.com; spf=pass (google.com: domain of public@hiadmin.com designates 61.xxx.xxx.xxx as permitted sender) smtp.mail=public@hiadmin.com;

domainkeys=pass (test mode) header.From=public@hiadmin.com
Received: from pc00497 (unknown [211.xxx.xxx.xxx])
by hiadmin.com (Postfix) with ESMTPA id 980912580D1
for ; Mon, 27 Oct 2008 17:46:09 +0800 (CST)
DomainKey-Signature: a=rsa-sha1; s=default; d=hiadmin.com; c=simple; q=dns;
b=Q/1un1hpfsZP7zs+0rPsVzb3DFtpIaaGkPL2aSEjmQL7cx9Fhn8EtYLz1J8p7xKLt
lItLJN609cDDER5kjCJKg==

设置milter-limit 控制postfix 发送频率
milter-limit 是Sendmail 的一个filter，用于限制用户发邮件的数量，以防止邮件服务器
被非法用于发送垃圾邮件，它可以实现对指定的客户端IP、收件人、发件人进行限制。该
filter可以不做任何修改即可用于Postfix中
到www.snertsoft.com 下载 (需要注册)
http://www.snertsoft.com/download/milter-limit-0.13.tar.gz
http://www.snertsoft.com/download/libsnert-current.tar.gz

shell>yum install db-devel
shell> tar -zxvf libsnert-current.tar.gz
shell> tar -zxvf milter-limit-0.13.tar.gz
shell>cd com/snert/src/lib
shell> ./configure --with-db=/usr # 检查是否有Berkeley DB 支持
shell> make build
shell> cd ../milter-limit
shell> ./configure --enable-run-user=postfix --enable-run-group=postfix
shell> make build
shell> make install

修改 /etc/postfix/main.cf

smtpd_milters = unix:/var/run/milter/milter-limit.socket # 如果有多个milter 用逗号分隔

过滤规则：
milter-limit 的规则文件写在/etc/mail/access 中，然后用makemap 来生成
makemap hash /etc/mail/access.db < /etc/mail/acces
# 请注意access.db权限不能为可执行，并且可以让postfix 用户能够读取
/etc/mail/access 文件的规则包括

milter-limit-Connect: # 客户端连接IP
milter-limit-From: # 发件人地址
milter-limit-To: # 收件人地址
milter-limit-Auth: # 通过SMTP认证的发件人

支持以下匹配规则
[network/cidr]limit 无类域间路由
!pattern!limit 简单文本匹配
/regex/limit POSIX正则表达式

limit：时间单位可以是秒(s)、分钟(m)、小时(h)、天(d)、星期(w)
格式： messages ‘/’ time [unit]

过滤规则例子：

milter-limit-Connect:80.94 [80.94.96.0/20]-1/1 500/3d # 冒号之间不能有空格

# 80.94开头的网段：从地址80.94.96.0/20 (80.94.96.0- 80.94.111.255) 不受限制，其他地址限制在 3天内最多发送500封邮件

milter-limit-To:163.com 100/1h

# 发往163.com域限制在1小时发送100封邮件
策略：
启动参数： policy=reject

none 什么都不做
tag 给邮件标题打标签启动参数：subject-tag=[SPAM]
quarantine 将邮件送入隔离队列(不发送,需要通过命令激活).
later 不接收邮件，提示发送端发送延迟消息，邮件仍旧在发送端的队列中，稍候重试
reject 拒绝邮件（默认值）
discard 直接丢弃

启动命令

/usr/local/sbin/milter-limit verbose=all policy=later -start

如果需要调试使用 verbose=all 在/var/log/maillog 中查看日志
其他参数用 -help 参数查看
postfix 基本参数设置

smtp_skip_4xx_greeting = yes
smtp_skip_5xx_greeting = yes
default_destination_concurrency_limit = 2 #同一IP并发连接
initial_destination_concurrency = 2
smtp_helo_name = mail.hiadmin.com # 本机对外真实域名
smtpd_milters = inet:localhost:8891,unix:/var/run/milter/milter-limit.socket
#使用sendmail 的milter-limit 插件来实现对指定的客户端IP、收件人、发件人进行限制

[转载]大型网站运维探讨和心得

Michael Field — Thu, 06 Nov 2008 06:10:27 +0000

看到一篇不错的心得体会；相信我们做技术的都会有或多或少的担忧自己的未来职业发展：

今天看到一篇心得体会，转过来和大家一起探讨一下：

一、什么是大型网站运维?
首先明确一下，全文所讲的”运维“是指：大型网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上亿（至少国内排名前10），如sina、baidu、QQ，51.com等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如有些公司把一些合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责。所以，非常重要一定需要明白：运维对其它关联工种必须非常了解熟悉：网络、系统、系统开发、存储，安全,DB等；我在这里所讲的运维工程师就是指专职运维工程师。
我们再来说说一般产品的“出生”流程：
1、首先公司管理层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计。
2、架构师根据产品设计的需求，如pv大小预估、服务器规模、应用架构等因素完成网络规划,架构设计等（基本上对网络变动不大，除非大项目）
3、开发工程师将设计code实现出来、测试工程师对应用进行测试。
4、好，到运维工程师出马了，首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大：应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能\安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装。运维工程师还需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复使：需求->开发（升级）->测试->上线（性能、安全问题等之前预估外的问题随之慢慢就全出来了）在这里提一点：网站开发模式与传统软件开发完全不一样，网站一天开发上线1~5个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像M$ 需要1年解决，用户早跑光了；应用上线后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作：
a 、尽量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等等），提高效率。
b、解决现实中服务存在的问题，如高可靠性、可扩展性问题等。
c、大规模集群管理工具的开发，如1万台机器如何在1分钟内完成密码修改、或运行指定任务？2000台服务器如何快速安装操作系统？各分布式IDC、存储集群中数PT级的数据如何快速的存储、共享、分析？等一系列挑战都需运维工程师的努力。
在此说明一下其它配合工种情况，在整个项目中，前端应用对于网络/系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的功能性开发，并对应用本身性能、安全性等应用本身负责，它不负责或关心网络/系统架构方面事宜，当然软/硬件采购人员等事业部其它同事也不会关心这些问题，各司其职，但项目的核心是运维工程师~！所有其它部门的桥梁。
上面说了很多，我想大家应该对运维有一些概念了，在此打个比方吧，如果我们是一辆高速行驶在高速公路上的汽车，那运维工程师就是司机兼维修工，这个司机不简单，有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快，汽车本身不能满足高速度时对汽车性能调优或零件升级、高速行进中解决汽车故障及性能问题、时刻关注前方安全问题，并先知先觉的采取规避手段。这就是运维工作~！
最后说一下运维工程师的职责：”确保线上稳定“，看似简单，但实属不容易，运维工程师必须在诸多不利因素中进行权衡：新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维工程师了。
另外在此聊点题外话，我在这里看到有很多人要sina、QQ、baidu,51.com等聊自已的运维方面的经验，其实这对于它们有点免为其难：
a、各公司自已网络架构、规模、或多或少还算是公司的核心秘密，要保密，另外，对于大家所熟知的通用软件、架构，由于很多公司会根据自已实际业务需要，同时因为原版性能、安全性、已知bug、功能等原因，进行过二次开发（如apache,php,mysql），操作系统内核也会根据不同业务类型进行定制的，如某些应用属于运算型、某些是高IO型、或大存储大内存型。根据这些特点进行内核优化定制，如sina就在memcache上进行过二次开发，搞出了一个MemcacheDB，具体做得如何我们不谈，但开源了，是值得称赞的，国内公司对于开源基本上是索取，没有贡献；另外，服务器也不是大家所熟知的型号，根据业务特点，大部份都是找DELL/HP/ibm进行过定制；另外，在分布式储存方面都有自已解决方案，要不就是使用现成开源hadoop等解决方案，或自已开发。但90%都是借鉴google GFS的思想:分布式存储、计算、大表。
b、各公司业务方向不一样，会导致运维模式或方法都不一样，如51.com和baidu运维肯定区别很大，因为他们业务模式决定了其架构、服务器量级、IDC分布、网络结构、通用技术都会不一样，主打新闻门户的sina与主打sns的51.com运维模式差异就非常大,甚至职责都不大一样；但有一点，通用技术及大致架构上都大同小异，大家不要太神化，更多的公司只是玩垒积木的游戏罢了，没什么技术含量。
c、如上面所讲，目前大型网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一角，局限于具体技术细节，或某某著名网站大的框架，真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧。或者也是国内运维人员比较难招，比较牛的运维工程师比较少见的原因之一吧。

二、运维工作师需要什么样的技能及素质
做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多IT工种技能与一身的岗位，对系统->网络->存储->协议->需求->开发->测试->安全等各环节都需要了解一些，但对于某些环节需熟悉甚至精通，如系统(基本操作系统的熟悉使用,*nix,windows..)、协议、系统开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理）、通用应用（如lvs、ha、web server、db、中间件、存储等）、网络,IDC拓朴架构；
技能方面总结以下几点：
1、开发能力，这点非常重要，因为运维工具都需要自已开发，开发语言：c/c++（必备其中之一）、perl、python、php（其中之一）、shell（awk,sed,expect….等），需要有过实际开发经验，否则工作会非常痛苦。
2、通用应用方面需要了解：操作系统（目前国内主要是linux、bsd）、webserver相关(nginx,apahe,php,lighttpd,java。。。)、数据库(mysql,oralce)、其它杂七八拉的东东。。。系统优化，高可靠性。。。这些只是加分项，不需必备，可以边工作边慢慢学，这些东西都不难。当然在运维中，有些是有分工偏重点不一样。
3、系统、网络、安全，存储，CDN，DB等需要相当了解，知道其相关原理。
个人素质方面：
1、沟通能力、团队协作：运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；这应该是现代企业的基本素质要求了，不多说。
2、工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师是网站admin,最高线上权限者，一不小心就会遗憾终生或打入十八层地狱。
3、主动性、执行力、精力旺盛、抗压能力强：由于IT行业的特性，变化快；往往计划赶不上变化，运维工作就更突出了，比如国内各大公司服务器往往是全国各地，哪里便宜性价比高，就那往搬，进行大规模服务迁移（牵扯的服务器成百上千台），这是一个非常头痛的问题；往往时间非常紧迫，如限1周内完成，这种情况下，运维工程师的主动性及执行力就有很高的要求了：计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯皮,7X24小紧急事故响应等。
4、其它就是一些基本素质了：头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观。
5、最后一点，做网站运维需要有探索创新精神，通过创新型思维解决现实中的问题，因为这是一个处于幼年的职业（国外也一样，但比国内起步早点），没有成熟体系或方法论可以借鉴，只能靠大家自已摸索努力。

三、怎样才算是一个合格的运维工程师
1、保证服务达到要求的线上标准，如99.9%；保证线上稳定，这是运维工程师的基本责职所在。
2、不断的提升应用的可靠性与健壮性、性能优化、安全提升；这方面非常考验主动性、和创新思维。
3、网站各层面监控、统计的覆盖度，软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用的运转情况。
4、通过创新思维解决运维效率问题；目前各公司大部份运维主要工作还是依赖人工操作干预，需要尽可能的解放双手。
5、运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性范错。
6、计划性和执行力；工作有计划，计划后想法设法达到目标，不找借口。
7、自动化运维；能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统；让大家更多的时间用于思考、创新思维、做自已喜欢的事情。
以上只是技术上的一些层面，当然个人意识也是很重要的。

四、运维职业的迷惘、现状与发展前景
运维岗位不像其它岗位，如研发工程师、测试工程师等，有非常明确的职责定位及职业规划，比较有职业认同感与成就感；而运维工作可能给人的感觉是哪方面都了解一些，但又都比上专职工程师更精通、感觉平时被关注度比较低（除非线上出现故障），慢慢的大家就会迷惘，对职业发展产生困惑,为什么会有这种现象呢？除了职业本身特点外，主要还是因为对运维了解不深入、做得不深入导致；其实这个问题其它岗位也会出现，但我发现运维更典型，更容易出现这个问题；

针对这个问题我谈一下网站运维的现状及发展前景（也在思考中，可能不太深入全面，也请大家斧正补充）

运维现状：
1、处于刚起步的初级阶段，各大公司有此专职，但重视或重要承度不高，可替代性强；小公司更多是由其它岗位来兼顾做这一块工作，没有专职，也不可能做得深入
2、技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。
3、体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空间了。
4、优秀运维人才的极度缺乏；目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技术都局限在各大公司内部，如google 50万台机器科学的管理,或者国内互联公司top 10 的一些运维经验，这些经验是非常有价值的东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通、贯通、与借签，并最终将限制了运维发展。
5、很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量PV、硬件规模足够大，如baidu可怕的流量、51.com海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大公司可能已有很好的解决方案或系统。
发展前景：
1、从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂；对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化。
2、从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视。
3、网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好的个人能力与技术广度的发展空间。
4、运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、全局思考能力等。
5、特长发控和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家。
6、如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做。
7、技术发展方向、网站/系统架构师。

五、运维关键技术点解剖
1、大规模集群管理问题
首先我们先要明确集群的概念，集群不是泛指各功能服务器的总合，而是指为了达到某一目的或功能的服务器、硬盘资源的整合（机器数大于两台），对于应用来说它就是一个整体，目前常规集群可分为：高可用性集群（HA），负载均衡集群（如lvs），分布式储、计算存储集群（DFS，如google gfs ,yahoo hadoop），特定应用集群（某一特定功能服务器组合、如db、cache层等），目前互联网行业主要基于这四种类型；对于前两种类似，如果业务简单、应用上post操作比较少，可以简单的采用四层交换机解决（如f5），达到服务高可用/负责均衡的作用，对于资源紧张的公司也有一些开源解决办法如lvs+ha,非常灵活；对于后两种，那就考验公司技术实力及应用特点了，第三种DFS主要应用于海量数据应用上，如邮件、搜索等应用，特别是搜索要求就更高了，除了简单海量存储，还包括数据挖掘、用户行为分析；如google、yahoo就能保存分析近一年的用户记录数据，而baidu应该少于30天、soguo就更少了。。。这些对于搜索准备性、及用户体验是至关重要的。
接下来，我们再谈谈如何科学的管理集群，有以下关键几点：
I、监控
主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行，及潜在问题的及时发现与干预；
a、服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端web server，我们就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否crash、通过icmp包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，常用方法是采用面业特征码进行判断，或对重点页面进行签名，以网站被黑篡改（报警、并自动恢复被篡改数据）等等，这些只是一部份，还有N多监控方式，依应用特点而定，还有一些问题需解决，如集群过大，如何高性能的进行监控也是一个现实问题。
b、其它就是集群状态类的监控或统计，为我们合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击等问题。
II、故障管理
a、硬件故障问题；对于成百上千或上万机器的N多集群，服务器死机、硬件故障概率是非常大的，几乎每时每刻都有服务硬件问题，死机、硬盘损坏、电源、内存、交换机。针对这种情况，我们在设计网站架构时需要充分考虑到这些问题，并将其视为常态；更多的依靠应用的冗余机制来规避这种风险，但给系统工程师足够宽裕的处理时间。（如google不是号称同时死800台机器，服务不会受到任何影响吗）；这就是考验运维工程师及网站架构师功能的地方了，好的设计能达到google所描述自恢复能力，如gfs，糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映，直接对用户拒绝响应。
b、应用故障问题；可能是某一bug被触发、或某一性能阀值被超越、攻击等情况不一而定，但重要的一点，是要有对这些问题的预防性措施，不能想当然，它不会出问题，如真出问题了，如何应对? 这需要运维工程师平时做足功夫，包括应急响应速度、故障处理的科学性、备用方案的有效等。

III、自动化
自动化：简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手及枯燥的重复性劳动，例如：没有工具前，我们安装系统需要一台一台裸机安装，如2000台，可能需要10人/10天，搞烂N张光盘，人力成本更大。。。而现在通过自动化工具，只需几个简单命令就能搞定、还有如机器人类程序，自动完成以往每天人工干预的工作，使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是/非判断、优化选择等。。。这些好处非常明显不再多说。。。应该说，自动化运维是运维工程师职业化的一个追求，利已利公，虽然这是一个异常艰巨的任务：不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现。
五、运维中关键技术点解剖（比较实际，现实中的案例，今天先想出这几条，如大家有其它感觉兴趣的，可以提出，一起交流～）

1 大量高并发网站的设计方案
2 高可靠、高可伸缩性网络架构设计
3 网站安全问题，如何避免被黑？
4 南北互联问题,动态CDN解决方案
5 海量数据存储架构

转自chinaunix

恶心的百度

Johnny Woo — Wed, 05 Nov 2008 15:32:29 +0000

为了推出自己的C2C网站
可谓下流无耻手段无所不用其极.

web 2.0 ide利器 - aptana

Johnny Woo — Mon, 03 Nov 2008 12:09:23 +0000

其实蛮早以前就听过aptana
是和zend studio一起听说的
当然我不是专业PHPer
所以IDE也只是顺便看看
zend studio做php没的说
但是现在做phper的
CSS也要搞.JS也要搞
所以zend 5.5是没搞头了
6.0以后是eclipse的插件.所以eclipse多强大.zend studio 6.x就多强大
但是今天要说的.却不是zend
而是一款比zend studio更小(aptana安装文件120M,zend 6.1 325M)
启动速度比zend更快(我的笔记本上面反差挺明显的)
更完美支持js,css的IDE
aptana

起初我没有理会这个软件是因为….名字太怪异
我对于名字过于怪异的软件,一般都会觉得写得不好.
但是这款测试下来…界面是出奇的完美
而且对于php的支持也是非常好.代码提示方面还会有标注是v4还是v5.
这样你就知道这个函数是在哪个php版本内的
如果你不在意使用java(确实比bin的会慢)
也不在意内存占用(java的东西都比较耗内存)
那么这款软件绝对有超过zend studio的实力

Notepad++ v5.1发布

Johnny Woo — Tue, 28 Oct 2008 15:53:40 +0000

前一阵notepad++的5.1就在RC状态了
我估计不会太久
果然今天再去刷新.SOURCEFORGE里的下载就多了5.1的正式release了
http://nchc.dl.sourceforge.net/sourceforge/notepad-plus/npp.5.1.Installer.exe
这次版本对unicode的支持加强
新增特性和bug fix如下
1. Make Notepad++ Unicode-compliant application(Unicode path supported).
2. Fix crash issue due to the incoherent modification/creation date.
3. Enhance Find in files feature : launch in thread, stop as wish.
4. Add find/replace dialog memorize capacity.
5. Fix “find in all opened files” and “find in files” unicode text search bug.
6. Fix “replace” and “replace all” bug.
7. Fix tag match highlighting mismatched bug.
8. Make tag match highlighting on non html zone optional.
9. Fix cpu high consumption bug while document is cloned with smart highlighting and xml matched highlighting features activating.
10. Refine the Save/Open file directory settings (follow tab/last operation/user defined dir).
11. Add “Doc go to new instance” and “Doc open in new instance” features.
12. Move document to another instance of Notepad++ via drag and drop document tab.
13. Add new pluin notification NPPN_DOCACTIVATED and NPPN_LANGCHANGED.
14. Fix context menu incorrect setting crash bug.
15. Fix crash problem while typing Chinese character in ANSI CSS document under Chinese environment.
16. Fix a problem with Incremental search+UTF8 in win9x.
17. Fix the User defined language not working in Unicode version bug.
18. Fix bug with CPP lexer keyword list.
19. Fix auto-completion not woring for HTML, SQL and RC problem.
20. Fix html, sql and rc auto-completion bug.
21. Fix cancel to save file in Notepad++ can not stop system shutdown problem.
22. Fix bug with opening relative path files.
23. Fix bug with clearing read-only flag.
24. Fix wrap after save as bug.
25. Improve “reload from disk” behaviour.
26. Add option to only show the filename in the titlebar.
27. Add NPPM_[G/S]ET_BUFFERLANGTYPE, NPPM_[G/S]ET_BUFFERENCODING, NPPM_[G/S]ET_BUFFERFORMAT messages to access buffer properties.
28. Remove all the comic sans font (finally :) ).

PHP静态,动态编译性能对比测试

Johnny Woo — Tue, 28 Oct 2008 09:30:44 +0000

1. 软件版本
Web服务器
nginx-0.7.17
php-5.2.6
eaccelerator-0.9.5.3
2. PHP编译方式
第一种为纯静态编译
编译参数如下

./configure --prefix=/usr/local/webserver/php-static \
--with-config-file-path=/usr/local/webserver/php-static \
--enable-fastcgi \
--enable-fpm \
--enable-force-cgi-redirect \
--with-libxml-dir \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--enable-gd-native-ttf \
--with-freetype-dir \
--with-mysql=/usr/local/mysql \
--with-mcrypt \
--with-mhash \
--with-curl \
--with-curlwrappers \
--with-zlib-dir \
--with-zlib \
--with-pear \
--with-openssl \
--without-pdo-sqlite \
--without-sqlite \
--disable-debug \
--disable-rpath \
--without-iconv \
--enable-bcmath \
--enable-pcntl \
--enable-mbstring \
--enable-exif \
--enable-zip \
--enable-ftp

第二种以及第三种将所有模块作为动态链接库
编译参数如下

./configure --prefix=/usr/local/webserver/php \
--with-config-file-path=/usr/local/webserver/conf \
--enable-fastcgi \
--enable-fpm \
--with-fpm-conf=/usr/local/webserver/conf/php-fpm.conf \
--enable-force-cgi-redirect \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--enable-gd-native-ttf \
--with-freetype-dir \
--with-mysql=/usr/local/webserver/mysql \
--with-libxml-dir \
--with-curl \
--with-curlwrappers \
--with-zlib \
--with-pear \
--enable-mbstring \
--enable-exif \
--disable-debug \
--disable-rpath \
--without-pdo-sqlite \
--without-sqlite \
--without-iconv

3.测试方法
将bcmath模块作为测试对象,以下为测试脚本

$a = '1.234';
$b = '5';
$i=0;
while($i<1000)
{
   echo bcadd($a, $i);
   echo bcadd($a, $i, 4);
   echo bcdiv($i, '6.55957', 3);
   $i++;
}
?>

另一台服务器发起http_load对指定脚本进行获取.对比最终的fetch数
4.测试数据
全部模块为静态编译,加载eaccelerator
USER %CPU %MEM VSZ RSS TTY STAT START TIME
root 0 1.2 94740 3284 ? Ss 04:44 00:00
nobody 0.3 1.8 95232 4720 ? S 04:44 00:00
nobody 0.2 1.6 95128 4368 ? S 04:44 00:00
nobody 0.3 1.6 95128 4368 ? S 04:44 00:00
nobody 0.3 1.6 95128 4368 ? S 04:44 00:00
nobody 0.4 1.6 95128 4368 ? S 04:44 00:00
nobody 0.4 1.6 95128 4368 ? S 04:44 00:00
nobody 0.4 1.6 95128 4368 ? S 04:44 00:00
nobody 0.4 1.6 95128 4368 ? S 04:44 00:00
nobody 0.3 1.6 95128 4368 ? S 04:44 00:00
nobody 0.3 1.6 95128 4368 ? S 04:44 00:00
nobody 0.4 1.6 95128 4368 ? S 04:44 00:00
nobody 0.4 1.6 95128 4368 ? S 04:44 00:00
nobody 0.4 1.6 95128 4372 ? S 04:44 00:00
nobody 0.4 1.6 95128 4372 ? S 04:44 00:00
nobody 0.8 1.6 95128 4372 ? S 04:44 00:00
nobody 0.5 1.6 95128 4372 ? S 04:44 00:00
nobody 0.9 1.6 95128 4372 ? S 04:44 00:00
nobody 2.9 1.6 95128 4372 ? S 04:44 00:01
nobody 9.6 1.6 95128 4376 ? S 04:45 00:02
nobody 10.8 1.6 95128 4376 ? S 04:45 00:02
nobody 9.9 1.6 95128 4376 ? S 04:45 00:02
nobody 10.6 1.6 95128 4376 ? S 04:45 00:02
nobody 10.1 1.6 95128 4376 ? S 04:45 00:02
nobody 10 1.6 95128 4376 ? S 04:45 00:01
nobody 5.6 1.6 95128 4376 ? S 04:45 00:00
SUM 76.6 41.4 2473044 112916
速度测试结果
161.396 fetches/sec, 2.75422e+06 bytes/sec
166.377 fetches/sec, 2.83923e+06 bytes/sec
164.772 fetches/sec, 2.81184e+06 bytes/sec
164.692 fetches/sec, 2.81047e+06 bytes/sec
166.4 fetches/sec, 2.83962e+06 bytes/sec

只加载bcmath动态库以及eaccelerator
USER %CPU %MEM VSZ RSS TTY STAT START TIME
root 0 1.1 89944 3104 ? Ss 04:49 00:00
nobody 1.1 1.7 90396 4508 ? S 04:49 00:00
nobody 1.4 1.5 90336 4156 ? S 04:49 00:00
nobody 1.2 1.5 90336 4156 ? S 04:49 00:00
nobody 1.2 1.5 90336 4156 ? S 04:49 00:00
nobody 1 1.5 90336 4156 ? S 04:49 00:00
nobody 1.2 1.5 90336 4156 ? S 04:49 00:00
nobody 0.8 1.5 90336 4156 ? S 04:49 00:00
nobody 0.9 1.5 90336 4156 ? S 04:49 00:00
nobody 0.8 1.5 90336 4156 ? S 04:49 00:00
nobody 1.1 1.5 90336 4156 ? S 04:49 00:00
nobody 1 1.5 90336 4156 ? S 04:49 00:00
nobody 1 1.5 90336 4156 ? S 04:49 00:00
nobody 1.1 1.5 90336 4156 ? S 04:49 00:00
nobody 1 1.5 90336 4156 ? S 04:49 00:00
nobody 1.2 1.5 90336 4156 ? S 04:49 00:00
nobody 1.2 1.5 90336 4156 ? S 04:49 00:00
nobody 1.1 1.5 90336 4156 ? S 04:49 00:00
nobody 1 1.5 90336 4156 ? S 04:49 00:00
nobody 1.1 1.5 90336 4156 ? S 04:49 00:00
nobody 3.2 1.5 90336 4156 ? S 04:49 00:02
nobody 9.6 1.5 90336 4156 ? S 04:49 00:02
nobody 10.2 1.5 90336 4156 ? S 04:49 00:02
nobody 10.3 1.5 90336 4156 ? S 04:49 00:02
nobody 8.6 1.5 90336 4156 ? S 04:49 00:02
nobody 9.1 1.5 90336 4156 ? S 04:49 00:02
SUM 71.4 38.8 2348404 107356
速度测试结果
161.5 fetches/sec, 2.756e+06 bytes/sec
163.6 fetches/sec, 2.79183e+06 bytes/sec
162.5 fetches/sec, 2.77306e+06 bytes/sec
160.098 fetches/sec, 2.73208e+06 bytes/sec
162.592 fetches/sec, 2.77464e+06 bytes/sec

所有动态库全部加载
USER %CPU %MEM VSZ RSS TTY STAT START TIME
root 0 1.2 98460 3220 ? Ss 04:46 00:00
nobody 3 1.6 98848 4320 ? S 04:46 00:02
nobody 1.8 1.6 98848 4320 ? S 04:46 00:01
nobody 3 1.6 98848 4320 ? S 04:46 00:02
nobody 2.9 1.6 98848 4320 ? S 04:46 00:02
nobody 1.5 1.6 98848 4320 ? S 04:46 00:01
nobody 1.2 1.6 98848 4320 ? S 04:46 00:00
nobody 1.4 1.6 98848 4320 ? S 04:46 00:00
nobody 1.5 1.6 98848 4320 ? S 04:46 00:01
nobody 2 1.6 98848 4320 ? S 04:46 00:01
nobody 4 1.6 98848 4320 ? S 04:46 00:02
nobody 1.3 1.6 98848 4320 ? S 04:46 00:00
nobody 1.5 1.6 98848 4320 ? S 04:46 00:01
nobody 1.5 1.6 98848 4320 ? S 04:46 00:01
nobody 1.3 1.6 98848 4320 ? S 04:46 00:00
nobody 1.3 1.6 98848 4320 ? S 04:46 00:00
nobody 1.5 1.6 98848 4320 ? S 04:46 00:01
nobody 1.5 1.6 98848 4320 ? S 04:46 00:01
nobody 3.2 1.6 98848 4320 ? S 04:46 00:02
nobody 3.6 1.6 98848 4320 ? S 04:46 00:02
nobody 1.9 1.6 98848 4320 ? S 04:46 00:00
nobody 7.2 1.6 98848 4320 ? S 04:47 00:01
nobody 0 1.6 98848 4320 ? S 04:47 00:00
nobody 7.9 1.6 98848 4320 ? S 04:47 00:00
nobody 1.4 1.6 98848 4320 ? S 04:47 00:00
nobody 3.2 1.6 98848 4320 ? S 04:47 00:00
SUM 60.6 41.2 2569660 111220
速度测试结果
160.9 fetches/sec, 2.74576e+06 bytes/sec
164.6 fetches/sec, 2.8089e+06 bytes/sec
164.1 fetches/sec, 2.80036e+06 bytes/sec
164.2 fetches/sec, 2.80207e+06 bytes/sec
163.7 fetches/sec, 2.79354e+06 bytes/sec

同时我们测试phpinfo函数
对比结果如下
加载全部模块/静态编译
251.4 fetches/sec
257.799 fetches/sec
258.993 fetches/sec
257.798 fetches/sec
249.2 fetches/sec
只加载最小模块
290.199 fetches/sec
332.1 fetches/sec
332.5 fetches/sec
319.8 fetches/sec
332.8 fetches/sec

5.测试总结
使用静态方式和动态方式来加载模块对于php的执行效率并没有非常显著的影响
甚至原先认为在内存占用方面,动态编译由于模块只需要加载一份在真实内存中,内存占用会比较小的假象
在实际测试结果中也没有获得印证
两者的差异几乎可以忽略.而动态加载所获得的机动性和便利性.则大大高于静态编译.
而是否加载了不必要的模块.会略微的影响到内存占用,但是不会影响到其他函数或者模块的执行效率
更不会影响到PHP本身的执行效率
在最后一次测试中.由于phpinfo需要遍历所有的模块并取出对应的参数
所以全部加载的效率远低于只加载必要模块.
如果是服务器需要处理很多外部请求.建议将模块数量最小化.
如果是量并不大到一定程度.全部加载没有太大影响.

lighttpd 配置reload问题

Michael Field — Tue, 28 Oct 2008 09:06:57 +0000

lighttpd1.4.x
默认情况下无法使用reload功能，即kill -HUP “PID OF LIGHTTPD” ?
在网上搜索了一番，结果发现可以使用lighttpd的sbin目录下的lighttpd-angel来实现这个reload功能；

方法如下：

/pathtolighttpd/sbin/lighttpd-angel -D -f /pathtolighttpd/conf/lighttpd.conf

-D 表示不在后台执行；（默认是在后台执行的）
而这个reload功能一定是要-D参数才能获得支持；

这样新问题就出现；一般管理服务器都是远程登录的ssh中执行&指令的话会导致退出登录ssh后无响应；
可以通过调整延时时间来设定，但毕竟使用起来有点麻烦；

最后执行在前面增加一个nohup工具，总算问题解决了，但毕竟还不完美；

nohup /pathtolighttpd/sbin/lighttpd-angel -D -f /pathtolighttpd/conf/lighttpd.conf &

然后再修改lighttpd的service脚本如下：

...
prog="lighttpd"
lighttpd="/pathtolighttpd/sbin/lighttpd-angel" #多增加一个lighttpd-angel的变量
lighttpd1="/pathtolighttpd/sbin/lighttpd"
RETVAL=0

start() {
   echo -n $"Starting $prog: "
   #以lighttpd-angel启动，去掉daemon函数，不然会启动失败，无法和nohup一起使用；
   /usr/bin/nohup $lighttpd -D -f $LIGHTTPD_CONF_PATH 2 >/dev/null &
   RETVAL=$?
   echo
   [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
   return $RETVAL
}

stop() {
   echo -n $"Stopping $prog: "
   killproc $lighttpd1 #杀进程的依旧是lighttpd
   RETVAL=$?
   echo
   [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
   return $RETVAL
}

reload() {
   echo -n $"Reloading $prog: "
   killproc $lighttpd -HUP
   RETVAL=$?
   echo
   return $RETVAL
}
....

这样修改完发现每次start的时候不能正常显示[OK]；lighttpd-angel开启的时候会调用lighttpd主程序；这样就是lighttpd和lighttpd-angel一起运行，这个也是执行reload必须的；

如果有更好的办法，请留言讨论！
貌似lighttpd1.5.x会解决这个问题。