企业官网建设流程全解析

最近开始准备投递实习简历了，所以需要对简历中的所有内容都进行一次拆解。

很早之前就听说过简历中的STAR 法则，但是一直没有完全搞懂，也没有真正用起来。这次我打算把 STAR 法则拆解一下，并结合我个人简历中的一个内容，举例说明它应该如何使用。

STAR = Situation + Task + Action + Result

Situation：背景

这一部分往往是最容易被大家忽略的地方。

在向 HR 或面试官介绍自己的工作内容时，如果忽略了工作背景，对方往往不能立刻意识到这项工作的重要性。因此，介绍工作背景，本质上是在给自己的工作内容“铺垫价值”，让 HR 能够快速理解：为什么这件事值得做、为什么它重要。

例如：

在实习期间，下游团队发现我们团队负责的表出现了任务延时的情况，导致下游表无法及时产出。

这里通过说明“出现生产问题”，解释了这项优化工作的必要性，也让后续内容更有说服力。

Task：任务

这一部分需要解释清楚：我们需要完成什么工作。

例如：

我们团队针对这个问题，需要对产出任务进行优化，从而达到规定的 SLA 要求。

Action：行动

这一部分需要体现我们解决问题的思路，而且最好是循序渐进、有层次地表达出来。

针对任务延时问题，可以从以下几个方向进行排查：

分支 1：检查代码历史发布日志

首先对代码历史发布日志进行检查，确认是否有人修改过代码。

如果发生了修改，就进一步查看修改内容是否会影响任务执行，例如是否新增了复杂逻辑、是否改变了 join 方式、是否引入了额外的数据扫描等。

分支 2：对比任务运行日志

查看当前任务运行日志和历史正常日志之间的区别。

如果发现大部分 job 都出现了任务延时，可以从以下角度排查：

• 是否是资源不足导致并行度不够，例如查看 task 之间的启动时间是否相差很大。
• 是否是数据膨胀导致 task 处理数据量过大，例如查看 task 的数据输入量是否明显增加。

如果只有少部分 job 出现任务延时，可以从数据倾斜的角度排查：

• 查看部分 task 的数据输入量是否显著大于其他 task。

需要注意的是，在回答时可以尽量把排查分支都走一遍，这样能够体现自己的思考过程。

但是最后一定要落地到具体问题上。比如最终选择的是分支 2 中的数据倾斜问题，那么可以这样描述：

最后发现主表中出现了大量 NULL 值，导致部分 task 数据量明显偏大。针对这个问题，我通过加盐的方式进行二次聚合处理，从而缓解了数据倾斜。

Result：结果

这一部分可以说明这件事最终产生的效果，也可以补充自己从中获得的成长。

例如：

通过对任务的优化，成功让任务在规定的 SLA 内完成，并且在之后都没有再次触发报警。

可选补充：

通过这件事情，我也更加清晰地掌握了当日常任务变慢时，应该如何进行系统性的任务排查。

总结

STAR 法则并不是简单地把经历拆成四段，而是帮助我们把一件“做过的事”，讲成一段“有背景、有目标、有过程、有结果”的完整经历。

尤其是在简历和面试中，很多时候我们不是没有做过事情，而是没有把事情的价值表达出来。使用 STAR 法则后，同样是“优化了一个任务”，表达效果就会从：

我优化了一个 Hive 任务。

变成：

在下游表产出延迟、影响业务使用的背景下，我负责对任务进行性能排查和优化。通过分析发布记录、运行日志和 task 输入数据量，定位到主表 NULL 值过多导致的数据倾斜问题，并使用加盐和二次聚合进行处理，最终让任务恢复到 SLA 要求内，后续也没有再次触发报警。

这样一来，经历就不只是“我做了什么”，而是变成了“我如何发现问题、分析问题、解决问题，并产生了什么结果”。