老菜鸟路过一下，跟 OP 差不多年纪，完全没有这么厉害。

个人感觉 kubenetes 拼错没什么问题，kuctl 拼错才是问题。

这个情况见仁见智的感觉，期待 OP 最终给个结果，我也很好奇。
目前就是两个方案。
1. 接受当前公司赔偿
2. 仲裁

方案 2 里面，仲裁结果公司不认可的话是可以提起诉讼的，第一次诉讼是一审。一审结果对方公司不同意，好像可以二审，二审就是最终审理。

我没记错的话，这种民事的金额不大的，貌似排队要很久。。计量单位应该是月。

其他公司我清楚，之前我司在发招聘的时候就有一些规律可循。

薪资范围越小的，不如从 20k-25k, 20k-30k 这样标，一般是对这个岗位的技能组成和经验是有非常明确的要求，所以很容易推算出这个岗位的薪酬范围。而且这类岗位一定是由具体的项目组才能提出来，也就是项目组会给予明确的信息，信息也包括多长时间内要招到人，HR 在这种情况下，不会无意义的扩大薪资范围，去收集额外的简历增加自己的工作量，靠谱程度很高。

标出 20k-40k 这种的都是报着捡漏的心态招几个，这个经验和技能跨度太大了。

因为大一点的公司每个部门都是有年度预算的，招人用多少预算，每个部门都会自己算一下的。
用人预算这里。从 20k 到 40k ，有点规模的公司都不会让你的预算直接 double 的。大概 30%到 50%的区间浮动是比较常见的预算范围。当然我也不能排除有些公司就是这个风格。。所以可以做个参考。

@NightFlame 看看工程类的书，纯看技术类的解决不了焦虑的问题。像项目管理相关的，软技能 这种书，然后一些市场营销之类的经典书籍都可以看看。。看多了就会觉得，技术之外其实还有更多的内容要了解。。。

这个真实，我曾经也为此焦虑了很长一段时间，各种看书、学习、报各种课程。
最后收效其实一般。。
我现在只能把这个问题归结为广度和深度的问题，这两者是相辅相成的。

当单独追求深度达到一定程度时，会觉得自己会的技术栈过于单一，没有足够广袤的视野，明明有成熟的方案，结果发现自己在哼哧哼哧的从头写，结果还不一定有别人的好。

当单独追求广度的时候，又会觉得自己的技术不够深入，很多原理不清楚，遇到特殊问题的时候很抓瞎。

我给自己的最后安慰就是，深度是需要的，广度也是需要的，两者相辅相成，目的是要形成自己的技术知识体系。
这一体系是为了帮我理清各种技术栈的优劣，形成一套客观的评判标准和架构思路。

比如说按照项目管理的角度去思考技术带来的风险和价值，用时间、质量、成本去评估自己的架构设计是否合理。

对于技术优化方面，重构这本书里面有一句话 “过早的优化是万恶之源” ，追求性能的时候加上这句话看看。。

对于评价一个数据库的优劣的时候，先看看评价指标有哪些，再用 docker 快速模拟一个环境，横向对比不同的数据库，把模拟的场景的尽可能贴近项目中的实际场景，然后对比看看。。这样大概能自己一个心里预期。。

这俩因为是开源且免费的，使用时间也是最久的。。
实际上技术部门在大部分公司地位并不高。
都处于完成工作是应该的，完成的好不好不重要。重要的是不能出问题。
出问题就扣 KPI ，这种情况下，选择稳妥且保险的策略是最优选择。

先明确一点，要钱是目的，仲裁是手段。
我记得成都是有劳动仲裁相关的法律咨询。
建议先咨询下专业的法律意见，准备好要保留的证据，证据准备好之后。
假如奔着双倍工资去的。直接申请仲裁。
不然的话，就先跟老板开诚布公的谈一次，看能不能直接给钱走人，好处就是省事。

严格来算工作时长的话，996 的性价比其实很低。。。。

上家公司某国企外包，早上 8 点半打卡，5 点下班，但是不打下班卡，有事和甲方打个招呼就让你走。。。
国企领导有事找你，没事随便你干嘛。准时上下班，周末没人找。。。
没有免费停车。。。后来因为搬地方实在太远了。。换了个新工作，996 ，简直了。。。

@polariszc 做这个 7-8 年的人员的平均技术水平

能成功转过去固然是好的。
可以成为最懂业务的 LLM ，也可以成为最懂 LLM 的业务开发。

实际上可能要付出数倍的努力才能达到平均水平。

“沉没” 的大多数

我有个不靠谱的建议，你可以思考，英语好的情况下，做外包，不如去国外的 freelance 网站上，找几个 3-6 个月相对长期点的项目（这个难度也不小其实）。。。

我的理由是：外包里面大多是熟练工，做的东西深入的不多。。然后现在行情很差，先混一下实际项目经验，编程这个东西理论学完了就剩下熟能生巧了。也顺便给你涨点信心。


然后想做全栈的话，PHP, Python 系列的东西中小企业里面还是有市场的。不介意的话，可以加一下这方面的技能。然后去接全栈的单子。。

Golang, java 这些大中小企业都有，但是学习难度比 PHP 和 python 大，看你自己想法了。。

这里面有多个问题：
1. 前置机数量多的问题，这个我理解是网络限制上问题，kettle 无法直接需要穿透到不同的网络中拿数据，需要前置机器去读取数据。不构成替换 kettle 的必要条件。解决方案的话，应该是从网络上下手。
2. 监控采集结果无法监控，服务停了不知道，这个应该是使用上有问题，kettle 我记得是有报警工具。而且 kettle 里面的日志也是很完整的。我不确定为啥无法监控。
3. 数据断层，配置字段校验规则。大部分 ETL 工具都做不到这个，这个模块叫做数据质量。有单独的工具，个人经验里面来说，这个自己定制比较靠谱。

我也折腾过挺多次这些的，最后的方案是 白裙双网口，容器里面起 翻墙代理。。。简单省事。

曾经偶然听过一个词，叫做技术人员的傲慢。就跟很多年前知识分子的傲慢一个意思。
技术含量这个，对技术人员才是有价值的。。

一个销售，一个非技术出生的人员，寻求解决方案时，关心的是能不能满足需求，需求发生变化的时候，能不能满足变化后的需求。当面对这一类人员的时候，技术含量是锦上添花。。。前提是能最高效的达成对方的诉求。。

PHP 我也曾使用过，开发 web 效率实在太高了，对于一个小的企业展示站，前后端不分离的情况下，一下午可以写出好几个。而且部署简单，维护也简单。性能要求也不高。一年几百块的服务器费用。跑个 5 年都没多少钱。对于非 it 行业，有没有全职程序员的公司，人家开心的不得了。

@aeestern 你这个厉害了，在哪里学的？ how much ？

@MJZ1995 B 站上有人开课，专门教人撸各种空投，要不你也整一个吧