标题确实说明了一切。
有时，开发和 IT 部门会因为这类事情而争执不休。当您被要求安装、修补、维护、启动、停止和诊断跨一台或多台服务器运行的解决方案时，您期望什么级别的文档？
答案1
所有这些事情都应该详细记录下来，尽管当操作是操作系统、应用程序服务器、网络服务器等的标准时，您可能能够假设 IT 运营人员知道如何执行此操作。
安装：记录有关如何安装和配置的所有内容，包括如何判断它是否正常运行。
告诉我们有关架构的信息，特别是有关各种解决方案组件之间的通信的信息（例如端口范围 - RPC 机制通常使用一系列端口 - 我们需要知道范围是多少以及应用程序何时可能用尽端口）。
修补：记录应用程序的任何特定内容 - 修补之前需要关闭的内容，以及修补后的任何后续操作（可能需要清除或重建的缓存，索引，代理）。
维护：记录正常和异常操作的样子——应该监控哪些队列和其他事物以及这些的正常范围是多少。
告诉我们如何管理数据 - 尤其是那些无限增长的表和文件（例如日志文件和事务历史记录）。应该如何清除这些数据，删除旧条目会有什么影响？（对报告等）。
告诉我们如何执行标准的“照常业务”/生活中的管理操作 - 例如，这可能是添加或修改用户帐户。
告诉我们可能需要的任何其他常规管理措施（例如，使用了哪些证书以及证书过期后该怎么办）。
对于所有更改，请告诉我们如何将其回滚（并非所有更改都会成功）。并告诉我们您已经测试了回滚计划！
诊断：记录日志文件格式和位置以及可能出现的每条应用程序错误消息，说明错误消息的含义以及可能需要进行哪些更改才能修复它。切勿对两个不同的事件使用相同的错误消息。
击落并重新启动：如何、以什么顺序、任何特殊程序（例如，让服务器在关闭连接之前耗尽连接）。
我坚决不同意最好的做法是将应用程序抛到一边，让 IT 人员决定需要什么。操作文档（以及一般而言，应用程序的可管理性功能）需要提前考虑。
答案2
后续问题是：当（不是如果）开发人员没有提供足够的文档时会发生什么？
我建议 IT 部门能够使用开发人员使用的任何缺陷跟踪系统针对软件输入缺陷报告。这样，如果他们没有告诉你，例如，某个文件夹中的文件需要清除，并且只应保留一周的文件，你可以输入一个缺陷，说“应用程序用日志文件填满磁盘”，并建议他们与 IT 部门合作，制定清除该文件夹的记录技术。
答案3
我对文档的要求如下（不分先后顺序）：
（文件：）
- 所有命令行开关
- 所有退出状态和返回值
- 日志消息（如果不可配置，则不是内容而是解释字段）
- 配置语法
- 配置文件中的开关
- 内存使用情况
- 它是螺纹的还是分叉的
- 服务器对哪些信号做出反应
- 是否有任何信号不重新启动服务器，但让它重新读取配置
- 它的行为如何？（它是否等待现有线程/进程以旧配置完成。它会杀死它们吗？......）
- 非正常关机时会发生什么（特别是如果它是某种持久性服务/服务器）
- 它是通过系统提供的调用来记录还是用它自己写的东西来记录（恶心对于 apache 和访问日志 - 我显然更喜欢使用板载工具进行日志记录）
- 如果是网络服务，则支持 IPv4 和 IPv6
- 主干文档和特定版本的文档
- 没有什么比花几个小时配置某个东西更糟糕的了，最后却发现它将被忽略，因为配置选项只在主干中可用
- 哪个配置选项在哪个版本中有效（自 v1.0 起可用，自 v1.2 起弃用或类似版本）
类似这样的文档就是良好文档的示例：
我认为这样的文档充满了失败：
FreeBSD 手册也是文档和 OpenBSD 方法的一个很好的例子。他们会剔除那些没有正确记录的内容。
编辑：这个列表并不完整，它只是基本的东西我立刻想到了这一点。文档应该易于阅读，而不仅仅是读起来像有人吐出来的东西。
答案4
我认为 IT 需要与开发人员沟通需要哪种文档。最好的方法是，开发部门提供解决方案的预发布版本（或迭代版本）供 IT 试用和测试，这样 IT 就可以做出所需的响应。