容器领域监控都用 prometheus， nmon 已经被淘汰了不知道多少年了

k8s 下无脑 chaos-mesh， 非 k8s 可以选 chaos-blade。

参考一下我的桌面：

所以楼主， 你为啥要 all in 某一种语言。。。。。 难道不是项目用啥你学啥么。。。 研发那边我都没听说谁是只会一种语言的。

据我有限的圈子内得到的反馈是大部分没有落地的， 极少数有落地的地方，业务团队都反馈效果不好。 这也是没办法的事情，精准测试这个东西很多人都把目光聚焦在了调用链分析和 AI 上，聚焦在了用例推荐上。 但很多人都忽略了一个网络段子 -- 人工智能是有多少人工就有多少智能。 这个段子虽然有失偏颇但其实也说明了人工智能是建立在大量的人工作业的基础上。 比如拿精准测试来说，推荐用例的前提是测试团队维护了非常精准的用例库，这些用例会随着研发代码和产品需求的更新而更新。 光是这一点其实 9 成 9 的团队就做不到。 还有就是产品的需求和代码架构非常频繁的变动的，如何建立起一个自动化的自学习（自动拉取最新数据最新代码并进行模型训练，并进行指标更新进而更新模型）也是一个非常大的工程（用人工的方式维护模型是肯定不行的）。并且很困难，比如监督学习的数据是要打 label 的（总结一下就是哪部分代码对应哪条或者哪些测试用例），目前大部分的 AI 团队都要花费很大的成本建立标注团队去人工打 label。 如果这些问题都解决了， 还需要面对人性， 就是这些用例推荐不是 100% 准确的（AI 做不到 100% 的精准与召回），如果推荐错误，导致线上出问题，那么谁来背锅？ 目前所有团队的做法是业务测试人员背锅， 那么问题来了，我用你的东西， 你的东西不保证准确，出了问题要我自己来背锅。 那么我为什么要用你的东西？

所以其实精准很难落地，不是因为大家普遍看到的 AI 和代码分析这样的技术问题。 而是要面对海量用例的维护问题，人工标注数据问题，模型更新问题和人性问题。

综上所述， 以我有限的圈子得到的结果， 能把精准落地而且业务反馈非常好的团队，我暂时还没见到。

想起来 10 年刚毕业那年， 工作地点在中关村微软双子大厦，我记得那个地铁站是苏州街的下一站（具体站名我忘了），我的房子租在了沙河高教园（当时工资 4000，到手 3400，所以房子只能租在那边，我记得房租是 1100），当时沙河高教园刚刚建成没两年（打听了一下是 08 年开盘的），所以附近什么都没有，一到晚上就黑灯瞎火的，那时候真是除了个小区周边啥都没有。 只有一个公交能到地铁站（2 站地）。 所以那两年基本是，公交->昌平线->西二旗转 13 号线（就是北京三个带西字的出了名的认多的站，号称基本上两脚离地被挤上去）->10 号线->下车步行 15 分钟。 基本上一趟也起码 1.5 个小时，早晚来回 3 个多小时。 当时觉得很痛苦但也没办法，工资到手 3500，去掉房租就剩 2000 来块钱，再算上吃喝拉撒日常开销，根本不剩下什么了。这也是为啥我租了个那么远的房子（还是合租的）。 所以当翅膀硬了以后（学到东西了，有跳槽涨薪的资本了），我立刻就把工作换到西二旗了，这样基本就可以控制在 50 分钟以内。

我觉得忍受极端通勤的人一定是没办法的， 如果有办法要么就换工作，要么就换房子。 都是向现实妥协的结果。 如果楼主要不要换工作，其实很明显， 有实力就换， 没实力就只能向现实妥协。

感觉好多人是被 PUA 习惯了么。。。。这么主观的问题纠结这么多分析这么多干啥。。。每个领导的风格都不一样，你面对这个领导的时候他认为做事方法是这样的， 面对另一个领导的时候他认为做事方法是那样的。 还在这分析这么多。。。。你们真是。。。。

为了把 mock server 注入到目标 pod 用的

感谢恒温和社区的支持

抱歉哈 ， 提前预热一下

我 87 年的，今年应该 36 岁。 上周一个大我 1 岁的朋友被裁员了。 今天我俩一块吃饭的时候说面试机会确实挺少的。 感觉这波经济下行还是没过去的， 最近大家还是能苟着就苟着吧

后面有机会就不要错过了~

对于测试行业的护城河这件事，我能在我自身的圈子里感受到的就是我们不再去卷什么 UI 自动化，接口自动化和测试平台这些事了。这些我们基本扔给了外包或者子公司或者职级更低的人来做。 因为讲道理这些东西在当今的测试开发圈子里都是基操了，技术含量有限。 相比于这些基本的通用技能，我们更多的精力都放在了相对门槛较高的垂直方向里，比如有同事专门去做大模型业务的测试， 有同事专门做大数据的， 有同事专门做内容审核的，又比如我更多的精力放在了云和人工智能的测试项目里。 这些领域中的产品无一例外的都是门槛较高的技术型产品，我们老喜欢开玩笑说这些产品里都是不说人话的，因为在这些产品里就算是点点点的门槛都相对较高，因为这里需要相当程度的时间和精力去学习这些产品中的业务和技术，并不是 C 端那种面对普通人的产品，而是面对专业领域工程师的产品。

我们在这些本身就偏向技术的产品中继续下沉，去研究更深层的技术和测试方案，起码在这个领域里做到大部分同行都做不到的程度，我理解这就算是我们的护城河了。 当然这里的护城河不是说这个事离开我们别人就做不了了，而是能和我们竞争的人已经比较少了，因为在这个赛道里的人本身就少，它的门槛也高，不是谁想进来就能进的来的。 我们当初能进来也有运气的成分，入职了相关业务的团队，有幸学习到了相关的技能。外人想靠自学进入这个赛道确实不容易，通用的自动化测试还可以自己去学习，但是在没有工作环境或者没有人指导的情况下，想靠纯自学去入门这些领域实在过于艰难。 所以跟朋友聊天的时候大家的想法差不都是虽然能去的公司没有特别多（以为做这些领域的公司也确实不多），但竞争对手也很少，所以相对没有感觉工作很难找，而且工资待遇也都还不错，对年龄的歧视也相对较轻一点（其实也没有轻太多）。

然后最后想说的是，护城河这种东西确实很难的， 就算我上面说的这些也没办法能保护我们整个职业生涯。 到了 40 岁，45 岁的时候我们一样也会很艰难。 所以现在很多人也都会找找后路， 比如我在学习技术以外也在学英语，看看以后能不能进对年龄相对友好的外企。也在积极的参与行业里的活动，锻炼演讲能力，攒攒人脉。 看看以后能不能当当培训老师什么的。 总之就是都找一找可能性，尽量的在年龄歧视的大环境下挣扎一下。

我今年 36，我们这里 30 多的不算少吧。 但是 40 多的确实少。

不在范式了都~~ 我跳槽到腾讯了

你这么牛皮么。。。。。2W6。。。 不敢想象。。。我听说很多母语为英语的人都没有这么多的词汇量。。。 太佩服了。 我上次测试好像才 4000 多词汇量

我也没碰见过这种情况~ 这种问题的排查我感觉挺难的，因为涉及到 linux 内核了，我也没正经八本的学过内核的东西。都是零零散散的。 我能想到的也就是在有问题的 pod 里开个 tcpdump 实时监控， 然后发请求看延迟，如果是网络问题，它可能会延迟个几秒 tcpdump 才能监控到，说明网络有问题。 但具体要我排查到哪个内核参数，我也做不到~ 内核的东西了解的还是少。

有啊，我现在就在瓶颈了， 今年 36 岁了， 技术职级已经到了我能触及的天花板了。 现在我自己的感觉就是即便再去学技术，也升不到下一个级别了。 再往上升需要产出有足够影响力的东西，可能是跨团队甚至跨部门的东西，而这些东西不是单打独斗能搞出来的，需要团队和业务的加持，但我当前的业务和团队都不够分量。所以受业务限制，我即便再去学习新的技术或者再深挖当前的技术，都很难升上去了。 以前没太大感觉，觉得有技术哪里都行， 现在深刻的感受到业务和团队的重要性。

没专门学过性能，其实都是针对 K8S 和 linux 的学习以后，自然而然的就有排查思路了。 所以还是要熟悉我们测试的产品的原理才行。

这个是你微信么

我看大家还都是按照没有专职的性能岗位这样的思路来回答的，这个大家说的也都没错，我就不重复了。 目前的行情是比较看中测试开发人员的综合能力的，这也是为什么大家都劝你别在性能测试上下太大的功夫。 但其实我想换一个思路来看这个问题，其实要做好性能测试的话，本身是需要比较强的综合能力的，当你把一些复杂的性能测试场景玩明白了以后，那么也就练成了一身较为不错的综合能力了。当然如果大家认为的性能测试就是用 jmeter 这样的工具对某个接口施压统计出个 TPS 这类的指标的话，那就当我没说了，因为如果负责的场景就是这么简单，那确实练不出什么有竞争力的技能。

我用一个我带的姑娘做的性能测试场景举例吧。

• 首先她需要模拟的就不是并发量，而是设备数量。因为我们是一个基于计算机视觉的人工智能产品，所以对接的都是网络摄像头，不能用 jmeter，而是使用 ffmpeg+ EasyDarwin 来搭建流媒体服务器。针对测试数据也需要裁剪，拼接，抽帧，调整分辨率等工作。 这需要测试人员学习一些视频领域的东西。
• 她需要学习 K8S 和 docker，因为我们产品整体是基于云原生架构的，她除了要在日常工作中有操作 K8S 和 docker 的需求，也需要把她的流媒体服务器和性能测试工具等等部署在 K8S 中。需要了解 K8S 怎么管理资源的，怎么计算负载均衡的，怎么实施资源超卖的。
• 性能测试除了要测试性能瓶颈外，还需要进行容量测试。尤其是在云原生架构中，每个容器都申请了不同的资源（cpu，gpu，memory，存储），这些资源具体应该设置成多少需要经过严谨的性能测试。而云原生 往往伴随着微服务架构，所以这个姑娘往往要面对几十甚至几百个服务的资源用量统计，包括每种资源的 request，limit，平均占用，最大占用等等，并需要分析每个服务的资源设置是否合理。 这种数据收集和计算的 工作如果是人肉的那很显然是不能接受的。所以她需要学习监控系统的使用，在我们这里就是 prometheus，这需要对 promql 比较熟悉，通过编写代码来向 prometheus 发送 promql 来进行统计和计算。 这里除了要学习 prometheus 外还需要学习前后端的开发，因为我们这里是把这个监控能力平台化了。
• 再说容量测试里，如果涉及到了一些存储系统，那也需要评估出需要申请的存储量，比如我们最近在执行的性能测试里包含了 ES 组件，这里需要测试出 ES 在 我们的业务下需要支撑多少数据量，在该数据量又下能支撑多少 qps。这就需要她对 ES 有一定的了解，需要学习 ES 官方的压测工具 esrally 的使用。

以上是我们这里这个妹子需要去学习的技术点，这样她才能完成她的性能测试工作。 而如果是我 曾经带过的另一个组（他们测试大数据产品的），那里的性能测试则是需要模拟大规模数据的场景 。所以他们需要学习 spark，hdfs，异步 IO 等技术。这个细节可以看我之前写的帖子：https://testerhome.com/articles/31471

总之就是其实负载的性能测试场景搞下来，也是会练成一身不错的技能的。但严格意义上来说， 这里面很多技能确实不算是性能测试技能。这个就看大家怎么看待这些事了，我个人觉得重要的不是性能测试本身，而是通过性能测试能学到什么，就像我聚的例子，我们这的这个姑娘就算以后不做性能测试了也没问题 ，因为她通过这份工作学到了 prometheus，k8s，docker，前后端开发，视频处理以及部分中间件，所以他换一家公司去做别的工作也没有问题。最后我想说的是分析系统性能瓶颈并给出优化建议这事对于测试来说不太现实，现在软件架构复杂到了已经轮不到测试人员指手画脚了，最好别妄想能指导专业的软件架构师做事情。专业的事情留给专业的人做就好。

我已经不在范式了~~ 目前在腾讯， 我们这现在没有集团 hc 了~ 只招西安的~ 现在行情难啊

我个人是不太会写简历的（我没经过编写简历的培训），所以我写简历挺随意的。 我的思路一般都是在想 -- 如果我是面试官的话， 一般我想从简历里知道什么东西。所以我一般都喜欢简历里直接去写我最擅长的东西和我认为我做的最重要的，最能体现我价值的项目，并且我会把这个项目的技术会较为详细的写一下（目的是希望突出项目难点）。 因为我在做面试官的时候，其实很懒得看那么长的简历的， 尤其是为了凑字数而写的各种流水账我是很不喜欢看的。所以我做面试官的时候希望候选人的简历是能直接看出他最擅长的东西是什么的（要是流水账太多我就会弄不明白他到底擅长什么），我写简历的时候也会把那些不重要的直接忽略掉不写（工作 10 几年了，要是都写那得多少页）。

我这里贴一段我简历中的一部分， 大家可以讨论一下， 我的简历带有我强烈的个人风格， 其实我也不知道这么写是不是比较好。

我的简历里， 基本上就是 3,4 个这样的项目撑着，其他的基本就不写了，或者在个人简介里一笔带过。 我的想法其实就是不想让一大堆的东西晃到面试官的眼睛， 让他迅速的知道我擅长什么（写太多了，我估计面试官就不知道我到底擅长啥了，或者直接就不想看了）。而且东西写多了，还有个缺点就是面试官一下子就跳到了那些没什么亮点的东西上去问， 那就更不好了。 所以我的习惯就是只要我写在简历里的，就是有亮点的。

如果实在有太多的东西想要点缀上去， 我的习惯是放在个人简介里：

哈哈哈哈， 有那味了。

欢迎大家加入

感觉老板喜欢推敏捷， 其实还是想迭代速度快一点吧， 不想搞几个需求就拖那么长时间， 毕竟市场如战场。 其实老板心里也知道在这个阶段质量不是那么重要，别有严重的 bug 或者 bug 别太多就行，还是抢市场更优先。 哪天老板开始抓质量了，那就说明要么是之前有点玩脱了，质量有点看不下去了。 要么就是客户的数量已经到一定程度了， 必须要开始抓质量来稳用户了。 要不然以 TOB 产品的特点，质量不好的话光是给各个版本打补丁都会被玩死的。