系统运维秘诀大分享专题

本专题整合收录了有关系统运维/系统管理员工作和个人成长方面的各种心得分享、经验总结、以及必须牢记的一些准则，适合所有在运维领域有追求的技术人阅读。有些分享的层次比较深，有些则是运维的基础课，但通过翻看他人的心得，相信你总能有所收获。

1 Dormando的系统运维秘诀三部曲... 4

1.1 技术篇... 4

1.1.1 为变化而设计.... 4

1.1.2 使用自动的，可重复的构建过程.... 4

1.1.3 使用冗余.... 4

1.1.4 使用备份.... 5

1.1.5 监控正确的东西.... 5

1.1.6 有关数据图形化，历史数据.... 5

1.1.7 日志记录，使用多个数据流.... 5

1.1.8 数据存储方式，数据库.... 5

1.1.9 多一些横向扩展，少一些纵向扩展.... 6

1.1.10 缓存.... 6

1.1.11 让工作异步化.... 6

1.1.12 安全和巡查.... 6

1.2 交流篇... 7

1.2.1 通过多种方式来学习.... 7

1.2.2 尝试各种事情.... 8

1.2.3 真正地搞清楚冗余是怎么一回事.... 8

1.2.4 真正地理解可扩展性.... 8

1.2.5 成为一个能够解决问题的超级明星.... 8

1.2.6 和IT人员一起工作.... 8

1.2.7 和开发人员一起工作.... 8

1.2.8 和其他领域的运维一起工作.... 9

1.3 实践篇... 9

1.3.1 现在就修复它，而不是以后再修复它.... 9

1.3.2 让每一件事情都自动化.... 9

1.3.3 只进行必要的变更.... 9

1.3.4 Design for change. 9

1.3.5 尽快地把更新的内容投入实践.... 9

1.3.6 规范化，坚持按照规范来行事.... 10

1.3.7 文档化.... 10

1.3.8 使用源代码控制工具.... 10

1.3.9 招聘.... 10

1.3.10 避免提供商锁入，同时和你的提供商保持良好的关系.... 10

1.3.11 给开源一个机会.... 11

2 系统管理员必须遵守的铁律... 11

2.1 优秀的Windows管理员应该具有的9大品质... 11

2.1.1 无编辑器操作.... 11

2.1.2 高权限的觉醒.... 11

2.1.3 工作站比服务器更重要.... 11

2.1.4 Google搜索，而不是编码.... 11

2.1.5 我们更喜欢测试过的解决方案.... 11

2.1.6 “尸检”是顾问们的事情.... 12

2.1.7 我们知道我们不知道什么.... 12

2.1.8 无论这个问题是谁提出的，我们都假设这个问题是我们自己的问题.... 12

2.1.9 网络安全也是我们的工作.... 12

2.1.10 经验分享：搞清楚何时应该跟注，何时应该弃牌（重启）.... 12

2.2 优秀的Unix管理员应具有的9大品质... 12

2.2.1 我们不使用sudo. 12

2.2.2 我们使用vi，而不是emacs，更不可能是pico或nano. 12

2.2.3 我们把正则表达式当成我们的利器.... 13

2.2.4 我们天生就比较懒惰.... 13

2.2.5 我们更喜欢优雅的解决方案.... 13

2.2.6 我们一般对事不对人.... 13

2.2.7 我们研究问题的时候，比医生的检查还要细致.... 13

2.2.8 关于Windows，我们知道的也很多（过去我们只是装作不知道而已）.... 13

2.2.9 几乎从来都不选择重启.... 13

2.3 系统管理员必须了解的六大铁律... 14

2.3.1 永远不要修改服务器或网络设备的连接接口.... 14

2.3.2 保证总是有办法回到原点.... 14

2.3.3 文档，文档，还是文档.... 14

2.3.4 在IT领域，不存在魔法，但是却存在幸运.... 14

2.3.5 在你修改每个配置文件以前，要对它们进行备份.... 14

2.3.6 监控，监控，还是监控.... 15

2.4 Linux系统管理入门必须经历的三步... 15

2.4.1 熟悉Linux以及发行版.... 15

2.4.2 熟悉相关的应用程序/服务.... 15

2.4.3 编写代码.... 16

2.5 系统管理员应该定期完成的九件事... 16

2.5.1 配置管理.... 16

2.5.2 备份.... 16

2.5.3 测试你的备份.... 17

2.5.4 日志轮换.... 17

2.5.5 资源监视.... 17

2.5.6 进程监视.... 17

2.5.7 安全加固（Hardening）.... 17

2.5.8 安全更新.... 17

2.5.9 日志监视/安全扫描/入侵检测.... 18

2.6 运维人员应该时刻谨记的十条安全法则... 18

2.6.1 网站用户的身份认证.... 18

2.6.2 网站数据的加密传输.... 18

2.6.3 用户账号使用行为的日志记录及其审计.... 19

2.6.4 恶意用户流量的检测、过滤及阻断.... 19

2.6.5 对非正常应用请求的过滤和处理.... 19

2.6.6 合理的子网划分及流量分割.... 19

2.6.7 负载均衡及负载保护机制.... 19

2.6.8 灾难备份及恢复.... 19

2.6.9 管理规范化.... 19

2.6.10 网站漏洞自我挖掘及防护.... 20

3 系统管理员软硬技能... 20

3.1 漫谈运维：半神半仙亦民工... 20

3.1.1 架构设计... 22

3.1.2 IDC选择... 22

3.1.3 服务器上架... 23

3.1.4 安装系统和布线... 24

3.1.5 资产统计... 25

3.1.6 监控架构... 26

3.1.7 企业实际面对的一些问题... 27

3.2 系统管理员需要掌握哪些软技能？... 28

3.2.1 软技能之一：自动化... 29

3.2.2 软技能之二：时间管理... 29

3.2.3 软技能之三：组织结构... 30

3.3 系统管理员易犯错误及解决方法汇总... 31

3.3.1 安装FreeBSD后无法重启... 31

3.3.2 更改Admin密码导致计划任务无法执行... 32

3.3.3 root密码更改后无法远程登录... 32

3.3.4 锁定了SSH会话... 32

3.3.5 移走硬盘造成Emergency模式... 33

3.3.6 sudoer文件损坏造成无法进入root模式... 33

3.3.7 root密码被更改... 33

3.3.8 依赖的库文件丢失导致root无法登陆... 33

3.3.9 忘记以su模式进入编辑器... 34

3.4 系统管理员应该怎样高效的书写文档... 34

3.4.1 为什么系统管理员应该学习编写文档.... 34

3.4.2 如何编写文档.... 34

3.4.3 其他注意事项.... 35

3.5 系统管理员之企业生存守则... 35

4 系统管理员的软硬件维护清单... 38

5 门户网站运维经验谈... 47

5.1 什么是门户网站运维?. 47

5.2 运维工作师需要什么样的技能及素质... 48

5.3 运维工程师的职责... 49

5.4 维职业的迷惘、现状与发展前景... 49

5.5 运维关键技术点解剖... 50

1 ?Dormando的系统运维秘诀三部曲

本文是SixApart的MySQL DBA，Dormando在2008年总结的一套运维秘诀。编者前日看到Google系统管理员TomLimoncelli在EverythingSysadmin上推荐这篇文章，并表示这篇文章的内容在今天仍然适用。阅读之下，发现的确是篇难得的好文章，有大量的经验分享总结。现在51CTO系统频道特将本文全文翻译过来，当作给各位运维读者们的2011新年礼物。

以下为正文。

在运维管理的过程中，我发现了很多有价值的秘诀，本文是这些秘诀的一个总结。虽然这些秘诀可能比较“唯心”，但是我还是把它们总结出来了，相信它们会对你有帮助的。

Dormando的运维秘诀分成以下三大篇：

技术篇

交流篇

实践篇

下面先从技术篇开始。交流篇和实践篇会陆续整理放出。

1.1 ?技术篇

1.1.1 ?为变化而设计

Google的秘诀是正确的——“为变化而设计”。“变化”就是不得不部署新的软件，升级现有的软件，进行扩展，设备损坏，以及人员流动等。

每一件事情都是在寻找平衡点。你也许会认为把你的系统和某个操作系统或某个Linux发行版牢牢地绑定在一起是一个好主意，但事实上这跟把它们完全隔离一样糟。如果实在有必要，你可以进行分层，并使用一点间接性。

这并不意味着你的系统必须是平台无关的。其实我们的目的很简单：一变二，二变二十，一个系统必须可以应对各种突发事件。也就是说，如果一个系统管理员被公共汽车撞了，你有应对的方案！如果挂载的硬盘出现故障了，你有应对的方案！如果某些人运行了rm -rf /，你也有应对的方案！增量的进行变更。记得安全更新，以及保持内容更新。

1.1.2 ?使用自动的，可重复的构建过程

不要手动构建任何东西。如果你一定需要手动构建，那么就做两遍，在做第二遍的时候把用到所有的命令都提取出来。

下面这一点十分重要：将新硬件上线到生产环境的过程不应该超过15分钟，而且这个过程必须足够简单。否则，当一个服务器出现故障，而没有人知道如何更换它的时候，你就该倒霉了。

下面这一条是普世真理：这个世界上不存在“一次性”的服务器构建。即使你的服务器只需要构建一次，但只要你构建过一次，就一定会有第二次。比如，当它损坏的时候，或者你必须进行一次重大的升级才能让它在在接下来的两年时间里更加稳定的时候。

测试，检查新构建好的服务器。这应该是比较容易的，因为你的构建过程都是自动化的，对吧！

脚本化的构建，意味着从某个Linux发行版的V3升级到V4应该是很快的。安装
V4，对脚本进行测试。如果有问题，参考文档并修复它，直到它可以再次正常工作。这最多应该是一个星期的工作，而不是一个长达一年的浩大工程（因为那时，刚刚完成的V5已经发布了！）

1.1.3 ?使用冗余

容易重新构建，并不意味着你可以忽视冗余。跳转盒，邮件服务器，计费网关，等等。如果其中的一半挂掉了却并不造成客户的宕机，生活将会变得更加简单。

按照以上方针来做的话，当某个设备在凌晨3点出现故障的时候，你可以“以后再处理那个出现故障的设备！”，把冗余的机器先替换上去。

下面这一条是个聊胜于无的解决方案：Rsync。DRBD也许也不是一个完美的解决方案，但是它可以提供令人称奇的服务。（参考阅读：DRBD笔记，DRBD实例1，DRBD实例2）

1.1.4 ?使用备份

备份是个严肃的话题。使用硬盘，烧录磁带。压缩它们，移动它们，并行地运行。对每一样东西进行备份！

如果你的构建过程是自动的，整个过程都可以被备份。如果到目前为止的几条你都做到了，那么一个真正的“灾难恢复”计划也许并不是那么遥不可及的。

1.1.5 ?监控正确的东西

监控你能监控的所有东西，而且要用正确的方法来进行监控。如果你的NFS服务器挂掉了，不要让你的监控工具发送1000条警报。如果对你的系统来说，超时的警报没有什么实际意义，那就别让它发。要针对各种具体的情况进行成功性测试：是的，这个服务可以进行一个新的TCP连接，它甚至可以响应，但是它还记得它要做什么工作吗？

如果你有500个Web服务器，其中一个挂掉了，你可能不必马上知道这个情况。但是，如果负载均衡器没有把这台机子踢出去，导致错误报告出现在了用户的屏幕上，那么你必须知道这个情况！

1.1.6 ?有关数据图形化，历史数据

图形的作用是让趋势可视化。历史数据的作用是让你对数据进行精确的分析。不要把这两者混为一谈！对图形进行目测，很容易获得错误的数值。许多站点都使用rrd类型的系统或其他的数据聚合系统，此类系统按照时间对数据进行平均化处理，然后保存在存储空间中。这不仅仅是难以阅读的问题：这根本是错误的！

如果你要浏览数百张图才能精确地对一个问题进行定位，那真是糟透了。想要找出极值？请使用脚本提取数据。

如果你必须使用图形来解决问题，尽量把各种高级的概念整合到一个单一的页面中，然后让这个页面链接到拥有具体信息的子页面中。如果你在数据库负载中可以看到一个峰值，你可以点击这个页面对那些数据库进行概览，然后找到那一两台可疑的机器。基本的理念是尽快地缩小范围，尽可能的减少猜测。

1.1.7 ?日志记录，使用多个数据流

无论是独立工作还是与开发部门合作，都要把尽可能多的有用的信息记录到日志中。无论是分析之后再保存，还是直接扔进数据库中生成报告，这些都无所谓。信息终归是有用的。

有用的例子：页面呈现时间（哪个页面？哪个设备？），面向用户的错误，数据库和内部服务错误，带宽使用率等。

建立图表，报告，并对产生的历史数据进行比较。

报告是十分重要的。每周或每天对你的基础设施变更进行汇总。

1.1.8 ?数据存储方式，数据库

诚然，数据库运维是一套完整而独立的知识体系。但是有时，你不能把一切都丢给你的DBA。

拥有多个冗余的数据库会给你带来很多好处。对于一个庞大的Oracle实例来说，从前，很多运维工作需要好几个小时的关机维护时间；而现在，完全可以在服务运行的同时进行。MySQL和数据库复制功能是一件奇妙的事情。

和DBA们一起努力，尽量为可能会发生问题的数据库争取到最好的硬件。RAID 10，大量的RAM，高速硬盘，乃至于强悍的RAM磁盘和SSD。运维人员对提供商要货比三家，这样可以减轻DBA对硬件的恐惧。从长远来看，找出哪个品牌的硬件更加优秀会节省大量的资金。

数据库配置一直在改变。现在出现了HiveDB，MySQL Proxy，DPM这些软件。我们绝对应该对巨大的数据集进行分割。我们也可以考虑一下像starling和Gearman这样具有一定创新性的软件。了解一下这些软件的用途，同时，了解一下并不是一切东西都要保存在一个数据库中的。

善用你的过滤器！如果这些数据很重要，应该对它们进行备份！单片的NFS服务器的快照很奇妙，它并不是一个备份！

可以虑一下替代的解决方案。MogileFS现在变得越来越好了（参考阅读：分布式文件系统试用比较）。实际上，还有其他类似的项目可以免费（或廉价）地维护大量的存储文件。类似的系统基本上都是是为youtube.com、archive.org等站点而开发的。我们最终会让廉价的NFS过滤器成为标准！

1.1.9 ?多一些横向扩展，少一些纵向扩展

横向扩展是我们应该走的路。应该使用常规的（即：可用的，价格适中的，标准的。而不是特便宜的！）硬件，然后和大家一起努力，确保各方面都可以进行横向扩展。

横向扩展从两台机子开始。另外，进行冗余的时候也会涉及到横向扩展。

尽可能的横向扩展，但是不要傻乎乎的扩展。在MySQL复制中有一个经典的白痴扩展的例子：使用一个master对很多个slave。所有的slave必须完成全部的写入，而写入次数是与读取次数成比例增加的（大多数应用都是这样）。也就是说，你添加的slave越多，通过添加slave扩展的资源就越少。

留意一下替代的解决方案。按照用户或区域对多个数据库进行划分，同时避免增加过多的slave。实际上，有许多种方法可以达到这个目的。

一切都可能扩展！路由器，交换机，负载均衡器，Web服务器，数据库，等等。

记得纵向扩展吗？以前那些邪恶的大型机们有很多核，很多IO板，配备了非常昂贵的存储设备。而现在，多核这个概念开始蔓延了。

RAM是廉价的。

将以上两点合并起来，这意味着你只需要再次合并服务就可以了。这儿有一个负载均衡器，那儿有一个Web服务器……如果一个应用程序可以使用许多个CPU（比如apache），那么这是完美的。如果它不能（比如memcached），那么你最终可能会由于离散的服务太多而浪费掉大量的可用资源。

作业系统（job systems）也许可以填补这个鸿沟。哪里的核心的越多，哪里的工作线程就越多。

1.1.10 ?缓存

对于开发者和系统运维人员来说，缓存可是个好东西，值得大力发展！的确，它是不可思议的。它是与众不同的。有时你可能必须要为它做一个权衡。有效地使用缓存可以让系统的整体性能提升10倍之多。对于你当前的系统来说，这是一个巨大的“放大镜”，并且，它的成本在总成本中只占很小的一部分。

Memcached。它可以为服务提供缓存，让数据库结构非标准化（这可以提升性能！），对squid缓存进行优化，甚至可以提高操作系统缓存的利用率。

测试它，玩弄它，并打破它。使用缓存会带来新的问题。要做好准备。

1.1.11 ?让工作异步化

可以使用Starling, Gearman, The Schwartz等工具。作业系统可以给应用程序提供更多的灵活性。工作线程可以一次性地产生出来，也可以是持久的（载入缓存数据，准备数据等）。它们可以在不同的硬件上，它们的地理位置也可以不同。它们既可以是同步的，也可以是异步的。

维护这些东西是一个运维人员的问题。使用它们既是开发者的问题也是运维人员的问题。

当用户点击“给我所有的朋友发送邮件”的时候，把这个工作列入计划，然后马上说：“OK，已经完成了！你的朋友马上会收到你的邮件！”——通过异步化的方式来处理这个工作。

作业系统是衔接各个服务的一个场所。博客投递-〉IM通知，定期计费-〉收费服务，网关认证等。

容易扩展。在请求进入的地方会有一些瓶颈，所有的工作线程必须要做的事情就是“拉”。这个是相对于HTTP中大量推/拉的状态而言的。

1.1.12 ?安全和巡查

一定要安装安全更新！这十分重要！有很多疯狂的网络专家致力于在尽可能短的时间内给你提供这些更新。不要因为你害怕改变而让他们白白地付出劳动。

安全性也是分层的。明白你能确保什么，以及不能做什么。MySQL有密码访问机制，并不意味着可以允许直接通过互联网来访问它。

在SSH上禁用密码。使用经过加密的passphrase密钥来进行身份验证。远程的用户无法猜出你的私有密钥。他们必须从你这里才能得到它。把它保管好。做好这点，就没必要在防火墙中关闭你的SSH端口了。

搞清楚你的应用程序是如何工作的，它具体需要做些什么，并相应的进行调整。比如说，如果你的应用当中，只有付费页面和Twitter投递服务是需要连接外部互联网的，那么就把它们做成工作线程。将这部分工作线程放在特定的设备中，让它们只能访问特定的主机。这可以神不知鬼不觉地把你的网络的其余部分保护起来。

对于PHP站点来说，以上这些建议尤其重要，但是在其他地方，它们也可以发挥作用。如果有人要入侵，那么多半是通过你的应用。即使有人从前门入侵了系统，也要让他们花费很大精力才能进入保险箱。你需要确保的是他们无法将数据带走或上传至别的什么服务器上。

除了这些具体的建议之外，你还应该多读一些资料。自己判断，自己动手测试。如果你不知道一个安全模型是如何工作的，一时半会儿可能问题不大，但是这就会导致你不知道它的限制在哪里，甚至于无法判断它是否在工作。

基于测试，理论，攻击树的安全机制是不会在背后给你一刀的。当人们构想出模糊的安全模型的时候我也很喜欢它，但是像我这样的普通人都可以把它弄的支离破碎。

尽可能地进行巡查！登录，退出，以及使用的命令都要进行审查。对面向外部服务的所有访问，包括所有在请求中指定的参数，都要进行审查。对于你的应用程序来说，找出极值，然后彻底禁止输入超出范围的值。做你能做的所有事情，让数据以可追溯的方式工作。

如果你怀疑某些东西可能会被破坏，应该采取适当的预防措施，最好懂得一点计算机取证方面的知识（或者聘请一个专门从事这项业务的公司）。通过移除可疑的网络访问来做出响应，通过一系列的控制台或直接通过终端来检查整个系统。在已经被破坏的机器上，避免使用任何的服务，配置文件，或数据。很多人都是“清除了一个木马”，但是不知道它是怎么进来的——这样并不算真正地清除了这个木马。

如果你有安全团队，取证专家，或其他人手，那么你尽量不要接触那台机器，把它隔离起来。这意味着不要重新启动它来“清除一些奇怪的进程”。他们需要这些证据。如果你必须这么做，就去做吧，但是要记得把系统彻底地清理干净，打上所有的安全更新，尽量搞清楚他们是否已经破坏了重要的数据。做你能做的所有事情。

安全实际上是一种权衡。如果你做错了，开发者和用户们都会“揭竿而起”：他们会找到一些方法来绕过安全机制。如果他们可以绕过它，那说明你的工作并没有做好。如果他们不能绕过它，那么他们也许会放弃，然后离开。

紧抓访问控制。这意味着运维人员必须要为已经锁上门的“房间”提供一些窗户。不让开发人员进入生产环境，意味着他们必须抹黑解决难题。你的确不能让开发者们直接对服务进行修改，但是你可以提供日志工具和调试工具等等。对于各种产品来说，这些都是成功的秘诀。

【51CTO.com译稿，转载请注明原文作译者和出处。】

原文：Dormando‘s [crappy] Operations Mantras

1.2 ?交流篇

在之前我们已经介绍过了技术篇的内容，讲述了有关变化、自动化、冗余、备份、监控、日志、数据库、可扩展性、缓存、以及安全方面的秘诀。今天介绍的第二篇是交流篇，讲述的是有关运维的知识积累、经验积累、协同合作、个人成长方面的内容。其中有些内容不仅是站在运维本身的角度来考虑，同时也对运维的管理者提出了建议。

交流篇

1.2.1 ?通过多种方式来学习

订阅一些RSS feed，每星期至少阅读几篇好文章。LWN，kerneltrap，undeadly.org。凡是相关的，或是仅仅是有点擦边的内容都应该关注。

阅读“达人”的博文。有时他们会投递一些有趣的主题，并且我们还可以通过评论直接和博主进行交流。

阅读几篇非“达人”的博文。通过他们遇到的问题，或者他们做了但没有做好的工作，我们可以找到一些感觉。（译注：这一点我个人深有体会。阅读一些新手的博文，我们常常可以得到启发，因为我们的一些做法虽然不会出问题，但是太程式化了，每天都重复同样的事情，我们无法进步，而新手由于缺乏经验，他们会不断地尝试各种做法，他们遇到的问题很可能是我们没有遇到过的，这对我们来说是一笔财富。）

想尽办法认识一些可以“痛扁”你的人。注意，一定要谦虚。

通过多种来源学习。通过多种方式吸收知识有助于找到最适合你的方式。

仔细研读其他公司成功或失败方面的故事。可以尝试打电话给他们的CTO，通过免费的午餐从他们那里获取一些有价值的建议。

1.2.2 ?尝试各种事情

如果你不断地进行尝试，你会发现你能做的事情远远超出了你的想象。以前从来没有见到过？那就试试看。

尽量不做一只危险的“菜鸟”。在你有把握不会把整个房间都烧掉以前，应该在“沙箱”中进行尝试。

1.2.3 ?真正地搞清楚冗余是怎么一回事

真正地搞清楚冗余会对哪些事情造成怎样的影响。在什么情况下它可以发挥作用，在什么情况下它无法发挥作用。

尝试破坏你的系统。你可以在测试实验室中尝试，有时也可以在生产系统中这样做。了解一下当你处于受限状态中的时候可以做什么。比如，拔掉电源，抽出网卡，杀死进程，拔掉几根内存，抽掉硬盘，拔掉网线。

在冗余存在的情况下尝试替换和升级系统。

1.2.4 ?真正地理解可扩展性

关于如何开发出可扩展的系统，有很多的资料可以参考。虽然你不用自己编写一个这样的系统，但是你要尽量搞清楚这方面的理论知识。

学习虚拟化。创建几个虚拟机，然后尝试着摆弄一下针对多台机器的应用程序。在本地的不同的端口上运行多个实例。

通常，运维人员要做一些系统承载量方面的计划。如果你不清楚应该把什么资源应该添加到哪里，你就不会知道应该添加些什么。

1.2.5 ?成为一个能够解决问题的超级明星

问题忽然发生，而时间是宝贵的。你必须要有自己的知识储备，并高效的使用它们。

经常练习着解决问题。挑选出一个可以正常工作的完美页面，然后试着跟踪一下它是如何工作的。

strace, ltrace, lsof,logs

搞清楚load != load（编者注：此处理解为load参数不等同于真正的系统负载情况）。主机运行情况的所有信息都需要查看。

熟悉IO系统相关的工具。“不可思议”的性能问题通常都是由于你的RAID或SAN配置出了什么问题。

记录文档。Checklist，解决问题的技巧，构建工具等。

构建更多的工具。不只是为了你自己，也是为了其他人。你也可以给现有的工具添加一些功能。

1.2.6 ?和IT人员一起工作

信不信由你，运维人员和IT人员之间存在交集。

运维人员必须要为服务器维护高带宽的网络访问。IT人员必须要做同样的事情，只是他们的服务对象是人。IT人员也往往是运维人员进入数据中心的“桥梁”。在这一点上，大家在一起工作是很有实际意义的。

彼此的分工要明确。IT人员应该负责管理邮件，而运维人员应该负责管理开发环境的服务器。不要插手职责之外的事情，尽最大的努力把你自己的事情做好。

不要疏远他人。Mac是流行的，Linux也（慢慢地）获得了一些市场份额。信不信由你，强迫大家都使用微软的生产软件可能会对你造成不好的影响。实际上有许多替代品，你可以试试看。在你的公司中，很可能熟悉Google应用的人比熟悉Outlook的人要多。

尽可能的让大家觉得Unix并不难用，毕竟这是他们要支持的系统，你肯定希望他们对Unix更加熟悉一些。当然，除非你家里是卖Windows的。

1.2.7 ?和开发人员一起工作

你们都为同一个产品工作，你们的目的也是一致的。试着多配合一下。

一起开策略会议并不等于在一起工作。

开发人员更了解代码资源，运维人员更了解硬件和部署。把这一切都记在心里，你可以让一些事情变得更高效。

交叉培训。传播双方使用和设计工具的心得，这可以提高工具的可管理性和灵活性。

注意不要过多地要求对方。这不是“我们”VS“他们”。每一个人都是有人权的。每一个人都应该尽可能地为公司多做贡献，而不是为了他们自己。

如果大家相处的很融洽，就可以从容地应对各种紧急事件了。

1.2.8 ?和其他领域的运维一起工作

每个领域的运维都有他们自己的专长。网络，数据库，OS。不要忘记彼此多交流！

一味地墨守陈规是消极的，令人厌烦的。让你的运维们重复的做相同的工作可以很快的增加他们的流失率。要尊重系统运维们在网络运维们的背后观察学习的机会。

时刻记得给人们尝试，学习和成长的机会。

注意别给你最优秀的运维安排了太多的活儿。你想要用的运维是那种有能力给自己找出空闲时间的人。

浑水摸鱼者（编者注：原文为bad eggs，直译为坏蛋）。对待他们要足够强硬。大多数人在帮助之下是可以完成任务的，但是他们必须要学会独立。

【51CTO.com译稿，转载请注明原文作译者和出处。】

原文：Dormando‘s [crappy] Operations Mantras

1.3 ?实践篇

1.3.1 ?现在就修复它，而不是以后再修复它

如果一个Web服务器处于脱机状态，不要担心，因为你应该有10个备用的！

在一周中，专门挑出一天来“清理门户”。更换掉所有存在故障的硬件。在欢度周末之前，确保一切都是完好无损的。

如果令人讨厌的小问题突然发生了，在早上要做的第一件事情就是永久性的修复它们。日志塞满磁盘的情况在上周发生了两次？明天再说吧！如果总是这样，这些问题会堆积起来……

如果你的构建过程是自动化的，充分利用这个优势来修复一些你可以马上修复的问题，或许也可以批量进行修复。

1.3.2 ?让每一件事情都自动化

人们无法（轻易地）搞乱脚本化的任务。

从第二次开始自动化。如果第一次你必须手工来做一件事情，那么把你做的事情写入一个脚本。

带注释的脚本是绝佳的文档。与其把如何安装一些东西的方法详细地写到长达20页文档中，还不如编写一个可以自解释的脚本。

脚本可以被放到自动化的构建过程中。如果要更接近这个目标，应该把一些经常做的事情都应该变成“零时间”的任务。

1.3.3 ?只进行必要的变更

只做小规模的，独立的变更。

如果不是必须改变，那么就保持原样。

这也意味着你必须搞清楚什么时候才应该进行变更。找出什么东西是必须要进行变更的，然后对它进行升级，把它拿出来，让它标准化。

1.3.4 ?Design for change

这里的Design for change（编辑注：技术篇的第一条也是Design for change）针对个人的成长。朝快速解决问题大师的方向努力吧。

如果快速解决问题比较困难，那么你可以学习一些基础知识，做出一张清晰的升级路线图。虽然你的新邮件系统也许并不是你梦想中的、带有强大反垃圾邮件功能的巨大系统；但是架设两台配置干净的postfix邮件服务器会比你想象中的效果还要好。

大家都倾向于把未完成的项目放在那里置之不理。这是你要避免的。

1.3.5 ?尽快地把更新的内容投入实践

一般来说，运维工作就是要让代码更好地运行。并行化，建立起回滚重启机制。

运行内容包括软件更新，安全补丁，配置变更。

使用puppet，cfengine以及你需要的任何工具对配置进行控制。让它干净，简洁，并且容易操作。

文件数量越少越好。如果只是为了推出一个新的数据库就要在20个文件中分别添加一行，那么你的方法一定是错误的。创建简单的模板，不要重复编辑需要手工编辑的数据。

1.3.6 ?规范化，坚持按照规范来行事

OS的规范，httpd的规范，数据库的规范，打包系统的规范。

坚持按照这些规范来行事。对一些方法进行调整和改进，让它变得更有意义。

永远不要紧抓着主版本不放。如果你的产品功能还没有永久性地冻结，你就必须要按照规范继续向前推进，把过去的一些事情都抛在脑后。

按照规范来做的事情越多，你的工具可以发挥作用的场合就会越多。用于支持其他运维领域的软件包越多，可以适应的场景也越多。

1.3.7 ?文档化

把流程文档化

把产品文档化

Deep Trees和ShallowTrees

不要让文档出现冗余。如果一个脚本的帮助文档很长，可以进行引用。好的文档是一个持续改进的过程，它要一直保持准确。

把文档和代码，perldoc，pydoc等联系起来。

过期的文档是有害的。留出一些时间来更新它们。当新的员工遇到问题的时候，和新的员工坐下来一起更新文档。

适当地使用问题跟踪系统（issue tracking）。为操作历史保留文档是十分重要的，以避免为了某个DNS故障的重现去骚扰他人。

1.3.8 ?使用源代码控制工具

使用git或者mercurial。避免使用SVN。

把配置文件、脚本等各种东西都放到源代码控制工具中管理起来。

为代码迁出提供各种入口。

保持迁出的严谨性，精准性和可控制性。禁止提交无法进行审核的变更。应该提交的变更应该是不用源代码控制工具也能容易地进行测试的（在虚拟机环境下，可以直接在一个单独的测试机器上进行测试）。

1.3.9 ?招聘

区分出固执的人和精明的人

不要避免聘请“老前辈”。某个领域的“老前辈”可能已经跟不上技术变革的脚步，以至于你可能不想聘请他们。但是，总是要有几个“超级巨星”来压住阵脚的。

不要避免聘请新手。我认识的很多人都是从一个真正的新手开始的（包括我自己！实际上，我认为我自己一直是一个新手）。经过这个阶段以后，他们会迅速地成长起来。现在正是确立职业生涯的时候。我相信我们中的绝大多数人都是这样的。当然，不包括那些不学习的人，没有积极性的人，或者入错行的人。

1.3.10 ?避免提供商锁入，同时和你的提供商保持良好的关系

购买专有硬件的主要劣势是提供商锁入，你不得不总是使用这个提供商的产品。这可能是一个特殊的SAN，NAS，也可能是特殊用途的随设备存储，备份系统等等（51CTO推荐阅读：别把鸡蛋放在一个篮子里）。尽量避免发生这种事情。如果你完全按照上面的设计建议来行事，那么应该可以很快地在不同的平台上搭建起测试环境。然后，你可以进行硬件评估，自由地进行选择。

如果所有东西都很深奥，都很不明朗，都还没有经过文档化，并且直接依赖于专有的负载均衡器……那么最好别用，因为用了你就不自由。

对你最终选择的提供商好一点。如果你每一次采购都在价格方面把他们逼到墙角，那么你只能得到一些垃圾硬件了。

有时候数据中心有很多潜在的可用资源。尽量把一些免费的远程协助服务写到合同里，比如就更换硬盘驱动器，提供商的出货/RMA条款，以及一些基础硬件的安装等方面的细则进行谈判。我有一个机架的设备，其安装上架的过程我们的人完全没有操心……真的很不错。

1.3.11 ?给开源一个机会

nginx，mongrel，lighttpd，apache，perlbal，mogilefs，memcached，squid，OpenBGPD，PF，IPTables，LVS，MySQL，Postgres，等等。在你选择可信、可靠、昂贵的专有安装程序以前，给开源一个机会。你会发现使用开源软件意味着可以自己添加插件，扩展，代码修复补丁，或者你可以把一些自己无法实现的功能外包出去。在我看来，开源软件是很可靠的，它们通常比巨大负载之下的大型的，昂贵的硬件更可靠。

“一分钱一分货”这种思想是一个彻底的谎言。如果你无法让开源软件为你工作，需要协助，你可以找一个提供商。如果你的团队既睿智又积极主动，这些小伙子们想要搞清楚他们的基础设施是如何工作的，那么你一定无法抵挡来自于GPL或BSD系统的诱惑。

MySQL和Postgres都不错。如果你要使用它们，可以权衡一下利弊。没有什么东西会在晚上从你的衣橱里爬出来“吃”掉你的数据。与经过测试的、稳定的冗余master<->slave MySQL集群实例相比，其实庞大的、处于脱机状态的Oracle实例更容易把事情搞的一团糟。

关于LAMP架构的文章数不胜数。无数知名网站、ISP、甚至企业现在都在使用开源软件。给开源一个机会。最糟糕的结果也不过是浪费一些时间，而最后从你那些心惊胆战的提供商们那里获得一些不错的报价。

【51CTO.com译稿，转载请注明原文作译者和出处。】

原文：http://dormando.livejournal.com/484577.html

2 ?系统管理员必须遵守的铁律

2.1 ?优秀的Windows管理员应该具有的9大品质

最近一篇关于优秀的Unix管理员应该具有的9大品质的文章使Mark Underwood深受启发，他认为优秀的Windows管理员也应该具有9大品质。如果你愿意的话，你也可以添加一些你自己的品质。

《优秀的Unix管理员应该具有的9大品质》的作者似乎听到了很多种不同的声音。这是来自于Windows阵营的回应。

2.1.1 ?无编辑器操作

我们不需要臭名昭著的编辑器。脚本就很好，我们钦佩那些精通vi和emacs的人，但是我们不会对它们“顶礼膜拜”的。如果我们必需要编写脚本，我们有Powershell，而且，我们中的大多数人都忙于提升其他8种品质，根本就没有时间学习它们。

推荐专题：Windows中的脚本技术-Windows Powershell

2.1.2 ?高权限的觉醒

Vista那糟糕的公众形象使我们清楚地认识到了“低权限”和“高权限”的优缺点。套用一句丘吉尔的话，有些人从来都没有遭受过这么多的苦难。在我们的工作中，我们清楚地认识到了这一点，而且，我们的用户社区也已经清楚地认识到了，对这个问题的漠视会造成怎样的后果。

2.1.3 ?工作站比服务器更重要

服务器技术很有魅力，而且回报也很大，但是，工作站上的管理服务水平真的很重要。当CFO的Outlook客户端挂掉的时候，我们要对整个供应链负责，从他/她的笔记本的F9键，所有的交换机和路由器，一直到他的Exchange邮箱，我们都要检查一遍。无论潜在的问题是什么，Windows管理员都会勇敢地接受现实，把它当作“Outlook问题”来处理的。

2.1.4 ?Google搜索，而不是编码

相对于其他系统的管理员来说，我们不会为了编写特定得脚本而给我们的系统增加潜在的安全漏洞，即使这会影响重复性的，手工任务，我们也在所不惜。取而代之的是，我们会假设某些人在某些地方遇到了同样的问题。我们会跳到最近的浏览器会话上，然后搜索一个经过全面测试的解决方案（其他人已经使用过这个解决方案了）。

2.1.5 ?我们更喜欢测试过的解决方案

我们尽量不去当“炮灰”。我们依赖于世界上最大的软件公司来检查我们部署的产品，经过时间验证的解决方案通常会胜过那些最新的，最伟大的解决方案。当一个用户有一些很酷的东西要尝试的时候，我们会把他们转到一个独立的子网或DMZ上的一台全新的虚拟机中的。

2.1.6 ?“尸检”是顾问们的事情

我们可以像下一代极客一样极客，也可以像下一代极客一样创造出比“Stuxnet”还要“优雅”的奇迹，但是最终我们是有“党派”的，有组织类别的。当发现一个问题的时候，我们也像其他人一样对问题的成因充满了好奇——即使研究证明只是我们犯了一个错误而已。但是通常情况下，我们都忙于处理下一次发布，下一次危机，或者下一次升级，根本就没有时间仔细考虑它们。我们深知，一个严肃，公正，优秀的“尸检”报告最好由一个公正的第三方来完成，而不是身心疲惫的管理员。

2.1.7 ?我们知道我们不知道什么

虽然我们也涉猎过Red Hat和Ubuntu，而且也曾为了让我们的“ServerFarm”中的Linux机器可以正常运行而费劲心力，但是我们深知，那只是短时间的涉猎，短时间地接触到了我们不知道的东西。我们宁愿让其他人维护那些完全用“bash”或“csh”编写的应用程序，尤其是那些没有“man page”的应用程序。

2.1.8 ?无论这个问题是谁提出的，我们都假设这个问题是我们自己的问题

像其他人一样，我们也可以凭借我们在服务器和网络产品方面的专业知识而趾高气扬，但是在专家的世界中，我们只是一些小角色。如果我们是CCNA，那么我们知道的东西就不只是告诉Microsoft System Center Configuration Manager她应该如何把新的虚拟机放到她的系统中，或者告诉她如何通过她的网络来管理桌面许可证这么简单的。类似地，我们也期望能遇到那些和我们专业知识水平相当的临时用户提出的专业问题，我们认为这是一件好事情。当我们需要帮助的时候，我们也可以请教这些用户。

2.1.9 ?网络安全也是我们的工作

无论我们是否是CISSP证书的持有者，我们都应该让我们的企业尽可能多地了解已经到位的各方面的安全措施。这几乎涵盖了从桌面磁盘加密到应用程序的每一件事情。我们不会以“Windows通常是攻击的目标”为借口来逃避责任的。

2.1.10 ?经验分享：搞清楚何时应该跟注，何时应该弃牌（重启）

这是事实。有时我们不得不重启Windows。当然，我们希望我们不必那样做。我们宁愿和我们的爱人待在家里，看比赛，或者和朋友一起喝啤酒。我们很担心最新的补丁会影响稳定性，或者带来新的漏洞。我们经常提醒自己，没有人可以入侵一台关闭的服务器。

2.2 ?优秀的Unix管理员应具有的9大品质

编者按：优秀的Unix系统管理员是怎样工作的？来自InfoWorld的Paul Venezia尝试为我们总结优秀Unix系统管理员的九大特点。Paul是一位资深编辑与咨询师，关注Perl，PHP，SQL，FreeBSD，Linux和Windows等领域。

2.2.1 ?我们不使用sudo

就像“caps lock”对于极客来说只是一个可有可无的控制键一样，sudo也只是胆小者的拐杖。如果我们需要对root做一些事情，我们需要su到root，这个sudo废话毫无意义。

实际上，对于那些强制所有用户都要使用sudo的类Unix的操作系统来说，我们要做的第一件事情就是sudo su -，然后改变根口令，以便于以后我们可以更加方便地su -。使用sudo就像在带有充气减震器的水槽中打保龄球——的确很安全，但是你也别想一展身手了。

2.2.2 ?我们使用vi，而不是emacs，更不可能是pico或nano

虽然我们知道，对于许多Unix管理员来说，emacs更贴心一些，但是，实际上它只是Microsoft Word的Unix翻版而已。vi（和vim）才是那些真正的Unix极客们手中的利器，他们需要在完成任务的同时，不被那些emacs自带的毫无用处的东西把事情搞糟。Emacs居然内置了一款俄罗斯方块游戏，简直是岂有此理！

虽然我只能万般无奈地承认vim中那些花哨的功能（例如：代码折叠和语法高亮）可能只是一时失误，但是，在一天的工作即将结束之际，真正的Unix工作可以和vi的模型编辑概念很好地融合在一起却是不争的事实。除此之外，它那苗条的身材和通用的可移植性可以让它成为一个真正的编辑器。感谢Bill！感谢Bram！（编辑注：Bill Joy是vim编辑器的开发者，后来Bram Moolenaar对其进行了改进）。

编辑推荐：有关vim编辑器使用心得的十个分享

2.2.3 ?我们把正则表达式当成我们的利器

对于正则表达式的排斥，甚至是漠视似乎都是“邪恶”的键盘造成的恶果。但是，对于我们来说，它是如诗般优雅的。它的强大表现在，任何其他的著名工具都无法和pcre (Perl Compatible Regular Expressions)的复杂性相匹敌。如果你需要在100000行文件中替换掉每一行的第三个字符（除了那些后面是数字4的字符之外），那么正则表达式不只是完成这个任务的一个工具而已——它还是完成这个任务的唯一工具。那些可怜的人时常会在他们的email中接收到一些字符串片段和一些声泪俱下的请求（寻求一个解析这些字符串的正则表达式），一般还会承诺请你喝一杯（但是从来没有兑现过）。

编辑推荐：正则表达式完全学习手册：菜鸟入门指导

2.2.4 ?我们天生就比较懒惰

当遇到一个看起来需要很多手工的，重复性的工作才能解决的问题的时候，我们这些守旧派的Unix代表一定会选择编写一些代码来搞定它的。这通常会比手工操作更加节省时间，虽然有时候事实也并非如此。无论如何，我们宁愿把时间花费在可以以后被引用或者使用的工作上面，也不愿意简单地修复眼前这个问题。通常，当几年以后我们遇到了类似的问题，然后可以从我们的起始目录（home directory）中的一个文件yank几百行Perl代码，在短短的几分钟之内解决掉了这个问题，然后回过头去分析那些可以提高工作效率的其他代码的时候，我们就可以获得回报了。或者，我们也可以去玩一下愤怒的小鸟。

编辑推荐：怎样做一个优秀而懒惰的系统管理员

2.2.5 ?我们更喜欢优雅的解决方案

如果有好几种方法可以修复一个问题或者实现一个目标，那么我们会选择花费更多的时间来开发一个既可以解决当前的问题又能防止将来发生类似的问题的解决方案，而不是简单地贴上一块邦迪牌创可贴。这是因为我们讨厌再次遇到那些在我们的印象中已经解决过的问题。我们认为，如果我们可以提前多考虑几步，防止将来发生类似的问题，那么在将来，我们可以节省更多的精力。通常我们都是对的。

2.2.6 ?我们一般对事不对人

enlightenment有足够的把握可以让你的Unix基础知识达到一定的水平。这意味着我们从不认为一个问题会一直存到我们发现它为止。告诉一个优秀的Unix管理员，一个文件“vanished”了，他只会轻蔑地嘲笑你。证明给她看，这真的发生了，他就会不知疲倦地研究这个问题了，直到可以找到一个合理的原因和解决方案为止。许多人都认为这是傲慢和自负的表现。的确是——但是我们有这个资本。

2.2.7 ?我们研究问题的时候，比医生的检查还要细致

当处理一个大问题的时候，我们在“尸检”上花费的时间要比我们解决这个问题所花费的时间多得多。如果不是工作压力太大，让我们无暇分身去研究这个问题，那么我们一定会搞清楚这个问题的确切原因的。在一个强悍的Unix管理员的工作中，不存在不可思议的现象。每一种情况必须要有逻辑起点，而且可以按照合适的路径来追本溯源。简而言之，每一件事情都有原因，在找到这个原因以前，我们绝不放弃！

对于我们来说，通过HUPping一个进程，或者改变一个文件或777目录的权限来“止血”是一件很容易的事情，但是这连成功的一般都算不上。为什么这个进程必须要重启？这并不是必须的，我们需要知道为什么。

编辑推荐：系统管理员需要掌握哪些软技能？

2.2.8 ?关于Windows，我们知道的也很多（过去我们只是装作不知道而已）

虽然在我们自己的机器上，我们可能并不运行Windows，而且，对于Windows服务器，我们似乎也不屑一顾，但是在诊断和修复Windows问题方面，我们却是行家里手。这是因为，当它们的“鲜血”流到我们的“版图”上的时候，我们必须要处理这些问题。但是，我们不喜欢承认这个事实，因为大多数情况下Windows都没有Unix那样深厚的逻辑基础，这让我们很困扰。参见上面的品质五和品质六。

2.2.9 ?几乎从来都不选择重启

Unix设备不需要重启。如果并非绝对没有其他选择，我们会花费数个小时在系统运行的状态下修复这个问题，而不是重启。我们的想法是除了内核或硬件改动，其他情况下都没有理由去重启，重启只是修复这个问题的临时办法而已。如果这个问题发生了一次，并且通过重启被“修复”了，那么它还会再次发生的。我们宁愿修复这个问题，而不是简单地拔掉电源，等着它再次发生。

从“谎言”的角度来看，这些品质中的某些品质看起来会有点另类或者难以理解，那是因为他们本来就是如此的。其他人只能看到棘手和困难的时候，我们却看到启示，学习，经验，更重要的是，我们看到了逻辑。

【51CTO.com译文，转载请注明原文作译者和出处。】

原文：http://www.infoworld.com/t/unix/nine-traits-the-veteran-unix-admin-276

2.3 ?系统管理员必须了解的六大铁律

系统管理员们踏上岗位，都已经具备了一些有关系统和服务的知识，如如何搭建生产环境，如何备份，如何监控系统等等，这些知识可能来自学校，可能来自自学。然而在工作了数年之后，系统管理员们对生产环境中的操作又会有了很多新的了解。下面，资深运维专家Paul Venezia为我们总结了他认为系统管理员在生产环境中必须遵守的六大铁律。这是一些学校里不会教的知识。遵守这些规则，你几乎可以解决任何一个问题。

在复杂的数据中心基础设施中，这种能力可以让你通过丰富的经验和自身的知识快速而准确地发现问题之所在。这种能力只可意会，不可言传。没有人会提供和“超自然故障排除”有关的认证的。

但是，那些重量级的问题解决专家都会遵守一些通用的，不成文的规则。这是我自己使用的六个规则。注意，它们适用于大多数情况，但是并不是所有情况。

2.3.1 ?永远不要修改服务器或网络设备的连接接口

虽然这听上去很简单，但是，令人吃惊的是，人们经常会修改他们用于连接到某个设备的网络接口的属性，这种行为的失败率很高。有时，这条规则可能是可选的，但是，如果有一种方法可以排除潜在的隐患，何乐而不为呢？如果你不得不修改这个接口，可以在这个接口上配置一个辅助IP（secondary IP）——通过另外一个设备或子网，串行控制台，KVM等来连接。如果设备放在远程的办公室里（那里没有IT职员），那么这绝对是一条真理。

2.3.2 ?保证总是有办法回到原点

无论何时，只要有可能的话，都要提供一种可以把问题恢复到原始状态的方法。这意味着，在对故障磁盘做任何修改以前，应该为这个故障磁盘做一个映像，备份整个目录结构（你不可能知道你以后需要哪些文件，这样可以以防万一），或者，在你胡乱摆弄一个已经出现故障的操作系统以前，应该在物理服务器上抽取出这块磁盘的RAID1阵列。当然，在虚拟机环境下，这会更加容易一些，因为你可以简单地做一个快照。

2.3.3 ?文档，文档，还是文档

在所有这些规则中，这条规则也许是大家最少遵守的规则了。毫无疑问，应该把一个问题和解决方法文档化。当你处在混乱状态之中的时候，你的解决方法也许并不明智。这就是说，当一个问题尘埃落定以后，要保留一份“尸检报告”，通过这份报告，你可以重新检查当时那个解决方案采取的步骤和途径。把它写下来，然后把它保存在安全的地方，最好是放到公司内部的wiki上；并且，应该备份到几个不同的地方。

推荐阅读：系统管理员应该怎样高效的书写文档

2.3.4 ?在IT领域，不存在魔法，但是却存在幸运

就像 Thomas Jefferson 说的那样：“我发现我工作的越努力，我就越幸运。”在IT领域，也是这样的。你花费越多的时间来研究你的基础设施，关注路由器，交换机，服务器和其他设备的特定的工作条件，你的基础设施就会运行的越流畅。这些日常工作可以让你在问题的早期阶段就发现这些问题，当问题真的发生的时候，你可以更加快速地作出反应。另外，在IT领域，有很多种方法可以“制造”幸运。例如，使用一些工具，让网络设备配置的备份自动化；如果使用这种方法的话，当你的交换机发疯的时候，你可以在几分钟内恢复它，而不是几个小时。

推荐阅读：系统管理员最需要自动化的十大任务

2.3.5 ?在你修改每个配置文件以前，要对它们进行备份

这条规则只适用于Unix服务器和几乎各方面的配置都提供了配置文件的网络设备。在你弄坏敏感的配置以前，首先对交换机和TFTP（Trivial FileTransfer Protocol）主机的配置文件进行备份。在Unix系统上，可以简单地把something.confcp到 something.conf.orig。

在必要的时候，如果想恢复到过去那个良好的状态，只需要简单地把文件拷贝回去，然后重启那个服务就可以了。因为注册表的存在和Windows喜欢把简单的概念复杂化，所以，在Windows系统上，这通常是不可能的。即便如此，你还是可以在胡乱摆弄注册表以前，对注册表进行备份，这样的话，如果天下大乱了。你可以重新导入备份的注册表文件。记住：当你对Windows注册表进行修改的时候，服务器的生命就掌握在你的手中。

2.3.6 ?监控，监控，还是监控

一点点预防工作就可以省去一个月的周末加班时间。你应该对你的数据中心的方方面面进行监控，从房间的温度，机架，和服务器，到服务器进程检查，正常运行时间检查......你还应该为所有网络设备构建一个集中式的日志系统，除此之外，你还应该安装一些趋势分析工具来监控带宽利用率，温度，磁盘空间的使用率，和其他的参数。当这些参数超过正常的阀值的时候，那些监控工具应该通过必要的手段来通知你。

如果在一个数据库由于分区过满而被破坏的一个小时以前，能收到一个email或短信，那么可以省去无数的工作时间和宕机时间。对你的数据中心进行监控刻不容缓。

推荐专题：Linux监控工具的展览馆

这些规则不仅仅是需要遵守的规则——在你日常的工作中，这些规则应该是贯彻始终的。在IT领域中，对于许多人来说，它们是核心理念，但是对于其他人来说，它们是神秘的——有点像忍者。

【51CTO.com译稿，转载请注明原文作译者和出处。】

原文：The six immutable laws for troubleshooting IT  作者：Paul Venezia

2.4 ?Linux系统管理入门必须经历的三步

Linux系统管理员如何入门？这是很多Linux新手们关心的问题。一位CentOS的开发者，在英国伦敦工作的系统管理员Karanbir Singh近日撰写了一篇博文，对Linux新人如何进入Linux sysadmin的世界进行了阐述。以下为全文译文：

51CTO推荐专题：SA，神仙与装机男：运维的工作到底啥样儿？

我们常常会看到这样的问题：面对 Linux 系统管理这个庞大的世界，应该从哪里开始？说实话，我觉得这个问题不存在一个清晰明确的答案。Linux 认证并非最理想的选择。你可以去参加一些培训课程，比如 RHCE。但是，如果没有任何背景信息而去参加培训，你可能无法享受到培训带来的好处，因为所有课程都有一个前提假设：你已经掌握了一些基本知识。

2.4.1 ?熟悉Linux以及发行版

一个开始系统管理员学习的方法是抓起一本相关主题的书来看（编辑推荐：51CTO读书频道的Linux版块有很多相关图书的样章）。然后安装几个 Linux 版本（参考：几个比较知名的发行版），然后在你喜欢的版本上搞一些 VM 设置（参考：Linux下三大免费桌面虚拟机评测）。从一个版本开始，然后继续使用这个版本，至少用上几个月。但是，一旦熟悉了那些基础知识，你就要转向其他发行版本，看看其他版本是如何工作的，这一点也非常重要。无论使用哪个版本，不同之处仅仅在于一些设计和平台常见通讯。最根本的操作系统还是 Linux，这一点不会改变。

使用一个新的平台时，有一点非常重要：你必须真正地投入进去。对此，有一个简单的方法：看看你现在正在做的事情，无论使用哪个平台，试着在这台 Linux 计算机上使用相同的方式去做系统的事情。掌握了那些基础的知识和操作之后，以后你就应该将这个 Linux 版本作为常用的工作平台。从低等级管理能力方面来看，这种方式并不会让你学到太多；不过，它可以让你学会从用户的角度来思考问题。

我一直都认为，最优秀的管理员一定是从用户的角度，从开发者的角度，然后从平台（和管理员）的角度，对问题进行思考。最后我们还要记住，计算机是用来工作的，而管理员的角色就是确保计算机能够充分发挥能力来完成工作。不要迷失了方向：目标仍然是做某件工作。

2.4.2 ?熟悉相关的应用程序/服务

我最初接触 Linux 的那段时间，常常会感觉很难与其他人的应用程序建立一种关联，很难弄清楚他们如何使用他们的计算机和网络。之所以很困难，因为我没有处于他们所在的位置，甚至连跟上最新的情况都很困难。在寻找那种亲身体验的机会时，我认识到，和一个应用程序建立关联的最好方式就是加入他们的邮件列表。这样，你就可以看到其他人遇到的问题，你也可以提出自己的问题，比如为什么那个事情要用那种特别的方式来解决，你还可以查看其他人贴出的 bug 报告。这些信息都清楚了展示了在“真实世界”中人们是如何使用这个应用程序的，这将为提供一个很好的根基。大约 14 年之后，我仍然认为特定程序的用户小组是学习一个应用程序的最好场所，你可以了解到如何对它进行管理，最好的部署方式，还有开发者/用户如何看待这个应用程序的角度。

2.4.3 ?编写代码

最后，编程和实际写代码的能力也是有益的。不要相信那种到处流传的说法：管理员无需写代码。和周围优秀的系统管理员聊聊（有很多这样的人），你会发现，几乎每个人都会告诉你，他们 40-60% 时间用于编写脚本，处理应用程序，而脚本的开发知识是有帮助的。我不是说你需要搞一个 Java 认证，但是你要对 bash的基本编程有很好理解，至少能够使用 python、perl 和ruby 中的一门语言（必要）。需要了解 unix/c 的传统想法仍然存在，不过现在，并不是有很多系统管理员需要深入到驱动程序开发那个层次，他们需要了解的大多数函数代码可以利用 bash、ruby、perl或 python 进行很好的处理。

原文：http://www.karan.org/blog/index.php/2010/09/28/getting-started-with-linux-and-sysadmin

其他相关推荐：

资深系统管理员给Linux/Unix新人们的建议

Linux系统管理员都应该熟悉的工具

系统管理员不可不知的三条黄金法则

2.5 ?系统管理员应该定期完成的九件事

Linux系统管理员每天都应该做一些什么工作？事实上，基于Linux搭建服务现在已经非常简单，但是如果你忽略了一些事情，你的系统很可能将在流量高峰期或是黑客入侵时挂掉。国外一位专业的系统管理员将系统管理员的日常工作总结为九件事，这九件事你都定期做了么？

今天，Linux的发行版非常地容易安装也非常容易入门。就算是一个缺乏经验的系统管理员，建立必须的服务并完成可运行的程序通常也可以在几小时内完成。

很不幸，容易入门反而掩盖了需要做的维护工作，这些工作是保持系统稳定和使系统长期处于一个良好的工作次序中所必需的。一个单一的服务器通常可以在没有人工干预的情况下运行很长时间。但是前提是所有其他的位和块必需被提前配置。

关于这个列表，最糟糕的事情是你可能已经几个月或几年没有做这些事情了。你忽略这些事情中的任何一件，它们都会在最糟糕的时候回来作祟：比如流量高峰期，硬盘驱动器崩溃，或黑客攻击的时候。Linux系统管理员每天都应该做一些什么工作？我们这就为您来总结一下。

2.5.1 ?配置管理

我用配置管理来开始，是因为它和这个列表中的其余项有很大的不同。这一项对单一的服务器并不重要，但是如果你有许多系统，这一项就至关重要了。Puppet或Chef这样的配置管理工具允许你编写‘recipes’来定义服务器应该如何的被放置在一起。那些‘recipes’可以在每个服务器上运行产生一个一致的、容易复制的安装程序。这可以让你立即启动一个系统的新拷贝，可以给你的安装提供极大的自由度。

配置管理是做了，但是，却给服务器安装程序添加了一定的初始化复杂性，所以如果你胆子小，不用也罢。不过，即使只有两个或三个服务器，好处也是相当巨大的。

2.5.2 ?备份

这一项是显而易见的，大多数的系统管理员都会在这方面做点工作的。如果你没有一个可靠的备份策略，你现在需要马上调整它。哪怕只等一天，后果很可能就是是灾难性的。同时请确保你正确的做了备份，因为备份很容易做错。Mozy，Carbonite，Backblaze等工具的At-home备份已经取得了很大的进展，但是类似的Linux解决方案还远没有成熟。Rsync ，tar，和类似的脚本工具一直很受欢迎，并且也是可行的替代方案，但是必须要小心，以适应像MySQL数据库那样的特殊情况。每个人的备份需求是不同的，所以无论你选择什么解决方案也要仔细研究它潜在的不足。你选择的解决方案应该：

◆定期运行

◆保持多轮的备份

◆自动的删除旧的备份

◆在你的现在的操作系统以外存储备份

◆保持和你的原始数据一样的安全性

◆合并所有的关键数据，关键的配置文件（更换服务器以后启动和运行系统可能会需要的任何东西），和最近的日志

2.5.3 ?测试你的备份

紧跟着备份计划的是测试它。这意味着定期检查备份是否一直在做，产生的文件是否是有效的并且是否没有被损坏，以及他们是否包括你需要的所有数据。一个好的经验法则是如果你的备份每30天一轮换，那么你应该经常的重新检查他们。这里自动化工具可以帮一些忙（自动地检查备份文件是否是最新的，是否是合理的大小并且是否有效）。尽管如此，没有任何东西可以替代人的眼睛……否则，当你发现你并没有备份那些你认为你已经备份的数据时，就只有哭的份了。

51CTO推荐专题：Linux 系统备份——操作实践与工具介绍

2.5.4 ?日志轮换

在最近几年，Ubuntu，RedHat和其他主要的发行版针对他们提供的软件包的logrotate的运行和配置有了很大的改善。所以你的apache和mysql日志也可以被合适的轮换（默认设置是相当合理的，虽然可能并不是你希望的方式）。但是你添加的“额外”的东西，例如Rails应用程序，需要建立它自己的logrotate条目。缺少这个步骤会在最不合适的时刻引发无数的“硬盘驱动器已满”的服务器错误。当然，通常你甚至不知道你的日志引发了这个问题。针对这种情况，资源监视才是关键。

51CTO推荐阅读：明明白白你的Linux服务器——日志篇

2.5.5 ?资源监视

跟踪CPU，内存的使用情况，硬盘空间，带宽，等可以让你更好的洞察你的系统状态。当流量增加的时候，你可以比较你的增加的内存或IO使用情况，来提前规划你的“scaling”。RRDTool/Munin，ServerDensity和Cloudkick是观察这些随着时间的推移而变化的数据的很好的选择。如果你选择的工具包括对意外的变化（失控的进程，驱动器已满等）的警报功能，你将会领先任何潜在的问题一步。

2.5.6 ?进程监视

对你的网站来说，让你的Apache，MySQL和类似的进程一直处于运行状态至关重要。有几个很好的工具，例如Monit和God，可以帮助你确保你的进程一直处于运行状态。通过检查进程的响应性，打开的端口，或进程id那些工具可以重新启动一个已死的服务或在一个失控的进程使你的整个系统崩溃前终止它。配置这件事的规则是个老大难问题，但是当一切都做好的时候，可以节省大量的凌晨3点钟的宕机时间。

51CTO推荐专题：Linux监控工具的展览馆

2.5.7 ?安全加固（Hardening）

Hardening包含了许多不同的操作，这些操作可以使你的stock系统更安全。许多简单的操作经常会被遗漏。你真的知道那些正在运行的进程中的每一个都做了什么吗？在你的系统上，哪些额外的端口和服务被打开了？有合适的PAM模块载入来进行安全认证吗？又一次，RedHat和Ubuntu走在了时代的前列，他们提供了安全stock系统，并确保最常见的软件包遵守正确的安全协议。但是，这并不意味着你可以跳过这个步骤。

2.5.8 ?安全更新

在一个基于apt或RPM的系统上，安全更新是很容易执行的。这个过程的陷阱是很难知道升级包是否会在你的栈里引发某些类型的错误。为了确切知道升级包将对你的系统产生怎样的影响，拥有一台同样配置的模拟服务器是唯一的好办法。幸运的是，由安全更新引发的麻烦是十分罕见的。修复一个更新的兼容性问题，需要花费一些停机时间，这个风险要比你的系统上的一个已知安全漏洞被利用的风险小很多。所以，不要让“not knowing”阻止你进行正确的升级。最后，不是每一个安全漏洞都能马上获得一个安装补丁。查看CVE字典上的可用警报，可以让你在补丁可用前，在保持你的系统安全性方面争取主动。为了确保一切都平滑的运行并保持最新，在这方面真的没有什么可以代替人的肉眼。

2.5.9 ?日志监视/安全扫描/入侵检测

这个列表中的所有项都是最低限度需要完成的。它们很容易被忘记，直到你的系统已经被入侵为止，你可能都不会想起它们。对异常活动，黑客攻击和其他恶意行为的持续扫描，对于帮助阻止或减轻攻击来说，是十分重要的。

51CTO推荐阅读：曹江华访谈实录：Linux服务器安全策略详解

总结

这当然不是一个完整的列表，但是它也是十分广泛的，许多开发者和系统管理员只是没有时间、兴趣或知识来处理它们。更糟糕的是，许多开发项目被移交给了客户，而一旦技术团队迁移到另一个项目上，这些客户就没有能处理这些事情的职员了。

原文：http://www.roundhousesupport.com/blog/9-things-you-should-be-doing-with-your-server-but-probably-arent

（51CTO编辑注：RoundHouse是一家国外的IT运维外包服务提供商。）

【51CTO.com译稿，合作站点转载请注明原文译者和出处。】

【编辑推荐】

系统管理员必须熟记的几个Linux命令

我讨厌电脑！--一个系统管理员的自白

系统管理员的苦恼与现状

2.6 ?运维人员应该时刻谨记的十条安全法则

网站安全问题可以说是现在最引人关注的问题。本文介绍了十条措施维护网站安全最低限度需要做到的事情，主要是给大家提供思路，为广大运维人员提供参考。这十条措施涉及到用户身份验证、数据加密传输、子网划分、灾难备份等多个方面的内容。

网站安全问题可以说是现在最引人关注的问题，有关服务器安全、用户隐私安全、企业数据安全的文章和争论从来没有停息过。系统管理员作为网站安全的第一道哨岗，既要确保网站服务器系统的安全，也要考虑到网站应用的一些基本安全防护。

在之前《明明白白你的Linux服务器——安全篇》中，抚琴煮酒列举了一些Linux/Unix服务器系统最基本的一些安全防护措施，这篇总结对于服务器端的安全防护思路介绍的相当详细。但是要保护网站的安全运作，仅仅针对服务器系统本身的防护是不够的，还需要有一个更全局的视角和防范思路。本文中介绍的十条措施虽然涉及到用户身份验证、数据加密传输、子网划分、灾难备份等多个方面的内容，但所有这些其实都是维护网站安全最低限度需要做到的事情。文章并没有深入的介绍每一个方面应如何实施，主要是给大家提供思路，为广大运维人员提供参考。

作者简介：李洋，博士毕业于中科院计算所。10多年来一直从事计算机网络信息安全研发工作，曾主持和参与多项国家重点项目以及信息安全系统和企业信息安全系统的研发工作。具有Linux系统应用、管理、安全及内核的研发经验，擅长网络安全技术、协议分析、Linux系统安全技术、Linux系统及网络管理、Linux内核开发等。

网站前端防护

2.6.1 ?网站用户的身份认证

一般可以采用用户名+密码验证，确认用户登录身份，并根据数据库中预设的权限，向用户展示相应的界面。

对于重要的网站应用，需要根据PKI机制，验证用户提供的证书，从而对用户身份认证（服务器对客户端认证），并确保交易的不可抵赖性。证书的提供可以采用两种方式：文件证书或是USB设备存储的证书。文件证书保存在用户磁盘和文件系统上，有一定的安全风险，但是可以免费；USB证书安全性高，但是一般需要向用户收费。

有关身份认证的具体操作，编辑推荐读者们关注51CTO安全频道的身份认证技术专题。

2.6.2 ?网站数据的加密传输

对于使用Web浏览器的网上系统应用，采用SSL+数字证书结合的方式（即HTTPS协议），保证通信数据的加密传输，同时也保证了用户端对服务器端的认证，避免用户被冒充合法网站的“钓鱼网站”欺骗，从而泄露机密信息（用户名和密码等），造成不可挽回的经济损失。

如何建立SSL（HTTPS）网站？鸟哥的私房菜里面有一章进行了简单的介绍。

2.6.3 ?用户账号使用行为的日志记录及其审计

系统服务器侧应根据账号，对用户的使用行为进行详细的日志记录和审计，通过上述因素的日志记录，进行阶段性的审计（时间间隔应该比较小），从而做到发现用户账号的盗用、恶意使用等问题，尽早进行处理。

2.6.4 ?恶意用户流量的检测、过滤及阻断

系统服务器侧应部署IDS入侵检测系统、IPS入侵防护系统、防火墙等设备，或者部署目前高效、流行的UTM（统一威胁管理）设备，对恶意用户采用的各种攻击手段进行检测和防护，重点过滤恶意流量、突发流量等。

相关阅读：

51CTO安全频道的IDS入侵检测专题

入侵防护系统(IPS)初探

了解统一威胁管理(UTM)技术

2.6.5 ?对非正常应用请求的过滤和处理

系统的服务器端，尤其是数据库服务器端，应该通过配置和增加对用户非常长应用请求的过滤和处理模块，以避免由于数据库的自身漏洞未及时打上补丁而遭受目前流行的SQL注入攻击等。

网站服务器侧

2.6.6 ?合理的子网划分及流量分割

系统服务器侧包括大量的服务器类型，包括数据库服务器、Web服务器、FTP服务器、邮件服务器等，为了避免由于恶意流量造成的某种服务器崩溃，而引起的攻击后果扩散，并最终导致其他服务器也发生“雪崩效应”，则需要通过子网隔离（比如VLAN划分）、DMZ区域的设定等方式来将这些服务器放置在不同的安全域当中，做到流量和数据的安全隔离，从而将服务器端在遭受攻击后对整个业务系统及其他内网资源和数据造成的影响尽量控制在最低的范围内。

参考阅读：VLAN的划分方法

2.6.7 ?负载均衡及负载保护机制

系统面临着巨大的服务量，服务器端的设备基本上都需要有多台服务器进行业务分担，这样才能提高性能，避免处理瓶颈的出现，因此，需要采用合理的负载均衡和负载保护机制：

◆对各服务器的业务流量进行有效地分担，可按照Round Robin、LRU等方式来进行负载均衡

◆负载保护机制需要实时地对每台服务器的CPU资源、内存资源等进行评估，如果一旦超过设定的阈值（80%或者以上），将马上进行过载保护，从而保证服务器自身的安全

负载均衡相关推荐阅读：

负载均衡技术全攻略

揭秘企业级web负载均衡完美架构（图）

负载均衡实例：如何解放昼夜不眠的网管？

2.6.8 ?灾难备份及恢复

任何系统都不能说100%的安全，都需要考虑在遭受攻击或者是经受自然灾害后的备份恢复工作，需要着重考虑如下几点：

选择合适的备份策略，做好提前备份，包括全备份、差分备份、增量备份等等

选择合适的备份介质，包括磁带、光盘、RAID磁盘阵列等

选择合适的备份地点，包括本地备份、远程备份等等

选择合适的备份技术，包括NAS、SAN、DAS等等

作好备份的后期维护和安全审计跟踪

Linux系统的备份手段和工具可以参考51CTO系统频道的Linux 系统备份——操作实践与工具介绍专题。更多有关灾难备份和恢复的信息可以在51CTO的存储子站WatchStor.com获取。

2.6.9 ?管理规范化

系统功能复杂，业务数据敏感，保密级别比较高，并且对不同管理人员的权限、角色要求都不尽相同，为了保证安全管理，避免内部管理中出现安全问题，建议作如下要求：

严格划分管理人员的角色及其对应的权限，避免一权独揽，引起安全隐患；

作好服务器机房的物理条件管理，避免电子泄露、避免由于静电等引起的故障；

应作好服务器管理员的帐号/口令管理，要求使用强口令，避免内部人员盗用；

作好服务器的端口最小化管理，避免内部人员扫描得出服务器的不必要的开放端口及其漏洞，实行内部攻击；

作好服务器系统软件、应用软件的日志管理和补丁管理工作，便于审计和避免由于安全漏洞而遭受到内部人员的攻击；

根据业务和数据的机密等级需求，严格划分服务器的安全域，避免信息泄露。

2.6.10 ?网站漏洞自我挖掘及防护

采用漏洞扫描和挖掘设备，对内网各服务器进行阶段性的扫描，并根据扫描所得的风险和漏洞进行及时地修补，以实现该漏洞为黑客使用之前进行自行修复的目的。

这方面的工具服务很多，比如五大著名的免费SQL注入漏洞扫描工具，十大Web服务器漏洞扫描程序等等。

上面这十条，并不是做了就能够保证网站安全，而是要“做好”，必须做好。正在阅读这篇文章的运维人员们，上面这些，你都做到了吗？

【编辑推荐】

资深系统管理员给Linux/Unix新人们的建议

给系统管理员们的节日礼物

系统管理员应该定期完成的九件事

系统管理员不可不知的三条黄金法则

3 ?系统管理员软硬技能

3.1 ?漫谈运维：半神半仙亦民工

运维工程师到底都在做什么？要回答这个问题，当然是有经验的运维自己来说最为真实。运维到底需要做哪些工作？网络，系统，安全，存储，测试，研发……全都要会！说运维是神仙都不过分。本文作者在撰写此文时已经有了6年的运维经验，让我们看看这群半神半仙的民工们到底是怎样工作的。

作者前言：看到chinaunix最近出的门户网站运维板块veyron大侠写的文章《门户网站运维abc》（51CTO编辑注：这篇文章目前尚未完成，部分整理版可以在这里阅读）深有感触，特写以下文章：

《谈网站或其他服务器运维》，这里只谈运维工程师所要做的细节工作，让人们知道运维工程师到底都在做些什么，至于上级所要做的，只是提一下，不做参考。

以下是个人观点，我说的只是我自己的想法，也是我发展的目标。你可以有异议，我们是来交流的。你对的我肯定会向你学习。因为我也在摸索。运维工程师至少要能做以下的工作：

1，网络工程师的工作

你至少要能配置CISCO 6509以下的设备，熟悉各种网络协议，否则网络出问题的时候你会傻掉。

2，系统工程师的工作

你至少要理解各种系统服务，在出问题的情况下要迅速解决问题，而不是等系统工程师来解决。

3，安全工程师的工作

我不要求你一定要会各种网络编程，但是在服务器收攻击的情况下，没有防火墙的情况下，做一些简单的处理工作。

4，存储工程师的工作

至少要熟悉各个厂商的设备，各种备份和还原的办法

5，测试工程师的工作

在新版本上线之前，你至少要协同测试工程师做测试工作，因为你是运维人员，不了解程序架构导致无法解决故障，你也有一份责任。

6，研发人员的工作 

运维工具都需要自已开发，熟悉开发语言，需要有过实际开发经验，否则工作会非常痛苦，我深有体会。

7，英语

不想说了，我的最大痛苦就在这里

8，好的沟通者

不出问题时候你可以打游戏睡觉，出问题的时候要能和项目人员沟通，快速解决问题，而不是推；我知道有很多人能推责任，你可以做替死鬼，但是离开这个工作你还能找到更好的；把责任推到别人身上的人，下次出问题的时候，绝对没人帮你。你要能和各个兄弟部门关系非常的密切，出了问题有兄弟帮你担责任；也要能非常扯皮，没事在会议上把别人都搞定。

9，库房管理员

数万台服务器让你来管理，任何丢失或者损坏都是不负责任和失职的表现。

10，运动员

不要回家就睡觉，有空还是运动下吧；在服务器down机的时候，机房恰巧就你一个人，机柜没有空间，你需要更换一台HP 585 4U的服务器，满配约80公斤的服务器，你怎么做？

11，责任心

这个我不想说什么，这是你的职业精神。

12，组织者

给你2个啥都不会的民工，再给你2000台服务器，要求你2天把服务器装完，你咋办？

13，1－7条中，你必须有一条非常精通，是这个行业的专家。否则过了32岁，没有公司要你。

大家看了肯定觉得这个人是神仙，但是这必须是你慢慢能做到的，至少是我6年来运维经验的一点总结。

因为现在的公司都在用招聘民工的钱招聘神仙，其次我也是想让各位看看，运维工程师要担负多少责任。

我去面试过的一些公司都说，你什么都会，什么都不精。我说对，正是需要我们这些什么都会的人领导什么都精的人。

我这句话没有贬低大牛的任何意思，只是当时一个临场的发挥。虽然说完就知道这个面试白来了，但是我还是想为广大的运维工程师出口气。

不怕千招会，就怕一招精。这仍旧是我给大家的建议。

最后给大家最后最大最重要的建议，做什么工作都可以，千万别做SA。

我把SA的定义成：speedinessanswer而不是system admin。为什么？你可以想象一下哪些工作需要快速响应。网络工程师需要，机房网络骨干交换机故障，整个机房所有服务器无法连接，需要快速响应不？系统工程师需要，系统出问题了，要快速响应不？安全工程师需要，服务器被攻击了，要快速响应不？存储工程师需要，公司核心存储有问题了，要快速响应不？

你可以做研发，出了问题可以测试，可以想办法慢慢解决；你可以做DBA，出了问题可以推到网络工程师或者系统工程师身上，说不是DB连接问题；你可以做测试工程师，你说有问题这个东西就可以不上线……在出问题的时候，倒霉的就是SA，所以不要再争论SA包含哪些工作，SA就是一个倒霉的快速响应者，你想，哪个SA 24小时不开手机？哪个SA 晚上可以舒服的睡觉或者安心的出去度假？走在路上一听到和自己手机短信铃声一样的，利马下意识的抓出自己的手机看看是不是服务器报警；晚上和老婆 XXOO00，一个电话过来，立马停下，抓出手机看流量图；包里放着笔记本，但是因为还要开机，太慢，拿着手机上putty ping或者telnet机器……

这就是大家羡慕的SA ，你也不要抱怨自己做了SA，生活就是这样。所以不要再争论哪些xxx员应该归属于SA，系统管理员或是运维工程师，如果想做这行，就安生的当一个“快速响应者”，这是你的职业，也是你需要做到的。作为一个SA，你肯定经历过通宵好几天加班做事，你肯定经历过饭买来已经忘记了吃，你肯定经历过几天加班没睡觉，着个沙发坐下就失去知觉睡倒……没有经历过不能说你不好，只能说你管理的机器太少。

我公司是每月发21天工资，某两月我一月发了44天工资一月发了47天工资，创全公司建司7年来加班记录……项目做完自然也就落了个部门通告表扬，然后的结果就是健康情况急剧下滑，然后就是某天晚上在机房内加班一通宵，穿着短裤进机房，然后一个通宵被机柜下面的冷风吹了个关节炎……这就是做SA的代价。

以下是一些实际经验，发给大家做参考，有任何问题可以mail我[email protected]

有的东西是企业机密，我不能透露也不能给你相关文档。

3.1.1 ?架构设计

现在你要做的，就是设计你的服务器架构和网络架构。

(1)     服务器架构

这要先看你的网站是做什么的，每日有多少的人数访问，

例如，我打算站点初期每日有20000左右的访问量，和1000人左右的并发量。我可以用我的人数并发量1000×站点中每个页面的平均大小200k×每个访问用户可能要打开4个网页＝800000k=800M的网络流量（当然这个数字肯定是非常的过分，至于为啥，自己可以想下）

然后可以用测试环境用软件检测在你的真实环境下的服务器压力，比如在2000人在线的情况下，服务器的cpu占用多少，内存占用多少。

那么你可以得到你大致配置，其实市面上的标准服务器配置都足够你用了，比如现在的DELL 1950,HP DL360G5,IBM X？？？（忘记了）

等服务器，足够我跑一个这样简单的网站。其实说白了，双奔3都够，真的。当然你网站的流量比我要大的多，那你可以买的更好一点的服务器。或者负载均衡器。

(2)     网络架构

站点现在是一台独立服务器，未来采用的是分布式架构，比如bbs.hilinux.com是一台服务器，man.hilinux.com是一台服务器……

mysql是一台服务器。这样你要算服务器要多少台，交换机要多少口，防火墙要买什么级别的。

哪些服务器可以放在一个防火墙下，哪些服务器不用防火墙保护，哪些服务器是内网服务器，

需要什么样的网络连接，最好是画出大致拓扑，方便你预算设备花费。

(3)     服务器交换机等设备选型和购买

说的简单点就是买什么机器，你可以和google一样开始，买几台pc作为你的网站服务器，也可以自己组装一台服务器

或者也可以和我一样，去挑选品牌服务器当然，现在你要看你服务器做什么的，

你可以亲自去电脑城看组装服务器，也可以打电话到IBM,HP,DELL的各地销售商让他们送服务器来测试，

当然你不要告诉他们你只买一台，那你就别指望测试了。我告诉供货商hilinux.com需要200台服务器，一个F5，10台CISCO 2960交换机，3个NETSREEN206防火墙，一个EMC CX500+满硬盘

那么不到3天，hilinux.com所需要的4台测试服务器，就送来了……当然，不要牛了这么多最后只买1台，那么你晚上走夜路会被人打的。

最后就是价钱问题了，这个你自己看着办吧。让你公司的财务或者采购出马砍价付钱就是了。当然，除了服务器的服务，你最好还是想想有利于自己的服务，比如人家公司可以帮你拆箱子了什么的。我做的最弱智的一件事情就是，来了400台服务器，50个交换机，8台EMC，我一个人花了一星期把箱子才全部拆完……

机器选型的时候你也要为自己考虑，比如HP的ILO功能，可以让你远程BIOS级操作服务器，比如浪潮的自动资产管理等等，为自己管理服务器提供便利，否则机器10来台还好，100台还一般，我这里3万来台，我不死几百遍了。丢失一台服务器，几个月工钱就没了……

3.1.2 ?IDC选择

首先要看你服务的地区是哪里，然后再去找当地的电信机房。毕竟，虽说全国已经互联了，但是各地的网速还是有差异的。

或者说有的IDC机房利用率高，虽然出口带宽大，但是利用率高的结果是导致你网速慢的原因之一。

我的做法是在全国各个机房的服务器用pingplus这个软件进行一周的的流量测试。可以看到平均丢包，最大延时等等。

当然，你也可以到你目标服务的地方，找个可以上网的地方进行网络测试，比如说网吧包个机器……

好了，网络测试完了。那么你已经决定去哪个IDC了吧。

然后你就可以电话或者自己提着礼品登门拜访一下IDC服务商的老大了

当然，你也可以找代理服务商，因为他们拿到的价钱有时候比电信或者网通给你的价钱低，但是，关键还是一个服务，因为你毕竟服务器放在那，晚上关键着急没人给你重启，机器出了问题其实按个F1就可以解决的问题，服务商的值班人员不懂。你就只能打晚上的打飞机去机房维护吧。

提着东西拜访一下服务商老大是礼节性的东西，东西不在多而在精，这样你未来谈事情人家也给你绿色通道，做事情要好做很多。当然，我也不反对你空手去，你一次租个100个机柜＋10G带宽，人家还是很优惠的。哈哈。大家都是混口饭吃，也不至于难为你什么。

最后你要知道现在的中国还是卖方市场，你给人家牛，那你买的产品只能是……蒙牛

然后是开始去参观机房

细心的检查一下空调数量，空调出厂和最后维护日期，网络布线类型和架构，是否可扩展，主备从电力等。

基本都是非常关键的东西，出问题了，人家可以给你更换一个新的，服务很好，但是你服务器挂一天的损失是多少，你可以自己掂量。

还有机柜电力，现在的机柜放置16台1U的服务器是正好，多了过于热，少了资源浪费；但是你发现人家只让你用10安培电力，过了要交钱买电；

或者不限制你用电，但是插线板只有10个，你还真买个托线板去转接？你要想想你一个托线板挂了，你服务器要挂几个？

最后，我的一个机房包间里140个机柜，2个空调，结果某天挂了一个空调，虽然6小时人家IDC商就给更换了一个空调机（这速度已经非常快了），

结果我机器至少被热死了100台以上，机器是HP的，机器过热，HP会自动关机，而且会不让你启动。你崩溃不？注：不是给hp做广告哈。

3.1.3 ?服务器上架

好了，要是你买的服务器到了，你会发现你接到电话后，楼下一个N大的“擎天柱”集装箱车给你送服务器来……（某次我收2000台服务器就是这样的阵势）；在这里有个重大的提示，你们财务给厂商下单的时候，收货地址一定要写对。比如 XX路XX号XX大厦XX楼XX室，你写到xx号，送快递的会给你堆到院子里，你写到xx楼，送快递的会给你送到电梯口，你写到xx室，他们才会给你搬到室内。因为送货的都是服务器厂商找的，你因为这个事情去联系厂商修改送货地址，至少要多等N小时。而且他们视你的单子的数量和楼层，判断来多少搬运人员。而且，一定要把服务器搬到你指定的地方再签字收货，否则……嘿嘿……

我最霉气的是：来了20台机器（还好不多），下着大雨人家给我往院子里一丢，让我自己搬上19楼，我没推车没啥的……

你可以说，找电信的帮忙撒，废话，这个我还不知道。那我告诉你，我在某电信大楼工作时，从CCIE到机房主管到机房工作人员，全部是美女……

虽然我在这个地方只干了5天活，我的同事们口水都有3尺长……你还叫人家给你搬机器不？

你可以说，雇民工撒，我又不是没雇过，钱得你自己支付，公司不给你报销的话，爽不？

下面是拆箱子，面对着堆积如山的2000台服务器，我是连抬手的力气都拿不出来……当时机房只有我们公司3个人＋电信值班2个人……

这时候，我的办法是……我打电话找来了2队收废品的：

这么多箱子，除了机器和电源线留下，里头的导轨光盘等等你全部拿走，谁拆的多谁拿的多……

最后按照我的要求帮忙搬到机柜上……于是我们5个人是监工……看人家拆箱子搬机器。

于是人家2队人找来了30多号人，一早上把2000台机器全部拆箱子完毕放到机柜上。

要是我们几个人拆，估计…………

最后再说个行价，服务器箱子一个价值5块钱甚至更多。你服务器到了，卖卖箱子请大家吃饭吧。别让扫地的阿姨拿走，几个无所谓，10来个箱子，够大伙儿吃顿烤肉了……还有EMC的木箱子……拿去养个小鸡小鸭的……

42U机柜1U的服务器最好是16台。你就看着上吧。呵呵

3.1.4 ?安装系统和布线

好了，面对几千台服务器开始装系统，我不知道你会怎么想……

全部是1U服务器有什么办法安装系统？（我们公司穷，买不起刀片；而且电信不配合，要是上刀片，电路你们自己拉线，价钱还是原来的价钱；最重要的……我们公司以人为本，宁愿多养个人也不愿意买个好服务器让人失业），而且不允许GHOST，因为你这是服务器，不是网吧……GHOST出来的系统，我不知道谁用过，爽不。我自己是郁闷郁闷到了，莫名问题的时候，你就知道GHOST还是靠不住的。

其次，我们公司安全部要求：必须得一台一台安装，先安装光板的系统（比如没有SP的WIn2000），然后手工打SP4补丁，不能网络打补丁。于是我们就光盘堆成山。最扯淡的，为了快，我做了一个补丁共享的服务器，所有的补丁CP的本地来打。结果忘记拔网线，导致人家说我们是插了网线打补丁，有中毒的危险，需要重装。我直接崩溃……

办法1，你可以1台1台慢慢装，反正这么多机器，你可以管公司要更多的时间。但是我们公司一般是机器到了，最多2－3天就要要，一向是那种计划不如变化快的没有计划没有进度管理的“小”公司，项目组拿着鸡毛当令箭，牛x哄哄的公司。郁闷！

这个时候前期的准备就比较重要了（我公司多用windows2003），因为首先我要装一个光系统，再打驱动，再打补丁，再安装远程控制软件。一台机器装完大约要1小时多点。那么机器多了怎么办？光盘不够怎么办？等等问题就来了。

我的办法是，我一看TMD全部是DVD，IBM的机器直接佩combo，公司给我们发的全部是CD，娘的，典型的没有最慢只有更慢，出了问题闲你慢的领导班子。于是只好自己出钱买了DVD，用软件把RAID,网卡，显卡其他驱动做到光盘里，需要安装的软件也直接做成自动安装的方式，补丁也刻录到光盘里（我们要求补丁必须单打，不能安装集成补丁的ISO，shit），这样弄，你只用把光盘往光驱里一丢，分区一分，就可以下一台机器了。然后等你在去关注这个机器的时候，已经可以设置IP插网线了。灵感来自番茄花园。吼吼。

当然这时候你最好是买个KVM,16口的KVM，一次准备16张光盘就可以用一套键盘鼠标操作16台机器。当然啦，KVM是可以级联的，我最牛一次一次一套键盘安装166台机器。郁闷的是，塞光盘塞死，插KVM线插死，配置IP配死，有时候还会弄错……

办法2，你可以用NETKVM去远程安装，但是你插那些NETKVM的线路，2000个插下来，爽不？然后你继续扎KVM和网线的时候，看着和瀑布一样的网线和KVM线交错在一起。估计直接崩溃。远程KVM有的牛x的是可以分发ISO的，就是传说中的远程分发安装。可以自己买一个研究研究了，我们公司以人为本，从来不买这类高科技。

办法3，我犯贱时候发明的：我们的机器全部是RAID1，于是我安装一台raid1的机器，系统全部安装好，然后拔掉一个硬盘，插上一个新硬盘自动恢复镜像，基本10来分钟恢复好一个硬盘，插到机器上去。这样，还是比装系统来的快。当然啦，型号是一模一样的……

办法4，HP的ILO2功能，实现远程分发。前提你得一台一台配置好BIOS里的ILO2。也是蛮痛苦的。IBM和DELL现在也都有这个功能，但是你在分发以前，还是得一台一台机器插上网线，配置好BIOS的IP，痛苦。然后把操作系统和机器的驱动程序和后续的软件全部做到一张DVD里，让他自动运行。然后所有的服务器远程运营这一个ISO,最好多弄几台，否则一台机器弄的慢死。

办法5，绝对最简单的办法!!!就是买机器前，让厂家给你在硬盘里灌好系统，和你买笔记本一样，打开是个安装完成需要你输入序列号的系统。但是弱点是后续的软件需要自己装。因为服务器厂商是不会帮你安装别的软件的。

还有更多的办法，只是暂时没想到，大家也可以谈论自己的办法。互相交流嘛。（51CTO编辑注：其实现在已经有很多无人值守安装系统的管理软件，比如KickStart和现在流行的Cobbler，都是不错的批量安装工具，而且都是开源的。现在都追求自动化，希望越来越多的运维们将不必面对一台一台装机的困扰）

所以我喜欢linux，可以用N种办法安装系统。

windows就是个让IT人当装机男，挨踢人当民工。

好了系统装好了，电源线和网线连接完，和瀑布一样的。这时候还是尽量把他扎一下吧。

否则机器通风不畅，会导致热死。

简单办法就是电源线扎一边，网线扎一边。有钱的公司可以买个网线序号标，没钱就自己拿胶布标。

你可以随便扎，或者和给你老婆梳头一样，好好扎。哈哈

插交换机的时候，从上往下，从1－24往后，这样网络异常，数一下就知道了。

想来想去这里也没啥值得关注的地方。所以就几行带过。

3.1.5 ?资产统计

假如你的机器只有2000台反而好容易管理了，但是现在我要管理的全国IDC有31个，平均每个机房有不同品牌服务器1500台。

一共大约有45000台的样子（我的资产管理系统里的数字，不包含交换机，防火墙等）

这时候怎么办？

每季度和财务小MM一起出去旅游盘点IDC资产，幸福啊……(我们财务小mm很PL的哦)

到了机房就是我一个人干活点资产，小mm带着大口罩，披着双层的放辐射服……

可怜我们这些干活的，短裤背心，IDC里一呆就是好几个月（IDC办公室就在机房边上……），不知道精子被辐射杀死多少……

1，必须有资产管理系统，虽然这个其实是个很简单的数据库，但是你可以把每一台机器的品牌，硬件信息，操作系统信息，购买年限，质保年限等，你非常关注的东西做一个详细记录，并配发同一的资产编号。

比如我们的资产号，FWQ-123456

服务器－123456，这是一个总的资产号，这个服务器哪怕搬到美国，也是这1个资产，直到丢失，或者抛弃，都是这一个资产，永远不会变。

比如我现在的板凳就是一个资产号是：服务器－000010的一个4U服务器，配置是P2 300*2  256M内存 16G硬盘×4

购买时间是1999年10月，从中维修过1次，升级过1次，在哈尔滨机房－广州机房－河南机房－北京网通机房－上海公司内部测试机房－上海库房服役过。

有历史吧…….

2，送到机房

看过我这个服务器去过的地方，羡慕不？见证我们公司的发展史。9年过去了，终于成了我的板凳……

服务器在购买合同确定以后，就应该按照配置记录资产，并且在财务备案，资产编号一定和财务记录相同。这样这个服务器走到哪里，都有备案和记录。现在要把这个服务器送到某个机房去，搬着走吧……汗

送到机房，我们要给服务器按照财务给的表格粘贴资产编号，选个顺眼的地方，不会磨损的地方。

一般是机器正面某个地方，然后是机器屁股后面某个地方，然后机器侧面把手的地方，粘贴3个，以防掉了就烦了。

然后在粘贴这个机器的应用资产号和IP标签：

应用资产号举例：FWQ-SH-XX-B31-WEBSERVER  意思是：服务器－上海－xx机房－B列31号机柜-web服务器

IP标签举例：外123.234.123.234内10.0.0.1。这2个标签你可以分开也可以在一张标签上写清楚。

并且在安装服务器的时候。把FWQ-SH-XX-B31-WEBSERVER-123-234  把这个作为你的HOSTS信息，windows里叫做计算机名

这样远程上来都非常清晰自己在哪个服务器上，出问题时候也非常容易找到这个机器，不要闲麻烦，一切的麻烦都是为了以后快速的解决down机问题而做的。

当然啦，甚至在密码管理上你也可以用这个规则来设置密码，但是最好规则别让别人知道了……

3，把这些信息全部录入你的资产管理系统

系统无非服务器名，IP信息，用途，机架位置，或者是否在使用一类的，我就不多讲了

4，资产系统软件交互，也可以说是监控系统。

企业可以开发一个软件，在装机的时候安装到服务器上。然后资产管理系统定时去取服务器上的信息，比如网络流量，CPU内存硬盘负载一类的东西，这样你的资产管理系统又变成了一个监控系统；

当然啦，你也可以在资产系统里集成一个远程桌面管理系统，自动载入用户名和密码，还有随机码，就可以登录系统。省的还得管理服务器密码。

然后用户的访问权限不同，看到的节面权限就不同。

比如说，监控人员没有登录权限，或者IDC人员没有登录权限一类。权限分配你自己研究好了。

5，还是IDC的工作。

话题继续回到我和财务小mm去盘点（你公司比较大的话，你可以多派几个人分开去各个地方……）

小mm一看我们机房服务器黑压压的一片，铺天盖地的，直接无语。为啥，因为要拿着资产表一个一个核对，面对几千个机器，直接晕倒。

虽然按照资产管理系统里导出的信息，机柜号，IP号，机器从上到下的顺序都非常精确，但是你一个一个核对，还是慢。

怎么办？

库房管理的工作用上了，哈哈。你买服务器或者买笔记本电脑的时候有没有注意到箱子上的条码？

那个条码非常清楚的记录了这个机器的详细信息。所以黑莓手机或者NOKIA手机（别的我没用过）都有扫描条码的功能……好像与主题无关……

那么剩下的就简单了。

去买个这种条码标签的打印机，编辑成自己需要的条码，一个一个贴好，上面有你所有需要盘点的信息……

比如我们是从资产到机柜号到服务器名字到内外网IP都要盘点……小崩溃

打印出来贴上去。然后买个扫描枪，和超市那种一样，不过你要买有存储功能的，否则你要端着笔记本去扫描，SB了。

然后我和财务mm本来需要一个人念号码一个人核对（你要直到在机房里大喊资产号，喊一天的结果是啥，自己想），现在一个人拿一个扫描枪，按照规则一个一个扫描。完成后把数据导出后重新整理分析。直接和数据库核对（当然这个也需要你自己开发），核对完成生成一张表。

表上写的非常清楚你哪个机架没有哪个机器，哪个机器不在特定的位置上，哪个机器缺少……等等

这样比如说，机器位置不对扣5块钱工资，机器IP不对扣2块钱工资，或者……反正扣到最后……这月不给发工资了，还得倒贴点……哈哈哈

3.1.6 ?监控架构

监控架构其实每个地方都有自己的做法，我也知道我的办法不是很先进，但是仍然拿出来和大家一起讨论

首先谈谈监控软件，一说起这个常用的东西MRTG,cacti一类的就都可以用了。只要稍微归类一下，流量展示看的还是很清楚的。

要是要监控服务一类的，那就只好启用大名鼎鼎的nagios,和一些牛x人基于这个做的一些别的商业软件。

或者就是自己做个脚本去定时探一下，不通了给你发邮件了啥的，你vim一下nagios的chack_xxx，学习一下里头人家探测的办法，自己也能搞出来个啥东西，都还是很不错的了。

作为IDC工程师，我们所要关注的东西就是个流量了，我们要很清楚某台65下的某台35上每个口的应用，当遭受攻击或者流量异常的时候，一眼就能知道是怎么回事。我不相信你天天看着10M的流量，某天突然一下给你来个80M，你说这是正常事件吧。哪怕正常，你也找相关的人确认一下吧，一个100m口跑 80M,估计电信的人都来找你了。

每天看着这些流量图是很枯燥的事情，那么我们没事只能想办法让他自动报警给我们了，于是EMAIL报警，然后把他发送到一个有手机提示新邮件的邮箱，你手机就有了。MSN报警，还是不错的吧，手机报警一类的办法都是不错的。这样你你可以和我一样放心的去打网游了。

这里只谈经验，不谈详细的技术，因为我一说我的系统架构地球人都知道我是哪个公司的了，虽然已经离职，但是咱也有个职业道德，谢谢。

当然了，有些公司是有网络监控部门的。但是我就一直在想这个问题，所有的数值都可以用短信报警，你随时都可以收到信息。用这个部门干啥，让一群可怜的家伙 8小时一动不动盯着屏幕，公司又在他们电脑上安装了抓屏软件，上班事件聊天上网就扣钱……我估计他们每天最期望的事情也莫过于服务器挂了，可以给我们打个电话重启个服务器或者连到服务器上检查一下啥问题，重启个服务了啥的。当然了，这些兄弟最后的职业方向也只能是进入运维部门了，至少公司服务器宕机维护的流程性东西掌握的非常熟练了。但是这是用好几年时间换来的经验，太……所以我是奉劝兄弟们有发现监控部门招聘人，就别去了吧。面前8台显示器，猛一看还以为是黑客帝国呐，结果仔细一看全tmd是流量图。常年对着8个显示器，那个辐射……

我就不清楚设置个节点，出现问题告诉人，人去操作会死啊，非要让人和机器一样一动不动的盯着显示器，TMD，官僚。虽然我没经历过，但是想也能想到。做SA，最大的要点是懒，把一些需要人做的事情都自动化……但是话说回来，我公司以人为本，人海战术嘛，可以理解。

上面的帖子位子已经满了，下来的帖子在这里写。

3.1.7 ?企业实际面对的一些问题

我大概通读了veyron 大侠的文章，认为系统架构方面的我绝对不如他。我就不在这里卖艺了，那么我卖企业都会实际面对的一些问题。

1，自动化，流程化你的信息管理

为什么要自动化，这年头流行办公自动化，你丫没事还拿着工单四处签字，老土了吧。

为什么要流程化，这念头流行流程管理，假如你公司没有一个固定的流程管理，出了事情，大家都不知道怎么做，各个部门的电话乱打，大家都一锅粥没有效率。所以，未雨绸缪，在没有出问题的时候，模拟出问题，多多准备，建立规范的流程，公司的每个人都要遵守，这样，流程化的管理+办公自动化，大家只用在电脑上翘翘键盘，点击确定，流程就发出去，一路审批，OK,流程发送到做事的人地方，也许这个做事的人在美国，也一样方便。

上面说的是一个原理和意思，用这样的理念去管理你的服务器应该如何去做？当然了，你假如只有10来台服务器，就不用考虑这个了…….

首先服务器采购录入资产管理系统（详细见上面有写），服务器的去向和调度都在管理系统里有提现。

这里说的是：如何去上架，维修，下架等流程控制

先说上架下架：服务器到机房以后，别人要用服务器怎么办？先可以到你的资产管理系统里，看你机房还有什么配置的机器多少台，然后让他们选择自己项目服务器的配置，数量。在流程管理系统中，把这些机器选中，生成一个表单，表单名字为xx项目上架需求，写清楚谁用，做什么，数量，哪个机房等。然后提交给他们部门领导，他们部门领导同意后，转给需要审批的领导，一层层下来，流转到我们部门领导，我们部门领导流转给部门机房员工，员工收到流程，检查上架下架服务器；如要上架，安装完系统后填写IP，机器名，机架等相关信息。如要下架，删除相关信息，提交给流程控制的人员，流程控制人员确认后，这个流程完成。届时，所有的人审批过的数据，经手人，数据库里都有，出现什么问题找相关责任人，一下就找到了，省的和某些XX部门JJYY。

维修也一样了，机器坏了，或者需要重装系统，按照上面的流程，一步步走一遍，就可以了。年底统计机房一天要干多少活，省的某些领导认为机房人TMD都在闲着。机房的人呢？没有流程不干活，否则白干。

在流程系统里重启服务器，重启服务器要是要流程，就太慢了，那么你可以做一个绿色通道，写清楚原因，重启哪个机器，直接提交给相关机房人员，在你的流程系统里绑定一个短信网关，机房人员可以收到需要重启服务器的短信。准确无误。

这样代替了无纸化办公，既有自己做的事情的每一个记录，又有相关人员管理，可以量化自己的工作，免得年终奖的时候xx人有说你干的少，发的少。你把记录拉出来对比对比就知道谁多谁少了。

2，如何升级你的服务器

服务器老了，或者需要加内存加硬盘，怎么升级。

虽然说是很简单换个CPU，加个内存，加个硬盘很简单。

但是，如何控制你的配件不丢失，确定的安装到机器上利用了呢？

简单，在服务器上做一个探测服务器配置的客户端，每天探测一次硬件配置发送到资产管理服务器上。

与资产管理系统的硬件配置做对比，出了问题就报错发一封邮件到机房工作人员，抄送流程控制人员一封就可以了。

至于的加内存的时候注意型号啥的问题就不说了，大家应该都没问题了

要说的是，假如你一个机柜上放的机器比较多，比如4个6个机器一摞，恰巧坏了，恰巧一个人在机房，非得解决，怎么办？

简单，一个办法，但是还是需要你有力气，虽然有力学原理

比如有4台服务器，最下面的坏了，

你可以拽住最下面的把4台一起往出拉，拉出来一点，把上面3台往后推，这样一点一点的拉出来，

下面最关键：

拉到最后，前面要留出来一点，轻轻的把上面3台的尾巴着地，然后一只手抬住上面3台机器，一只手拉出下面一台机器。

上面3台一定要留出来一点，否则放下的时候，机器和机柜托板会压住你的手，你一松手，机器震一下，硬盘就挂了……

所以在推进去的最后仍旧要留一点在外面，最后放下来了再推进去这最后一点。

然后就可以换或者加内存了。相对比较省劲，不危险，不会压倒自己，不会砸坏服务器的办法就是这样了。

【编辑推荐】

大型网站运维之道漫谈

Linux批量安装 五大开源软件挨个看

资深系统管理员给Linux/Unix新人们的建议

3.2 ?系统管理员需要掌握哪些软技能？

大多数系统管理员小组时间紧、资金少。这种情况下，要做的头一件事就是，借助自动化、时间管理和组织结构，最充分地利用现有资源。系统管理员需要掌握哪些软技能？系统管理员怎样才能减少工作场所中的压力和冲突？本文将为你提供一些指导。文章作者Christina Lear是具有十多年系统管理员经验的老运维。

系统管理员和系统运维的工作内容好理解，就是在技术上确保企业的IT架构和服务正常运行，为此需要学习如何架设测试和生产环境，如何备份，如何监控，如何选择最合适的技术来实现对业务的支持，如何预防潜在会出现的问题造成服务不稳或中断等。但是，你知道系统管理员需要掌握哪些软技能吗？系统管理员怎样才能减少工作场所中的压力和冲突？下面这篇文章将为你提供一些指导。文章作者Christina Lear是具有十多年系统管理员经验的老运维，她是SAGE的一员，也是Usenix LISA的活跃贡献者。她与ThomasLimoncelli合作撰写了The Practice of System and NetworkAdministration。

大多数系统管理员小组时间紧、资金少。这种情况下，要做的头一件事就是，借助自动化、时间管理和组织结构，最充分地利用现有资源。一旦做到了这一点，小组经理就可以改善系统管理员小组在别人心目中的看法和形象，从而争取更多的资源。

3.2.1 ?软技能之一：自动化

应对资源缺乏问题的一个好办法是，使那些最耗费时间的任务实现自动化，从而为系统管理员挤出更多的时间。自动化节省时间的途径有两个：一是让任务更迅速地完成，二是确保一致性，从而减少支持电话。

推荐阅读：优秀DBA应该让数据库的每一件事情都自动化

不妨先编写一段脚本，让输出的命令可自动执行任务。系统管理员只需要审阅命令以确保正确，编辑命令以用于特殊情况，然后把它们粘贴到命令行中。编写这样的脚本，通常比整个过程实现自动化更容易做到，有望为流程实现进一步的自动化打下基础。

与尽可能实现任务的每个方面都自动化的一套庞大系统相比，有助于处理普通情况的一段简单脚本可能更有用。使80%的容易部分实现自动化，把特殊情况留给下一版本的脚本。记下哪些情况需要手动处理、需要做什么事情。

寻找厂商提供的可使操作系统安装等任务实现自动化的工具，并积极使用它们。还要弄清楚如何使针对你环境所作的定制工作实现自动化。如果可能的话，使客户经常请求的那些任务实现自动化，并建立一个网页，让这些请求成为自助服务式请求。这个方法不但为系统管理员和客户都节省了时间，而且提高了客户满意度。

3.2.2 ?软技能之二：时间管理

想最充分地利用可用资源，另一个办法就是运用各种众所周知的时间管理方法。时间管理意味着明智地运用时间——更聪明地工作，而不是更卖力地工作。系统管理员如何更有效地管理时间，这个话题本身就可以出一本书了。时间管理对系统管理员来说可能特别困难，原因是他们的工作常常受到打扰。为了提高工作效率，重要的是打破这个怪圈。你可以把请求写入到自己的个人待办事项清单，告诉对方你稍后会处理请求，这样可以避免工作受到打扰。要是你没法把请求写下来，那么礼貌地请对方给你发送电子邮件或故障单请求。注意选用对你来说最恰当的措辞，让对方觉得更容易接受。

一天当中工作效率最高、最不会受打扰的时间通常是早上，所以不要把这段宝贵时间浪费在收阅邮件上。迅速检查一下监控系统，看看有没有问题；浏览一下邮件，找出标记为“紧急”的邮件。然后编辑你当天的待办事项清单，确定工作事项的轻重缓急；要是事项太多，重新安排一下，把一些不太重要的事项留到下一天。每天的事项尽量排得细化点（比如半小时、一小时、两小时或半天），前提是要适合自己。为当天的待办事项确定轻重缓急，就更容易、更迅速地决定“下一步该怎么做？”把这头一个小时的其余时间用来处理优先级最高的事项。一天结束后，把待办事项清单上仍没有完成的事项重新挪到下一天的待办事项清单上。

每次处理一个文件或电子邮件。要是你根本没时间去处理，那看也不要看。每个文件或邮件第一次就要完全处理好，而不是挤成一堆，之后非得重新阅读。你在处理每个文件或邮件时，先看一下，决定是不读就扔掉、读后就扔掉、处理好后扔掉，还是回复后再扔掉？有时候，处理一个文件或邮件意味着要把它记入到待办事项清单中。而有时候，你可以马上回复邮件，或者把回复意见写到纸张文档的空白处，然后交还给发送方。文件或邮件尽量少归档。若有怀疑，就扔掉。

使尽可能多的电子邮件处理工作实现自动化。比如说，自动将电子邮件归类到不同文件夹，可按电子邮件列表或论坛、社交网站发来的通知、博客帖子、非垃圾邮件优惠券、最新资讯和厂商的特惠广告来归类。然后确定你想多久扫描那些文件夹，收阅感兴趣的内容，甚至可以设置在某几天后就自动删除。让文件夹将信息保存一段指定的时间（比如保存一周、一个月、两个月、六个月或一年），然后自动删除超过指定时间的邮件。要不断完善和更新你的自动化机制。

保持注意力集中。干净的办公桌、干净的电脑桌面、每个任务的虚拟屏幕以及干净的电子邮件信箱，可以减少分心、帮助你集中注意力。禁用电子邮件到达提醒功能也有帮助。安排好收阅电子邮件的时间，而不是立即收阅到达的每封邮件。《清空收件箱》一书作者Merlin Mann给出了清空收件箱、保持收件箱干净的几个秘诀。

想方设法减少每项任务所花的时间。自动化是可以做到这点的一个方法。另一个方法是预先想好决定，比如决定：始终在编辑文件之前先备好一份，随身带着个人数字助理（PDA），记下所有请求，更早而不是更晚做小任务，或者何时给打印机添纸。有时候，解决办法很简单，就像在打印机旁边放些备用的墨粉盒，那样不至于为了安装墨粉盒，而将大部分时间耗在跑到远处的库房上。

3.2.3 ?软技能之三：组织结构

让系统管理员提高工作效率、少受到干扰，那样可以最充分地利用手头的有限资源。从一项工作换到另一项工作要花时间。系统管理员换着处理的工作越多，浪费的时间就越多，工作效率也就越低下。控制系统管理员在一天当中受到的干扰次数，恐怕是减小压力、提高工作效率的最有效方法。

通过改变系统管理员小组的结构，就能做到控制干扰。对系统管理员小组进行划分，以便一线支持人员处理客户要求迅速予以处理的请求。处理起来比较费时间的请求则可以交给二级工作人员。高级系统管理员则负责大型项目，比如创建服务。这样的分工可以确保：你的优先事项与你同事的预期要求相一致，保护正在处理长期项目的人员不会老是受到干扰。听起来像是只有庞大的系统管理员小组才可以这么做，但其实连只有两名系统管理员的小组同样能得益于这个方法。一名系统管理员可以在早上保护另一人不受干扰，而在下午对方反过来可以保护他不受干扰。这个方法就是所谓的彼此保护不受干扰。

改善看法和形象

系统管理员面临的许多压力因素（包括缺乏资源）可能来自于看法和形象方面的问题。

◆看法是指别人怎么看待你；这是衡量质量的一种指标。

◆形象是指别人有多看重你；它是衡量数量的一种指标。

别人对你看法好的重要性很明显；而形象好的重要性也许不大明显。当系统管理员不引人注目时，同事可能觉得他们没有在作贡献、没有忙于工作、人浮于事或资金过多，或者纯属多余。这可能导致资金和人手不足，进而导致更坏的看法和更差的形象。

这里讨论的方法大多数侧重于如何改善别人对系统管理员的看法。要注意：要是别人对你的看法很坏，需要大量时间和精力才能改变别人对你的看法。系统管理员可以通过许多办法来改善其工作在别人心目中的形象，但只有在真正把工作做好的时候，才应该竭力提升形象。换句话说，不要拿搞砸的产品大吹大擂。

比如说，要提升你的形象，可以制作一个系统状态网页，以便你每天都出现在客户眼前。制作的这个网页还要有其他实用信息和链接，以便它可以成为一个主页。定期会见经理，既帮助他们了解你所做的工作，又帮助你在经理心目中有重要地位。

注意你的办公场地。与客户打交道的人应该选择比较显眼的办公场地。可以在市政厅举行用户组会议，那样每个想法、每个请求或每个批评都可以客观公正地记录下来。要弄清楚：记录下来是为了表明会认真考虑问题，未必是要落实什么。

内部通讯常常由系统管理员小组编制，但客户很少去阅读。编制内部通讯要花大量工作，可是太容易被忽视。与客户一起吃午饭、参加社交活动是保持良好关系的一个简单方法，而且通常比内部通讯来得更有效、更省时间。

想为你和你小组的正面形象负责任？那就要改善系统管理员小组在别人心目中的看法和形象。而系统管理员经理到时可以利用小组的正面形象，争取更多的资源。

未来需要怎样的软技能

由于新技术的出现以及客户要求越来越高，系统管理员的工作在不断变化。那么这些变化在如何改变所需要的哪些软技能呢？

当我母亲开始从事系统管理员（其实是“操作员”）时，只有系统管理员才能使用机器；他们把同事的程序输入到读卡器，然后等程序处理完毕后，将结果返回给同事。她的同事对于多快完成完成的要求与我们现在司空见惯的要求大不相同。她的客户群小得多，比较精通技术，但不像现在凡事都依赖电脑。她的工作也不像现在这样经常受干扰；她没有电子邮件要处理，她的一天主要是处理项目工作，而不是为许多不同的人处理许多小的任务。所需的软技能天生就与本文讨论的那些软技能不一样。

在过去的四十年，系统管理员需要的软性能发生了很大的变化；我预计，在接下来的四十年，会出现更大的变化，而这主要将归因于技术方面的变化；可问题是，我们不可能事先很早地预测到这些技术变化。不过我们可以预料：在接下来的几十年，本文中讨论的软技能对系统管理员来说会变得越来越重要。

网络一族的人数在继续增加，而保持连接、与别人进行联系的方式也在继续增加，因而使得沟通越来越以电子方式为主。人们越来越要求“始终联通”：如果你在线（为什么你不在线呢？），就能立即回复任何消息。电子沟通难免会带来干扰。时间管理和控制电子沟通，而不是让电子沟通来控制我们，将对每个人来说会变得越来越重要，对经常受干扰的系统管理员来说尤为重要。

考虑到我们大家收到的电子沟通数量势必会继续增加，我们就要关注自己发送的信息的质量和数据。系统管理员必须学会简洁扼要，态度又不能粗鲁。这既节省了自己写东西的时间，又节省了同事读东西的时间。

系统管理员的客户群会变得越来地遥远、越来越移动。对更多的人来说，远程办公将变得切实可行，在上下班途中办公也会变得切实可行。外包和国际化办公会继续成为两大因素，让系统管理员处在远离客户的地方。当系统管理员与同事没有挨得很近时，他们需要确保处理好本文提到的看法和形象问题。另外值得一提的是，打电话常常比通过电子邮件或即时通讯来联系远地的同事更有效。这样更有人情味，可以更迅速地处理问题，并减小引起误解的可能性。这还让你有机会运用之前提到的沟通技能。

移动计算设备只会变得越来越普遍——它们是每个人确保工作效率的一个重要部分，尽管它们也随之带来了技术挑战。不要排斥移动计算设备，而是要看到它们的好处，并积极迎接挑战，然后满足你同事的支持要求。对于将来的技术，也要这么做。要及早采用技术。关注最新技术如何有助于每个人、为此需要作什么样的变化。

随着计算设备继续变得更无所不在，之前独立的系统会日益融入到系统管理员支持的计算机和网络中。由于越来越要求系统“正常工作”，一旦某部分停止运行，面临的压力也会越来越大。你的一些同事会提出一些更高的要求，而一些要求比较低的同事会依赖于你所支持的系统。你需要培养这种能力：与同事积极有效地沟通，并支持技术水平各异的客户。

结论

系统管理员是一份充满压力的工作。但是一旦意识到造成压力的某些因素，就可以解决大部分的压力，同时能够明白这份工作的确是值得的。有众多方法可以减少与同事的冲突、处理资源缺乏问题和常受干扰的环境、解决优先事项相互冲突的矛盾，以及积极接受这个现实：系统管理员要对每一个失败负责。

【51CTO.com译稿，转载请注明原文作译者和出处。】

原文：http://queue.acm.org/detail.cfm?id=1922541

3.3 ?系统管理员易犯错误及解决方法汇总

本文分享的都是系统管理员在工作的时候容易犯的错误，比如安装FreeBSD之后造成无法重启，更改WindowsAdmininstrator密码导致计划任务无法执行等等。经抚琴煮酒整理并提供解决方法，希望可以给大家一些指导，避免在工作中出现此类问题。

本文分享的都是系统管理员在工作的时候容易犯的错误，经抚琴煮酒整理并提供解决方法，希望可以给大家一些指导，避免在工作中出现此类问题。

作者简介：余洪春（博客），网名抚琴煮酒，英文名Andrew.Yu，武汉某外企高级Linux/Unix系统管理员、项目实施工程师，红帽RHCE讲师，擅长负载均衡高可用和中小型证券类和商务网站架构，目前关注网站架构研究及网络安全。

3.3.1 ?安装FreeBSD后无法重启

问题描述：

装惯了Linux的人肯定知道一般会有个boot分区，可是在bsd就不那么容易了。在安装FreeBSD 8.1的时候遇到了问题，查阅了chinaunix上面，正好也有相关问题整理，特摘录如下：

我要求FreeBSD分区：

2G For /

4G For swap

10G For /root

256M For /boot

其余 for /usr

安装正常，结果安装重启后便出现杯具了：

>> FreeBSD/i386 BOOT

Default: 0:da(0,a)/boot/kernel/kernel

boot:

原因：

通过网上查资料，了解到手动引导的全过程，发现了问题所在：

由于独立分区/boot造成了FreeBSD引导过程中无法正确找到内核引导的位置。

解决方法：

通过

boot: 0:da(0,e)/loader

可以解决引导问题，然后进入loader界面

*这个引导盘符根据da0s1x 的 x 得来，因此你安装系统的时候/boot所在分区区号，才是真正的x字母，如果不知道就从往后试试

同样由于默认kernel位置是/boot/kernel所以依然需要手动加载

ok load kernel/kernel

获得kernel信息后

ok boot

这样就可以正常引导了。

但是这样还没有彻底解决问题，随后还需要在磁盘挂载的时候输入

mount root>ufs:/dev/da0s1a

才能进入系统，而且每次重启都手动一次。所以其实问题没有彻底解决。

所以，为了避免以上的/boot问题，目前我装机一般规范化操作，一般只分三个区，避免独立分区/boot，也希望玩Linux的朋友们重视下这个问题。

2048M For /

4096M For swap

其余的均For /usr

3.3.2 ?更改Admin密码导致计划任务无法执行

问题描述：

公司有系统管理员离职了，有不少Windows 2003服务器，此时负责安全的部门要求接手的系统管理员更改Administrator密码，粗心的系统管理员急急忙忙更改windows密码后，却发现windows的计划任务全都执行不了，因为windows的计划任务都要求输入正确的Administrator密码。

解决办法：

大家养成好习惯，每次更改完windows密码一定要检查一下计划任务，否则很容易导致公司的重要业务执行不了进而影响中整个网站的运维及业务，希望此问题能引起大家的注意。

3.3.3 ?root密码更改后无法远程登录

问题描述：

系统总监嫌托管的新Linux服务器root密码过于简单，吩咐公司的系统管理员将密码改复杂些，急躁的系统管理员用passwd root密码改掉后赶车回公司，杯具的发现密码设置得过于复杂，密码给忘了。由于机器是新装，没有配置具有sudo权限的用户，自己远程都进不了root了。这种问题就只有百分百靠系统管理员负责了。

解决方法：

这个问题只要养成良好的习惯就可以预防，就是大家更改完root密码后，别急着退出，可以用ctrl+shift+F2或F3-F8尝试用另一个终端进去下，如果当时就忘了，马上切换到F1更换。抚琴煮酒经常犯这种错误，呵呵，希望此法对大家有效。

3.3.4 ?锁定了SSH会话

问题描述：

我在配置某机房Linux服务器的iptables时，不小心设置了某一项错误参数，结果锁定了SSH会话，导致我们经理及另一技术员连不上服务器。

解决方法：

下面介绍的这个方法及其有用，强烈推荐给大家：为了预防此类问题出现，可以配置一计划任务crontab，每5分钟运行一次，即

*/5 * * * *? root /bin/sh/root/firestop.sh

firestop.sh内容为:

service iptables stop

这样即使你的脚本存在错误设置（或丢失的）规则时，也不至于将你锁在计算机外而无法返回与计算机的连接。这样你就可以放心大胆的调试你的脚本啦。这都是生产环境下逼出来的，呵呵。

3.3.5 ?移走硬盘造成Emergency模式

问题描述：

同事在处理Linux服务器时，移走了一块硬盘，然后就直接启动红帽RHEL5，发现进了Emergency模式，焦急中他连忙跑过来找我；我第一句就是问他：你改动了硬件没，他说他移走了硬盘后就直接启动了，不是跟windows 2003一样嘛，有什么问题？我都无语了……

解决办法：

耐心跟他讲解了 Linux下/etc/fatab的作用及语法，告诉他可以在Emergency模式下输入root密码进入此模式，然后用

mount –o remount,rw /

将/分区设置成可读写，编辑/etc/fatab，将移除的硬盘用#号屏蔽掉后重启服务器，故障解除。

3.3.6 ?sudoer文件损坏造成无法进入root模式

问题描述：

同事远程处理一台机房的FreeBSD 8.1机器，想加一个具有sudo用户的特殊用户，所以编辑了/etc/sudoer文件，却不小心多加了一个.，然后直接保存退出了。结果杯具发生了：由于sudoer文件损坏，所有具有sudo权限的用户均不能切换到root模式下工作，而FreeBSD8.1与Linux不同，它默认是不允许root远程连接的。

解决方法：

这时只有请专人到机房去处理问题了……

3.3.7 ?root密码被更改

问题描述：

一个开发小组都是用内部机房的Linux/FreeBSD机器，大家都知道root的密码；不知哪个兄弟是搞着好玩还是怎么的，偷偷的改了root密码却不通知大家，结果大家都用不了root密码，杯具了。

解决办法：

此时处理办法有2种，一种就是大家都知道的单用户模式修改root，其实另一个办法也蛮简单的，系统管理员应该多配置一个具有sudo权限的用户，遇到此种情况时可以用sudo权限来修改root的密码，至少免得跑到机房去。毕竟有时候，机房未必在市内或在国内的。

3.3.8 ?依赖的库文件丢失导致root无法登陆

问题描述：

我们的jail母机192.168.21.36，因为root的shell设置成的bash，而其依赖的库文件libintl.so.8发生丢失，导致了root不能登陆。具体报障如下：

/libexec/ld-elf.so.1: Shared object "libintl.so.8" notfound, required by "bash"

Connection to 192.168.21.36 closed.

解决方法：

①用单用户模式进入系统；

②扫描磁盘(此步非做不可，而且是安全的)

fsck -y

③将文件系统重新挂载

mount -a

④将root的默认shell切换到sh

chsh -s sh

重启后一切正常。

3.3.9 ?忘记以su模式进入编辑器

问题描述：

普通用户用vi编辑nginx.conf 等配置文件，保存的时候会提示：没有Root Permission

解决办法：

其实只要保存时加上：

:w !sudo tee %

就可以了。

“:w !sudo tee %”这条命令的含义是把当前编辑的文件的内容当做标准输入输入到命令sudo tee 文件名里去。也就是sudo保存为当前文件名，相当管用的命令，尤其适用于FreeBSD和Debian系统(我经常忘了自己原来不是root了)，相当very nice.

系统管理员容易犯的错误和解决方法暂时就总结到这里，希望对大家有帮助！如果大家有什么问题，也欢迎在评论中沟通。

【51CTO.com独家特稿，转载请注明原文作者和出处。】

【编辑推荐】

系统管理员搬家也要专业——域控制器迁移

系统管理员指南：如何给系统打补丁？(知识篇)

FreeBSD 系统管理员都应该知道的那点秘密

3.4 ?系统管理员应该怎样高效的书写文档

系统管理员在面对书写文档的要求时，总会拿“系统应该自我记录”或“我没有时间写文档”为挡箭牌而拒绝编写文档，甚至还有人认为“缺乏文档使他的工作更安全”。但事实上，这些理由都是荒谬的。一个优秀的系统管理员应该将适当经历投入到良好文档的编写当中去。

本文是上周在美国召开的LISA大会的一个课程总结，课程内容为“针对系统管理员的文档技巧”，讲师是Coffee Bean Software Pty Ltd软件工程师Mike Ciavarella，他曾经是Sun的Unix系统管理员，编写过UNIX防火墙。Mike现在也是麦克米兰的技术编辑和墨尔本大学的软件工程课的讲师。LISA会议全称Large Installation System Administration，意为大规模服务器环境的系统管理，由USENIX和SAGE这两个组织协办。今年的第24届LISA大会刚刚在上周落幕。本文作者Ben Cotton是来自Purdue 大学研究系统团队的系统研究工程师。以下为全文：

3.4.1 ?为什么系统管理员应该学习编写文档

系统管理员在面对书写文档的要求时，总会拿“系统应该自我记录”或“我没有时间写文档”为挡箭牌而拒绝编写文档，甚至还有人认为“缺乏文档使他的工作更安全”。Mike Ciavarella认为这些观点对系统管理员和组织都没有任何好处，他在周二的“系统管理员需要知道的文档化技巧”课堂上，不仅反驳了这些荒诞的理由，而且就如何更有效地书写文档从技术方面分享了他掌握的一些经验。

我对这个课程特别感兴趣，因为我是Fedora项目文档小组的成员，事实上我已经成为我们小组的文档工作传道士。我必须掌握更多的文档编写技巧，帮助整个团队写出高质量的文档。我经历过因缺乏有用的文档而造成不良后果的事故，我相信许多系统管理员应该有类似的经历，因此改进文档工作对减少这类事故是至关重要的。不要把什么事情都装在脑袋里，关键时候也许你人不在，也许你被糟糕的状况吓蒙而记不起了。正所谓好记心不如烂笔头，如果你认为写文档是一件枯燥的事情，那是因为你还没有爱上它。当你认真写完一篇文档后，你会发现自己的思路更有条理，也会学到许多新知识。因为写文档的过程就好像你站在讲台上给学生上课一样，不能忽悠，你会发现原来自己是多么浅薄。因此写文档不仅是一件快乐的事，也是学习提高的捷径，更不会因此而丢掉工作。

3.4.2 ?如何编写文档

编写文档时首先应该考虑的是谁是目标读者。如果目标读者是管理员，客户或管理层，那么文档的风格和内容将有所不同。弄明白目标读者后，写起文档来思路也会更清晰，最终的文档用途也更大。

高效编写文档的关键是在读者已经知道的需要知道的内容之间建立起连接，列举读者已知的一些内容可以帮助他们理解文档和减少文档被驳回的可能性。试问如果你写的文档目标读者都已经全部了解了，那你这个文档还有存在的必要吗？同样，如果你写的文档让目标读者丈二和尚摸不着头脑，那么他们会有兴趣读下去吗？

重要的信息在文档中可能会出现多次，但要注意措辞适当，不要一味使用重复的字眼，那样会让读者觉得你在反复炒剩饭。

编写文档时还需要注意语态。如果是技术文档，常常使用被动语态，如果是教学用文档，使用主动语态更好（编者注：这个比较适用于英文的情况）。此外还需要注意词性，不要表错了情，会错了意。象对待卷宗一样对待文档是个好主意，举证责任在撰稿者，前面没有介绍过的东西在后面就不能提，否则在接受盘问时你会被问的四分五裂。

文档写完后，编辑和校对很重要。编辑最好由理解材料的人进行，他们可以帮助重新排列文档章节以提高可读性；校对则需要敏锐的眼光审查拼写和语法，校对人员不一定要完全了解文档中的技术术语。经过编辑和校对的文档应该拿给既不是目标读者，又不熟悉该主题的人阅读。如果他读完后不能根据文档的内容确定目标读者，那说明文档还存在严重的问题。本来你是写给同为系统管理员的人看的，但却不见一条命令或操作步骤，这就好比是牛头不对马嘴，这样的文档只能被扔进垃圾桶。

3.4.3 ?其他注意事项

系统管理员必须展示文档对自己的工作和整个组织都是有益的，否则就没有存在的必要。Mike建议文档工作应该作为一个定期评估的绩效组件，促使系统管理员保持文档更新。在文档编写工作中，不管是部门经理，还是刚刚入职的新手，都可以参与到其中。例如，初级管理员可以帮助高级管理员写一些局部内容，如一个安装步骤，一条命令的参数解释等。重要的是每个人都要参与。

有多人参与编写相同的文档时，就涉及到使用协作工具了。没有哪一个协作工具是最好的，重要的是确定需求，选择最适合的工具。一般来说，任何工具都能够处理多种格式的文档（如数字和印刷）。

文档写完后事情并没有就此结束，还应该定期评估和保持更新。确保文档的准确性非常重要，如果不这样做，文档就会渐渐失去其价值，这种情况在现实工作中是很常见的。一开始大家都兴致勃勃地编写文档，当写完后就放在硬盘的某个角落，不管文档记录的事情如何变化，都无人再问津，久而久之，文档就成了摆设，等到需要使用的时候才发现文档已经失效了。因此文档应经常更新，养成良好的文档维护习惯是成为优秀系统管理员的必备素质。

原文：http://blogs.usenix.org/2010/11/10/documentation-techniques-for-sysadmins/

【编辑推荐】

网站运维之道 之知识管理与积累

门户网站运维经验谈

3.5 ?系统管理员之企业生存守则

本文是一位资深系统管理员所写的职场经验。对于刚刚入职的系统管理员来说，这些都是十分宝贵的意见和建议。本文作者告诉大家如何处理好在企业内同事与领导之间的关系。相信刚刚走进系统管理员的你会对自己的工作明朗很多。

编者按：本文是一位资深的系统管理员对自己工作经历的描述，并且告诉大家在职场中需要注意的事情。这些宝贵的经验对于一个刚刚入职的系统管理员来说无疑是一份无价的财富。

一、良好的人际关系比什么都重要。

俗话说得好：先做人，再做事，良好的人际关系是你成功的关键条件之一和愉悦工作的基本条件之一，千万不要以为技术第一，其实技术人成功的条件之中，技术未毕是排在第一位的。其实在公司的人事架构中，技术类岗位往往是排在中下位的，所以我觉得仅仅只跟本部门的技术类同事打交道是不够的；你应该多跟其它部门的同事，如行政部、人事部等部门的同事多接触下，多了解下公司的企业文化和内部规定及人事架构，这样对自己的成长也是有帮助的；抚琴煮酒以前在公司上班时，往往三个月都不知道自己公司的董事长和总经理长什么样，其实这样不好，万一哪里在他们心里留下一个目空一切的印象，很影响仕途的噢。尽量在不影响公司的内部规定的前提下，帮助能帮助的人，多跟其它部门的同事多聊聊，多沟通，这样就算你是在一个新公司里，也能够很快溶进去，很快进入自己的角色。

二、正确处理跟本部门同事的关系。

有句老话：不要跟同事做朋友。很不幸，这句话并不能适用在系统管理员身上。如果是一个大型公司，比如超过500的某分公司，IT部门一部分为开发部、系统组、网络组(包括网络安全)，有许多工工作要求协同工作，而并不仅仅是凭一人之力就能完成工作的。所以这时候你需要花大量时间，跟你的同事，如PHP开发或网工们沟通，让他们明白或了解你的需求；特别是一些开发环境的布署，因为最后的测试使用者正是你的Devoleper同事。打比方说，我在某公司作系统管理时，我们的测试环境是Nginx+FastCGI，而PHP们当时正使用的Zend Framwork，他们对nginx的要求就是要有统一入口，这个就需要在nginx写相关匹配的正则了；我个人觉得，如果同事们在私底也能聊得来的话，不妨也可以作为朋友交往；如果确实在工作上利益冲突，其实可以完全以商量的口气来协调工作。

切忌的二件事：第一、不要以技术压人，这个没意思，我从来不作；二、也不要以老员工的身份欺负技术新人，这个更不推荐了，这只能说明你的无知。系统管理的工作其实就是搭积木，只要愿意花时间的话基本没什么难度。而网络及网络安全这块，我跟他们沟通得就更多了，比如要将内网的某台服务器作DMZ映射，新网站如果要推行了，还要跟负责网络安全的同事们协同工作，看有哪些安全漏洞，或防火墙的安全性能及服务器的最大压力承载等。我的做法一般是：平时也可以学习些系统之外的知识，然后闲时可以跟同事们多聊些技术外的私话，比如手机啊、游戏或别的，周末方便的话，尽量参加公司或同事们的聚会。

不要冷冰冰的做人，一张笑脸比什么都重要。在本部门同事的处理关系上，我的做法是：能做同事就做同事，能做朋友就尽量做朋友，毕竟多一个朋友多一条路；所以，以前公司的同事们，只能能够聊得来的，我基本都保持联系；平时或周末都会跟他们聚下餐，大家轮流聊会天，既减轻压力，又相互了解对方公司的一些趣事，何乐不为?正好，下段文字正是描述这段情景的，不知大家看了能否体会我的心情与意境。

关于饮酒·聚餐

周末，同事聚餐。我们选择是平时总在一起吃饭的地点“三顾茅芦”，点了六个菜，连我在内四个人，我做东；因为前面几次都是同事们请了，这次算我回请，我们实行轮询制(RR)。由于平时都不是贪杯之人，我们点的是“雪花清爽”啤酒。席间除了一猥琐以茶代酒，我们仨饮酒都是随意，浅尝辄止，这也是我最喜欢的一种饮酒方式。抚琴煮酒虽然名字带一酒字，但酒量甚浅。。这次参加饭局的三个同事，都是平时工作中很聊得来的伙伴，平时工作遇到了问题就一起交流，相互之间都很熟了，可以说是无话不说了，所以我很享受这个过程。俗语说得好：饭还是那个饭，但人未必是那个人了，所以，吃饭，饮酒也是看心情的。

三、遇见领导要服软。

二个原则：一、在原则性的问题要服从上级领导的管理；二、千万不要越级报告，无论是国营还是外企，这二个心得体会赠予给刚刚上班的小愤青们，如果确实体会不了，建议仔细阅读《杜拉拉升职记》三部文章，里面许多故事都是挺真实的，特别是越级报告这个问题，短期来看，你可能会取得局部的胜利，但从长远来看，你绝对是最大的输家，因为没有领导会喜欢一个越级报告的下级，哪怕你的能力再高也是一样。抚琴煮酒第一工作是在某大型国营企业做企业网管，主要是负责windows2K服务器及DB数据库，当时以为自己技术牛B(在公司里技术确实也算是第一吧)，再加上很快就提了IT部门的Leader，很有些飘飘然的，在领导面前就是不尊敬，结果很快发现仕途不顺，一直都只能是Leader；其余当时如果明白这一真理的话，我现在估计也是朝技术+管理这一目标一直走下去了，也没有后来转售前和实施工程师的必要了。

我当时就很迷惑：为什么许多没有能力的人都当了Manager了，而我还只是一个Leader?其实当时就没正确处理好与领导的关系，可能是太年轻和性格比较外向的缘故了。这一点惨痛的经历告诉大家，希望大家引以为戒，特别是希望做管理的小伙更要注意这点了。有时候，你的上级能力可能没你强，也有可能不懂系统这块，这时候你更要耐力向他解释，为什么不能这样做，这样做会带会什么样的恶果，千万不要消极对抗，尤其不要发生正面冲突。其实这个情况，大家到了一定年龄层次就会明白；不过，我觉得提前明白还是有好处的，这样可以少走许多弯路，至少杜拉拉明白这点。

四、明确你的发展定位也是很重要的。

作为一个系统管理员，即System Admin，你要明白你的发展定位，到底是做技术+技术，还是技术+管理，另外还是做技术+销售呢?这决定了你在相关方向的投入和精力，技术+管理这个大家都应该明白，技术+技术是一个怎么样的定位呢?许多公司都应该有这样的岗位，即高级开发工程师，此岗位的薪资跟manager持平，但不汲及人事管理；比较大的公司，也有高级系统管理员一职，我在北京的岗位也跟这个类似，系统总监不属于此岗位，它属于系统+管理；技术+销售就比较好理解了，即售前工程师和售后工程师，它们的技术含量跟系统管理(系统集成)比较起来，就比较低了，特别是售前，这个是我比较喜欢的职位之一，如果是做过项目实施工程工作的小伙更可以考虑下，特别是大公司的售前，福利待遇相当不错，在某种程序及时间范围内可以解决不少生活上面的困难，众所周知，技术员都是比较穷的吧。每个系统管理员都应该明确自己的发展定位，做到有的放矢，合理的分配自己的精力和时间。

另外，这里说个题外话，英语对系统管理员很重要，因为许多新产品和新技术，基本上都是从国外引进的；要想熟练的掌握及应用，英文是必不可少的基本功之一；而外企是不用说了，我们向国外的上级Leader报告，其正式文档均要求是英文。搞技术的人都容易忽略的另一条就是口才，其实这个也是很重要的；尤其是作为售前，你总不可能向你的客户推销你公司的产品方案时就直接让客户阅读吧，或者就直接告诉他们，这个好，这个确实好吧。不说别的，大家面试时，成功的关键之一也是要说明面试你的人，这个也要求你在平时注意锻炼下，如果只是打算单纯的做技术的，这个稍为注意下即可。但我觉得一个技术人有一个好口才，其发展方向也可以是多方面的，至少你还可以作为讲师，让更多的人学到你在工作中掌握的心得和技巧。你也不想你作为一个技术人，竹筒倒豆倒不出，那就是一个杯具了。

五、系统管理员一定要明确自己的企业定位。

老板们现在越来越喜欢Linux/unix的原因之一，未必就是你想象中的那样，Linux/unix有多么的有效率，据我所知，就是因为Linux/unix免费，而且下面许多软件都是免费开源的，其中不乏强大的，比如Apache、LVS、Nginx、Squid及bind，还有一个iptables，我就职的公司，至少有50%是用iptables作为NAT路由哭，而且其效果也是不错的。

作为系统管理员，并不是你的作用有多大，而是你将技术转为生产力有多高而矣，所以千万不要以为公司缺了你就不转，一定要抱着平常心的态度去工作和生活，我现在认识的大牛们，基本上都是谦虚和平民化的，这个也值得我们学习。平时还是要注意学习的，毕竟新技术是层出不穷的，能力不是天生的，这个需要后天培养。你还可以通过博客等形式发布自己的工作或者学习心得，或是率先掌握一门新技术，并率先向社会推广这门新技术。分享是一门艺术。在分享的同时，一定会伴随着理解、应用、总结、提高、表达甚至推广方面的提高，这对个人的技术提高和社会影响力的建立有着非常的意义的，这个目前我也是努力的方向和目标之一。

六、一定要有效率和简单的工作。

其实作为系统管理员，许多工作都是重复性的，特别是一些维护和备份工作，这个时候你完全可以编写一段shell脚本，加进crontab计划任务里，代替你在某时间段执行这些操作。windows下的批处理也是相当不错的，许多用图标的操作也可以用其简化。当你将工作都理顺后，你会发现你的工作原来就是如此简单。你完全可以将你的时间用于其它方面的学习，比如数据库和程序开发等，就就是我一直强调脚本重要性并特地为此设了专题的原因之一。做一个优秀而懒惰的系统管理员，我完全赞成这个观点，优秀的管理员绝对是一个懒惰的家伙，呵呵，如果你作为系统管理员，每天都要加班加点的工作，这个时候不妨反思下。

七、系统管理员要明白自己在公司的作用。

作为系统管理员，一般都会职守公司的Exchange邮件服务器，当然还有许多机密的文件，这时候一定要作为保密工作，不该说的话和不该做的事都要注意，尤其是涉及到薪水方面这些敏感的话题，在公司内部，透露和打探公司的薪资都是职场大忌。

另外，随便透露公司的资料及敏感信息、上班时间接私活，这些事情尽量都不要做，都是些犯忌讳的事情；另外一件事就比较头疼的事情就是，每个公司，无论大小，都会有一些政治斗争，这个时候该怎么办了?我一般的做法，绝不拉帮结派，尽量保持中立，做事要对得起自己的良心。如果确实做不到，那就考虑离职吧。毕竟做人是一辈子，做事是一时。

下次工作时，记得找一个工作环境比较单纯点，这些事情其实遇见一次是好事 ，下次至少不会惊惶失措了。我在公司里尽量会做到以下二点：注意保密，保持中立，一般的话，政治斗争不会影响到系统管理员，毕竟公司的网站或开发服务器都需要专人维护，总不可能连做事的人都随便开了吧。

八、其它方面就是身体相关了。

有时候，服务器迁徙的活还是比较重的，1U、2U的服务器还好说，4U的比较重了，我以前的同事，也是做系统的，90多KG，他来了以后我们都很高兴，至少来了个半民工；抚琴煮酒长得比较单薄，单独一人勉强能应付1U的服务器，其它就不行了。

另外一个就是夜班值守的问题，这个就比较头疼了。我一般就是白天注意多休息下，晚班的时候会将手机邮开通，音量调到最大，下半夜时能睡会是一会。别的网站崩溃了不要紧，如果是电子商务型和广告类型的，那就是钱了。所以系统管理员也要注意锻炼身体，平时可以办一张健身卡，周末去锻炼下身体，平时能走路的话就不要打车了。

另外，要注意心里方面的压力，因为我们的平均故障处理时间不能超过5分钟，所以上班时的压力还是很大的，有段时间还掉毛!所以，我现在平时喜欢讲笑话，跟MM聊天，有时候还自我吹嘘，自我赞美一番，保持自我良好感觉(即吹牛是必须的)。周末还去养生堂做下保健，因为有时坐多了，有些颈椎之类的小毛病。身体是革命的本钱，如果你的工作直接影响到你的健康的话，我建议，还是换一份工作吧。没有什么理由和原因，比健康更重要。有健康，才有将来。

作者博客：http://hi.baidu.com/yuhongchun027/home

【编辑推荐】

系统管理员最需要自动化的十大任务

系统管理员的双系统生活Windows 2003与FreeBSD8

Linux系统管理员都应该熟悉的工具

系统管理员都应该是瞎子？从Google用户隐私谈起

系统管理员大拿们的访谈系列（一）：Tom Limoncelli谈交流

4 ?系统管理员的软硬件维护清单

春节长假将至，有些系统管理员们被老板要求写一份公司的软硬件维护清单，对于没写过此类文档的运维朋友们而言会感到很苦恼。本文整理收集了一些软硬件系统维护清单，有些来自微软、IBM等厂商，有些由系统管理员同行们分享，希望能对大家有所帮助。

春节长假将至，有些系统管理员们被老板要求写一份公司的软硬件维护清单，对于没写过此类文档的运维朋友们而言会感到很苦恼。

系统维护清单该怎么写？

其实不光是在长假前后，系统管理员平时也应该养成按时（比如每天、每周、每月）按照维护清单进行软硬件维护的习惯。

简单而言，系统维护主要包括如下几个方面：

保持软件和系统的更新。软件更新通常包含bug修复和安全漏洞修复，这是为了你的安全着想。

杀毒软件的更新和定期查杀病毒。

检查你的系统监控数据是否完好的保存。各种监控。

检查系统的备份是否完好的保存。备份的重要性相信不用再强调了！

检查机房的物理环境，如温度、湿度等。

检查硬盘/RAID的情况，磁盘占用情况，是否有坏道。

……

从某种角度而言，系统维护清单都应该是系统管理员们必须遵守的铁律。51CTO编辑在此

具体的系统维护清单，其实不少厂商（尤其是微软和IBM）都提供了软硬件维护清单的参考文档。可惜的是，大部分都还没有翻译成中文（这也是为什么技术人学好英文很重要，因为太多资料手册都是English Only）。下面摘录部分相关文档，以供大家参考。

微软BizTalk Server维护清单参考文档

每日检查清单

每周检查清单

每月检查清单

IBM Lotus Domino服务器维护清单

另外也有非官方文档，其他系统管理员的经验分享：

SQL Server硬件检查清单

Windows Server 2003系统维护清单

Daily Operations Checklist

Checklist: Performing Physical Environmental Checks

Usethis checklist to ensure that physical environment checks are completed.

Task:

·         Verifythat environmental conditions are tracked and maintained.

·         Checktemperature and humidity to ensure that environmental systems such as heatingand air conditioning settings are within acceptable conditions, and that they functionwithin the hardware manufacturer‘s specifications.

·         Verifythat physical security measures such as locks, dongles, and access codes havenot been breached and that they function correctly.

·         Ensurethat your physical network and related hardware such as routers, switches,hubs, physical cables, and connectors are operational.

Checklist: Check Backups

Task:

·         Makesure that the recommended minimum backup strategy of a daily online backup iscompleted.

·         Verifythat the previous backup operation completed.

·         Analyzeand respond to errors and warnings during the backup operation.

·         Followthe established procedure for tape rotation, labeling, and storage.

·         Verifythat the transaction logs were successfully purged (if your backup type ispurging logs).

·         Makesure that backups complete under service level agreements (SLA).

·          Checklist:Check CPU and Memory Use

·         Usethis checklist to record the sampling time of each counter.

Checklist: Check Disk Use

Followthe checklist and record the drive letter, designation, and available diskspace.

Task

·         Createa list of all drives and label them in three categories: drives withtransaction logs, drives with queues, and other drives.

·         Checkdisks with transaction log files.

·         Checkdisks with SMTP queues.

·         Checkother disks.

·         Useserver monitors to check free disk space.

·         Checkperformance on disks.

Checklist: Event Logs

Checkevent logs using the following checklist.

Task

·         Checkapplication and system logs on the server to see all errors.

·         Checkapplication and system logs on the Exchange server to see all warnings.

·         Noterepetitive warning and error logs.

·         Respondto discovered failures and problems.

Weekly Maintenance Checklist

Checklist: Create Reports

Usethis checklist to create status reports to help with capacity planning, servicelevel agreement (SLA) reviews, and performance analysis.

Task:

·         Usedaily data from event log and System Monitor to create reports.

·         Reporton disk usage.

·         Createreports on memory and CPU usage.

·         Generateuptime and availability reports.

Checklist: Incident Reports

Usethis checklist to create incident reports.

Task

·         Listthe top generated, resolved, and pending incidents.

·         Createsolutions for unresolved incidents.

·         Updatereports to include new trouble tickets.

·         Createa document depository for troubleshooting guides and post- mortems aboutoutages.

Checklist: Antivirus Defense

Usethis checklist to perform your antivirus defense.

Task

·         Performa virus scan on each computer.

·         Checkanti-virus definition updates timely.

Checklist: Status Meeting

Usethis checklist to conduct weekly status meetings during which the tasks arereviewed.

Task

·         Serverand network status for the overall organization and segments.

·         Organizationalperformance and availability.

·         Overviewreports and incidents.

·         Riskanalysis and evaluation including upcoming changes.

·         Capacity,availability, and performance reviews.

·         Servicelevel agreement (SLA) performance, and review items that have not met targetobjectives.

5 ?门户网站运维经验谈

本文所讲的门户网站运维，一般是服务器规模大于1000台，pv每天至少上千万的网站的运维工作。网站应用运维对其它关联工种必须非常了解熟悉：网络运维、系统运维、应用开发、内容；但这些非自已的本职工作，本文所讲的运维工程师就是指专职应用运维工程师。

原文地址：http://bbs2.chinaunix.net/viewthread.php?tid=1281178

对于网站运维，感觉大家还是比较迷惘与不解，确实，这是一个新兴岗位；近来闲而无事，在此结合自已以往的一些经历，与大家先共同探讨一下“什么是门户网站运维”？ 以下是自已的一些经验和感受请大家斧正，希望和大家一起探讨，共同进步。

5.1 ?什么是门户网站运维?

首先明确一下，全文所讲的”运维“是指：门户网站应用运维，与其它运维如网络、系统的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上千万（至少国内排名前20），如sina、alibaba、sohu、baidu、网易等等。

其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如本版有些同僚将公司的合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责，这是网络工程师的工作，我们就不要抢人家饭碗了，但是，有件事非常重要一定需要明白：网站应用运维对其它关联工种必须非常了解熟悉：网络运维、系统运维、应用开发、内容；但这些非自已的本职工作，我在这里所讲的运维工程师就是指专职应用运维工程师。

我们再来说说一个般产品的“出生”流程：

1、首先公司BOSS层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计

2、开发工程师将设计code实现出来、测试工程师对应用进行测试（同一产品事业部）

3、网络\系统工程师根据产品设计的需求，如pv大小预估、服务器规模、应用架构等因素完成网络规划及设备上的调整（基本上对网络变动不大，除非大项目）、SA系统工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装

4、好，到运维工程师出马了。

首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大：应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能\安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复使：需求->开发（升级）->测试->上线（性能、安全问题等之前预估外的问题随之慢慢就全出来了）在这里提一点：网站开发模式与传统软件开发完全不一样，网站一天开发上线1~5个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像M$需要1年解决，用户早跑光了。

应用上线后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化（大于50台）、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作：

a 、尽量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等等），提高效率

b 、解决现实中服务存在的问题，如高可靠性、可扩展性问题等，

c、大规模集群管理工具的开发，如1万台机器如何在1分钟内完成密码修改、或运行指定任务？2000台服务器如何快速安装操作系统？各分布式IDC、存储集群中数BT级的数据如何快速的存储、共享、分析？等一系列挑战都需运维工程师的努力。

在此说明一下其它配合工种情况，在整个项目中，前端应用对于网络/系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的功能性开发，并对应用本身性能、安全性等应用本身负责，它不负责或关心网络/系统架构方面事宜，当然软/硬件采购人员等事业部其它同事也不会关心这些问题，各司其职，但项目的核心是运维工程师~！所有其它部门的桥梁

上面说了很多，我想大家应该对运维有一些概念了，在此打个比方吧，如果我们是一辆高速行驶在高速公路上的汽车，那运维工程师就是司机兼维修工，这个司机不简单，有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快，汽车本身不能满足高速度时对汽车性能调优或零件升级、高速行进中解决汽车故障及性能问题、时刻关注前方安全问题，并先知先觉的采取规避手段……这就是运维工作~！

最后说一下运维工程师的职责：“确保线上稳定”，看似简单，但实属不容易。运维工程师必须在诸多不利因素中进行权衡：新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维工程师了。

另外在此聊点题外话，我在本版看到有很多人要sina、网易、sohu、baidu等聊自已的运维方面的经验，其实这对于它们有点免为其难：

a、各公司自已网络架构、规模、或多或少还算是公司的核心秘密，要保密；另外，对于大家所熟知的通用软件、架构，由于很多公司会根据自已实际业务需要，同时因为原版性能、安全性、已知bug、功能等原因，进行过二次开发（如apache,php,mysql...），操作系统内核也会根据不同业务类型进行定制的，如某些应用属于运算型、某些是高IO型、或大储存大内存型……根据这些特点进行内核优化定制，如sina就在memcache上进行过二次开发，搞出了一个memcacheDB，具体做得如何我们不谈，但开源了，是值得称赞的，国内公司对于开源基本上是索取，没有贡献；另外，服务器也不是大家所熟知的型号，根据业务特点，大部份都是找DELL/HP/sun/ibm进行过定制；另外，在分布式储存方面都有自已解决方案，要不就是使用现成开源hadoop等解决方案，或自已开发。但90%都是借鉴google GFS的思想:分布式存储、计算、大表。

b、各公司业务方向不一样，会导致运维模式或方法都不一样，如alibaba和baidu运维肯定区别很大，因为他们业务模式决定了其架构、服务器量级、IDC分布、网络结构、通用技术都会不一样，主打新闻门户的sina与主打网游的盛大运维模式差异就非常大,甚至职责都不大一样；但有一点，通用技术及大致架构上都大同小异，大家不要太神化，更多的公司只是玩垒积木的游戏罢了，没什么技术含量。

c、如我上面所讲，目前门户网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，我相信大家也讲不出所以然来（我现在也中抓破脑袋挤出这点字，呵呵），可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一角，局限于具体技术细节，或某某著名网站大的框架，真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧。

5.2 ?运维工作师需要什么样的技能及素质

做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多IT工种技能与一身的岗位，对系统->网络->存储->协议->需求->开发->测试->安全等各环节都需要了解一些，但对于某些环节需熟悉甚至精通，如系统(基本操作系统的熟悉使用,*nix,windows..)、协议、开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理）、通用应用（如lvs、ha、webserver、db、中间件、存储等。。。）、网络（至少要对应用所处网络环境非常了解）；

技能方面总结以下几点：

1、开发能力，这点非常重要，因为运维工具都需要自已开发，开发语言：c/c++（必备其中之一）、perl、python、php（其中之一）、shell（awk,sed,expect....等），需要有过实际开发经验，否则工作会非常痛苦

2、通用应用方面需要了解：操作系统（目前国内主要是linux、bsd）、webserver相关(highttp,apahe,php,tomcat,java。。。)、数据库(mysql,oralce)、其它杂七八拉的东东，如系统优化，高可靠性等等。这些只是加分项，不需必备，可以边工作边慢慢学，这些东西都不难。当然在运维中，有些是有分工偏重点不一样。如可能有专门的运维DBA

3、系统、网络、安全等需要有所了解，至少知道其原理

（51CTO编辑注：本站鲜橙加冰的《运维人员应该掌握哪些常用技术》一文也写得相当不错，值得阅读）

个人素质方面：

1 沟通能力、团队协作：运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；这应该是现代企业的基本素质要求了，不多说了。。。

2 工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师是网站admin,最高线上权限者，一不小心就会遗憾终生或打入十八层地狱……

3 主动性、执行力、精力旺盛、抗压能力强：由于IT行业的特性，变化快；往往计划赶不上变化，运维工作就更突出了，比如国内各大公司服务器往往是全国各地，哪里便宜性价比高，就那往搬，进行大规模服务迁移（牵扯的服务器成百上千台），这是一个非常头痛的问题；往往时间非常紧迫，如限1周内完成，要命~~~，这种情况下，运维工程师的主动性及执行力就有很高的要求了：计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯皮……7X24小紧急事故响应等。

4 其它就是一些基本素质了：头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观

5 最后一点，做网站运维需要有探索创新精神，通过创新型思维解决现实中的问题，因为这是一个处于幼年的职业（国外也一样，但比国内起步早点），没有成熟体系或方法论可以借鉴，只能靠大家自已摸索努力

5.3 ?运维工程师的职责

1、保证服务达到要求的线标准，如99.9%；保证线上稳定，如，网络/系统运维工程师对网络、系统稳定负责，那应用运维就需对线上应用的稳定负责。

2、不断的提升应用的可靠性与健壮性、性能优化、安全提升；这方面非常考验主动性、和创新思维

3、网站各层面实时状态的监控、统计的覆盖度；软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用的运转情况。

4、通过创新思维解决运维效率问题；目前各公司大部份运维主要工作还是依赖人工操作干预，需要尽可能的解放双手

5、运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性范错。

6、成本控制；通过技术手段提升硬件承载、架构优化，如虚拟化技术，节省硬件开支。

7、自动化运维；能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统；让大家更多的时间用于思考、创新思维、做自已喜欢的事情。

5.4 ?维职业的迷惘、现状与发展前景

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

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

运维现状：

1、处于刚起步的初级阶段，各大公司有此专职，但重视或重要承度不高，可替代性强，工作职责也有所不同；小公司更多是由其它岗位来兼顾做这一块工作，没有专职，也不可能做得深入

2、技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。

3、体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空间了

4、优秀运维人才的极度缺乏；目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技术都局限在各大公司内部，如google 50万台机器如果科学的管理？或者国内top10 的一些经验，这些经验是非常有价值的东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通、贯通、与借签，并最终将限制了运维发展。

5、很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量PV、硬件规模足够大，如baidu可怕的流量、海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大公司可能已有很好的解决方案或系统

发展前景：

1、从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂；对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化

2、从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视

3、网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好的个人能力与技术广度的发展空间

4、运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、全局思考能力等

5、特长发控和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家

6、如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做

7、技术发展方向、网站/系统架构师

5.5 ?运维关键技术点解剖

1、 大规模集群管理问题

首先我们先要明确集群的概念，集群不是泛指各功能服务器的总合，而是指为了达到某一目的或功能的服务器、硬盘资源的整合（机器数大于两台），对于应用来说它就是一个整体，目前常规集群可分为：高可用性集群（HA），负载均衡集群（如lvs），分布式储、计算存储集群（DFS，如google gfs ,yahoo hadoop），特定应用集群（某一特定功能服务器组合、如db、cache层等），目前互联网行业主要基于这四种类型；对于前两种类似，如果业务简单、应用上post操作比较少，可以简单的采用四层交换机解决（如f5、foundly），达到服务高可用/负责均衡的作用，对于资源紧张的公司也有一些开源解决办法如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变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等。。。。。。因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现

2 大并发网站的设计

网站架构设计中，非常重要的一个要素，就是确保架构的可扩展性、这是高并发网站的基石。往往，一个网站的大流量不是与生具来的，而是有一个积累过程~~最后变成巨无霸，包括google、yahoo这种全球流量大户，而在这个成长过程中所积累的经验才是最值得我们学习的，包括思考方式、问题解决、改进过程。没有最好的架构设计方案，只有更好。。。，因此在此不会给大家一个终极方案。。。，在此介绍的这些经验，更多的是让大家真正掌握架构设计方法、理念、灵魂，并真正的能利用到实际中。为了让大家更易理解，我在此主题讨论中将会借用本版”jiang2798 “贴的"google架构、youtube架构"等经典案例和大家分析一下，再谈谈一些通用性原则及技巧。

高并发架构需满足的一些因素、要点：

I负载均衡架构

首先网站前端需要采用负载均衡群集解决用户高并发的响应，目前常用方法包括

a、squid反向代理，这也是各大网站常用的方法，包括sohu、sina...；

b、DNS轮循；

c、采四层硬件设备，包括google、baidu使用这种方式。。。对于lvs，小频道或不重要应用可以尝试使用，对于大流量、实时性要求高的网站目前还不成熟。

II 高性能中间件选择、优化

中间件选择、优化非常重要，当服务流量大于一定承度时，性能的稍微提升，对于整体硬件成本控制、服务的整体性能提升都是非常可观的。对于web server 目前常用的属apache，但apache多进程(线程池)架构有一些缺点，进程频繁生成\注销系统开销大，特别当流量大时更是明显，对于应用逻辑简单的可以考虑lighttpd 采用单进程+epoll并发模式，效率高，但对多CPU支持有问题，但可采用启多服务解决这个问题；如果由于应用架构原因必须使用apache，可考虑apache module 性能比普通CGI成倍提升。。。其它原则，包括各中间件各版本测试、包括性能、安全上的考良，找到平衡点，不要太关注某一点因素，导致整体架构上出现隐患，另外一点非常重要，那就中间件的参数优化，这些方面大家可以google、baidu上找找，比较多，但有个原则那就是需要根据服务器实际资源情况进行优化，如httpd最大进程数设多大合适呢？有些朋友，就随手来个2048，觉得这样肯定不会再出现httpd由于进程阀值过低导致拒绝服务，但这有个隐患，因为生成进程，是需要硬件资源的，当进程数达到一定承度，可能服务器内存会溢出，导致服务器crash，特别是内存消耗量大的应用。。。这样的案例很多，需谨记

III扩展性问题

扩展性对于高速发展期间的网站非常重要，大家可以经常在网上看到某某网站的发展励途，那简直就是一部进化史，过程曲折而痛苦~~。因此成熟的经验就非常重要了，扩展性可以从两个方面来看：网络系统上的扩展性及应用本身的扩展性，首先在网络上需层次分明，尽量扁平化，全网冗余不能存在故障点，尽量按业务类型进行划分网络结构(pv大小、优先级)防止互扰，重要的一点：网络设计中，简单就是美~~，在不影响扩展性的前提下，不要搞得太复杂；网络硬件资源、机架位、IDC都需提前至少半年进行规划，这些规划的重要依据是公司业务发展的前景评估，这就体现公司的战略眼光了，包括是否需要外地IDC（依用户群体而定）。。。；另外，选一个好点的IDC是非常必要的，否则就得疲于IDC迁移了，北京地区好IDC还是不少的：皂君庙（有点老了。）、土城、联通、酒仙桥、爱立信、互联世纪、奥运官方机房数字北京据说马上也能入驻了。。。当然了，有钱也能像google一样自已搞个IDC，国内谁有这个实力?

另一点就是应用本身的扩展性了，原则其实很简单，应用设计时应尽量确保应用的层次化、采用高性能的中间件、逻辑复杂及大数据量交互的功能尽量做成独立模块\后台、cache层、数据库分层（读/写操作分离），不要图前期简单直接将功能全部揉进前端CGI中，这很致命，随时都可能会遇到性能瓶颈、而且毫无扩展性。。。

当以上两点很好的解决后，现在唯一的问题就是每半年根据业务的PV增涨、新业务发展，预购服务器了……；当然了，对现有架构优化，性能提升才是根本解决之道，特别是现在全球经济不景气，大家都不好过，这就是运维工程师的责任了，优化再优化~~

IV应用设计、开发中的注意点

架构层设计好后，应用层设计就是我们重点关注对象了，这也是一个项目成功的关键，好的设计主要体现在：性能(高并发承载能力)、可扩展性、可维护、安全性（数据完整性、应用稳定性、前端应用安全如SQL注入）、模块冗余、负载均衡等等，技术点：线程池、epoll、TCP(长/短)连接的选择、功能模块的细化及后台化、模块冗余/负载均衡考虑(可扩展性)、高频数据cache缓存、数据分层、应用单故障点的解决(数据唯一性问题)等。有两点要注意：

1、应用设计时要允分考虑服务器、硬件设备甚基于IDC的不可靠性；也就是说我们在应用设计时需要考虑到应用运行过程中，随时都可能会有1~2台服务器或更多服务器出现故障情况(网络故障、灾难、攻击、停电((整个IDC全挂)))，如googleGFS就是一个典型，我们不能将应用的稳定性寄托于硬件的稳定上，特别是门户型公司大部份采用的都是X86普通机型，服务器crash是家常便饭、随时随刻(当总量到一定量级时)，所以我们在做应用架构设计时需允分考虑这些问题发生时的对策，做到允分的冗余/负载均衡（这两点可统一），如多IDC间通过智能CDN的流控、单IDC应用模块多节点冗余/负载均衡等，即使某些应用由于特殊原因无法做到这点，也需允分考虑应急预案。。好的设计在这些突发情况下可以做到不用人工干预，当然难度也很大。。。记得前年李开复在北大演讲时说过：google一个IDC同时故障800台机器，不会影响到任何应用的正常响应（有点怀疑，可能是他挑选的某类服务器，呵呵）

2、大流量应用/模块中能不使用数据库就不要使用数据库。

（本部分内容缺失，包括V   数据库问题；VI  用户分地域优化；3 高可靠性问题解决）

4 网站安全问题

网站安全是一个系统性工作，影响安全的因素也很多，如DDOS（最常见的）、应用漏洞、系统层面漏洞、内部安全流程漏洞等（人为失误），可以从以下几方面着手考虑:

1、网络层

首先在网络设计时需考虑到安全因素；在主干出口处，对非业务端口进行屏蔽（如非80端口全部屏蔽），对于非常规数据包进行限速，如icmp，udp等，但是需考虑主干设备性能，不能因为安全限制导致设备性能明显下降，需要做到平衡，否则又会出现一个新的隐患点；另一方面就是主干带宽要足够富余，做到冗余互备（vrrp、hsrp），以抵抗DDOS的所带来的带宽消耗（对于大型网站DOS随时都存在，只是规模大小不一样），另外，现在部份4~7l硬件具有一定的syn 代理功能，可以抵御一定规模的flood，但主要还得拼资源、带宽、硬件性能；另外，需做好主干数据镜像分析，对于一些有规律的攻击定位到特征、甚至是攻击源，进行针对性的防御。对于公司重点业务可以在网络层进行物理隔离，增强关键性业务的健壮性，甚至是将业务冗余分布至不同IDC，做到跨地域容灾（如地震）

2、系统层

系统层主要是操作系统安全加固、系统安全BUG解决、对非业务端口进行屏蔽、非业务软件清除、跟踪系统工具软件最新安全动态，并做到及时更新。特别是直接对外提供服务的服务器（处于外网），更需做好定期安全审查评估，由于一般公司服务器内网都是相通过，攻占一台外网机器可能会导致公司整个内网全暴露，很恐怖

3、应用层面

应用方面安全就不多说了，主要是开发细节上需把好关，不留逻辑上的漏洞，并对上传接口严格控制、越界检查、SQL安全性考虑等，特别是对于用户具备上传接口的应用（如mail、bbs、blog、云计算等应用），漏洞是很多的；系统应用，如中间件也需做好相应的安全配置。。。不多说了，大家上网能馊到一大堆。需要多关注网上关于自身网站安全漏洞方面的信息（或定期搜索），因为往往应用上的漏洞，都是用户先发现的，用户是最好的测试人员，发现后需第一时间修复，并对同类业务进行全面排查；对于特定重点页面也可以进行监控，并采用程序自动恢复主要页面（功能上如有问题，可显示业务升级提示），以免应用被攻破后对公司形象造成影响

4、内网安全管理

对于日常内网准入方面需有严格流程，统一入口，技术方面如vpn、rsa,securID（如sina就用的动态密钥）等，没有条件的也需定期更新入口密码

5、安全巡查

偶尔由于人为失误会导致一些漏洞的出现，如由于工作需要临时变更了某些安全参数，但忘记开启。。。这个问题其实是最大的，往往出问题也多是人为失误，需要定期对全网关键安全点进行巡查；而且这也是404审计的一个重点，想必在sohu、sina、网易等美国上市公司里做安全的兄弟应该很有感触吧

来自为知笔记(Wiz)

[转载]系统运维秘诀大分享专题