[菜鸟]浮躁心态不可取
乐乎今天早上一睁眼手机告警信息爆了，打开电脑看下日志，服务在不断的重启，panic 。还好有些健康的实例在扛着，流量也不是很大。没有造成线上事故。初步判断了下日志，显示的是读取配置的时候导致的 panic ,第一反应是中间件那边是不是有问题了，从新发版本以后就正常了。
来到公司， leader 叫了我一下，提醒了我一下 有关 gc 的配置没有配对，导致的内存溢出了。我很奇怪没看到内存溢出的告警，都是运行时 panic 。仔细的翻到了最开始发生告警的地方，还真的有一条 oom ，现象是这个应用 oom 后就一直在 panic , 其他的事例也陆续的 panic, 告警就被 panic 淹没了。仔细排查了一下 panic 的日志，还真是程序底层在做 gc 相关的操作失败导致的报错。
问题的主要原因是我设置了 GOGC = off 关闭了 go 语言的自动 gc ,又没有设置 gc 触发的时间。我当时因为要解决线上频繁 gc 的问题，同事跟我说:设置下 GOGC 参数，我自己没怎么过脑子看添加上以后 gc 频率下来了就没有多想。自己本身在系统底层知识的掌握就比较欠缺，这种情况下草率的设置一个参数，删除一个参数。不知道其所以然的行为，是非常愚蠢的。
经过 leader 的提醒后，我赶忙查了下 GOGC 相关的设置参数，其实这些相关知识不是三言两语能学明白的，好在之前 java 的 gc 也学习了一些，gc 本身的底层逻辑是想通的，而 GOGC 的参数设置又比较少。发现了自己没有设置触发 GC 的内存限制, GOMEMLIMIT 。 当我加了这个参数发好版以后，发现监控上的内存利用率并没有下来（达到内存限制后，没有触发 gc ）, 然后我又开始了一系列的愚蠢的行为。。。
首先我看了下其他应用也配置了这个参数，我脑子里就在想，他这么配 ok ,我这么配置咋不行了。
然后开始了大家来找茬的对比了一通。
google 了一下无果。
以为自己参数配置错了，查看了下文档，调整了参数重新发了版本仍然不生效。
这个时候我的脑子已经不转了，只能找了下同事帮忙 check 一下。
后来我挺不住了去吃饭了，他发现我们的框架里已经不在是用 GOMEMLIMIT 参数作为 gc 配置了，而是用了 MEMORY_LIMIT_PERCENT 这个参数，在项目启动的时候去调用 SetMemoryPercentLimit, 而我没有看到这个配置的原因是，这个参数被放置到了另一个配置文件中，而不是在应用配置的环境变量里。
最近愚蠢的事情做的挺多的,印象里有 2-3 次了吧，总结下模式
- 遇到一个奇怪的问题，经常是照抄了一遍之后发现不行
- 找茬，看看自己哪里没抄对
- 看代码，这个问题对应的功能在代码里是怎么实现的，哪个环节是有问题的
- 找同时 double check
- 最终往往是同事帮忙找到了细节中的魔鬼
感觉这样做事情有点像个愣头青的菜鸟。长此以往会损失他人对自己的信任。该如何矫正自己呢？我发现那些帮我解决问题的同事，他们解决问题的时候，都深入到了代码里，看代码是怎么工作的。虽然我也做到了这一步，但是我做的不彻底，才导致自己没有解决问题。深入代码后，用最小的成本测试、验证，而不是想当然的觉得这个程序就该这样如何如何
关于自己没有掌握的知识，遇到了就把他记下来。一个问题一个问题的补， 不是总说自己不知道学啥吗？这就是自己要去学习的方向。勤能补拙,不要觉得自己学了点皮毛就懂了
最近项目中遇到的一些问题，让我意识到了修剪的必要。随着版本的迭代，有些功能已经不用了,但是由于没有修剪，代码之外散落着各种不知为何物的配置。后面的人只有两种选择，要么全抄,不费力但是留下了维护成本。要么修剪掉不需要的配置,可能会引起一些未知的问题。提起修剪，也是 leader 经常和我们提起的，这种意识我深有感触。在我看来，修剪是一种在大千社会下的修炼，环境很复杂，你要自己选择怎么去做。我们在日常的开发中，经常都是来了需求就实现需求，一个版本一个版本的迭代，产品，开发人员都在流动，最终堆砌的代码是需要开发人员去理解，维护的。我们当时对于需求的解决方案，也并不是非常完美的，只是当时情况下比较合适的方案。这一坨坨代码经历一代代大师开发后，无疑会变成“屎山”一坨，最终逃不过新坨换旧坨的命运。我们只有长留修剪的心态，每次让他变好一点，让他更健壮一点。也算对得起自己的职业生涯吧。
自己还需要的学习的地方