<p>如果你一周花 50-60 个小时管理你的 Unix 服务器，解决用户的问题，仍然觉得没做多少事，那么你应该养成既让你更高效又让你有时间为下一波问题准备的好习惯。</p>    <p>有些 Unix 管理员常常连续工作好几个小时，处理一大堆重要事情，但他们的工作却很少获得好评，而另一些看上去很傲慢的管理员，即使对最简单的问题也倾向于使用优雅的解决方案，他们对运用正则表达式来解决遇到的任何挑战的能力引以为豪，他们也真是懒到骨子里了 —— 即使做的是日常工作，他们也不断的寻找方法，以敲更少的字符。当技术和知识积累到一定程度，如果他们养成一些类似《 高效人士的七个习惯 》书中所讲的习惯，他们可以做更多的事情并且从工作中获得更多好评。有鉴于此，这里推荐了高效 Unix 管理员的一些习惯。</p>    <h3><strong>习惯 1：不要让问题来找你</strong></h3>    <p>避免紧急事件（让你疲于应对的那种）的一个办法是，在问题的萌芽期将其消灭。我发现在服务器上安装脚本很有用，这些脚本会在事情看起来不正常的时候通过邮件通知我，比如报告异常日志，检查性能和磁盘空间统计，报告应用程序失败或进程丢失。这么做的风险是这种邮件变得越来越多时，会导致当消息停止或被识别为垃圾邮件时，你其实没有看过或没注意到。注意到有消息没到达，就像注意到你的12或更多个人组成的团队中有个人没来开会一样困难。</p>    <p>要做到先发制人，在它们导致中断之前，在用户注意到问题或发现他们不再能完成工作之前，你很可能发现很多问题。如果你拥有应对灾难所需的资源来也会很有帮助。如果一台主服务器停止工作了你会进行故障转移吗？你会用备份快速重建服务环境吗？你有没有定期测试备份以确保它们完整可用？为关键服务准备灾难计划（比如，邮件服务可以迁移到数据中心的空闲服务器上，NIS+ 服务器可以用副本来启动）会让你免于在压力下变得手忙脚乱和浪费太多时间。</p>    <h3><strong>习惯 2：熟悉你的工具和系统</strong></h3>    <p>可能找出你的哪台服务器出问题的最快方法是，熟悉它正常情况下的状态。假如一台服务器通常使用50%的内存，突然间用到了99%, 你会想知道发生了什么。现在是什么进程在跑，之前不是这样的呀？什么应用比平常用了更多的资源？精通一套查看性能、内存使用等的命令，我通常用 sar 命令，也鼓励别人使用它 , 我用它来查看目前系统发生了什么的同时也用它回顾以往以找出问题发生的时间。我在我最关键的服务器上运行的一个脚本发给我足够的数据，让我可以快速查看最近一两周的性能指标。</p>    <p>在问题发生的时候练习所有可能有用的命令也是个好主意。你能构造一个 find 命令帮你识别可疑文件，大文件，和权限有问题的文件吗？你需要分析一个程序的时候，知道如何使用一个好的调试器真是有如神助。当你的系统受到攻击的时候，知道怎么检查网络连接也很重要。</p>    <h3><strong>习惯 3：优先级，优先级，优先级</strong></h3>    <p>谈到你如何安排工作的时候，把重要的事情放在首位是毫无疑问的，但有时候选择哪一件事情更优先要比看起来更困难。想要合理的安排任务的优先级，你必须考虑解决问题所带来的价值。对我来说，问题影响到的人数常常在我的考虑范围之内，但也要看被影响到的是谁。你的 CEO 可能必须等同于 1000 名员工，但只有你（或你的老板）能做这个决定。你还应该考虑他们受影响的程度。这个问题指的是，他们根本没法工作还是只是给他们的工作带来干扰？另一个确定优先级的关键因素是解决问题需要的时间。除非我正在解决的问题需要断电，我会尽快做完可以快速解决的。对我而言，这个类似超市的少量购物结算通道（美国的超市结算台有“不多于10件商品”与“超过10件商品”之分）。如果我可以在几分钟之内解决一个问题，回过头再做那个可能要花费我所有剩余时间的更重要的问题，我会这么做。如果觉得这个技巧有用，你可以设计自己的量化系统来计算任务的优先级，但不要太复杂。评定问题严重程度的 “value” 可以从1（不严重）到5（严重），影响到的人数也从 1（一个人）到 5 （每个人），需要的时间可以是, 1（星期），2（天），3（小时）和 4 （分钟）。某种程度上用量化的方式来确定优先级总是个好主意。</p>    <p>严重程度 × 影响到的人数 × 需要的时间 ＝ 优先级 （最高优先级 ＝ 优先级的最大值）</p>    <p>3 * 2 * 2 = 12 问题 #1</p>    <p>5 * 1 * 4 = 20 问题 #2</p>    <p>这里问题 #2 会排在任务列表的第一位。</p>    <h3><strong>习惯４：进行事后分析，但不要把自己搞糊涂了</strong></h3>    <p>有些 Unix 管理员对事后分析有点走火入魔。弄清为什么会出现问题，事后分析的确是个好办法，但是也许不值得你在这上边花太多时间。如果你遇到一个非常严重的，很高级的问题并且可以重现，你应该花点时间弄清楚到底发生了什么。不太严重的问题没必要这么认真的分析，所以对那些很容易解决的和没有严重后果的问题，你应该设个时限，确定要花多长时间在它上面，来弄明白问题的起因。如果你确实知道事情为什么发生，而不是只知道发生了什么，最好把它记录下来，好在几个月或几年之后发生同样的问题时你或别人可以查询得到。</p>    <p>我很想从这些年来遇到的问题中学习，可是曾经有太多次，我发现当遇到一个问题的时候会说 ”我之前碰到过…” 同时仍然想不起原因或者我之前是怎么解决这个问题的。记录正确的笔记，把它们放到安全的地方，可以在今后的某些时候节省你几个小时的时间。你也要仔细确认你的办法真的有效。不然你可能会发现确凿的证据，证明你所认为的办法其实没有效果。这样的证据有时不止一条。在你把它记下来之前，尝试确认你处理的任何问题完全解决了。有时你需要终端用户帮你确认。或者你可以用 su 命令切换到终端用户，自己确认修好了没（我经常这么干）。</p>    <h3><strong>习惯 5: 记录你的工作</strong></h3>    <p>通常来讲，Unix 管理员不喜欢把他们做的事情记录下来，但有些事真的有必要花些时间和精力把它文档化。我曾经编译了一些很复杂的工具，很值的记录下来，但我没有这么做，因此我不得不通过记忆来回想每个程序到底是如何工作的。例如，我有一些程序，包含几个可视化脚本，跑在 windows 虚拟服务器上给一台 Unix 服务器发文件，此服务器用 Perl 格式化这些文件，为把它们放入 Oracle 数据库做准备。</p>    <p>如果别人接手了这项任务的安装，会花很长时间来理解这些脚本片段，它们跑在哪里，它们在干什么，它们是怎么彼此配合的。实际上，我有时必须停下来问自己 “等一下；这个是怎么回事？” 一些我为自己准备的最好的文档，列出了每个程序和哪一部分在哪运行，展示出程序每个阶段的数据样本并且详细介绍了每个程序如何工作和何时运行。</p>    <h3><strong>习惯 6：修复问题并向解释给用户</strong></h3>    <p>好的 Unix 管理员对他们支持的用户总是积极响应，他们会回复用户反馈的问题并且在为用户解决问题的时候也会让用户知晓。如果你花时间回复用户反馈的问题，在解决这个问题的同时通知反馈问题的用户，并在问题被修复后告诉用户，你的用户可能不会感到沮丧而会感激你花时间来帮助他们。</p>    <p>更进一步，如果你花时间解释哪里出了问题和为什么会出现问题，这可能会让他们以后能够自己解决问题而且还会佩服你的直觉。</p>    <h3><strong>习惯 7：给自己留点时间</strong></h3>    <p>正如我曾经在文章说过的，工作不是你的全部。照顾好自己也是做好工作的重要部分。不要把自己拴在办公桌上。不时的到处走走，让脑袋放松放松，并保持学习 — 尤其是你感兴趣的。</p>    <p>如果你在意你的幸福，调养生息，并短暂脱离工作，你可能会更幸福并且在人生的各个方面都更成功。</p>    <p> </p>    <p>来自：http://blog.jobbole.com/107956/</p>    <p> </p>