ps 一句，你们 kpi 居然有按 bug 等级来列的？猪队长赶紧跑。。。
没有程序员不出 bug

把 1 和 2 做好了是在帮你省事，不是在指责你的设计也不是指责你的实现，测试没这个闲工夫。但他如果是能力强，他可以通过数据结构和日志帮你分析出问题在哪。你直接去改就好了。不要抱有敌对的心思。我个人认为 1 和 2 不是你的疑问，是 3 触及了你的利益，所以你觉得不爽。这个是可以沟通的，他不搭理就找他头。

1 和 2 没毛病，作为研发反而要配合他们得到这个信息，说得不好听点，现在的所谓功能测试的人员 80%都达不到这个水平和要求。但这是测试进一步发展的基本要求，连数据库不看，日志不看，啥都不看，就在那点点点？ 1 年和 10 年没啥本质区别，被毕业被和谐太正常了。我的观点一直是只会点点点的测试，迟早被淘汰。没有任何竞争力，真当以为精通业务就牛逼了？业务天天变化，任何行业都是如此。今年的和 3 年前的可能连逻辑都不是一个逻辑了。

在今年秋招普天同庆的市场行情下，这简历真的，可能连测试都没人要。。。海投吧。

据说俄罗斯为什么 IT 其实巨强，就是因为他们小学生就会正儿八经的编程，开始很高级的数据启蒙

lz 是面试太少了。。。这样写的通常都是模版导出来的。。。

@wandehul 我所感到困惑的就是强制要求 terraform 去变更线上资源这一点上，terraform 擅长的是基础资源。但依然无法解释，强制性，带来的收益和损失两者之间的投入产出比是如何的？比如我前面说的弹性伸缩的场景下。再比如很容易 k8s 的资源也纳于 terraform 管理。实际碰到的情况就是，通过 ansible 或者其他工具手段组织的结构，可以比较快的响应业务的快速发展需要，而且给后续的优化提供了空间。但是如果只是用 terraform ，就扼杀了这一部分可能性。最典型的场景就是运维人员堆了成堆的运维任务要变更成 terraform 脚本，堵塞业务的发展流程

还有人么？

@xiaket 对应用的定时调整在某些需求下可能是非常频繁的。比如弹性伸缩场景和多资源类型的动态变动这样的场景下。我现在的业务模式就是在低规模时期调整一批应用的配置。然后逐步变化机器配置甚至是数据库配置。企业云端成本也是基础设施运维一个比较有挑战的话题。所以第二点让我觉得很困扰

@dayeye2006199 第一个，阿里云和 aws 我都碰到过尚不支持的功能
第二个，并不说状态存在哪。而是并不是时候一样东西会去修改状态，一个简单的例子，terraform 定义一台机器，但是 ansible 定义他定时开关机或者是 update 一些事情。比如调整机器的配置吧，但这个事是放弃掉 ansible 或者其他工具。而是用代码把 tf 文件拉下来，修改再提交上去？怎么想怎么别扭啊。

管理或者团队的问题我能想明白，并不是说不好，只是这两个点我一直没想明白，不敢冒然大规模实施

巴不得低代码平台。。这可是好东西。。作为研发要用发展的眼光来看待事情。重复简单的工作，老走一套流程太麻烦了

这凡尔赛得高级。。。

这还用纠结？你这 30 多年怎么过来的？
1 有个毛线的前景。。除非这个招你的人和你打了十几年交道你绝对信任他。所有落不到纸面的都是吹牛逼。在 2 这么好的环境比较下选 1 一定是想得太多

现在体检有一样就是头型是否正常。。。

不要把简单问题复杂化。。运维工作不是好看即正确的。jenkins 是现阶段开源里面唯一能做任何事的。没有任何毛病，插件系统是他的优点，并不是缺点。升级也并不痛苦，我们每年升级一次，也没啥问题。部署是要的稳定，不是好看

一只笔，会打开新世界的大门。最近发现一个 app muse 。。。成为我最近的很长时间的生产力输出工具

有一说一，被入侵不是运维的锅，是公司的锅。术业有专攻，公司不安排安全部门。。。要求所有运维都有极高的安全风险控制能力是大概率不可能的。现在 devops 这么活，都是搭个 ci/cd 就说自己是 devops 了。10 个运维里面有 1 个懂代码？不懂代码必然不懂安全控制。

再进一步，如果定时任务是研发写的，研发有责任控制定时任务的安全。如果是运维写的，运维的锅。

再再进一步，代码都背注入了。。只能是从 web 进来的，这锅运维部背

这是送命题啊。。。
给皇后买衣服，买化妆品。
然后再要 5000 铜板买 ps5

换任何合格的领导不留你就是脑子进水了。。。因为不是只有你要走。。是别人也可能要走。所以他 100%会留你，并且给你涨薪。但那又如何？已经在全员降薪了。。还留着？？

另外 ps ，你新东家也很不妙的感觉。如果你有裁人权，一边是跟了你几年的兄弟，一边是一个刚进来连转正都还没的新人。是你你选择裁谁？