每个程序员都应该知道哪些系统管理员知识？

Question

作为程序员，我们倾向于认为系统管理员是理所当然的。有几次我没有一个好的系统管理员，这让我很感激你们所做的事情。当我们冒险进入没有系统管理员的环境时，您能给我们提供哪些智慧之言？

Answer 1

我会从：

1. 始终拥有某种备份系统。如果有历史就更好了。
2. 考虑单点故障以及如果它们出现故障如何处理它们。
3. 根据所涉及的计算机数量，寻找某种方法来制作和创建跨计算机的标准图像将使每个人的生活更轻松 - 没有“它适用于我的”，因为他们通常没有安装这样那样的程序。
4. 记录所有内容，即使只是因为您会忘记如何设置某些内容。
5. 及时了解安全更新。

Answer 2

<在此处插入大帖子免责声明>

其中一些之前已经说过，但值得重复一遍。

文档：

• 记录一切。如果您没有，请安装一个不为人知的 wiki，但请确保对其进行备份。从收集事实开始，总有一天，会形成一幅大图。

• 为每个逻辑块创建图表并保持更新。我数不清准确的网络地图或集群图救了我多少次。

• 保留每个系统的构建日志，即使它只是复制和粘贴如何构建它的命令。

• 在构建您的系统时，安装和配置您的应用程序，测试它的工作情况并执行您的基准测试。现在，擦除磁盘。严重地。'dd' 磁盘前面的第一个兆字节，否则会使盒子无法启动。时间在流逝：证明您的文档可以从头开始重建（或者，更好的是，证明您的同事只需要您的文档即可）。这将构成您的灾难恢复计划的一半。

• 现在您有了灾难恢复计划的前半部分，记录其余部分；如何恢复应用程序的状态（从磁带恢复文件、从转储中重新加载数据库）、供应商/支持详细信息、网络要求、更换硬件的方式和位置——任何您能想到的都有助于恢复系统。

自动化：

• 尽可能自动化。如果您必须做三件事，请确保第二次用于开发自动化，以便第三次完全自动化。如果你不能自动化它，记录它。那里有自动化套件 - 看看你是否可以让它们为你工作。

监控：

• 应用仪器是纯金。能够观察通过系统的事务使得调试和故障排除变得更加容易。

• 创建端到端测试，不仅证明应用程序还活着，而且确实做了它应该做的事情。如果它可以被插入监控系统以用于警报目的，那么点数就是你的了。这有双重作用；除了证明应用程序有效之外，它还使系统升级变得更加容易（监控系统报告绿色、升级成功、回家时间到了）。

• 对一切正常的事情进行基准测试、监控和收集指标。基准测试会告诉您什么时候可以预期某些东西会冒出神奇的烟雾。监控会告诉您何时发生。指标和统计数据使通过管理获得新套件（带有新鲜的魔法烟雾）变得更容易。

• 如果您没有监控系统，请实施一个。如果您确实将上述端到端测试插入其中，则可以获得奖励积分。

安全：

• “chmod 777”（又名授予所有访问权限/特权）从来都不是解决方案。

• 订阅“最少位”原则；如果它没有安装、复制或以其他方式存在于磁盘上，它就不会受到损害。“厨房水槽”操作系统和软件安装可能会使构建阶段的生活变得更轻松，但您最终会为此付出代价。

• 了解服务器上每个开放端口的用途。经常审核它们以确保没有新的出现。

• 不要尝试清理受感染的服务器；它需要从头开始重建。使用新下载的媒体重建到备用服务器，仅从备份中恢复数据（因为二进制文件可能会受到损害）或将受到损害的主机克隆到隔离的某个地方进行分析，以便您可以在同一个工具包上重建。围绕这有一个完整的法律噩梦，所以如果您需要寻求法律途径，请在保护方面犯错。（注：IANAL）。

硬件：

• 永远不要假设任何东西都会像盒子上说的那样做。证明它可以满足您的需求，以防万一。您会发现自己比预期的更频繁地说“它几乎有效”。

• 不要吝啬远程硬件管理。串行控制台和熄灯管理应被视为强制性的。当您别无选择时，远程控制电源板的奖励积分。

（旁白：有两种方法可以解决凌晨 3 点的问题，一种是保暖，穿着睡衣通过 VPN 在笔记本电脑上工作，另一种是穿厚夹克和开车去数据中心/办公室。我知道我知道哪一种更喜欢。）

项目管理：

• 从项目生命周期的第一天起就让维护系统的人员参与进来。套件和大脑时间的提前期可以而且将会令人惊讶，毫无疑问，他们将（应该？）拥有将成为项目依赖项的标准或要求。

• 文档是项目的一部分。在项目关闭并且系统进入维护后，您将永远没有时间写下整个事情，因此请确保在开始时将其作为工作纳入日程安排。

• 从第一天起在项目中实施计划报废，并在您在项目文档中指定的关闭日期前六个月开始更新周期。

当服务器适合用于生产时，它们具有定义的生命周期。此生命周期的结束通常定义为供应商开始收取的年度维护费用高于更新套件的费用，或大约三年，以较短者为准。在此之后，它们非常适合开发/测试环境，但您不应该依赖它们来运行业务。在 2 1/2 年重新审视环境，让您有充足的时间跳过必要的管理和财务流程，以便订购新套件并在将旧套件发送给空中的大供应商之前实施平稳迁移。

发展：

• 确保您的开发和登台系统类似于生产。VM 或其他虚拟化技术（区域、LDOM、虚拟服务器）使真实世界中的各种意义但性能的生产克隆变得容易。

备份

• 您不备份的数据是您不想要的数据。这是不可改变的规律。确保您的现实与此相符。

• 备份比看起来更难；有些文件将被打开或锁定，而其他文件则需要停顿才能有任何恢复的希望，所有这些问题都需要解决。一些备份包有代理或其他方法来处理打开/锁定的文件，其他包没有。将数据库转储到磁盘并进行备份算作“停顿”的一种形式，但这不是唯一的方法。

• 除非经过测试，否则备份毫无价值。每隔几个月，从档案中随机抽取一个磁带，确保其上确实有数据，并且数据是一致的。

而最重要的是...

选择你的失败模式，否则 Murphy 会……而且 Murphy 不会按照你的时间表工作。

针对故障进行设计，记录每个系统设计的弱点、触发它们的原因以及如何恢复。当出现问题时，一切都会变得不同。

Answer 3

不要以为这很容易。我认识很多程序员，他们认为仅仅因为他们可以在开发箱上设置 IIS 或 Apache，他们就可以运行网络农场。了解工作涉及的内容并进行研究和计划，不要仅仅认为系统管理员工作是您可以在 10 分钟内完成部署应用程序的简单事情。

Answer 4

• 意识到，无论好坏，他们倾向于使用的许多服务器和/或网络设备非常像来自第二个家庭的孩子。 这些是他们的宝贝。 他们照顾他们，在他们生病时帮助他们，并警惕地监视他们是否有麻烦。这不应该是这样，但多年后，它经常是。当您向他们传达您对设备运行不正常或预期不正常的担忧时，请记住这一点。如果你得到一个你不理解的回复，试着通过这个世界观来过滤它。
• 保持良好的工作条件。听起来很俗气，但它的重量是黄金。总有一天，你会需要一些特别的帮助。总有一天，系统管理员会很乐意竭尽全力让您的生活更轻松，就这一次。
• 这种工作关系是双向的。如果系统管理员很忙，而您可以通过编写一个小脚本或程序使生活更轻松一些，那就去做吧！他们会比你知道的更欣赏它。
• 要非常清楚。“这很糟糕”不如“断断续续的网络连接有点烦人，你有机会看看吗？”
• 如果您认为您的应用程序会扩展，请在假设它会扩展之前询问管理员。他们可能会“看到”一些您看不到的东西，或者了解您将要部署的设备的性能限制。
• 如果您的应用程序需要调整，但它似乎不是代码问题，请很好地询问服务器的性能。系统管理员小心翼翼地照料他们的机器，当他们“生病”或“行为不端”时会不高兴。很好地询问将使一台出现故障的机器转过身来（或修理/更换）。
• （如其他地方提到）记录您使用的设置，以及为什么使用它们。只是“设置复选框 X”或“取消注释配置文件行 Y”没有帮助。您可以设置在下次重新启动时清除所有数据的选项。
• 如果您没有时间将设置记录在纸上，请尽可能尝试将其记录在系统中。随着配置文件，这应该几乎可以说是标准的做法-每一个设置变更，应盖销，包括缩写，即设定的预期效果，原因为什么它被改变（见之前的子弹点）。这个小习惯在关键时刻不止一次拯救了我的培根。“我们为什么这样做？” “因为我们强制执行策略 X，而设置 Y 为我们提供了策略 X 所需的行为”。
• 啤酒。或者可乐。甚至水。饮料总是受欢迎的。成为系统管理员是一项艰巨的工作。

Answer 5

安全不是事后的想法。虽然被黑的应用程序可能会使程序员看起来无能，但（至少）是一个浪费的周末，用于为系统管理员验证、清理和/或从备份中恢复。

就此而言，不要将备份视为版本控制。它们用于灾难恢复，并不是真正旨在恢复您的代码，因为您忘记了更改的内容。

不要盲目地将代码被破坏的原因归咎于 Windows 更新。我不在乎它是否有效，告诉我为什么它现在不起作用 - 然后我们可以看到这是谁的错。

Answer 6

如何调试网络问题并使用 sysadmin 工具观察程序运行。作为一名刚开始从事系统管理的程序员，当网络“停止”时，许多程序员变得多么无能，这让我感到惊讶。

• Wireshark，以黑盒方式逐包观察您的代码运行
• 直接连接到网络服务的工具：
  • Telnet、netcat 或 socat用于通过 TCP 或 UDP 的普通连接
  • OpenSSL与加密相同（提示：openssl s_client -connect target-host:port有时尝试），用于手动连接到网络服务
• dig（在 BIND 9 包中）用于调试名称解析
• 能够根据连接失败的时间和其他特征判断网络堆栈的哪一部分失败
• 可能是HTTPFox 和/或 Firebug

Answer 7

知道如何解决问题。

推卸责任很容易（例如，您的网络正在管理我与数据库的通信）。这可能是网络的问题，但您应该拥有包含错误的应用程序日志，使用 Google 或 SO，这些错误可能会揭示应用程序配置中的问题。

每个人都喜欢责怪硬件、操作系统或网络，所以如果你多加注意，你会让系统管理员成为一个快乐的人。因为，如果不出意外，您也许可以指出他们可能出什么问题的特定方向（而不是说“您的网络很烂”或同样有用的东西）。

Answer 8

记录一切你能做的。无法告诉您上一个系统管理员有多少次认为不为“工作保障”或某人只是想进进出出而记录一些东西会很可爱。就像程序员应该留下好的评论一样，系统管理员应该记录。拓扑图也很好。

Answer 9

计划 B。

在设计和开发解决方案时，始终牢记灾难恢复计划。识别可能导致中断的单点故障。

Answer 10

文档：无需纠结，而是应用程序是如何工作的，一个图表显示了这些位如何配合以及在出现问题时测试每个组件的方法。示例数据和输出很好。

需求：依赖哪些模块？版本？操作系统？

监控：理想情况下，开发人员应包括对应用程序的监控信息和测试。

说到包装，包装！没有什么比“部署”更糟糕的了，这意味着从 VCS 检出文件的新版本并将其复制到一堆服务器。程序员常常不理解部署软件的复杂性：版本化、打包的软件构成大多数操作系统的支柱是有原因的。

如果开发人员带着 RPM 来找我，并且第一次安装时带有简洁、全面的文档和一些 Nagios 测试，他们将成为我最好的新朋友。

Answer 11

令我惊讶的是，到目前为止，这里给出的 17 个答案中没有一个包含有关确保您的应用程序在以标准用户身份登录时运行的任何内容。

除了安装过程之外，当使用标准用户帐户登录时，应用程序应该可以正常运行。