标题说这一切真的。
有时候最终会导致开发和IT处于这种状况。 当您希望安装，修补，维护，启动，停止和诊断在一台或多台服务器上运行的解决scheme时，您期望什么级别的文档？
所有这些东西都应该详细logging下来，但是当操作系统，应用程序服务器，Web服务器等标准操作时，您可能会假设IT操作人员知道如何执行此操作。
安装：logging有关如何安装和configuration的所有信息，包括如何判断它是否正常运行。
告诉我们这个架构，特别是关于各种解决scheme组件之间的通信（例如端口范围–RPC机制通常使用一系列的端口 – 我们需要知道范围是什么以及应用何时可能用完端口）。
修补：logging特定于应用程序的任何内容 – 在修补之前需要closures哪些内容以及修补后的任何后续操作（可能需要清除或重build的高速caching，索引，代理）。
维护：logging正常和exception操作的样子 – 应该监视什么队列和其他事情，以及这些是什么正常范围。
告诉我们如何pipe理数据 – 尤其是无限增长的表格和文件（例如日志文件和交易历史logging）。 这些应该如何清除，删除旧的条目有什么影响？ （关于报告等）。
告诉我们如何执行标准的“一切照旧”/生活中的pipe理行为 – 例如，这可能是添加或修改用户帐户。
告诉我们可能需要的其他定期pipe理措施（例如，哪些证书被使用以及何时到期）。
对于所有的改变，告诉我们如何回滚（不是所有的改变都是成功的）。 并告诉我们，你已经testing了回滚计划！
诊断：文档日志文件格式和位置以及可能出现的每个应用程序错误消息，说明错误消息意味着什么错误以及可能需要更改以解决该错误消息。 切勿为两个不同的事件使用相同的错误消息。
击落并启动：如何，以什么顺序，任何特殊的程序（例如让服务器在closures之前排除连接）。
我强烈地不同意这样做的最好方法是将应用程序放在围栏上，让IT人员弄清楚需要什么。 操作文档（一般来说，应用程序的可pipe理性）需要事先考虑。
后续的问题是：如果（如果）开发人员没有提供足够的文档，会发生什么？
我build议IT能够使用开发人员使用的任何缺陷跟踪系统来input针对软件的缺陷报告。 这样，如果他们没有告诉你，例如，一个特定文件夹中的文件需要被清除，只有一个星期的价值应该保留，你可以input一个缺陷，说“应用程序填充磁盘日志文件“，并build议他们使用文档化的技术来清理该文件夹。
我的文件要求清单将（不按任何特定的顺序）：
（文档:)
像这样的文档是很好的文档的例子：
我会认为这样的文档充满了失败：
FreeBSD手册也是一个很好的文档例子，也是OpenBSD的方法。 他们踢出的东西没有妥善logging。
编辑：这个清单是不完整的，它只是立即在我脑海中的基本东西 。 另外， 文档应该是可读的，而不仅仅是像某人抛出的东西 。
总之，我期望我指定和签约的文件。
这个关键的细节太多了，没有达成协议。 最终用户期望它，当然是免费的。 优秀的开发人员会尽早纠正这种疏漏，并设定包括价格和时间要求的期望值。
我相信IT需要与开发人员沟通需要什么样的文档。 最好的方法是如果开发提供了IT发布和testing的解决scheme的预发布版本（或迭代版本），那么IT部门可以根据需要进行响应。
用应用程序创build足够的发行说明将是一个好的开始。 如果发行版中的当前行为发生更改，则QA中关于依赖性或启动/停止行为的更改的任何注释，负载到相关服务器或数据库的更改等等。
@Spoike（我不能评论答案呢..）
IT实施者（angular色将因企业types和规模而异）必须始终如一地工作以实现以下目标：
安装/营业额最低要求 – 换句话说，IT不能被动，希望开发人员“知道”在安装/更换时需要什么信息。 我发现在IT方面经常存在相当混乱/不同意的是什么构成应用程序的正确文档。 开发人员了解需求（我们希望），IT部门必须小心，以便至less了解需求。
安装/更换stream程 – 在企业设置中，您可以将其称为“变更控制”或“治理”，但本质上这是一个标准的审查周期，其中IT部署在Dev PRIOR顶部安装中，以获得有关产品及其需求的简介。
安装应用程序与推出剧场作品不同。 开幕之夜（公众安装）之前，导演（主要开发者）与舞台制作团队（IT执行者）多次会面，确保一切都“如此”。
你不能改变开发人员的angular色（为什么你想？），但是你可以指出你的共同目标，即为所有用户快速运行一个梦幻般的应用程序。 您一致的IT文档要求只是确保这一点所需的一件事情。