概述
在3月2日晚上，大概8点左右，本想打道回府，回家歇息，忽然被人在bug群@了一下，说是管理后台，拜访不了，界面上呈现了:
503 service temporarily unavailable
我赶紧尝试拜访了一下，确实如此，但不是每次都不行，而是偶发503的错误提示。其时我是没有马上着手去定位问题，而是先拉了一个暂时处理群，这样做的原因是：
- 先将线上出毛病了这件工作同步出去，要让相关的人知道，像运维、测验、你的上级、产品等；
- 一定是先止损，优先【线下去处理毛病】，而不是【直接在线上处理毛病】；
群拉完后，我简略同步现象后，就开端剖析了，首先想的第一点便是：
是不是因为做了线上改变导致的，比方有发版之类的。
从这个点切入去想的原因是源于自己处理线上毛病的经验，大部分都是发版导致的，能回滚的优先回滚，第一时刻降低影响。因此我打开了发版日历（技能团队是有维护一个发版日历的，记录了每次发版或许改变的内容），发现3月2号当天，在线上做了如下两件工作：
火速电话公司的安全专家，先暂时封闭WAF，但封闭后没有用，拜访管理后台仍是一向呈现503提示，没办法了，得马上回滚当天上线的内容，合理运维要操作回滚的时分，我反而制止了它。因为：
管理后台忽然又能拜访了。
，跟产品和事务方确认了一下，他们也反馈体系康复了。好吧，这个也算一个好消息，毕竟能够给技能团队多一些时刻去定位问题。
体系暂时性康复后，我这边也就没那么大的压力和紧迫感了，静下心来开端着手仔细剖析，找出根因。
剖析过程
是否有突增的流量过来
运用阿里云的SLS日志渠道，写了个简略的脚本，履行后发现，流量一向很平滑。虽然是管理后台的服务，但是仍是要先看看流量的，因为有可能有一些守时任务或许重量级事务操作，导致疯狂的调用管理后台服务。
是否是发版导致的?
因为发版的内容还不少，很难一会儿剖析出是哪些代码导致的，只能利用阿里的日志渠道以及监控渠道，从毛病产生的时刻范围里，寻找一些蛛丝马迹。
首先是查看毛病时刻内，对应的后端服务有无返回状况码非200的，能够运用阿里的SLS日志渠道，写个简略指令查询一下即可：
xxxx_app_id:yyyy not statusCode: 200
上面的一些查询字段，是能够在SLS上自己界说的。终究发现返回的状况码都是200的，这个就有点奇怪，但仍是继续看一下有无异常日志。
xxxx_app_id:yyyy and logLevel: ERROR
发现也没有，初步判断，不是后端代码上线导致的，便转而开端用阿里云的监控渠道调查后端服务pod节点的运行状况，但也没有什么收成，pod既无重启的状况，内存、CPU usage也都正常，也没有什么慢的恳求。
其时就有点摸不着北了，因为那会也比较晚了，后台管理体系也暂时没有呈现问题了，我就先回家了。而隔天又有其他重要紧急的工作要处理，我就忘掉去跟这个工作了，一向到3月6号早上，又开端呈现503问题了，持续时刻是两分钟，然后就又自己康复了。
这次我就把手头上的工作先悉数放下，全力跟进这个问题。通过3月2号晚上的剖析，感觉跟后端服务没有关系，那会不会是前端的node服务有问题呢? 当然平常假如线上出毛病，我很少以为会是前端问题，都是先从后端服务定位起。
但这次没办法，死马当活马医，所以便到阿里云上去看一下前端pod节点的运行状况，发现有重启的状况，我感觉发现新大陆了，马上去确定pod重启时刻，但是很惋惜，我没权限看，就暂时去看一下这个pod的内存波动状况，一般来说，pod有重启的话，内存会时间短开释，公然，在毛病期间，前端的pod的内存占用有下降的趋势，然后毛病后的几秒，内存占用又康复了日常水平。
所以便火急火燎的跑去找了一下运维：
把前端的xxx pod有重启的状况，我怀疑管理后台503问题，是这个原因导致的，你能不能把这个pod重启前的日志发我一下。
其时运维回复说，重启前的日志找不到了哦。当然，这句话我是不信的。就让运维去查一下或许找阿里云的售后，看看怎么拿到pod重启前的日志。公然，能够运用kubectl指令，找到日志：
kubectl describe pod xxxx-pro-vyyyyyyyy | grep ‘State: ‘ -A 5
日志里有几个信息：
- 一个是pod重启前的代码报错日志；
- 一个是pod具体的重启时刻；
- 一个是Exit Code，这个code等于1，阐明pod重启，是服务本身的报错导致的。
报错日志如下：
TypeError [ERR_HTTP_INVALID_HEADER_VALUE]: Invalid value “undefined” for header “Content-Length”
到此，基本就清楚了，恳求先通过阿里WAF和阿里nginx-ingress后，由nginx-ingress转发给前端的service，从而进入到pod，但是因为pod同一时刻都在重启，暂时无法提供服务，service这一层就不知道pod的状况，nginx-ingress自然也就无法知道service的状况，所以便返回了503。等重启完毕后，就又正常提供服务，之所以偶发的出问题，原因就在这儿。
所以便找了前端的开发leader去定位原因，最终他回复说，要改一个底层文件，兼容一下Content-Length为空的状况，改完后，简略在在测验环境和预发布环境测验一下，过一下核心主流程，没问题后，就上线了。
从3月9日上线到现在，暂时没有发现503问题了。
那魂灵一问来了，这个底层文件，从2021年来一向都没有改动过，也没出过啥事，为啥最近才开端出问题呢?
答案是：
比较难查，不知道是哪些恳求会没有Content-Length，但肯定是发版导致的。
本文正在参与「金石方案」
