昨天请一个刚工作的同事评价一下某个开发团队的素质,他说很不错,用了很多先进的技术……,我意识到我没有教过他如何判断一个开发团队基本素质。

准确全面地衡量一个开发团队的素质要看很多方面,团队文化、个人能力、各种标准和方法论、是否有够多的技术储备和经验积累等等。但如果5分钟内要做一个大致的判断,可以试试看问技术负责人一个问题:你如何做日志。

最业余的家伙意识不到日志对系统维护的作用,因而在正常运行时不记录日志,仅在debug时打开,那么他的系统是很难维护的,在出现系统故障时无法得到足够的信息去定位问题。

其他一些常见问题还有:

1.日志无法反映处理过程进行到哪一步。需要高可靠性、高可维护性的系统,每个模块或处理环节应在处理过程进入本环节时、本环节完成处理时、本环节提交到下一环节时记录日志,并有足够的信息区分出是哪一笔交易,以便故障时分析问题出在哪一步。

2.日志没有清理机制。运行一段时间后磁盘空间满了,系统宕机。

3.同步方式向数据库里写大量日志。通常的数据库用来写日志效率很低很低,会大量消耗数据库性能和空间,另外数据库故障就写不了日志。

4.没有汇聚机制。假设应用服务器是一个30台机器的集群,现在怀疑昨天9点5分有一笔交易有问题,你需要去30台机器上一一找日志文件去。

5.日志切割策略不实用。比如,每100M切割一个日志文件,还是那个问题,现在怀疑昨天9点5分有一笔交易有问题,碰巧现在你又在外面用×××上的公司网络,你就在那100M的文件里慢慢找吧。如果日志产生速度比较快,每小时产生一个文件名中包含时间的日志文件会方便得多。

6.不能提供足够的信息与接口系统核对交易。例如:A系统调用B系统完成积分扣减。AB系统在日志中应分别记录每笔交易中自己和对方的交易流水号,以便核对。同时,一些关键的调用应该定期(比如每天)核对双方的交易记录,确保双方记录一致。

7.没有方便的日志查看工具。大系统大团队的分工是比较细的,不能要求值班接报障碍、监控系统的人去深刻理解系统的运行机制并开发一个搜集、拼接、展现日志信息的工具,如果你的开发人员不希望整天参与问题分析和障碍处理,最好提供一个方便的日志查看工具。

好了,差不多今天想到的就这些了,在现在这样一个三四流开发团队横行的时代,能找到一个有意识避免上面7个问题或其中大部分的开发团队,是一件非常值得庆祝的事情。