只要小钱钱和桌面大小允许。。。放多少台显示器都不嫌多。。。。

1password 用得比较好，主要是体验方面，这么多非自建的一个能打的都没有。从公布的安全信息来说，就算泄漏也只是泄漏加密的密码。咱们都是研发，哪个脑残的做密码产品的把用户密码保存在服务端？但是。。。凡是有但是，你把源码泄漏了就有点扯了。理论上所有代吗都有漏洞，开源的是有所有人盯着漏洞去快速解决。闭源的被找到路由就要完蛋，这确实是不应该。

反正我不相信我自建的可靠性会比云端的可靠性强，除非付出足够多的成本。低成本的高可用从概率上说都是可以一锅端。

chrome 之类的就不用扯了，本地密码库和本地用明文存文件管理密码没啥太大的本质区别。对有安全要求的，基本没啥意义。

最后看到总结。。。。
what ？你这叫啥总结？？？？

看到这一句。。。线上使用 K8s 部署（单 Node 单 Pod ） bitnami PostgreSQL 14 版本数据库。。我就表示，不是这次出事就是下次出事。
数据库放 k8s 不是不可以，开发测试环境无所谓。生产环境？你是真不怕挂啊。。。。

我觉得这就很蠢。会让 java 研发误 json 的有排序的。

@Ashore 就有 19 页就很迷。。。

是不是可以换个思路？先直接开源，跟公司说你就是做个开源产品。。。。

我觉得没毛病吧。人家就是一个做灰产的。你把你代入他们的视角看看就明白了，如果是你在做灰产，肯定不会明说，而是说一些内行人听得懂的。对方听不懂，说没做过。你是不是第一反因就会说能力不行？做灰产的就是这个思路，并不是看你技术怎么样，是看你做没做过。做过就是 7k 。没做过就是 700.。就这样。。。

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 文件拉下来，修改再提交上去？怎么想怎么别扭啊。

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

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