基于“组织问题” – IT的痛点？ 我认为说系统pipe理员需要确定一个地方是否值得工作是公平的。 Joel为程序员提供了一个类似的众所周知的testing 。
系统pipe理员在面试中应该询问的12个问题是什么，以帮助他们决定是否适合工作？
遵循Joel的规则：
编辑：请一次发布一个问题，以便我们可以看到用户投票。
你使用事件/票务跟踪系统吗？
您是否执行系统备份，并定期testing恢复？
这会影响您以非常直接的方式执行的能力。 这也影响你的能力，以不间断的假期…
这个答案会有所不同，但这是组织如何实际“组织”的一个很好的指示。 大型设备应该有一个帮助台和票务系统; 小型机构至less应该有售票系统，以及某种公司付费寻呼机的帮助。
“只有你”不是一个可以接受的答案。 这是一个完全缺乏组织的问题，应该跟进一个“如何跟踪用户请求？”的问题。 这必须回答“你不”以外的东西 。
这不应该太高（高于50：1）或太低（低于5：1）。 太高，你的工作量太重了，你会踩踏水来保持漂浮。 太低，你或者是一个人的商店，或者是商店pipe理系统的能力存在严重问题。
与往常一样，规则也有例外。 可以从单一来源（考虑networking头端）对200多个系统进行映像的实例，以及业务非常less的实例（20名员工可能只需要2台服务器）。
这是一个期望的措施。 这些是你的“顾客”。 当有问题的时候，这将是你解决问题的“压力”。 如果你的系统有问题，5000个只有2个pipe理员的组织可能是非常非常有压力的地方。
这是衡量服务器工作量。 非常高的比率可能是过度使用的标志，或预算限制，在需要扩展的时候会牵扯住您的双手。 未被使用的情况下，利用不足也是一个问题（也就是说，HR有自己的服务器是有意义的，但是对于组织中只有5个“常规”用户的文件服务器是红旗）。 这可能需要一些“虚拟化”来整合服务器…
除（a）“我不知道”或（b）“我们不更新”之外，这应该是其他答案。
这应该总是一个合理的问题。 如果面试官在这个问题上受挫，那么他们不了解你的工作性质，这是未来前景的重要线索。 如果期望是全天候运作的，那就没问题 – 除非他们没有基础设施，这意味着你会很多的保姆机器 。 知道什么是不可接受的，有助于向他们展示他们真正的期望。
喷水器不是一个可以接受的答案。 这确实发生了，你会得到一些组织，认为把一个架子放进一个没有通风的扫帚壁橱里，顶上的喷水灭火器是一个好主意 。 如果这被低估，被忽略，或遭到敌意，起床，感谢面试官， 不要走路，跑步…
这是另一个应该回答的问题，除了“我们不”和“我们没有备份媒体”。
上述问题的后续行动。 如果你不是经常testing的话，那你只是在招惹麻烦。
如果答案是“我们（别人）会在我们需要的时候购买它”，那是一面红旗。 这意味着“我们不信任你在需要的时候购买设备，所以我们会让其他人去做”。 应该总是有某种预算。
购买东西的过程应该很容易在不到2分钟的时间内解释。 它不应该涉及两个以上的签约方（数字越大表示繁文</s>节），也应该以天或小时为单位，而不是周（如果过长，关键性的购买将被搁置）。 应该总是有某种过程。
实际上，我看到一些运营在18年前的小型机上的公司依靠支持合同和大量的支持供应商提供的备件。 当然，原来的硬件厂商早已离开…
桌面设备永远不应该比3年或5年更慢。在预算紧张的企业中，将桌面延伸到5年有时是一个合适的答案。
回收的一点是testing他们是否对旧硬件有“一次性”的态度。 这是不好的，你应该通过一个已知的回收商妥善处理它，但在某种意义上说，如果需要的话，你可以把旧硬件压入临时工。 它也会给你一个“boneyard”的大小（一堆旧的硬件）的感觉。
相关问题：
https://serverfault.com/questions/44638/how-often-does-tech-refresh-happen
你有一个灾难恢复计划，这是否包括IT？
好评如下：如果是这样，是否包括整个组织而不仅仅是IT？ 它是否包括人员，你是否经常testing？
相关问题：
灾难恢复计划发展的最佳实践或资源？
当前的环境是否logging在案？
政策和程序是否有文件logging和一致？
内部会计实践是否评估IT向其他部门提供的服务的价值，还是IT仅仅作为成本中心？
（这与Stick的“是你的组织中的优先事项还是必要的邪恶？”几乎是同一个问题，但是措辞可能引出一个诚实的答案，而不是公然的电报正确的谎言。
有一点我认为是一个必须具备的testing机器，它与现场服务器具有相同的硬件规格。
你的testing环境与生产的匹配程度如何？
我觉得很有意思的是，许多答案的措辞是“你有这个吗？” 或者“你是否经常这样做？” 如果我将被聘用为一个新的系统pipe理员，我希望能够实现这些东西，如果他们不存在。 灾难恢复和监控日志不会造成或中断采访。 如果他们不做这些事情，他们会在我被录用之后。
我如前所述主要关心的是上面的支持。 如果我说我们需要更换服务器，我想得到怀疑的好处。 或者如果我实施一个恼人的安全政策，我不希望合作伙伴给予抱怨的人豁免，所以他们可以看起来像漂亮的照顾老板。
系统pipe理员在公司结构层次中处于一个陌生的地方。 有时候，他们会根据大多数入门级人员的需求来指导和设定他们的优先级，有时他们会对pipe理层进行决策。 我们同时处于最底层和最高端的环节。
只要在我处于顶峰的情况下，pipe理层听从我的build议，我就愿意扮演替罪羊的angular色。
是否所有新的系统/软件/应用程序购买都是通过IT进行的，IT是否有权拒绝和build议另一个系统，或许是另一个系统已经使用的系统？
你是否愿意花钱购买适当的监控/logging工具？
– 或从原来的乔尔testing问题：
你使用金钱可以买到的最好的工具吗？
相关问题：
服务器健康监测软件
我可以和你以前的系统pipe理员交谈吗？
您是否使用通用pipe理员/ root帐户login？
在“一群”中间抛出“否”的答案总是很有趣。
IT是否有自己的预算？
矿井不是，我们依靠其他部门的资金来满足我们所需要的一切。 吮吸大时间。
你是否在异地存储备份的副本？
请允许我继续接受培训和教育，并允许我购买材料以及时了解安全问题？
无论多么不受欢迎，你是否会支持我的政策和程序方面的决定？
我会注意到，对于我们这些喜欢为初创公司或早期公司工作的人来说，其中大部分的答案很可能是“不是，但是……”。 这个陈述之后的内容往往是相当丰富的。
IT是您组织中的优先事项还是必要的恶果？
咖啡机在哪里？
你使用版本控制？ 你在版本控制下做了什么？
你的系统pipe理员能写代码吗？
你有集中日志吗？ 有人读过吗？
您是否有关键系统的响应时间策略/阈值？ （或者有什么更好的方法来expression，“你是否已经熟悉了什么应该而不应该让我在凌晨3点起床的概念？”）
你可以一步添加新的用户吗？
向你致敬：你能一步到位build造吗？
我是唯一的系统pipe理员吗？ 成为唯一的系统pipe理员可以很好 – 事实上，这可能很有趣，但是只有当业务理解这些带来的影响时：
你有SLA吗？
询问他们是否在说系统pipe理员时，他们是否确实指SA和DBA以及networkingpipe理员和Apache / IISpipe理员和电子邮件pipe理员以及ADpipe理员和桌面疑难解答人员。
你使用像Puppet或Chef这样的configurationpipe理系统吗？
你能告诉哪个系统在任何时候缺less哪些补丁？
你使用补丁/变更pipe理？
您是否执行每月/每年的灾难恢复testing？
IT是否负责并通过系统正常运行时间和票据来衡量？
您是否对所有IT部门使用集中票务pipe理？
员工是否可以在办公桌上打断IT人员？
您的IT人员是否有意为业务线创build解决scheme？还是只遵循高层pipe理人员的指导？
即使在接近报废时期，您是否仍保持关键的硬件和软件平台的许可和支持？