标题说明了一切。
有时最终会导致开发和 IT 在这类事情上发生争执。当您需要安装、修补、维护、启动、停止和诊断在一台或多台服务器上运行的解决方案时，您期望什么级别的文档？
所有这些事情都应该详细记录下来，尽管当操作是操作系统、应用程序服务器、Web 服务器等的标准操作时，您可以假设 IT 操作人员知道如何做到这一点。
安装：记录有关如何安装和配置的所有信息，包括如何判断它是否正常运行。
告诉我们架构，尤其是各种解决方案组件之间的通信（例如端口范围 - RPC 机制通常使用一系列端口 - 我们需要知道范围是什么以及应用程序何时可能会耗尽端口）。
修补：记录特定于应用程序的任何内容 - 修补前需要关闭的内容，以及修补后的任何后续操作（缓存、索引、可能需要清除或重建的代理）。
维护：记录正常和异常操作是什么样的 - 应该监视哪些队列和其他事物以及这些的正常范围是什么。
告诉我们如何管理数据——尤其是无限制增长的表和文件（例如日志文件和事务历史）。应如何清除这些内容以及删除旧条目的影响是什么？（关于报告等）。
告诉我们如何执行标准的“一切照旧”/生活中的管理操作 - 例如，这可能是添加或修改用户帐户。
告诉我们可能需要的任何其他常规管理操作（例如，使用了哪些证书以及它们到期时的处理方式）。
对于所有更改，请告诉我们如何回滚它们（并非所有更改都成功）。并告诉我们您已经测试了回滚计划！
诊断：记录日志文件格式和位置以及可能出现的每个应用程序错误消息，说明错误消息意味着什么出错了以及可能需要更改什么来修复它。切勿对两个不同的事件使用相同的错误消息。
关闭和启动：如何、什么顺序、任何特殊程序（例如，在关闭服务器之前让服务器耗尽连接）。
我强烈不同意这样做的最佳方法是将应用程序抛在一边，让 IT 人员解决需要什么。需要预先考虑操作文档（以及一般来说，应用程序的可管理性特性）。
我认为 IT 需要与开发人员沟通需要什么样的文档。实现这一目标的最佳方法是，开发人员提供解决方案的预发布版本（或迭代版本）供 IT 部门使用和测试，以便 IT 部门能够根据需要做出响应。