1. 来源：
最近，给客户作了一次服务器更新。
随后一周，客户因操作失误，需要调查不当操作，因此得检查系统的Log文件，发现自从发布后，再也没有看到新生成的Log文件。
2. 分析过程：
2.1 第一时间，对Log文件的属性进行了调查。简单右键点击属性，将读取专用属性的Check栏取消，并确认。然后进行调试执行。发现没有任何实际变化。
2.2 问题再现：随后，在本地环境中测试，没有任何问题，Log顺利生成。开发环境中发布测试（开发环境内（同一台系统）测试），也没有问题。
2.3 再编译：再往后，将本地开发文档再次重新编译发布到测试环境，测试失败。
2.4 无解，休息。（一周后）
2.5 调查Log4net的版本，再次分析，Log没有生成的原因。本次代码因为用的是log4net通用DLL。版本一致。
2.6 发布方法：之前发布是直接在VS2012中编译，于是改用VS2012中的发布Tool进行发布，生成发布后的ZIP文件。结果不变，Log没有生成。
2.7 众人讨论：短时间，聚集几个一起工作的同事看，没有任何结论。
2.8 文件对比：发布成功的代码文件，和Log无法生成的代码文件对比，结论完全一样。在此基础上，测试结果仍然不变。之前成功的Log继续自动生成，后面的Log仍无法生成。
（此时，若冷静思考，可以推测出是文件属性的问题。遗憾的是，我忙于各种细节的对比，而忽略了整体的思考）
2.9 再讨论：从下午2点开始，到9点一直论证Log不出来的理由，然后在Manager闲聊。有什么遗漏的，属性检查撤退没有？文件遗漏没有？重新检查Log文件的各种属性，对比发布成功的Log文件夹属性。发现安全Tab下，IIS_IUSER管理权限没有变更权限。
修正後の属性 （IIS_IUSRS）
修正前の属性 （IIS_IUSRS）
结论，过早排除最有可能出错的地方。让后续工作全部进入盲区。Log文件属性，在排查的时候，若一开始就非常详细的进行对比，事后不至于费了2天的时间。
Log文件夹在过去并没有任何人进行修改，发布时，应作单独说明。原有的发布文档，只是特别提到，切勿删除Log文件及其子文件夹。给人主要是为保留服务器
中以往的操作信息的直观感受，而Log文件夹自身的属性并没提及。另外一点关键的是，以往IIS发布时，通常是局域网内，将www整个文件夹的属性改成共享可读可写，因此不用顾虑详细的IIS属性。
顺序渐进而不盲目。抓重点而细分析，赛过撒大网胡乱猜测。