几乎清一色劝楼主提桶跑路，实在理解不了现在年轻人的思路……

建议：观察学习新 CTO 新团队的新思路新方法，对照着补强自己，自己强大才是王道。原因如下
1 、空降 CTO 还带团队，说明现团队肯定有（老板认为的）无法解决的严重缺陷，深度参与这一修正过程能大幅提高自己的阅历和能力；
2 、CTO 带团队过来说明领导力不错，说不定是个赏罚分明有口皆碑的人呢？
3 、CTO 的老团队也不过和他多共事几年，如果你们工作节奏很合拍，你也能加入他的圈子。
4 、即使立即跳槽去新公司，也免不了碰到资深同事是领导嫡系的情况，你又继续跳？

PS. 楼主给的信息不太充分，如果存在下列情况之一，当我没说。
1 、楼主本来就对公司（老板）严重不满，上班如上坟。
2 、CTO 整人立威，原团队苦不堪言。
3 、CTO 只会吹牛推诿，技术能力堪忧。
4 、楼主安于现状，拒绝变化。
5 、楼主本来对 CTO 角色虎视眈眈，现在严重挫败和失落，拒绝合作。

利益相关：曾经空降过，也曾经被空降过，我都持开放心态希望这一变化能把蛋糕做得更大。

对接的平台有成熟解决方案就直接用。
特别是抢券模块，预估好并发量，准备好机器，提前做好压力测试。

上个月合肥市发消费券，微信通道一上线连崩两天，第三天刷新页面上百次才抢到（美团通道倒是一切正常）。
怀疑又是层层转包给某个野鸡团队随便糊弄的。

同是不怎么会聊天（吹牛）的技术型 leader ，分享一下之前空降到新公司负责技术部门的经验。

部门内部相当简单，用你的技术实力征服他们：
1 、适当场合顺带提提自己的成功经验，给他们“这些场面老大都搞定过”的感觉，有人兜底心里不慌；
2 、结合公司、团队、个人情况，与每一个团队成员坦诚沟通，量身定制职业发展规划并在日常工作中落实（“我之前有个同事跟你很像，他做了 xxx 、xxx 、xxx ，现在 xxx 混的风生水起”）；
3 、不思进取摆烂混日子的人，果断 n+1 ，用事实和数据告诉老板和团队此人负贡献。

部门间勾心斗角互相甩锅的情况没办法避免，弯弯绕绕的办公室政治不是我们的专长。
我的策略是紧密跟随引荐我到这家公司的伯乐。
在任何组织里，站队是免不了的，选择一个相当知根知底的人，风险小一些。
外事不决就找他，他也通常能从更高的维度和更广的视角提供信息和建议。
当然这也带来一个风险，伯乐一旦靠边站，我也会很快凉凉。

“我就截取了一个 json 里面的几个参数，表示是相加得出来的” -> 没有接口文档或 swagger
“我维护了几百个微服务” -> 运维小伙出身？还是一个接口部署一个微服务？没读出来有啥技术含量的

“经常对他的方案表示质疑，对外处理问题也还是以前的路子，习惯了” -> 有人能忍你不表示所有人都会忍你
“然后他就说会议室聊会，我就去了，然后他就一直说了很多很难听的话” -> 在没找好替补前就说这么直白，这个 leader 也够憨直的

从技术能力和协作沟通两方面看，当事双方都是半斤八两，正好针尖对麦芒了。

感觉楼主的团队很有一些故步自封的腐烂气息，不妨趁这次机会跳出舒适区看看外面的世界。
在技术圈里，“能力越强的人越谦逊”大概率是对的。

分享一篇关于站立会议的的文章，非常全面的分析了站立会议的形式、意义、最佳实践和常见问题。
楼主有兴趣可以研究学习一下，不过是英文版。
https://www.martinfowler.com/articles/itsNotJustStandingUp.html

如果发现站立会议流于形式，没发生正面作用，可能有两方面原因：
1. 团队荣誉感 /自治性不足，主观上不愿意作为团队的一部分去共同实现一个有意义的目标；
2. 团队成员职业能力有短板，客观上无法理解团队目标，达成团队协作，阐述团队及个人的工作内容和价值。

两者都是站立会议可以轻松暴露的问题，但需要在站立会议之外解决。

不管是给自己部门招人面试还是帮其它部门交叉面试，我都会先看过《应聘登记表》上的期望薪资再接触候选人。

因为期望薪资体现了候选人对自己工作能力的认知；
我也要根据这一价位选取合适的交流主题，判断其能力是否符合公司对该 level 员工的期望。

只有双方对能力及薪资的认知大体一致，后面才能有合作的可能。

> 1.收到您的简历后，如果符合要求，我们会通过邮件与您联系第一轮 coding test 。
> 2.您有两天时间完成 coding test 。通过之后 HR 会邀请您进行一次非技术面试，以了解您的更多信息，如薪资期待等 。

本来想要试试的，被这面试流程劝退了……
公司情况、团队情况、发展规划、工作要求都不先聊聊，候选人怎么知道和企业的匹配度如何，是否值得花几天时间去做 coding test ？

> 由于每日收到邮件较多，无法一一回复，希望大家见谅

据信标准模板都懒得抄一下，太过于傲慢了。
接触过的北美本土 startups 都会「礼貌婉拒」。如果再去信想要了解不匹配的地方，大多也会简单说几点。

1 、靠谱的产品策划 /行业布局
2 、兼容互补、互相欣赏、逐渐信赖的合作伙伴
3 、突破当前职业天花板的机会 + 合适的股权期权
4 、能让团队存活一年以上的现金
5 、能保持体面生活的月薪

「政务类项目+销售型老板」的通病……

在我看来这不应该是「工作优先级」的问题，而是「项目管理如何平衡“功能范围 & 时间 & 质量”」的问题。

如果老板逻辑还算清晰，能尊重技术的话，建议准备好充分的素材后与其做一次坦诚深入的沟通，从你的视角提供几个解决方案让老板选。举个例子：
技术团队上一个月同时维护 x 个项目，共发布 y 个版本，总计 z 个用户故事；
以同行业同地域平均水平而论，需要 xx 个团队成员 yy 人日完成；
但由于现在仅有 4 人，导致加班严重，交付质量严重下降，共出现 xxx 个缺陷，其中 yyy 个是生产环境严重级 bug ；
目前团队修 bug 和开发新功能的时间比大概在 x:y，参照前几个月工作产出估算，接下来四周最多能完成 z 个用户故事；
解决方案 1: 缩减功能范围，专注开发 a 、b 、c 几个核心功能，其余低优先级项目 /功能由商务挡住；
解决方案 2: 延长开发周期，下两周开发 a 、b 功能，再下两周开发 c 、d 功能，……总计开发周期预估为 x 个月；
解决方案 3: 降低产品质量，所有功能均做最小化开发与测试，商务验收后再长期救火不足部分与线上 bug ；
长期解决方案：补充团队成员至与项目规模匹配的数目，但要说明新人上手需要一个月，稳定输出需要两三个月，对近期项目没有帮助，甚至帮助新人融入还会降低老员工的工作效率（没有银弹！）。

如果老板不讲理的话，那就真的只能六字真言了。

> 我们公司同个部门的好几个同事

多个成员存在这样的问题，说明这是团队（负责人）的问题，而不是孤立的某几个人的问题。

如果要从团队层面系统地解决这个问题，推荐两个实践：
1 ）引入压力测试 /性能优化，对于数据量千万级以下的传统应用，要求单机支持 1k+ tps 、100- ms latency，可以在设计 /开发 /测试环境快速识别性能瓶颈，避免低质量的设计和开发；
2 ）引入 Application Performance Monitoring 工具，数字化直观展现应用在生产环境的性能瓶颈，将慢操作视为高优先级技术债务，对应的产品有 SkyWalking 、New Relic 等等。

通过建立体系化的开发流程，即使新的工程师加入时没有相关的经验和意识，处理几次相关问题后也能逐渐适应和融入。
当然，这对团队负责人的技术能力和管理能力要求就比较高了。
如果楼主部门领导不具备这种能力，楼主描述的问题必然会反复出现。

钉钉的锅，不要甩到 Spring Security 上。

@zxCoder #3

从文章里可以看到，Aurora Serverless 可以根据负载情况自动调整配置规格，最大规格可以支持到最多 6000 连接数。

如果把一个连接数看作一个并发访问，那相当于是能支撑一个「千万用户级」的系统服务。
虽然达不到 Lambda 的无限伸缩（理论上），但对于 90%（其实我想说 99%）以上的业务场景也基本够用了。

如果期望支持更大的并发，需要组合其它技术来支撑，比如说缓存、消息队列、拆分服务。

https://www.jeremydaly.com/aurora-serverless-the-good-the-bad-and-the-scalable/

Max Connections
A major limitation of relational databases in serverless architectures is the maximum number of concurrent connections allowed by the database engine. While FaaS services like Lambda may scale infinitely (in theory anyway), massive spikes in volume can quickly saturate the number of available connections to the underlying database. There are ways to manage connections in serverless environments (also see Managing MySQL at Serverless Scale), but even with Aurora Serverless, this still appears to be a possible limiting factor.

AWS uses the following formula for generating the max_connections value for Aurora instances:

log( ( <Instance Memory> * 1073741824) / 8187281408 ) * 1000 = <Default Max Connections>

A db.r4.xlarge instance with 30.5 GB of memory for example would have a default max_connections value of 2,000.

log( (30.5 * 1073741824) / 8187281408 ) * 1000 = 2000

@yidinghe #23

只是类图就错综复杂绕来绕去的……
就算代码写的再优雅，要是移交给别人（或者半年后自己再来看）会很难看懂吧……

针对这种计算规则多样，并且可能频繁修改的需求，一个比较推荐的办法是做个简单的「计算规则引擎」。

比如说：把「计算公式」和「参数」按照标准的格式记录在 Excel 文件里，「计算规则引擎」解读该 Excel 文件生成计算规则，然后应用程序读取数据并调用计算引擎作计算。
当需要更新计算规则时，业务人员只需修订 Excel，然后重新上传到系统。

除了 Excel，Python/Lua/Javascript 之类的脚本语言也能用来定义计算规则，我甚至用过 xml 。
之所以首选 Excel，是因为运营人员（产品经理、系统运维）和用户（学校老师）都熟悉 Excel 操作，而且能直接在 Excel 文件里输入一些样例数据对公式做人工验证。

@caroline1022 #22

> 我很好奇作为面试官真的有义务回答面试者反问的问题吗？

没有“义务”。但是如果追求成为负责任的面试者，很有必要。

我与候选人交流时，当对方回答问题不在点上时，即使对方不提问，也会提出一两个解决思路与他 /她作进一步的探讨。

如果候选人开始答不上来只是对问题的表述理解有偏差，这时候就可以理解问题的关注点，展现自己的技术实力；
如果候选人开始确实没有思考过这个问题，但是提示思路后能迅速理解关键点并举一反三，或者指出我思路里的不足，那也能说明他 /她的技术理解力和敏感度。

在我的招聘理念中，“面试”是一个平等交流双向选择的过程，可以认为是与未来同事提前模拟一下后面工作中的技术讨论。
我要在团队里努力营造一种“协作进取”的技术氛围，那从与团队成员的第一次接触 - 面试时就力争能给到他 /她这种印象。

@eric96

如果只评估传统的关系性数据库的话，那就尝试分区、分表、分库操作吧。

撑不住 20k tps 写入，可以考虑加一个消息队列做缓冲，批量处理批量写入。
在对读操作要求不高的场景下，问题应该不大。

> 目的：根据唯一主键从数据库中查询一行数据，要求 50TPS，延迟在 200ms

如果没有硬件资源限制的话，任何支持水平线性扩展的分布式数据库都能满足吧。
数据量再大，性能要求更高，加机器完事。

Cassandra 完美契合这一需求，参考 Discord 的经验：12 个节点，3 重复制，支撑日均过亿消息，写操作亚毫秒，读操作 5 毫秒。
https://blog.discord.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7

Discord 去年声称迁移到了性能更佳的 ScyllaDB，但是没有看到具体的性能指标。
https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/

@weiwenhao #17

> 问一下大专怎么写能去大厂面试，投了几十次了都没有面试

先要明确自己的经验能力和大厂岗位要求的匹配度有多高。
以我自己为例，如果目标岗位是 Amazon Senior Principal Engineer，岗位匹配度非常低，简历写的再漂亮也没有机会。

当然了，JD 和实际要求可能会有偏差，自我评估也可能会有偏差。
一个可能的办法：寻找各种途径联系到目标大厂的资深员工（ linkedin ？微博？邮件？），请求对方帮助评估匹配度和不足之处，针对性地补强后再投简历。

@luckyrayyy #18
@jin5354 #21

> 确实没做过这么多高大上的产品就很蛋疼
> 很多候选者那简历纯 CURD

简历想要打动人，总得先要把自己的亮点找出来吧。
没有高大上的产品项目经验，可以强调对技术的钻研和应用，再退一步也能说说工作细致负责，最次那就强调努力和加班吧。
要是连努力也谈不上，那还是建议他别想着换工作了，好好修炼一两年再说。

我文中举例的测试小伙子，他的工作表现其实也就中规中矩，业界平均水平吧。但只要努力挖掘，总能找到工作的闪光点。