被忽视的利益相关者 a.k.a 系统管理员答案

【问题标题】：The Neglected Stakeholder a.k.a the System Administrator被忽视的利益相关者 a.k.a 系统管理员
【发布时间】：2010-09-23 08:51:48
【问题描述】：

前段时间我意识到，到目前为止，我从事的几乎每个客户项目都忽略了一组重要的利益相关者：系统管理员。

这些默默无闻的英雄通常只在项目结束时才参与进来，并留下一个可执行的黑匣子，他们必须在未来几年内安装、支持和维护。每当这个黑盒出现问题时，他们必须找到一种方法来使用黑盒或底层平台提供给他们的任何随机信息和工具支持来解决它，如果这还不够，那么他们必须即兴发挥.

如果他们从一开始就作为项目的利益相关者参与其中，他们就有机会预测潜在问题并将其告知项目团队。但实际情况有所不同，即使我作为一名开发人员愿意让系统管理员作为额外的利益相关者参与进来，但外部因素可能会阻止这种情况发生。

在这种情况下，我想尽我所能帮助我们沉默的英雄。所以我的问题是：

当我们开发他们必须维护的系统时，系统管理员希望我们这些开发人员做什么？

如果您是系统管理员请讲述一个关于您曾经遇到的难题的战争故事，以及开发人员可以采取哪些措施让您更轻松地解决它。

【问题讨论】：

标签： maintenance requirements system-administration

【解决方案1】：

该系统正常工作，以便他可以回家照顾孩子。

【讨论】：

@Jonas Kongslund：实际上我可以删除这个答案，如果它阻止你的问题引起注意......但我认为这是有道理的:)
他不希望它工作得太好，否则他会失业。
@nobody：他可能有很多其他软件让他忙得不可开交；无需增加工作量。

【解决方案2】：

系统管理员通常需要以下内容：

系统操作的透明度。所以某种 GUI 可以显示系统设置，可能还有系统问题的历史记录，以及系统正确处理的列表。
清晰的上下文相关问题升级路径。我的意思是，每种问题类型都有一些关于解决问题的说明，以及在问题无法快速解决且需要上报时可以联系的人员或团队。
积极主动，即能够在最终用户通知最终用户之前通知最终用户系统问题。因此，在可行的情况下，对任何系统问题都会立即发出某种警报，
不会被警报淹没。因此，一旦警报到达，就不再针对同一问题发出警报；系统再次运行时的另一条消息。
使用事件日志（在 Windows 中）等内容进行详细日志记录，以便深入调查问题。

【讨论】：

感谢您的意见。 “上下文相关的升级路径”是什么意思？

【解决方案3】：

每个项目都有“容量规划”及其系统架构。系统管理员应该参与容量规划过程以及系统架构的最终审查。这将有助于他更好地了解系统并为部署和支持做好准备。

【讨论】：

事实是，并非所有项目都具有此功能，而具有此功能的项目并不总是涉及系统管理员。在我的问题中，我假设系统管理员在开发期间不可用。这可能有很多原因，例如如果其他公司负责托管。

【解决方案4】：

各种各样的事情，包括（但不太可能限于）这些，不按优先顺序排列：

无需使用特权安装
使用特权安装的选项
分布式安装选项（因此它可以安装在服务器上并在其他计算机上使用）
彻底卸载
合理的升级模式
选择安装位置的选项
对其他软件的依赖最小
系统周围的数据分散最少（不要将内容转储到 /etc、/usr/lib、/var/adm、...）
没有不断增长的日志
静默安装
脚本安装
在线文档（机器上以及互联网上）
可能是手册页
易于配置
易于最终用户访问
没有安全风险
没有特殊用户或组（或数量有限 - 最多一个特殊用户，一个特殊组是目标，尽管并不总是可以实现）
要么没有“电话回家”功能，要么仅在明确配置时（不得默认）
出现问题时良好的诊断记录
如果出现问题，可以提供良好的技术支持
安装过程中无需获取激活码
安装后无需重启机器
能够并行运行新旧版本

很大程度上取决于软件是什么以及如何使用它。在 Windows、Linux 和 MacOS X 上运行的 GUI 程序的要求与网络守护程序的要求完全不同 - 但目标仍然应该是稳定、可靠、易于管理的软件。

请注意，由内部部门准备供公司内部使用的软件与供开发该软件的公司外部客户使用的软件之间存在很大差异。

【讨论】：

我可以补充一下，轻松自定义日志输出。

【解决方案5】：

如果我的家庭管理经验值得参考的话，软件随附的文档齐全的依赖项。

【讨论】：

【解决方案6】：

我认为是以下几点的结合：

1) 容量阈值 -> 运行此软件需要哪些机器以及应使用哪些指标来确定此数字何时可能更改，例如从 2 到 3 个数据库服务器或从 10 到 15 个网络服务器。硬件需要有多强大，并且其中一部分比另一部分更重要，例如。 CPU 比 RAM 更重要吗，硬盘配置和空间呢？

2) Cookbook 式故障排除 -> 如果出现问题，如何轻松地将其归类为代码、数据或网络错误。

3) 环境图 -> 该软件的开发、测试和生产实例是什么样的？目前是否有这些以及可能的其他环境正在运行？

4) 维护 -> 是否有日志文件可以解析成报告、每周发送的错误日志，或者与软件有关的某种内务管理，例如每周重启服务器。

5) 安全性 -> 是否有要创建和管理的帐户以及安全策略来概述谁在系统上拥有什么级别的权限。

这些将是我想到的主要内容。

【讨论】：

【解决方案7】：

嗯，比战时故事更恐怖：维护一个应用程序，无缘无故要求在管理员用户帐户下运行。

我认为在应用程序中有一些随机的东西会很好：

有意义的命令行参数
某种脚本功能（如果适用）
任何类型的长期运行进度指示器
错误记录
一致的用户界面

【讨论】：

【解决方案8】：

易于维护包！

安装和升级软件应该非常简单，依赖项也是如此。如果有很多依赖项和子依赖项，并且您不倾向于掌握每个操作系统的包管理方法的细微差别，那么最好提供一个包版本，其中所有必需的依赖项捆绑在一起形成一个巨大的 tarball .运行脚本，将其全部放入 /usr/local/yourproject，并告诉他们启动/关闭/重启脚本在哪里。

【讨论】：

【解决方案9】：

当不可避免地出现问题时，请注意系统管理员所说的话并相信他。如果它不符合您的初步评估，请不要立即将其忽略。

战争故事：大约 6 年前，我是一家小型制造公司的系统管理员，他们决定购买一些软件来处理他们设备的预防性维护计划。它的一个功能是从电子邮件中导入维护请求，但在此过程中我们偶尔会遇到与邮件服务器通信的错误问题，最终我在与开发人员的电话中被叫来查看它。对话涉及多次迭代

开发者：我从没听说过任何人和他说话有那种麻烦邮件服务器。它必须是一个防火墙问题。

我：我已登录防火墙，运行数据包嗅探器，并观察您的应用程序的流量通过没有任何问题。它通过防火墙就好了。

开发者：不，不 - 它必须是防火墙问题。

(最后发现问题出在app打开POP3连接，读取所有邮件，等待用户安排任务，等所有请求完成后，发送POP命令删除邮件如果用户调度时间超过 15 分钟，则 POP 连接超时，应用程序无法恢复，所以它反而死掉了。然后用户不得不重复调度，这意味着它可能会需要足够长的时间才能再次超时...）

【讨论】：