运维文档的几点看法
菜鸟运维问：昨晚就改个配置重启一下，怎么搞那么晚？
老鸟运维答：考虑方案半个小时，改配置1一分钟，写注释5分钟，写文档半个小时。
运维文档的作用，相信大家都非常重视。运维工作与开发工作相较缺少了一些创造性和灵活性，因此运维文档能够更准确的记录运维工作实施中的步骤，更稳定的将运维要注意的相关经验进行记录和传播。
可实际上，不管是开发人员还是运维人员，真正愿意写文档的运维人员非常少。往往到了重要运维人员要离职的时候，才发现原来什么文档都没有。就像是《凤凰项目 - 一个IT运维传奇故事》中的布伦特一样，他总是像救火员一样出现在问题处理的现场，可是他的经验却没有有效的记录和传播。
本文的目的在于希望各位读者读完后，能够圆满的回答下面三个问题：
- 我所运维管理的系统该有的文档都有了么？
- 我的运维文档中记录的操作都能正确执行么？
- 我的团队的人都知道有些运维文档么？
运维文档都有哪些
上面是在工作中整理的一份思维导图，将运维中可能用到的文档罗列出来，下面对几个比较重要的文档简要描述。
- 架构类的运维文档主要是帮助运维人员从逻辑架构、物理架构、数据库三方面了解系统的基本信息，文档的数量并不重要，这些文档可以合并成一个，重要在于文档内容准确、全面。文档中还要将系统各个组件的高可用机制、与周边系统的关系、系统的业务用户和业务范围等等信息。运维人员掌握了这类文档，对于系统的架构、用户、业务种类就会有一个概括的认识。
- 操作类。这是实际工作中最重要的一类文档，包括了维护手册、应用预案、常见问题处理手册，可能还包含有值班手册，也可以将相关内容放在维护手册中。维护手册侧重于介绍系统各个应用的详细信息，包括安装的路径、起停脚本（这个一定要有）、日志的路径、配置文件的路径，还应当包含日常值班过程中所应该做的检查和操作，对于常规的操作系统类的检查，还应当重点关注业务运行情况的检查，例如营业状态、业务成功率、业务量等（当然这些指标也需要系统的支持）。应急预案侧重于介绍应急处置措施和操作方法，包括应用起停、高可用切换的相关脚本和方法，预案编写应注重详实准确，并且要定期演练并维护。常见问题处理手册侧重于记录系统日常运维过程中常见的问题和解决方法，是一类经常更新的运维文档。
- 支持类。这属于背景类知识，可能不属于本系统运维人员产生，包括一些单位内部的操作系统规范、数据库规范、中间件规范等规范类文章。不要小看规范，没有规矩不成方圆，组织规模小的时候规范都在脑子里，组织成员增多之后，就必须形成明确的规范。
如何管理运维文档
通常来讲，我们的运维文档往往都会以本地文档、内部知识库系统或在线文档的形式进行维护，文档质量的好坏往往在关键时刻才能体现出来，例如人员离职发生工作交接时、发生故障需要紧急处理时，为了避免临阵慌乱，个人认为应当从以下三个方面改进：
- 明确文档的模板和编写标准。写作业有作文的讨论，写运维文档也有相关的套路和要求。因此在安排具体编写文档之前，我们必须明确文档的模板和编写标准。例如每次更新都要留下修订记录、需要提供目录、优先用表格而不是图表等等。只有这样才能避免写出来五花八门的运维文档，每人都有自己的风格，减少文档阅读者的成本。
- 明确文档维护的责任人。文档的维护责任必须落实到人，而且还需要经常的要求相关责任人按期更新，因为大家对于写文档总是有一些惰性。
- 定期进行文档的交叉审核与更新。周期可以安排在一个季度或双月进行文档的交叉审核和更新，原则上对于常见问题处理手册，应当是遇到问题后立即更新。如果有条件，还应当安排一些定期的桌面演练，在系统上实际操作验证文档的可用性。
