一次生产故障引发的一些思考与问题，请大大们帮忙分析

[zhoudaiyu]

我们是公司的 K8s SRE 运维团队，近期发生了一次生产故障，一台机器上某 2 个 Pod 里面创建了很多线程，达到了宿主机的 pid_max 的阈值，机器上所有进程在某些达到阈值的时刻都无法创建新线程（ Pod 正常），导致了故障。
我们领导的想法是，他们线程创建过多了，并且是不应该创建这么多的（也得到了对方的认可），这是直接原因，我们设置 pid_max 较低（约 10 万），是间接原因。开会讨论我们要补齐相关告警，优化 pid_max 的配置，并从 kubelet 维度限制 Pod 的线程数。但是开发的领导说，这次是 pid_max 导致的，如果下次是别的内核参数不对出问题怎么办？我的领导说让我参考一下其他集群的相似的机器的内核参数（有多个生产集群，但是硬件配置，操作系统，内核，k8s 版本都不完全相同），修改出问题的机器的配置。
我部分赞同领导的想法，但是我也不能确保没出过问题的机器的内核参数配置就一定对，而且同步过来参数是不是一定适合这台机器，这也不好说。
我现在有疑虑的点就是，在我们的技术有限（运维经验都在 3 年以内），人力有限（ 3 个人运维 300 开发团队的应用）的条件下，如何能解决这种认知范围之外的问题（之前没有线程数监控，甚至排查的时候也花了较多时间才看到），因为操作系统实在是比较复杂，各类的内核参数、system service 配置等等实在是难以完全掌握，确实没有办法保证不会再出类似的问题。而且，为了控制成本，领导也不打算社招一些丰富经验的老运维去带带我们。

[xueling]

@zhoudaiyu 光测试我倒觉得用处不大，很多线上环境中的问题，测试服务暴漏不出来。不要觉得云服务多么完善似的，人家只分配给你固定资源，不要想当然以为出了问题这些云服务厂商会一直给你排查。他们只处理整个集群层面的问题，如果只有你自己的服务出了问题，主要还得自己处理。就像你说的线上故障，本身定位到 pid_max 的故障原因都花了很多时间。线上问题的排查需要逐一排除各种可能的原因，云服务厂商有可能给你提供全方位的服务吗，毕竟对于云服务厂商来说，这里面涉及太多比如用户数据隐私、人力成本等等因素了。你说的监控告警指标，网络搜集就足够了，比如： https://cloud.tencent.com/document/product/457/39820 你自己网上找找，把这些云服务的监控指标汇总一下就 ok 了。

[guanzhangzhang]

每次发生生产故障，监控也很重要，有没有监控，没有就部署上，有监控没监控到，如何监控上。后续在考虑看看怎么限制