咨询:为客户组织站点/环境文档?[关闭]


12

随着时间的推移,我开始为各种客户提供咨询和合同工程工作。最近,客户要求提供某些类型的文档。

  • 我可以在安装新的网络时钟时使用哪些静态IP地址?
  • 如何在网络过滤器中添加排除项?CEO不能再访问NRA网站了!!
  • 我们需要关闭Linux服务器,以防计划中的断电。再次命令是什么?

这些是小型企业,通常没有专门的技术人员。在一个单一的公司,维基/合流/的Sharepoint等是行得通的,作为记录和环境信息的中央资料库,但找到一个一致的方法来提供这种信息,我挣扎离散的客户。

我要开发的过程比简单的电子表格或充满过时信息的可怕活页夹更可移植,安全和优雅。

  • 重要的IP地址,DHCP作用域等
  • 网络图(如果需要)。
  • 管理用户名和密码以及管理URL。
  • 软件许可证密钥。
  • 支持合同和保修信息。
  • 供应商支持联系方式和说明。

我知道这里还有其他顾问。关于以客户友好的格式在多个环境中维护文档的任何建议或技巧?如何做呢?

Answers:


12

自2004年6月以来,我一直是三人合同/咨询服务的合作伙伴。我们每个人都主要使用自己的“帐户”,但是我们需要相互维护文档以允许合作伙伴之间进行“故障转移”。我们的大多数客户都有某种内部IT员工,其中许多人需要执行一定数量的日常维护,我们也需要有效地与他们交流文档。

我的两个合伙人的优势(如果可以这样称呼)是在另一家公司担任我的员工,因此,他们俩都被灌输了我自以为是的做事方式。客户的配置之间的严格一致性(显然可以做到)是天赐的。显然,产品会发生变化,因此我们会讨论新产品/版本等,并在部署之前决定一致的配置策略。这不会扩展到大型公司,但是坦率地说,我认为这是功能而不是错误。(我不会再开始抱怨大型的“托管服务”公司及其员工“工程师”,以及一次过的,“半成品”的解决方案以及客户之间不一致的可怕趋势……>微笑<)

强烈反对“可怕的活页夹”。我从来没有见过实物资料不断更新不断。我认为花时间制作文档的物理副本浪费了客户的钱。我宁愿花时间研究如何基于正在运行的配置中的“实时”数据生成文档。

例如,我绝对不会维护IP地址信息电子表格。这就是DHCP和DNS的用途(有关详细信息,请参见下文)。如果这些事情不起作用,那么我们就会遇到重大问题。

我们已经让客户要求诸如“制作一个显示所有组策略配置的文档”之类的事情,而我却步履蹒跚,拒绝这样做。我反复提出的反建议(到目前为止是有效的)是向客户介绍管理工具,这些工具可以使他们“自助”或使用软件按需生成“实时的”客户友好文档。

我们非常努力地谨慎操作,以简单的英语拼写出来。非技术IT联系人可以例如查看计算机的Active Directory组成员身份,并查看“软件-安装Microsoft Office 2010 Pro”和“组策略-信息亭计算机自动登录”之类的内容。不需要任何文档即可解释这些含义。

这是我们使用的一些“实时”数据:

  • 所有 IP地址分配都存储在DHCP服务器中-这也包括静态寻址的设备(注释中已注明)。MAC和IP地址可以很容易地通过脚本或手动查询,并且根据定义,如果用于生产中,则数据必须是最新的。

  • 一切都会在DNS中获得名称和PTR记录。大多数主机还获得HINFO记录。需要冗长说明的事物会获得TXT记录。

  • 在任何可能的地方,都过度使用和“冗长”使用“注释”字段-Active Directory,计算机描述,共享文件夹描述等。对于安全组名称之类的内容,我们也非常冗长和清晰。

  • 网络设备配置中的注释/备注(例如,有关ACL的注释,端口说明,SNMP位置/联系信息)。

我对在文本文件,Wiki等中的格式自由存储信息的想法持否定态度。结构有助于良好的搜索。每当我可以使用结构化的存储机制为我工作时(即使这意味着我必须编写软件来查询它),我都会喜欢它。我可以从配置文件,数据库等中解析出的注释,在遇到几乎立即过期的手动生成的文档时,总会吸引我。

当我们必须存储“自由格式”信息时,我们使用我们自己的SVN存储库。它包含了我们多年来创建的由客户提交的所有各种静态文档。自2004年以来,我们一直在使用SVN,它作为我们的协作工具非常有效。我们对数据库架构,sysadmin脚本,组策略对象备份等进行版本控制。我尝试将所有可以检查的内容都放入版本控制中。

使用基于文件系统的索引工具搜索我的结帐非常容易。我知道我们每个人随时都有至少一个完整的存储库副本可供我们在本地使用。我们还使存储库可以通过SSL上经过身份验证的WebDAV进行访问,以防万一我们必须访问存储在其中的数据并且仅具有浏览器访问权限。

我们从未被要求这样做,但是我们很乐意在SVN服务器上创建一个帐户,以允许客户检出并与他们自己的文件进行交互(如果他们拥有如此倾向的内部资源) )。我们使用标准化的格式来存储所有静态的客户文档(软件许可文档,购买记录等),这很容易解释。

除SVN存储库外,我们还自托管电子邮件。自公司域开始接收电子邮件以来,所有传入/传出电子邮件均已存档。它可以作为BSMTP日志提供给合作伙伴以供参考(而且,就我个人而言,我认为它非常宝贵)。这种情况从未出现过,但是,我知道我们很乐意为客户提供与员工之间的往来邮件记录,如果他们有要求的话。在合作伙伴之间提供内部沟通会更加困难,因为我们很可能在同一封邮件中引用多个客户。(我们可能应该对此有所改善,但事实并非如此。)

密码是我们流程中的主要“陷阱”。我们为每个客户使用单独的“密码安全”存储库(具有唯一的组合),以允许与客户共享安全文件。我们将所有安全文件的主密码保存在另一个安全文件中,并且只有合作伙伴知道这些密码。这部分确实需要一些工作。我想我们希望每个客户都使用一个真正的多用户密码保险库应用程序(带有审计跟踪等)来托管一个现场凭证保险库,但是我们已经将这个想法付诸实践了近十年了。

我们的时间跟踪记录非常详细,并以他们想要的任何电子格式(到目前为止,已经是ASCII文本和PDF)提供给客户。客户获得每个收费事件的开始/停止时间,以及所执行工作的详细说明。我们认为这些服务说明在内部非常有价值,因为它们使我们能够跟上合作伙伴客户现场的最新情况。如果出现问题,这些记录将使我们了解这些年来我们遇到的所有以前的问题和解决方案。我不感到羞耻地说我已经通过找到我几年前忘记写给另一位客户的笔记而解决了一位客户的问题。


除了快速和谨慎外,还需要重新制作文档:在我的“老工作”(几年前为其他人工作)中,公司针对非付费客户提起了法律诉讼。我们最终陷入了来自非付费客户的反诉讼业务。我们的内部记录和电子邮件回复:该客户在法庭上受到传唤和骚扰。这段经历教会了我很多关于不将任何不想公开的东西存储在固定介质中的知识。

我写了一些电子邮件,其中包含一些(erm)选择单词和短语,以表达我对这位客户以及我公司中其他“工程师”的不满。我根本不喜欢在公开法庭上对这些事情进行盘问。

当我们开始目前的业务时,合作伙伴同意将所有固定记录(电子邮件,文本消息,语音邮件,SVN存储库中的文件,时间跟踪器中的工作记录等)始终视为“面向客户”,甚至如果它们从未打算最终落入客户之手。这很难做到,需要很多纪律,但我认为这是值得的。我们当然想向我们的客户投射一种敬业精神,而实践就是做到这一点。我一定再也不会像以前那样在法庭上感到尴尬了。


1
极好的答案。虽然我不是顾问,只为一家大公司工作,但我同意大多数情况。我要补充一点,填充诸如DNS,监视,p等之类的资产数据库也可能是一件好事,但不要在其中存储不使用的信息,否则它将过时并成为无用。
丹尼斯·考斯玛克

您使用哪种软件来生成这些实时报告?物理位置,故障转移图等如何处理?
史蒂夫·巴特勒

@SteveButler-当我腾出一点时间时,我将扩展您的要求以及解决问题的内容。我比以前更少了。>微笑<
Evan Anderson

2

对于您正在描述的核心信息(“网络图”除外),我们使用单个Excel工作簿,并将其保存到带有客户名称的网络文件夹中。尽管我能理解为什么人们不喜欢这种方法,但我发现它非常有用,因为它是一个参考文档,可以随身携带到网站中,通过电子邮件发送和快速更新。

我最大的抱怨是缺乏版本控制,但是我还没有找到任何可行的方法而又不费劲。

为了反驳“我正在为一个比简单的电子表格更便携,安全和优雅的过程而努力”:

更便携:什么比一个500千字节的电子表格更轻便?我不敢使用任何基于云或基于Web的内容,因为无法保证互联网连接。

安全:我会给您的,我也希望获得使我们的解决方案更安全的解决方案。

优雅:我们花了一些时间为工作簿创建一个不错的模板。就像我说的那样,这是一个多页工作簿,而不仅仅是分散的信息的巨大页面。我认为大多数IT文档都非常适合表格形式,而电子表格使这一过程变得非常整洁和简单。

尽管我在如何记录和存储构建文档方面存在很多问题,但在可靠,格式正确的电子表格中我确实找不到问题。我还要补充一点,我们与一些大型 IT服务公司合作,它们的工作方式几乎相同。再次,这是很棒的-我去现场,索取文档,并获得一个整洁的电子表格,可以在整个过程中使用。


2

这种可怕的粘合剂的最大优点是:

  • 非技术客户可以理解它们,将其保存在现场并确保其安全,就像他们已经习惯并已经处理所有其他重要文书工作一样。
  • 您的客户可以轻松地将其移交给他们,以备他们为您租用替代产品,要做的专业工作以及在您将其作为客户使用时为您提供的快速入门和参考。
  • 在每次站点访问要点的开头都有一个简单的维护日志,很明显。
  • 如果BSA或其他供应商来访,活页夹还保存CD / DVD以及带有许可证代码和激活密钥的证书。

不管您使用什么数字系统,只要您管教自己做了有价值的事情就可以更新资料夹,就不再重要了。

当然,如果您几乎远程地进行所有支持,活页夹对您完全没有用。

我一直很喜欢使用Wiki,因为它易于维护,可以轻松访问到ILO和管理界面的超链接,远程桌面和SSH登录。自由格式适合我想要的大多数信息:

  • 站点描述:“网络打印机(OKI 1234 MFP)是约翰办公桌旁的一台,型号0123的HP喷墨打印机位于鲍勃,老板的办公室里”,这使得接听电话变得非常容易:“我们已经墨水用完了,我们应该再次订购什么墨盒?”。

  • 每个设备的页面,理想情况下带有图片,类型和配置,用途等

  • 有一些不错的Wiki导出模块,可以为Wiki生成硬拷贝或数字文档,以进行移交并包含在该可怕的活页夹中


好点。我远离90%的客户,但经常出差。您是否建议我托管一个中央Wiki,而不是一个内部Wiki?
ewwhite

当您托管Wiki时,将其设置为同步到笔记本电脑变得容易得多,这在您经常旅行时似乎很谨慎。
HBruijn

0

我同意Dan认为Excel是一个很好的便携式解决方案,并且我认为他是一个很好的例子,但安全方面除外,我认为这种担心有些误导了:

无论采用哪种方法,都可以采用一种安全的解决方案(例如,加密的电子邮件,安全的共享存储等)。版本控制(例如卷影副本,svn等)也是如此。

但是,仅通过建设性批评并在所有方面尊重我,我想补充一下,共享Excel电子表格的主要缺点是其并发限制。当您有两名或以上的管理员时,他们会被迫在一次只能打开一个页面进行编辑,或者保存了多个副本然后需要合并(这是是最新的,哪个不是?)。这确实是一个痛苦。

更好的解决方案是使用Excel(或您希望使用的任何工具)作为所选小型数据库的前端,无论是Access(只是为了解决可移植性),MS SQL,MariaDB还是您喜欢的任何工具。

我主张将其作为一种解决方案,不仅适合于将信息传递给另一方(= Excel),而且还适合于维护正在进行的文档。

简而言之,我的观点是,即使只有几个管理员(更不用说大型商店),依靠Excel进行文档数据存储的部门还是一个庞大的文档部门。除非只有一名管理员,否则从未见过例外。

但是,使用数据库驱动的存储的部门有机会保留紧密而最新的文档。那么这只是一个努力的问题。Excel是具有优点和缺点的可行的数据库前端,但绝不是唯一的选择。


回想一下,这是针对具有多个客户的咨询情况。不会有任何并发​​问题。
ewwhite

0

这可能不是您要找的东西,但这是我的工作。

我使用Microsoft Office为每个客户创建所有文档。我使用Excel(IP地址信息,交换机端口映射,机架布局),Word(配置信息,发票,SOW模板)和Visio(图表)。我创建一个文件夹层次结构,其中父文件夹名为Consulting,子文件夹命名为每个客户端。创建或更新客户端文档时,我将它们同步到iPhone(使用Documents To Go),USB拇指驱动器和DropBox帐户(使用两因素身份验证)。这样,我可以在任何地方,任何地方访问所有文档(一种或另一种)。

我还使用了名为OfficeTime的项目管理/报告/发票/时间跟踪应用程序。有一个iPhone应用程序和一个配套的Windows应用程序,所以当我在网站上时,我可以在iPhone上访问项目信息,发票,工作时间等,到家后可以同步到桌面。


0

虽然这不是一个完美的解决方案,但是您应该看看Device42

您可以执行以下操作:IP和设备可以与客户关联。而且,您可以具有VRF组,以在各个客户之间重叠IP范围。

它没有对IP /设备的精细权限(仅基于全局角色的访问),因此您不能允许最终客户直接访问。但是您可以为每个客户创建带有设备和IP信息的报告,并在需要时将其发送给最终客户端。

这至少将为您提供一个界面,用于组织中央存储库中的所有信息。您可以存储资产信息,IP信息,合同信息和密码。

它还在REST API调用中提供了大多数信息,但不确定是否可以基于此为单个客户提供信息。


这不太合适,但是对于大型环境来说是一个有趣的资产管理平台。
ewwhite

1
同意,而不是根据您的需求的完美契合。我向他们提出了一项功能要求,以增加基于客户的基于角色的访问权限。云服务提供商可以跟踪所有客户设备和IP地址,这对我们来说非常有效,但是我们也希望为客户提供门户访问权限,以便他们可以自己访问其信息。
Sonu Bansal
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.