背景：秋招了，昨天经历了第一场面试，明明感觉自己准备的挺不错的，但是一面试就紧张，紧张了就脑袋空空，表达稀碎，毫无逻辑。面完就知道凉透了。
反思：平时不仅要看八股，还要多动动嘴皮子，按照star法则来组织语言，溜嘴皮。
star法则
- s代表情景，也就是你的业务背景
- t代表目标，也就是你要实现的目标，
- a代表行动，为了实现这个目标你做了什么
- r代表result结果，说明你完成这件事情以后取得了什么成果
运用的注意事项
- 介绍目标的时候，要着重讲我们的背后的价值是什么
- 介绍行动的时候，要着重讲难点是什么
- 介绍结果的时候，要 体现你给公司带来的正向价值和收益是什么，你的心得是什么，经验是不是可复制的。
运用示例
简单说说日志清理这个部分
这个需求的背景是这样的，物联网设备对接有设备直连和云云对接两种方式，云云对接指的是物联网设备，比如海康的门禁，已经连了海康的系统，但是园区希望将他纳入我们自己的物联网平台，那么就要通过和海康的系统来对接，我们去连接他们的mq，做他们的mq消费者，来同步信息。或者说他们推送过来。在这个过程中，要记录推送的记录，方便做到排查还有统计。北向面向应用也是这样的，我们中台要定期向北向的应用去推送消息。也要记录下来 （业务背景）
推送是很频繁的，比如五分钟就要同步一次信息，这个时候我们的日志表就会快速增长，到我要清理的时候，就已经有10个亿的数据，每个月大概会产生一个月的数据，要做表清理的时候已经是查询都会报错了。日志表也占了整一个磁盘空间的80%。 （问题背景）
现在目标就是要找到一个合理的解决方案，确保功能的运行同时，解决掉大表的问题。大量减少空间开销。 （目标）
- 首先我们是明确了这个业务的需求，就是日志到底是不是需要的，系统中日志的主要作用就是记录和运维，主要是运维的。我们详细讨论以后觉得这些日志数据只要保留一部分就行了，所以定下的策略就是保留15天内的数据。这里的难点是如何确定删掉这些数据不会影响运维。这个系统是一直有人用的，所以当出现问题的时候，两周内可以有人修复，这个是没问题的
- 明确了业务需求以后，就做方案了。首先是先解决大表问题，为了尽可能地减少影响，先手动将旧表改了名字，然后先让数据切到新表当中去。后面再设定一个定时任务删掉旧表
- 对新表，为了检索的需要（快速找到哪一天的记录）对数据做了一个分区的设定，可以建索引，但是价值没有这么高，按照时间这个字段来分区 （行动）
最后的结果是，顺利将大表问题清理掉，新表的检索效率也能兼顾（没有建索引），减少了大量的空间开销。 （收益结果）
临时想的一个例子，收益部分讲的还不是很完善，后面再加工一下。
