聊聊程序员最头痛的问题：如何写一篇好看又易读的文章（续）

在 上一篇博客，我介绍了文章总体结构的布局方式应该遵循金字塔结构，才能做到重点突出、易懂易记。有些朋友说，不要光讲原则，讲讲具体的金字塔结构怎么搭嘛。

这年头，还是干货值钱。下面，我将以一个真实的例子，来讲解如何应用金字塔结构组织文章。

这篇文章来源于我部门的某位同事，他应客户的要求，写一份系统故障原因分析。客户对这次系统故障很不高兴，开始的时候，认为是我们负责的部分出现了问题，后来经技术调查，发现跟我们无关，因此需要写一份报告，给客户做出解释。很明显，客户不太懂技术，文件要写得尽量易懂，而且要考虑到，客户会将报告发送给他的领导或对此不太了解的其他同事，为了让他们也能认同我们的分析结论，更需要做到文章结构清晰，让读者有兴趣阅读，并很快抓住重点。

这种报告是典型的可利用金字塔结构进行组织的文章，可惜我这名同事没有注意到这一点。 

我同事的文章是这样写的，为了减少篇幅，只是将大概的意思表述。

 

标题：XX系统的故障分析

1.现象

XX系统出现短时间无法访问的现象，故障现象如下：

（省略拨测系统图表说明） 

2.分析

  通过拨测结果，可以看到错误的原因是连接失败，和拨测公司的工程师沟通，如果是应用出现错误，返回错误页面的情况，会在拨测结果里详细说明错误类型，例如500应用程序错误或404该页无法找到。如果出现连接失败，那么可能有几种情况，目标应用服务器出现宕机或者WEB服务不可用或者目标应用服务器和拨测服务器之间的网络通讯出现问题。

  通过检查应用服务器，没有出现在那些时段出现宕机。

  通过检查系统WEB访问日志，通过访问日志的时间的连续性进一步确认，拨测出现问题的时段没有出现WEB服务不可用。 

3.进一步分析

 和拨测公司工程师沟通，确认拨测服务器的IP为X.X.X.X。

 挑出了拨测服务器的IP的访问记录进行进一步分析，发现了如下情况，在拨测出现问题的时侯我们接受到了拨测服务器的访问请求并且正常处理，但是在返回数据的时候无法和拨测服务器进行网络通讯。

 这里我们截取一段日志来做个说明，

  (省略日志说明)

（省略了根据日志进一步分析，得出了当时我方负责的系统并没有问题的结论的描述） 

4.结论

  通过上述分析，在故障发生时，我方负责的系统运行正常，故障应该是由于网络连接的短时间中断引起的，建议客户单位检查网络原因。

 

  这篇文章是循序渐进的叙述方式，反映了作者作为技术工程师，分析问题和解决问题的过程。如果该文章的读者想从中学习此类问题的解决思路，这样写是没有问题的，但对于客户而言，他却没有这种耐心跟着你的思路来阅读，文章得顺着读者的思路来组织，才能更有效地引起共鸣，从而被读者接受。

  于是，我用金字塔结构原理，帮同事修改了文章。大概的表达思路如下。

 

标题：XX系统的故障分析

一、背景

讲述了我司负责的系统在整个客户系统中的位置，为了保障该系统的不中断运行，我司采取周全的监测体系，该体系发挥了很严密的监控效果，但最近发生了XX问题，我司提供了本篇报告，对故障进行分析。

二、分析结论

直接说明该问题不是我司负责的系统引起的，我司系统运行正常，应该是网络连接短时间中断引起的。有以下分析依据支持。 

2.1 拨测系统没有捕捉到我方系统的错误

此段内容是原文2.分析的内容。 

2.2 我方系统日志证明故障发生时服务没有中断

此段内容是原文3.进一步分析的内容。 

三、总结

此段内容是原文4.结论的内容。

 

这样的改动在内容上并无大的修改，但是着重做了以下调整：

1.增加了背景一节

金字塔结构的文章里需要特别注意背景一节。读者的认知过程往往是从接受自己已知的事实开始的，因此，背景一节里应先铺垫容易被人接受的事实，然后引出矛盾或问题，读者自然就会问：为什么会这样?是什么原因引起的？ 现在，是时候由第二节抛出你的观点了，这使得读者很清晰地记住你的结论。当然，读者肯定会接着问：为什么你做出这样的结论？带着这个问题，读者接着阅读第二节。

2.以归纳的方式支持你的论点

 第二节以两段论来支持你提出的结论。这两段的子观点之间的关系是归纳式的，相互独立，同样的主谓句式，说明的是有共性的结论，读者会觉得文章的思路很清晰，更快地理解你的结论。

 

从上面的例子可以看出，应用金字塔结构写公文并不难，只要作者在写作前，先将思路放进金字塔结构里，做到上一层文字是下一层文字的概括，下一层文字分组归类地对上一层观点进行支持，并辅以承接的语句，让读者的思路在不断地提出问题、得到答案的过程中完成阅读，文章就达到了好看、易懂的水平了。