聊聊大厂潜规则，有点子意外的
作者：五阳
为什么面试造火箭？
面试的时候，我有个习惯，我会先描述一个具体的问题场景，让候选人设计方案，同时让候选人聊聊如何解决这一类问题。因为这样和候选人探讨具体场景的具体方案，可以很深入的讨论细节，考察实际的系统设计能力，防止他夸夸其谈，询问如何解决这一类问题，能考察是否具备深度思考和抽象能力。
例如服务的full gc 非常频繁，半小时一次，如何解决这个问题，你有哪些思路？谈谈GC问题有哪几类，优化GC参数有哪些方向？
例如优惠券领券活动有库存限制，有总库存和日库存，系统并发度最高 1W TPS，要求设计一个扩展性强的库存系统？
为什么要这样提问呢？因为解决问题的能力和突显你的能力同样重要。解决问题要看结果，你拿到了好的结果，只能证明你解决了这个问题。如何突显自己的能力？要充分说明这件事的挑战、难点，要能说清楚解决方案的逻辑性。
在职场里光干活显然不够，活是永远干不完的。在大公司里，快速解决一个具体的问题和完美解决一个具体的问题，似乎是存在矛盾的。
快速解决一件事，一般使用改动少、风险低的成本低的解决方案，这种方案最终会被定为短期方案。而长期方案则有如下特点：
能解决根本问题，不仅针对一个具体特殊场景
不仅能解决当前场景的风险，更全面地解决潜在风险。
具备更好的扩展性，未来的需求来临时，更好评估和修改，需求交付更快。
系统边界更加清晰，职责划分更加合理。（至少上下左右相关方都认可的标准）
……
完成胜于完美
完成胜于完美，我上家公司的CEO说过这句话。那家公司研发团队少于500人，当时公司创建时间不足5年。
在中小型公司，业务压力非常大，业务的稳定性不足，往往需要团队快速试错，快速拿到结果。快速淌出来一条路，证明这条路是光明的。试错的次数足够多，成功的几率越大。
这种情况下，研发团队的目标是更快的交付需求，系统稳定性、系统设计合理性在初期是次要目标。
所以我们的CEO对公司产研团队的要求是完成胜于完美。 项目组采用敏捷开发模式，每天的晨会负责过项目进度，每一天会单独过个人的项目进度。 每个人每天干了什么活，当前有什么在跟进的项目在领导层到时明确的。每个人的压力也是非常大的。
当时领导对我们的要求就是快速完成需求，有困难提出来，领导帮协调解决。 大部分情况下甚至不写设计方案，对齐接口以后，直接写代码。
每天都有写不完的代码，什么都做过，什么都不精通。我感觉自己的成长很慢~ 这可能是小公司的通病。我做过很多项目，经验看似很丰富，但是如果问我精通什么？在这个领域，我足够专业吗？我的心里底气不足。
停下来思考的时间很珍贵~ 因为不停的有倒排期的需求，甚至需求提出越晚，上线要求越急，简直倒反天罡。
完美胜于完成
入职大公司一段时间以后，我开始意识到，原来大公司大部分时间不是在写代码，是在写技术方案，写梳理文档，写SOP处理方案，写重构方案。每天不是忙需求，而是在忙稳定性。
大公司里虽然没人说：完美胜于完成，但那是大家心照不宣的潜规则。
大公司里核心项目的产品形态已经很成功稳定了，产品经理的需求方案评审更加严格，项目规划也更长远。在落地前，会分析大量的数据得出业务结论，会花大量的时间思考产品设计，总之 产品经理更加专业，作为研发感受是：需求频率低了，沟通氛围更和谐了，上线要求没那么急了。
但这不代表你更加轻松了。因为要求你花在技术方案上的时间更多了，你需要考虑更多的事情，它会要求你的技术方案写的更全面。
你要做的足够完美，并且能告诉别人，它在哪些方面有挑战，我采用了哪些动作，化解风险，解决问题。至于完成这件事，这是最低的要求。
<顺便吆喝一声，技术大厂，前后端测试捞人，欢迎共事>
解决问题能力与推销能力都很重要
老黄牛不会说话，只知道干活，主人会认为他很辛苦吗？主人会想：“你干活的时候，我牵着你，我也在风吹日晒，我还要负责你的草料，所以你辛苦时，我更辛苦。”
主人会认为自家的老黄牛，能力很强吗？恐怕很难，老黄牛只能通过日复一日、老实巴交的干活，向主人证明：他是一头合格的黄牛，无法证明它是一头能力强的老黄牛。
只有你凸显了项目的挑战性，才能凸显你的能力。只有这样，你的领导才能向更高层领导，说清楚这件事难在哪里？
这不就是卷吗？
如何突显项目的挑战性，怎么做有亮点？
有这么几个方向，供大家思考。
需求复杂，我是如何和产品经理沟通的？
记录沟通过程。越是难以理解，沟通成本越高，可以记录和产品经理沟通问题的数量，并且逐个记录下，作为产品结论。例如 产品需求逻辑复杂，和产品经理沟通需求，总计35个沟通结论。
描述需求如何复杂，系统需要处理多少个场景，处理多少个极端问题，需要有多少个交互方。系统对外提供了多少个接口，新增调用下游多少个接口等等。
一定要可以量化~
系统并发度非常高，要求低延迟，我是如何解决的？
支持如此高的并发，系统瓶颈在哪里？自己是如何分析的
高并发接口应该如何设计？自己产出了哪些经验和方案，应该从哪些方面去思考。
如何进行存储系统选型？使用了本地缓存，分布式缓存，和数据库三级缓存。
使用缓存如何保证数据一致性？
全链路上多少个接口需要支持高并发，自己是如何梳理的，涉及多少相关方，如何沟通确认的。
如何规划系统容量？设计了全链路压测方案，压测出多少问题
如何识别高延迟的风险，有哪几类，例如GC参数不合理，协调优化了X个服务的GC参数，效果如何？
上下游相关方多，如何保证数据一致性
如何描述挑战：
相关方有多少个，相关接口有多少个，返回值多少个，极端场景多少个，是否有资损风险？
如何解决挑战 2. 如何识别出系统的相关方？如何保证是全面的 3. 相关方非常多，如何把问题拆解下去，问题和责任明确到个人。 4. 写场景，如何保证众多的参与方数据一致性？这本身是一个难题 5. 制定上下游接口规范，即上下游对齐数据一致性方案。例如最终一致性如何保证、谁是事务管理者谁是事务参与者、谁负责发起重试、系统是否要回滚、返回值上游如何处理、接口幂等性要求、超时了重试还是失败等等。如果没有一个组织者跟大家对齐标准，各系统各行其是，在异常和边角场景各参与方的数据不一致风险非常高。
拆解问题和制定标准规范 是很困难很有挑战的事情。
如何更好提供扩展性？
和产品沟通未来业务如何扩展，扩充的粒度是什么？
模型上如何设计的，预留了哪些字段，提供扩展性。
不同场景的流程存在差异化时，如何更好扩展呢? 使用流程引擎，提供流程编排能力。
流程上提供了哪些扩展点，业务可以自定义扩展。
上下游交互协议如何设计的？可以支持新的业务场景接入。
项目梳理成本高，我是如何梳理的？
如何体现梳理成本高？ 接口数量、服务数量、页面数量、数据库表数量、相关团队数量等等。
如何拆解问题到个人，明确责任和分工。当工作量庞大时，分解工作量很重要。
领域：确保相关的领域都评估全了。拆解问题到对应的领域负责人，展现层：确保所有的页面都评估到了，接口层：确保所有页面相关的接口都评估到位，数据库：确保所有的表评估到，写入和查询逻辑，如何存储等。
项目时间短，我是如何快速完成的？
和产品沟通成本最低的解决方案，优先保证重要需求上线，一些不重要的问题能否二期再做。
协调更多的人力参与进来，拆解问题。
协调更多的开发时间，向上申请周末加班等(有加班补偿的情况下)
注重预期管理。越是紧急的项目，问题越多，风险越大，越需要不停对齐风险。当识别出风险以后，就能向上申请更多的资源：时间或人力。不要等项目铁定延期了，再向上报风险要资源，要注意过程透明。
明确项目里程碑，互相依赖的问题要明确交付时间和交付物。 例如X 日提供接口文档，X日提供接口Client，X日可以联调，X日可以提测。
前置完成下一阶段的事。当提测以后，接力棒交到测试同学手中，研发同学可以设计上线方案，设计监控告警方案，代码Review等等，提前完成下一阶段的事情。
项目人手不够，我是如何快速完成的？
人手不够，可以申请时间。人手不够，时间充足也能如期完成，或者砍掉不重要的需求。
可以申请将一些次重要的事情交给其他人去干。像组织例会、稳定性工作等协调类工作交给其他人，让参与人完全投入到代码开发。
拆分后的任务要独立完成，减少互相依赖的情况。如果有依赖，一定要明确交付时间和交付物，参考上一条。
多说一句：越忙的时候越要加班，至少做做样子，当领导发现你划水时，你申请资源的难度会增加（人和时间），这将导致你更加的忙~ 如果实在想划水，可以趴桌子休息会，营造自己很困的假象。这不就是卷吗？
不熟悉项目的情况下，如何保证需求交付速度和质量
不熟悉怎么办，那就慢慢熟悉呗。只要功夫深，铁杵磨成针。
要向上协调资源，在没有专业人下场参与的情况下，要尽可能的让熟悉项目的人，给自己讲解，给自己写梳理文档。对方不配合就找老板协调。
不熟悉项目的情况下，最容易遗漏事情。如果有一个熟悉项目的人，能告诉你哪几个接口需要改动，我相信你的工作量能下降很多。因为你不需要花时间在无关的事情上。如果没有这样的人，那么自己一定要提前做好规划，自己应该梳理什么什么东西，把计划列出来，尝试去执行，如果时间不允许，继续向上反馈，申请资源，增加更多的人手参与梳理。
在这个过程中，你要量化需要梳理的东西有哪些？这些都是挑战和困难。一定要量化。
项目相关方多，我是如何保证关键信息不丢失的？
项目相关方多，保证关键信息不丢失本身就是一个极大地挑战。
量化相关方的数量，数量越多，挑战越大。
相关方越多，越需要重视技术方案和评审。
每日例会，各参与方出责任人，对齐关键信息，由责任人向下同步。每日例会过进度，过关键风险。过遗留TODO问题
记录关键信息，确保项目参与者都能找到。
项目参与方多，需要项目经理负责以上问题。专业的人负责专业的事。
如何保证快速发现问题？如何快速定位问题？
快速发现问题本身就是一个挑战，项目的参与方越多，系统链路越长，接口越多，越难以快速发现问题。
全面有效的监控和告警能快速发现问题。又回到了那个问题，如何保证全面？这个问题可太难了~ 就好比 数学老师考试之前问你："小帅，这次考试你怎么做才能保证考100分呢？”。
你可以回答：“我圆锥曲线、立体几何解析几何、极值求导等各种题型都非常精通，我有信心考100分”
数学老师：“这些我知道，你怎么证明你一定能考100分呢？”
这不就是卷吗？
全面性很难保证，但是你至少可以保证，你梳理的全面性。例如本次需求涉及哪些业务场景需要监控，你分别予以说明。拆分到页面、拆分到接口、拆分到数据库等等，保证这些异常场景有监控打点，保证上下游调用返回值都有监控打点，保证自身接口返回值有监控打点，制定监控标准，要求各接口负责人都按照标准做。做到这些基本上就够了。
如果想做的更好，则需要思考业务上有哪些异常情况，例如哪些流量突增突降等，分别配置告警策略。
做到这些就是很有挑战的事情。
如何保证快速恢复故障？
发现问题后，如何快速降级，恢复故障 灰度发布，要求所有的新功能都具备灰度能力。出现问题后，降级灰度，系统切回原处理逻辑，故障得到恢复。
又回到了这个问题，如何保证全面性？这不就是卷吗？
写在最后
当你看到这里，想必已经意识到在大公司里大部分时间不是在写代码，而是在写文档和PPT。
当你做这件事的逻辑如果无法自圆其说，甚至无法证明全面性、正确性时，那么这件事八成白干了。
完美胜于完成，大公司的潜规则~
页:
[1]