我的任务是研究 NoSQL（在这种情况下可能是Neo4J) 并且SQL-Server可能是解决我们一直遇到的性能问题的解决方案。
我的技术分析的一部分是平台的可维护性和稳定性。
这意味着我需要找到一种方法来正确记录和维护很少使用的应用程序（NoSQL），并将其与我们有特定和严格指导方针的应用程序（SQL-Server）结合起来。
我主要担心的是，当我回顾过去完成的类似设置时，一次性应用往往会陷入黑盒子尽管最初是在内部创建的，但这种情况仍然会发生。
那些不是内部创建black boxes的往往落在一个不幸的人的肩上，他最终会花费大部分工作时间来维护和处理一些访问数据库 过时的技术没人愿意触碰它，而且它显然对任务至关重要。
作为负责此平台设置和文档编制的幸运系统管理员，您如何确保您的庞然大物 很棒的设置经得起时间的考验吗？
人们通常如何处理大型公司中一次性的小型申请，并且希望不会将自己的名字永久地束缚在申请上？
答案1
我的第一个基本组成部分是制定灾难恢复计划很棒的设置即从头开始重建并从上次备份中恢复其数据的分步方法。这包括所需组件的列表及其获取位置、完整配置以及从上次备份中完全恢复应用程序数据的过程。写作和测试这样的计划将揭示操作概念中的许多最明显的漏洞，例如应该包含在备份中但实际上并未包含的数据、被遗忘的依赖关系或没人知道其来源的软件。
第二个基本组成部分是操作手册，涵盖正常运行期间发生的任务。这需要已测试最好让一名不熟悉很棒的设置按照该手册运行一段时间，并由常规管理员在后台做笔记，以应对紧急情况。
如果很棒的设置是任务关键型的，那么其灾难恢复计划当然会包含在您的 ISMS 要求的定期应急演习中。常规管理员的年假是重新测试操作手册的自然机会。因此，两者都会定期验证是否是最新的。
当然，如果你没有成功获得很棒的设置首先被归类为任务关键型。
答案2
一般来说，我将文档分为不同的阶段。第一阶段是开发，按时间顺序记录创建应用程序的所有步骤。我先写一份明确的使命陈述，然后列出一份需求清单。开发的每个步骤完成后都会添加进去。我发现录制会议的视频可以很好地帮助回忆。我个人使用票务系统（在我的情况下是 RT）来完成文档的这个阶段。
第二阶段是在应用程序测试和发布之后。在这里我记录安装（所需的软件、软件包、环境）。重新创建应用程序所需的一切。最后一个阶段是记录维护程序。只有那些特别复杂的程序才会被记录下来。
最后，我在 wiki 上发布了第二阶段也是最后一阶段。这看起来似乎很繁重，但当记录成为日常工作的一部分时，你实际上就不再注意到它了。当然，与开发挂钩的可能性也大大降低了。
希望这对您有帮助。