上一次面试的时候，有个问题印象很深刻。

面试官问：如果让你接手负责公司的一个web项目，在你并不是十分透彻了解系统的前提下，运营人员反馈出来一个“页面加载过慢”的bug，如何快速定位问题？

我当时思考了一会儿，回答首先通过“Web开发工具”，确定网页加载慢的原因是来自于前端静态资源问题，还是后端数据接口；常见的，如果是运行了一段时间的系统突然发生加载过慢的问题，一般都是后台数据接口的问题。

然后，接下来确定具体加载过慢的数据接口，然后查接口的逻辑，是否存在外部依赖？是否存在数据库操作？是否存在文件操作？等等可能影响程序运营速度的关键点。

然后通过debug、打断点等方式最终确定问题。

当时这么回答，是基于我对“日志”这个神器不了解的前提。入职之后，还真遇到了一个类似的问题。运营人员反馈管理后台的某个页面数据加载过慢，在我确定具体问题接口之后，打开源码，是个巨复杂的逻辑处理接口...

于是我问了一下当时面试我的大神，有什么好的方式确定问题，得到的回答就三个字——“查日志”。

老实讲，除了算法等等可以对外“炫”的技术本领，系统日志的健全与否，真的很能显示一个程序员的职业素养与业务水平。公司的各种日志记得是真详细啊...日志中直接就显示了系统当前所存在的问题，是调的百度那边的一个接口挂掉了，很快的就联系相关的人员解决了。

以上，算是我和“日志”的第一次相遇。之后，我就想着要找时间好好把日志相关的内容整理下，让自己朝着“专业”的方向再迈进一步。

言归正传，回到今天我们所要思考的问题：

我们为什么要记日志呢？

“屁股决定脑袋”，在每一个项目的开发中，往往都会遇到“工期紧”的问题，对于开发人员来说，记日志，是一件比较琐碎小事，而且“日志写的好又不会加工资”...所以会常常少记甚至不记日志；而对于项目的运维人员或者使后续的接手人员来说，旧有项目的日志是否完善，是后续对维护成本很大的影响。

总的来讲，记日志这件事情，有来自如下几个方面的需求：

1. 追踪程序运行过程，快速定位问题

2. 记录分析运行数据，便于后续版本统计优化

3. 分析用户行为数据，便于做用户运营

4. 甚至有些时候，记录用户行为数据，是某些监管部门的要求

常见的，在我们的系统上线之后，一旦发生了问题，我们第一时间就需要知道“究竟发生了什么”，这时候，日志中记录的“用户操作、数据变化、环境异常”等等内容就是我们分析定位问题的第一手资料。

如果说，算法、数据结构等内容是一个程序员手中的剑的话，那么“日志”这种内容其实就相当于程序员手里的盾了，在日常开发工作中，除了要常解决遇到的问题，如何避免后续发生的问题也是需要重点思考的。