随着时间的推移，我已经为不同的客户提供咨询和承包工程。 最近，客户正在寻求某些types的文档。
这些都是小企业，通常没有专门的技术人员。 在一家公司内部，Wiki / Confluence / Sharepoint等都是有用的，可以作为文档和环境信息的中央资源库，但是我很难find一种一致的方法将这些信息提供给离散的客户。
我正在拍摄一个比简单的电子表格或充满过时的信息的可怕的活页夹更便携，更安全，更优雅的过程。
我知道这里还有其他的顾问。 关于以多种环境以客户友好格式维护文档的任何build议或提示？ 你怎么做到的？
自2004年6月以来，我一直是三人合同/咨询服务的合伙人。我们每个人都主要负责自己的“账户”，但是我们需要为彼此保留文档以允许合作伙伴之间的“故障转移”。 我们的大部分客户都有一些内部的IT人员，其中许多人执行一些日常维护，我们也需要向他们有效地传达文档。
我的两个合伙人有优势（如果你可以这样称呼的话）是在另一家公司工作的我下属的员工，结果，他们都被灌输了我以自己的方式做事。 客户configuration之间严格的一致性（显然可以）是天赐之物。 很明显，产品会发生变化，因此我们会讨论新产品/版本等，并在部署前决定一致的configuration策略。 这不会扩展到一个大公司，但坦率地说，我认为这是一个function，而不是一个错误。 （我不会开始用他们的员工“工程师”和可怕的倾向来一蹴而就，一半的“解决scheme”，以及客户之间的不一致性。
我猛烈地反对“可怕的活页夹”。 我从来没有见过有形的文件保持最新。 我认为浪费客户的钱花费时间来制作文件的实际副本。 我宁愿花时间研究如何根据运行configuration中的“实时”数据生成文档。
举个例子，我绝对不会维护IP地址信息的电子表格。 这就是DHCP和DNS（请参阅下面的细节）。 如果这些东西不起作用，那么我们就有重大问题。
我们已经有客户要求诸如“制作一份显示我们所有组策略configuration的文档”，而且我已经挖掘出了自己的力量，拒绝这样做。 我反复提出的反提案（迄今为止的工作）一直是向客户介绍可以使他们“自助”或使用软件按需生成“现场”客户友好文档的pipe理工具。
我们很难用简单的英文来拼写。 例如，非技术性的IT联系人可以查看计算机的Active Directory组成员资格，并查看“软件 – 安装Microsoft Office 2010 Pro”和“组策略 – 自助服务terminal计算机自动login”等内容。 它不需要任何文件来解释这些意思。
以下是我们使用的一些“实时”数据：
所有分配的IP地址都存储在DHCP服务器中，这也包括静态寻址的设备（在注释中注明）。 MAC和IP地址可以通过脚本或手动查询，根据定义，如果数据在生产中使用，则数据必须是最新的。
一切都在DNS中获得一个名称和PTRlogging。 大多数主机也得到一个HINFOlogging。 需要详细描述的事情得到一个TXTlogging。
在任何可能的地方都可以使用“注释”字段 – 活动目录，计算机描述，共享文件夹描述等等。我们也使用诸如安全组名称之类的冗长而清晰的方式。
networking设备configuration中的注释/注释（例如ACL上的注释，端口描述，SNMP位置/联系信息）。
我对文本文件，维基等东西的自由forms的信息存储的想法相当消极。结构使得search更好。 每当我可以得到一个结构化的存储机制为我工作（即使这意味着我必须编写软件来查询它），我更喜欢它。 我可以从configuration文件，数据库等中parsing出来的注释总是让我胜过手动生成的文档，这些文档几乎立即就会过时。
当我们必须存储“自由格式”信息时，我们使用自己的SVN信息库。 它包含了我们多年来创build的由客户提交的各种各样的静态文档。 自2004年以来，我们一直在使用SVN，作为我们的协作工具，它已经非常成功。 我们版本数据库模式，系统pipe理员脚本，组策略对象备份等。我尝试检查我可以进入版本控制的一切。
使用基于文件系统的索引工具search我的结帐非常容易。 我知道我们每个人在任何时候都至less有一个本地存储库的完整副本。 我们还通过SSLauthentication的WebDAV使存储库可访问，以防万一我们必须获取存储在那里的数据并且只能浏览器访问。
我们从来没有被要求这样做，但我们很乐意在SVN服务器上创build一个帐户，以允许客户退出并与他们自己的文件进行交互（如果他们有一个如此倾斜的内部资源）。 我们使用标准化的格式来存储所有静态的客户文档（软件许可文档，购买logging等），这是非常明显的。
与SVN仓库一起，我们还自行托pipe我们的电子邮件。 所有传入/传出的电子邮件已被存档，因为该公司的域名开始接收电子邮件。 这是BSMTP提供的日志给合作伙伴参考（和个人，我发现它是无价的）。 这种情况从来没有出现过，但是我知道，如果有问题的话，我们很乐意让客户访问与员工通信的日志。 提供合作伙伴之间的内部沟通会更加困难，因为我们可能会在同一条消息中引用多个客户。 （我们可能应该做得更好，但是我们没有。）
密码在我们的过程中是一个重大的“疣”。 我们为每个客户使用单独的“密码安全”存储库（具有独特的组合），以允许将安全文件与客户共享。 我们将所有安全文件的主密码保存在另一个安全文件中，只有合作伙伴才知道这个密码。 这部分确实需要一些工作。 我想我们希望每个客户使用一个真正的多用户密码电子仓库应用程序（带有审计跟踪等）来托pipe一个现场凭证保险库，但是我们已经在海滩上将这个想法踢了近10年。
我们的时间跟踪logging是非常详细的，并以任何他们想要的电子格式（到目前为止，已经是ASCII文本和PDF格式）提供给客户。 客户可以在每个计费事件上获得开始/停止时间，并可以详细描述所执行的工作。 我们认为这些服务笔记在内部非常有价值，因为它们使我们能够及时了解合作伙伴客户网站的情况。 在发生问题时，这些logging为我们提供了以往所有问题和解决scheme的知识基础。 我不惭愧地说我已经解决了一个客户的问题，find了几年前我忘记为另一个客户写的笔记。
一个快速和谨慎的撇开：生产文件：在我的“老工作”（多年前为其他人工作），公司对非付费客户采取法律行动。 我们最终处于非付费客户的反诉讼的业务终点。 我们的内部logging和电子邮件是：客户在法庭上被传唤和揭发。 这个经历告诉了我很多关于不把任何东西存储在一个你不想公开的固定媒体上的事情。
我写了一些电子邮件，其中包含一些（erm） select词汇和短语，关于我对这个客户和我公司的其他一些“工程师”的挫折。 不得不在公开场合对这些事情进行盘问，这并不是我喜欢的。
当我们开始当前的业务时，合作伙伴一致认为， 所有固定logging（电子邮件，短信，语音邮件，SVN信息库中的文件，时间跟踪器中的工作logging等）都将被视为“面向客户”如果他们从来没有打算结束在客户的手中。 这很难做，需要很多纪律，但我认为这是值得的。 我们当然希望为我们的客户提供一个专业的空间，而生活就是这样做的方式。 我当然不会再像我在法庭那样尴尬了。
对于您所描述的核心信息（除Network Diagram外），我们使用一个Excel工作簿，并将其保存到具有客户名称的networking文件夹中。 虽然我可以理解为什么人们不喜欢这种方法，但我发现它很好用，因为它是一个单独的参考文档，我可以带我到现场，发送电子邮件并快速更新。
我最大的抱怨就是缺乏版本控制，但是我还没有find任何可以很好地工作的方法。
为了对付你的“我正在拍摄一个比简单的电子表格更加便携，安全和优雅的stream程：
更便携：什么可以比500千字节的电子表格更便携？ 我会害怕使用任何云或networking，因为互联网连接不能得到保证。
安全：这一个我会给你，我也想解决scheme，使我们的解决scheme更安全。
优雅：我们花时间为我们的工作簿创build了一个很好的模板。 就像我说的，这是一个多页的工作簿，不只是一个分散的信息巨大的页面。 我认为大多数IT文档很好地适用于表格forms，而电子表格使得它非常简洁。
虽然我有很多关于如何logging和存储构build文档的问题，但是我确实无法find一个结实的，格式正确的电子表格。 我还要补充一点，我们和一些大的 IT服务公司合作，他们的工作方式也是一样的。 再次，这是辉煌的 – 我转向网站，请求文件，并得到一个整齐的电子表格，我可以使用的持续时间。
这个可怕的绑定的最大好处是：
无论您使用的是什么数字系统，只要您自行更新活页夹，只要您已经做了一些有价值的事情，就不用多久了。
而且，如果远程执行几乎所有的支持，活页夹当然是完全没用的。
我一直很喜欢使用wiki，因为它很容易维护，超链接到ILO和pipe理界面，远程桌面和SSHlogin很容易遵循。 自由forms适合我想要的大部分信息：
网站描述：“networking打印机（OKI 1234 MFP）是John桌子旁边的一台，HP喷墨打印机型号0123位于Bobs，老板的办公室”使得接听电话变得更容易：“我们已经墨水用尽了，我们应该再次订购什么墨盒？“
每个设备的页面，理想的图片，types和configuration，它的目的等。
有一些相当不错的出口模块可以让Wiki生成硬拷贝或数字文件，用于切换和包含在可怕的资料夹中
我同意Excel上的Dan是一个很好的，便携式的解决scheme，我认为他是一个很好的例子，除了安全部分，我认为担心有些误导：
无论希望分发哪种方法，都可以使用安全的解决scheme（例如encryption电子邮件，安全共享存储等）。 版本控制也是如此（例如Shadow Copy，svn等）。
然而，仅仅通过build设性的批评和所有的尊重，我会补充说，共享Excel电子表格的一个主要缺点是它的并发限制。 当你有两个或两个以上的pipe理员时，他们会发现，在一次只能打开一张表格进行编辑或者保存了多份副本之间被迫进行select是非常痛苦的，这些副本随后需要合并（哪些数据是最新的，而不是？）。 这真的是一个痛苦。
一个更好的解决scheme是使用Excel（或任何你想要的）作为前端的一个小型数据库的select，无论是访问（只是为了解决可移植性），MS SQL，MariaDB或任何你喜欢的。
我主张这个解决scheme不仅适用于将信息传递给另一方（= Excel），而且还适用于维护正在进行的文档工作。
我的意思是，即使只有几个pipe理员（更不用说更大的商店），依靠Excel进行文档数据存储的部门也是一个庞大的文档部门。 从来没有看到一个例外，除非只有一个pipe理员。
但是使用数据库驱动存储的部门有机会保持紧密的，最新的文档。 那只是一个努力的问题。 一个Excel是一个可行的数据库前端利弊，但决不是唯一的select。
这可能不是你想要的，但是这是我所做的。
我使用Microsoft Office为每个客户创build所有文档。 我使用Excel（IP地址信息，交换机端口映射，机架布局），Word（configuration信息，发票，SOW模板）和Visio（图表）。 我创build了一个名为Consulting的父文件夹和一个为每个客户端命名的子文件夹的文件夹层次结构。 在创build或更新客户端文档时，我将它们同步到我的iPhone（使用Documents To Go ），USB拇指驱动器和DropBox帐户（使用双因素身份validation）。 这样，我可以随时随地访问所有文档（无论是哪种方式）。
我还使用了一个名为OfficeTime的项目pipe理/报告/发票/时间跟踪应用程序。 有一个iPhone应用程序和一个伴随的Windows应用程序，所以我可以访问项目信息，发票，小时等，当我在我的网站上，当我回家时同步到我的桌面。
虽然这不是一个完美的解决scheme，但你应该看看Device42 。
以下是您可以做的事情：可以将IP和设备关联到客户。 而且你可以有不同客户的IP范围重叠的VRF组。
它没有针对IP /设备（仅基于全局angular色的访问）的精细许可，因此您不能允许最终客户直接访问。 但是，您可以使用设备和IP信息为每个客户创build报告，并在需要时将其发送给最终客户端。
这至less会给你一个界面来组织中央仓库中的所有信息。 您可以存储资产信息，IP信息，合同信息和密码。
此外，它提供了REST API调用中的大部分信息，但不确定是否可以根据这些信息为各个客户build立连接。