打卡 +2

前年也有想法搞这个，后面因为各种事情耽搁就搁置了，挺好的，点个赞。

滴滴，学生卡

所以我其实是想设计一套跨地域多集群的通信方案，跨地域的带宽跟流量计费可以保持跟 CVM 一样，量大便宜，流量转发性能损耗低。

摘取见开头。

走的 CVM 外网带宽，同享 CVM 的限制，比对等连接限制少，便宜。

主要还是因为太杂了，业务方向太杂，技术方向太杂，在七年这个阶段可替代性比平均值高。
其实没有天赋，也不想刻苦努力，那么最好的选择就是七年踏踏实实深耕一个方向，那样也会比现在好得多一些。

业务价值，简单来说，就是对养得活自己有正向作用就好了。
终点，其实最完美的是做大做强，向外卷，可复制可规模化，利人利己。
很可惜，现在只有向内卷，自然就看不到终点了。

嗯，落地才是闭环，相比于 KPI/OKR，其实最近一年多我更多思考的是 ROI。
因为是打工仔，除非你做老板，否则你的 ROI，你的业务价值，才是活下去的手段。
包括之前做的很多东西，其实我感觉最宝贵的是基于业务痛点提出来的通用型解决方案，可复制可落地到相同场景。
如果这期间，能用到新技术当然好，用不到，也无妨。
所以作为技术宅，第一个要找到的就是技术与业务之间的平衡。
第二个就是落地，产生的业务价值才是落地的成效。
第三个就是标准化，规模化，可复制化。
以上仅代表个人观点。

挺好的。
不过这样就只能局限于 jmeter 这个引擎吧，其他压测引擎可以通用适配吗~
另外我比较好奇的是，你的很多非结构化日志数据存到了 mysql 里面，日志检索速度是很慢的，这里是怎么做全文检索和实时数据展示优化的呢？

除非没得选，不然不要当外包。

1. 两年以上，最好往测试领域 + 专精技术发展，得深挖。
2. 找机会多落地多实践，纸上谈兵永远只是纸上谈兵。

如果从事云原生相关技术栈，go 就是必备项。

1. 如果想一劳永逸，把安装步骤写进 Dockerfile。
2. 如果不会写 Dockerfile，手动装完，记得 commit 重新打个新镜像。

老哥过来人，大实话。

1. 虚框的 Pod 代表已被删除，因为这里 Replicas=2，所以新 ReplicaSet 增一个实框 Pod，旧 ReplicaSet 就会删一个 Pod，使得实框 Pod 的总数恒定为 2。
2. Deployment 发生变更，ReplicaSet 是有个唯一 hash 做版本区分的。
3. 失效多少个 Pod，ReplicaSet 就会自动拉起多少个 Pod。

不一定，不过先写着吧，就当个科普和总结 hhh

十周年快乐！冲鸭！

不愧是槽神大佬 hhh

有好有坏，得辩证分析，取其精华去其糟粕。

是的，其实告警等于没有，靠得用户反馈，以及 CPU 报错 100% 才发现，为什么不在 80% 就有预警，可以提前扩容或者降级熔断？SRE 的 KPI 肯定是完不成的。

对测试的要求是很高的，然后发现其实大部分都是找开发做的测开，给大家的警示可能是，未来如果所有业务全面上云了，测试该具备怎样的能力？

其实可以看到，没出事之前，容灾，熔断，都没有演练过，重建也没有演练过，这种东西平时如果有节奏定期演练，事故是可以很快恢复的。

明天下午还有个复盘和优化分享会 hhh

这个平台的落地情况是领导的 kpi，你清醒一点，不完善就迭代开发完善，造个轮子而已，不一定要用开源框架。

赞同

token 可以做成 jwt 的鉴权体系，前端缓存数据也完全可以放 localStorage，不要 cookie 也没事。