嗯，也是当初运气好，进了一家特别能锻炼人的公司

算虚岁的话， 今年 37 了。 身体状态还好， 因为没有特别熬。 一般晚上 11 点多睡， 早上 7 点起，可以保证 7 个小时的睡眠。 半个月前刚去做了肠胃镜（因为前几年拉肚子拉的太厉害了， 每天都窜好几次，后来中医说是脾虚和有湿气，所以吃中药调整了 3 个月，就好了很多， 但还是不放心，半个前就去做了肠胃镜），现在正在吃药，主要是有胃炎，我理解应该没大事。 有脂肪肝了（虽然我特别瘦，才 120 斤不到），以后要注意饮食。 等胃看好了去查查颈椎， 感觉有几次头疼难受是供氧不足引起的。 其他的就没感受到身体有什么不舒服了。 岁数上来以后就比较重视体检， 每年都体检然后感觉不舒服就去医院（有补充保险，花不了多少钱）。现在精神状态和身体状态感觉都还行，起码目前没大毛病。

我觉得工作上的熬看是怎么熬的吧， 要是常年的那种睡眠不足的熬夜，再加上工作压力特别大， 一般来说会这样的。 如果只是半夜 1 点睡， 但是 8,9 点多也才起床， 并且这个作息时间比较稳定。 那其实还好， 只要作息稳定，并且睡眠足够，人体的生物钟会自己调整的。现在很多大厂的上班时间都比较晚（上午 10 点），所以大多数人只要别浪，回家别玩游戏别刷手机，倒头就睡，周末去外面锻炼锻炼身体，爬爬山什么的，不至于身体被消耗的很厉害。 当然像华为和 PDD 这种常年压力和加班并存的地方， 确实容易出问题。

能不能活到 70 岁以上我也不知道， 人是很脆弱的，随便一个意外，一场疾病能就没了， 所以我很少想这种事。 我现在的原则就是在不拼命的前提下，尽量努力。 多挣一些钱，给我们小两口的晚年和孩子更多的保障。

看是怎么熬的吧， 要是常年的那种睡眠不足的熬夜，再加上工作压力特别大， 一般来说会这样的。 如果只是半夜 1 点睡， 但是 8,9 点多也才起床， 并且这个作息时间比较稳定。 那其实还好， 只要作息稳定，并且睡眠足够，人体的生物钟会自己调整的。现在很多大厂的上班时间都比较晚（上午 10 点），所以大多数人只要别浪，回家别玩游戏别刷手机，倒头就睡，不至于身体被消耗的很厉害。 当然像华为和 PDD 这种常年压力和加班并存的地方， 确实容易出问题。

你也在到家呆过啊~~ 冬梅那个害群之马还在么

我看看能不能找到以前的简历了~

我这几天其实计划想把自己的简历，脱敏一下发出来，一起讨论一下的

因为每个人能选的出路毕竟不一样， 对我来说最靠谱的方式就去培训机构找个讲师做， 或者开发这些机构的测试产品。 但这个路不是每个人都适合去走的。 大家还是要选择对自己来说最靠谱的方式。 所以我不敢把话说死了， 说跑去干培训最靠谱。

大厂的人失业了，再去找另一个大厂，要是岁数大了就大幅度降薪去小厂，岁数再大了降薪小厂也不愿意要了就去做外包做子公司。 岁数再大了外包也不要了就再降薪去个培训机构做老师做销售。 水平不差的话肯降薪总是能混到 40 多岁的。总归是比送外卖开滴滴强。 要是说等 45 了以后咋办，嗯，好问题。 45 以后了失业除了真大佬以外（反正我不是）真是谁也没招，英语好的看看有没有外企的坑（这年头外企的坑比纯牛马的头发还少），混圈子的看看能不能在培训机构继续当老师当销售当助教开发测试产品。有人脉和资源的看看能不能转行干别的。也可以选择学习开发技能然后做个独立开发者接私活，开发小游戏，接众包（我有些朋友选择了这条路）。 实在不行滴滴外卖快递这些该做也得做，都是为了生活，不寒碜， 不怕大家笑话，我以前甚至想过 50 岁以后去做保安（50 岁以下的人家嫌弃你岁数小当保安不合适）。 所以如果真是生活所迫， 什么快递外卖滴滴保安收银员都不是问题，该干都得干。

总之无法在公司里继续做测试，也不想去送外卖/快递开滴滴这些工作， 那就一定要去学一些新的技能，接触一批新的人去适应另外一个领域，这是躲不开的。 之前有同学问我这个问题的时候我说可以去做独立开发者接接私活。但那个同学说我要是想写代码当初就不做测试了。 然后这个天就聊不下去了， 因为不管你建议他做什么，他都是这个想法，有各种各样的理由来搪塞说这个事情对他来说不靠谱， 不想学新东西。比如跟他说去外企试试， 他说英语不好也不想学。 跟他说去培训机构做老师做销售，他说不会讲课性能内向，反正就是怎么地都不行。 那这就一点办法都没有了。

不过其实对于我身边的人来说，很多人的想法其实都是在 45 岁之前，或者 40 岁之前攒够钱，然后就躺平。 这也是为啥 pdd，华为那种拿命换钱的地方还是有大把大把的人去。 大家都知道自己干不了多少年。 必须在这些年里把钱挣够了。 我现在也是这么个想法。 能多干一年是一年， 尽全力去延长自己的职业生涯。能干到 45 岁就是我现阶段最大的目标（我算了算，以现在的收入，只要不浪费，干到 45 岁攒个几百万的，回老家养老也是个退路，老家也有房子， 这几百万就存银行吃利息都行，老家那个消费水平一年 5，6 万块就够了），为了实现这个目标。就要不停的学习，不停的卷，领导说干啥我就干啥，尽量在公司里体现自己的价值。 所以我从很久之前就不再嘲讽很喜欢卷的同事了， 都是家里的经济支柱，是不能倒下的。 当然我也要做好干不到 45 岁的准备， 或者到了 45 岁但没攒够养老的钱，继续找个营生接着挣钱的准备。

我来了~~ 我回答一下楼主：

关于第一个问题

其实不管是 K8S 还是其他技术， 这些技术对于测试的主要意义在于产品是否用到了这些技术，产品用到了这些技术那么就需要去学习它，熟悉它，这样才能设计出更完善的测试场景，才能执行相关的测试方案。如果测试人员希望能够测试的更加深入，那么就需要学习产品中使用到的主要技术栈，这是通往高阶测试职位的必经之路。 尤其对于 K8S 这种基础的底座平台，如果对它完全不了解， 那么在产品出现什么问题的时候， 测试人员连日志都不懂得要怎么看， 这就是非常尴尬的。 当然如果是外包同学，我们对他们的要求就是在 UI 上点点点就可以了，出了任何问题都直接扔给研发。如果是这样的话，是不用学 K8S 的。

我再举几个测试需要用到 k8s 的例子，通常在 k8s 场景中会有一些比较独特的测试类型：

• 容量测试（性能测试的一个分支），这跟 k8s 的资源模型有关系（limit 和 request），需要熟悉 k8s 在资源上面的设计和相关的监控手段。如果出现过度超卖要怎么办，软驱逐和硬驱逐应该怎么设置是合理的，评估容器的内存使用应该用 RSS 还是 working set。
• 混沌工程：如何在 k8s 环境中注入故障是一个需要研究的方法（当然现在有 chaos-mesh 这样的开源工具了）， k8s 在高可用上是如何设计的，业务应该如何配合 k8s 的特性完善自己的高可用场景，如果业务没有配合 k8s 会的高可用设计会发生什么行为， 应该向哪里注入故障，注入故障后又应该预期发生什么样的容灾行为。 这些也是要去了解后才能测试的。
• 稳定性测试：在不注入故障的前提下，长期运行自动化测试或性能测试，验证系统会不会稳定性运行。 这个测试方法和普通的场景是一样的。只是在 k8s 中常规监控工具无法满足这种测试类型的需要，需要根据 k8s 的 ListAndWatch 机制开发相关的监控工具。
• 云原生的测试：一般产品上了 k8s 就是云原生架构，那么 k8s 的一些特性可能会进入到产品里，比如云计算，边缘计算，AI 等等。

除了上述的测试类型， 我们也需要依赖 k8s 的特性开发一些测试工具，比如我之前写过的 mock server，故障注入工具，监控工具等等。 为了更形象说明一下， 我这里分享一个我在测试中发现的bug 总结

首先说一下 k8s 和 linux 在内存上的策略：

为了确保节点的可用性，不至于让用户进程把所有内存吃光。在每个 k8s 的节点上都会有 3 层内存回收机制的保障：

• K8S 驱逐策略: 由每台机器上的 kubelet 进程控制，用户可以根据自己的需要配置驱逐策略的阈值。当节点内存达到一定用量时，就会触发驱逐策略，按一定的优先级开始把 Pod 驱逐到其他节点上，这样可以保证节点不至于因为内存吃满而瘫痪，也可以保证系统的核心服务依然正常工作。

• Linux 内存回收：分为异步的 kswapd 和阻塞的 direct reclaim，当驱逐策略没有生效时，系统内存到达一定的阈值后，会开始触发 Linux 自己的内存回收策略。

• OOM Killer：当 Linux 内存回收的资源也无法满足进程需要时，就会触发 Linux 的 OOM Killer， Linux 也会给每个进程计算一个 oom score 来划分优先级。当内存不足时，就会强行杀死进程来释放内存。

Bug：产品服务没有设置合理的优先级

K8S 的 Pod 优先级策略

根据 CAP 和 BASE 理论， 当系统出现故障或者资源吃紧或者压力过高时，如果无法保证系统完全不受影响，那么可以牺牲部分非核心服务或者用户的可用性，来保证核心能力的可用，这也是架构设计中熔断和降级策略的来源。而 K8S 的驱逐策略就是这样的设计理念，当业务高峰期来临， 导致节点资源不足时， 为了保证核心模块的可用性，会把低优先级的服务驱逐到其他节点上释放资源。 而 K8S 在触发驱逐策略时，为了保证驱逐的是低优先级的服务，在 K8S 中专门设置了两种策略来让用户设置优先级。 这样驱逐策略才能保证按优先级进行驱逐。这两种优先级策略分别是由资源配额和抢占优先级两种配置来决定的。

资源配额的优先级

K8S 会按照资源参数 reqeust 和 limit 的设置把 Pod 分为三类优先级：

• Guaranteed(有保证的)：

  • Pod 中的每个容器都必须设置 CPU 和内存的 reqeust 以及 limit。
  • Pod 中每个容器的 CPU 和内存必须设置相同的 reqeust 和 limit。

• Burstable(不稳定的)：

  • Pod 不符合 Guaranteed 的标准。
  • Pod 中至少一个容器设置了内存/CPU 的 limit 或 request。

• Best-Effort(尽最大努力)：

  • Pod 中的容器没有设置内存/CPU 的 request 或 limit。

从这些定义就可以知道它们的优先级了，当驱逐策略触发时，k8s 会最先驱逐 Best-Effort 类型的 Pod，如果释放的资源仍然不足以满足要求，会开始驱逐 Burstable 类型的 Pod，最后是 Guaranteed 类型。

抢占优先级

除了通过资源配额推理出优先级外， k8s 也准许用户手动为 pod 设置优先级。在 Pod 中有一个字段叫 priorityClassName 专门负责此事。 用户可以定义名为 PriorityClass 的对象，事先约定更好一组优先级。比如：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "此优先级类应仅用于 XYZ 服务 Pod。"

bug 出现的原因

产品设计上并没有给服务设置合理的优先级， 导致在驱逐策略发生时，核心服务被驱逐掉导致产品在一段时间内不可用。

总结

所以要测试出这样的 bug， 前提就是需要把高可用设计原则（知道原则你才知道什么样的行为才是正确的，高可用没有需求文档，全靠测试人员和开发人员对高可用的理解）和 k8s 中的驱逐和优先级机制了解的门清才可以。 所以同学们想要有能力分析出这种 bug 么，想要拿金 bug 奖么， 那就更深入的学习吧。

关于第二个问题

K8S 要掌握到什么程度， 这当然是越深越好。 不过人的精力有限， 所以我的建议是如果不是专攻云原生方向的，那就把 K8S 的普通特性学习好就可以了。 就按自己可以在 k8s 中从 0 到 1 的部署一个高可用版本的服务为基准，自己来这么一遍就差不多把大多数常用的特性学的差不多了， 也可以在出问题的时候知道怎么查看日志和其他信息。 而如果是专攻这个方向或者有意深入了解 k8s 的， 还需要懂得 k8s 内的机制：比如 listandwatch，比如 operator，比如各种更复杂的内部机制，需要懂得根据 k8s 的 api 开发工具，总之学的越深越好。

关于第三个问题

• 极客时间上 k8s 的课程
• 我写过一本书《云原生测试实战》PS：我再一次无耻的推销一下自己的书

好久没研究过单测框架了， 现在出了新技术么， 以前 java 系就 testng 和 junit 这俩选择