第19章 述职评审2
随后当她说出"；通过库存动态平衡抓手提升周转率"；时，陈默微微点头。
20分钟后，随着PPT翻到最后一页。
“...随着这次的优化，我主导的智能切换方案将故障恢复时间从8分钟压缩到37秒。”
“各位评审，我已述职完毕。” 胡笳讲完后站定。
“你设计的智能补货算法在试点仓库降低30%库存，但导致华南区三次缺货。你解释算法缺陷及改进思路。” 陈默开口问道。
这里主要考察胡笳对算法设计的容错能力以及业务与技术平衡意识。
他也知道这是胡笳的强项，故意问出这个问题是想让她展示一下自己。
果然，对面的胡笳立马回答道：“原算法过度依赖历史销量数据，忽略了两个变量：一是私域渠道导致的脉冲式订单，二是极端天气对物流的影响因子，三是友商新品发布造成的需求转移。”
她侃侃而谈，“新版本引入LSTM神经网络，动态权重分配从0.3提升到...”
说完后便不再出声。
"；你的容灾方案依赖华兴云Stack 6.5的API，如果只能用阿里云架构怎么办？"； 朱总问道。
陈默有点不高兴，皱了皱眉，瞥了一眼朱然。
胡笳是应用支持，工作中也是负责应用系统，这种底层系统架构的问题显然是有点偏了。
刚准备开口就看见胡笳给了他一个眼色，随即就不再说话，神在在的坐在那里。
胡笳重新打开测试环境，调出未公开的兼容层代码。
回复道："；朱总，已在沙箱环境对接阿里云API，但涉及友商专利..."；
朱总点点头。
"；你的算法需要多少GPU算力？中小客户用得起？"； 系统架构师王辉问道。
王辉没等胡笳的答案，反倒是听见陈默淡淡的声音在耳边响起。
“她的这套新算法仅使用在内部ERP里，和客户没关系。王工是不是有点累了？”
他赶忙道歉，“不好意思陈总，我没注意。那我没别的问题了。”
陈默转头看向朱总，朱总摇头表示自己也没有别的问题了。
“那就休息5分钟。” 陈默开口道，然后又对秘书补充道，“你让最后一位5分钟后直接进来。”
“好的陈总。” 秘书说完径直走向隔壁的会议室等候区。
华兴的晋升述职评审，负责评审的评审官一般都是三个人，其中一正两副。
实际上评审结果都是以主审意见为准。
但是，当主审和两个评审结果都不一致时 —— 比如主审通过，两个副审皆不通过；
或者主审不通过，两个副审皆通过；
虽然结果还是以主审为准，但事后公司会调取评审时候的影像资料。
再次核实是否存在违规情况发生。
但是上面说到的主副完全不一致的情况一般都不会发生，毕竟评审们是会有交流的。
“朱总，你觉得咋样？” 陈默问道。
“挺好的，升16绰绰有余，17都够了。” 朱总倒是没有说违心话。
三人分别在电脑上提交了自己的评审意见。
......
又过了20多分钟，陈默看着拿着激光笔滔滔不绝的张福全没忍住敲了敲桌子，打断了他说道：
“得加快了，还剩8分钟，你的PPT才讲了一半。”
今天的张福全黑色西服套装配白色衬衣，蓝底佩斯利花纹的领带应该是他老婆给挑的。
“谢谢各位评审，我述职完毕。” 张福全说完擦了擦汗，有点紧张。
"；你主导的CRM系统在去年双十一期间扛住了百万级并发，但事后监控显示Oracle数据库出现大量闩锁争用。请说明根本原因及优化方案。"；
陈默照例问了一个能让对方展示自己优势的问题。
闩锁争用就像读者老爷去的超市收银台如果只有一个扫码枪，顾客排队就会挤爆。
这个问题主要是考验他对数据库底层机制的理解以及在高并发场景的调优能力。
张福全想了想，回答道，“问题出在客户画像更新事务的索引设计——我们原用的B+树索引在热点数据区产生闩锁风暴。”
他继续说道，“解决方案有三步：1，对手机号前缀做哈希分片，将争用分散到32个分区；2，在华兴云GaussDB启用内存优化表。3，用自研的异步批处理工具替代实时更新。”
哈希分片就相当于还是前面那个超市，给开32个收银台，按顾客手机尾数分流。
内存优化表就相当于把商品先放购物车再统一结账，减少收银台压力。
王工就这个问题追问道，"；哈希分片需要重建索引，用户能接受停机2小时