您开始工作或担任公司顾问，并“继承”了配置不当的服务器。您见过的最严重的配置错误是什么？
答案1
我已经在这个行业工作了 15 年，还没有在一家公司开始担任新的咨询职位时发现他们拥有“良好”的基础设施。这通常是我被叫去纠正他们问题的原因。
造成这种混乱的常见原因是非技术决策者做出技术决策。
答案2
几年前，我曾做过一份工作，对一家小型制造公司的网络基础设施进行“评估”。在那项工作中，我发现他们的 ERP 系统从未备份过。他们不知道，他们以前的 IT 承包商配置了 Backup Exec 进行每日完整备份，但从未编写任何类型的“转储”或停止/启动其 ERP 系统使用的数据库服务器的脚本，因此数据库文件始终处于使用状态并被备份跳过。因此，在超过 3 年的时间里，他们每天都在执行磁带备份，但磁带上没有任何 ERP 系统的数据。他们尽职尽责地更换了磁带，就像承包商告诉他们的那样，但显然没有人（包括承包商）费心去检查磁带上到底有什么。
答案3
很久以前，我们的一位高级管理人员离开了公司，将“文档成像系统”的职责移交给了我。我是团队中级别较低的人，缺乏经验，而且急于参与任何工作。
这就像是老可口可乐和 Mean Joe Green 合作的广告……我非常兴奋能够成为面向客户的生产系统的主要（唯一）管理员，而当他走出门时，他说，“嘿，孩子，接住”，但他扔给我的是一团皱巴巴的纸，上面写着一些登录信息和一个支持电话号码，而不是一条汗湿的毛巾。
兴奋感很快就消失了……该系统由 2 台运行数据库的服务器、一个共享服务器、大约 6 个带有扫描仪和处理应用程序的工作站以及一个用于引用文档的 Web 服务器和应用程序用户组成。它是 Apache 和 Java 以及至少两种在 Windows SQL Server 上运行的脚本的混杂体。哦，是的。我们还为一系列经常出现故障的“定制”付费，而他们的支持人员对此却一无所知。
《美好时光》简短名单：
- 该应用程序存在内存泄漏并且会挂起。
- 它通过一系列在夜间 FTP 作业上来回传输的 feed 文件与我们的 ERP 集成。两端的 feed 生成、处理、文件推送和数据库更新的顺序取决于远程 ERP 系统上的某些应用程序调度、SQL Server 作业和夜间 cron 之间的精确时间安排。如果任何一个方向的更新失败，整个部门就会陷入停滞状态，因为他们的“报告”没有从打印机中打印出来，或者更糟的是，包含不准确的信息，会导致客户投诉。
- SQL Server 没有配置维护作业，并且日志截断是手动的。
- 有时，应用程序的许可证文件会随机“过期”并锁定所有人。
- 有时内部用户角色会“混淆”，人们会登录并看到（并能够使用）管理界面按钮。（这些电话很棒......“丹......我看到一些新按钮......我应该点击它们吗？”）
记录的内容很少，当出现问题时我才发现每个问题。比如说……报告有误或未打印。或者桌面推送了新版本的 JVM，但没有人可以扫描。或者有人从扫描工作站踢掉了加密狗，应用程序崩溃了。或者日志文件系统已满。或者 OCR 提取的数据由于错误捕获某些内容并将其提交为非法内容而导致应用程序崩溃。或者发现有大约 30 张支持不同部门的票据处于打开状态，其中许多票据已经打开了几个月。等等。我每周以 4-5 个的速度发现新的、重要的东西，并开始非常快速地了解该应用程序的来龙去脉及其需求，以及足够的 SQL Server 来保持数据库适度健康。
最棒的是，我被邀请参加内部用户组会议，以“欢迎”我担任新职务。我不骗你。30 个愤怒的用户围成一圈，我坐在中间。
虽然很艰难，但我很快就学到了很多东西。抛开所有的痛苦，这是一个很好的机会。我有点希望它不是那么艰难，但也许我不会学得这么快。
抱歉，写了这么长...但是啊...这就像治疗 ;)
答案4
一个完全标准化的小型网络：Windows 95和NT 服务器。
那是几周前的事了。;-/