被忽视的利益相关者又名系统管理员

StackOverflow https://stackoverflow.com/questions/307353

题

不久前，我开始意识到，迄今为止我所从事的几乎每个客户项目都忽略了一个重要的利益相关者群体：系统管理员。

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

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

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

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

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

有帮助吗？

解决方案

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

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

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

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

其他提示

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

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

的多次迭代
  

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

     

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

     

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

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

我认为以下各项的组合：

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

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

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

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

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

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

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

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

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

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

好吧，这比战争故事更恐怖：维护一个无明显原因需要在管理员用户帐户下运行的应用程序。

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

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

易于打包维护！

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top