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

Question

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

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

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

在这些情况下，我想尽我所能帮助我们的无声英雄。所以我的问题是：

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

如果您是系统管理员，请讲一个战争故事，了解您曾经遇到过的一个难题以及开发人员可以做些什么来让您更轻松地解决问题。

Answer 1

各种各样的事情，包括（但不一定限于这些），这些事情不是优先顺序：

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

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

请记住，内部部门准备在一家公司内部使用的软件与为开发软件的公司外部客户准备的软件之间存在很大差异。

Answer 2

当问题不可避免地发生时，请注意系统管理员所说的并相信他。如果它不符合您的初步评估，请不要将其解除。

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

的多次迭代

  

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

     

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

     

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

（最后，事实证明，问题是应用程序打开了POP3连接，读取了所有邮件，等待用户安排任务，然后在所有请求之后发送了POP命令来删除邮件如果用户花了超过15分钟的时间进行调度，POP连接超时，应用程序无法恢复，所以它就死了。然后用户不得不重复调度，这意味着可能花很长时间再次超时......）

Answer 3

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

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

Answer 4

我认为以下各项的组合：

1）容量阈值 - ＆gt;运行此软件需要哪些机器以及应使用哪些指标来确定此数字何时可能发生变化，例如：从2到3个数据库服务器或从10到15个Web服务器。硬件需要多么强大，一部分比另一部分更重要，例如CPU是否比RAM更重要，硬盘配置和空间怎么样？

2）食谱风格故障排除 - ＆gt;如果出现问题，可以轻松地将其分类为代码，数据或网络错误。

3）环境图 - ＆gt;这个软件的开发，测试和生产实例是什么样的？现在是否有这些以及可能正在运行的其他环境？

4）维护 - ＆gt;是否存在要解析为报告的日志文件，要发送的每周错误日志，或者与软件有关的某种内务管理，例如：每周重启服务器。

5）安全性 - ＆gt;是否有要创建和管理的帐户以及用于概述谁在系统上具有什么级别权限的安全策略。

那些会成为我想到的主要因素。

Answer 5

系统正常工作，以便他可以回家给孩子们。

Answer 6

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

Answer 7

如果我的家庭管理员经历过任何事情，那么随软件打包的记录良好的依赖项就可以了。

Answer 8

嗯，恐怖而不是战争时期的故事：维护一个无需明确理由要求在管理员用户帐户下运行的应用程序。

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

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

Answer 9

易于打包维护！

安装和升级软件应该简单易懂，这也适用于依赖项。如果存在大量依赖关系和子依赖关系，并且您不倾向于掌握每个操作系统的包管理方法的细微差别，那么将包含所有必需依赖关系的包版本捆绑到一个巨大的tarball中会很不错。运行脚本，将其全部放入/ usr / local / yourproject，并告诉它们启动/关闭/重启脚本在哪里。