某公司后端老大遇到 500 错误让前端查是否缺少页面，怎么破？

[stroh]

服务页面挂了，运营找运维看，运维看服务没问题找前端查问题，前端看页面路径上来就 500 了，然后找后端寻求帮助，后端上来就踢皮球，也是醉了，还说是因为前端缺少页面导致的 500...
每次一出问题就找前端，除非找到决定性证据后端自查，现在后端都这么好干吗》


[ccppgo]

楼主脸被打烂了不敢说话了, 赶紧出来谢罪道歉吧

[cxilife]

后端群里可能的讨论。 这个 sb 前端，啥都不懂又开始甩锅了

[hellodigua]

蹲一个结局

[blindie]

看评论，觉得这个后端没有问题的一大把的 CRUD 仔真多。
不管怎么说，都是一个团队的，作为一个后端就算不是你的问题，别人找上门来了，请你看一下日志，来帮助他定位问题，这不也是你的职责范围吗。
说真的遇到这种后端，跟他的沟通成本不如把他开了我来同时写前后端。
给楼主一个建议，这种同事遇到了，一定不要跟他怼完就好了，一定要当时就找自己的主管，把这件事情反应上去，不然你觉得自己什么都没问题，对面直接就告状告你了。最后就变成你背锅，什么破坏同事关系，责任意识不强。一定要找自己的主管，让他知道实情。你的主管会帮你把事情搞定的，比如把这个后端踢开以后项目就不会跟他合作了。

[koloonps]

@blindie 出了什么问题都来后端,这个是页面 500.不是接口 500 啊,前后端分开的项目不应该是去找运维吗?你至少要看下这个页面 500 是后端把你重定向到了 500 页面,还是路由配置错误的 500 啊

[Foxkeh]

建议这种问题不要私聊, 在项目技术群里公开讨论就好, 不然像这次这样情绪激动就尴尬了, 只要你确认前端请求发的没问题就把球踢出去, 真大佬在群里看到就知道去使唤谁去解决.

[lucays]

@blindie 请求没到后端的话，就算找上门来，后端怎么给你日志呢？后端哪来的日志呢？后端只能说让你找中间层啊，根本没到他那。

聊天记录明明是 OP 一直在怼，后端态度又没问题，都说了应该找谁了，不找一直怼后端有什么用吗

[lucays]

@abuabu 这些其实都没啥，最后那句“我也做过后端”真的让我想起我前公司一个类似的前端真的合作不来

[wanacry]

楼主现在怎么样了 到底是谁的责任啊

[ily433664]

@blindie #104 先不看问题原因单纯看沟通，也是前端的沟通更有问题啊
后端开始还好好在沟通，给分析问题让去找人，“你问问丁丁吧”
再看看前端怎么沟通的，“500 能是前端服务报的吗”，“肯定是后端少判断。。。”，“我第一次遇到 500 让前端找少页面的”
明明是前端自认为后端有问题，然后一顿怼后端，怎么反而说后端了？

[sadfQED2]

@zpf124 总结一下问题。

运营发现访问不了，喊运维，
运维粗查监控没有宕机，甩锅前端，
前端一看 500 错误，就觉得这是后端的错，甩锅后端。
后端一看返回的是 nginx 的页面，而且访问的还是前端的路径(聊天里说的)，和我有 p 关系？

最后前端出来发帖："现在后端都这么好干吗。"

最终，在各位网友的齐心协力排查下，帮楼主公司找出了 bug 所在。楼主公司运维，后端，前端继续划水

[fzdwx]

@blindie #104 有啥问题？



这么明显的问题，请求到后端了吗？这么大个 `openresty` 没看到？



别人后端一眼就看出问题来了。

[fengfisher3]

虽然我觉得楼主的语气并不好。但作为一个运维，我真没见过 500 找前端的。
楼上都说过了，500 要么就是运维的 nginx 配置，要么是后端。所以，这个事情最大的问题是在于，运维的锅，为什么找到前端去了呢。

[isbase]

op 的沟通方式也有很大问题。推荐《非暴力沟通》这本书

简单的说：当你觉得对方有问题时，不要反讽或者责怪对方，而是直接说出你希望对方怎么做，例如：现在访问 xxx 出现 500 了，前端这边确定请求没有走到前端，现在不确定是 nginx 还是后端服务的问题，请帮忙查看日志定位下问题。


如果查了日志确定请求没走到后端，再直接拉运维和 SRE 之类的人到单独的群。紧急的问题可以顺便拉上他们老板。

[DT27]

哈哈哈哈，心疼楼主。

[wonderfulcxm]

@zpf124 不，用原生 PHP 起一个服务，php.ini 直接使用生产环境配置，也不要什么框架，随便写个语法错误，openresty 返回的就是这个默认的 500 错误页，而不是 PHP 自带的报错。因为错误会包含敏感信息，比如文件路径是不可能暴露出来的，只会显示这个 500 页面给用户！

[Anarchy]

作为客户端觉得只要 500 就 500 后续问题就该后端牵线解决了。现在前后端分离，前端的处境和客户端也没太大区别吧。不过你们这沟通真是墨迹，感觉是运维拉进来组个小群也好啊。

[Envov]

我也做前端的，感觉 op 沟通方式问题很大

[orangefanta]

都 23 个小时过去了，BUG 还没解决吗？

[godloveplay]

@fengfisher3 #113 从聊天记录中看出 后端一直在说 要去找运维。
我任务 楼主这种属于 眼神不好（学艺不精?）+ 说话阴阳怪气，坛友应该引以为戒

[olaloong]

人菜话还多，都让你找运维或者找别人帮忙了还一个劲 BB ，就这语气后端不开怼算是脾气好了

[iseki]

取决于你对后端的定义了，明显和这位后端大哥没对上。
他的 [后端] ：自己 Java 写的这一亩三分地，别的一概不知
你的 [后端] ：本地发出的 http 请求对端全算后端
实际上看上去像是你和这大哥中间的某个东西出问题了，后端不想说，你也不知道，于是就变成了你俩搁着互相甩锅。

不过啊，这公司的氛围看上去也挺紧张的了，多大点事都能怼起来，这种环境工作可有点累啊

[iseki]

个人非常反对报错吃掉响应体还返回一个错误页的行为，所以即使是后端报了 5XX ，运维控制的网关也不应该这样返回，定位问题都不好定位了。

[zooeymango]

问题还没定位出来就上外网吐槽了吗，没有后续是不是定位到最后结果不理想啊

[imycc]

@iseki #123 5XX 这一系的错误，常见的是后端未捕捉的异常（ 500 ）、超时、不可用的情况，替换成错误页面也能接受。后端 API 除了 500 也不会出这类错，如果后端自己全局捕捉到异常，处理之后也不是报 500 了。

在 nginx 的日志上可以捞到是哪个 upstream 报的 500 ，再去看具体 web 后端的错误日志就 OK 。

[zpf124]

@wonderfulcxm
那是因为 php 和 nginx 的结合方式是用 cgi-bin, 原理上和 允许 lua 类似，属于于 nginx + 插件这种方式，nginx 和你的脚本绑定到一块了，属于 nginx 作为执行者去调用了某个函数然后访问了你的脚本，属于同一个进程内的方法调用，然后函数去返回某个结果，调用出错 nginx 作为调用方是会接收到异常退出信息的。

然而这种题主的截图对话里告诉你了人家后端是 java 开发，java 不玩 cgi-bin 。


实际上 cgi-bin 的优点是非常简单方便，但缺点限制更明显，以前的脚本语言支持这种协议的多一些，php, py, perl 。

但其他大多数语言不论是 java ，go ，.net 还是 nodejs ，甚至你们 php 的许多框架也都直接选择了用自己实现的 http-server 来执行对应的代码，这样可以支持更多的特性更灵活的业务处理。
在这种时候 nginx 只是一个单纯的 反代服务器， 他只有一个作用，反代，完全不会参与代码执行，，这时候就不是进程内的方法调用了， 而是网络传输，nginx 去代用户发起了一个 http 请求到后端服务器上，这种情况 nginx 不会接收到异常调用栈的，这时候他实际上是不会涉及 500 错误的。 只会发生 502 ，504 ，这种 nginx 访问后端超时的错误。

如果这种反代的情况下还触发了 500 ，那只能说明 nginx 除了反代还做了其他功能，比如 lua 脚本或者其他插件进行限流等操作时候发生了 bug 。

[akira]

感觉这后端态度还行吧。。被人这么阴阳怪气的也还是好好说 没有发脾气。。
对不对那是能力问题，但是 OP 这么说话 是要干嘛 好好说不行么

[micean]

是不是线上问题要有人背锅？

[zero47]

小丑，运维说了服务没问题，500 是服务器错误，关后端什么事？还挂人...

[spicecch]

看对话后端态度没啥问题，倒是题主一直在咄咄逼人

[xmi]

蹲一个后续

[arch9999]

自爆卡车

[xFrye]

好好说话，不要把你平时在网上说话的风格带到现实生活中，比如工作上的问题反馈

这位后端老哥已经算好说话了，op 说话攻击性这么强，换做别人搞不好直接让 op 滚了

[blindie]

@koloonps @lucays @ily433664 这个第一句就把自己摘出去了，也没有当即给一个该找谁。这就是你们觉得的沟通吗。
@fzdwx 我根本就没用过 openresty 没办法跟你讨论技术细节。我也不想跟你讨论技术细节，这事情根本就不是个技术问题而是个团队合作的问题。就算跟你合作的是个完全的萌新，误找你了，正常应该是直接拉群三方，后端直接跟运维开始沟通一起定位问题，直接踢回算什么呀。

[lucays]

@blindie 没有当即给出找谁不是第二次回复就说找运维了吗？
你怎么不说楼主全程阴阳怪气呢？不是一次两次，是全程阴阳怪气

[fzdwx]

@blindie #134

确实是团队的问题。

[lucays]

@blindie 首先，谁接到的问题谁拉群没问题吧，这里先接到问题的不是运维就是前端，反正不可能是后端，你说楼主是萌新所以楼主不拉群可以理解后端要体谅他来拉群的话，有全程阴阳怪气的萌新吗？然后还挂到网上来说后端有问题的萌新？

[blindie]

@lucays 正常人谁上来阴阳怪气，有没有可能这种事情发生了好几次了？你说谁接到的问题谁拉群，这是哪里的规矩？我合作的从来都是需要群的时候建群，就这种情况下他们俩谁拉群都可以，但是你看这后端根本就没有要三方的意思，而是直接打回去。你如果是因为谁接到问题谁拉群这个为打回去辩护的话，你根本就没有把解决问题放在最优先。
反正不可能是后端？要做出这个结论就要找到问题，问题都没找到，怎么可能把自己撇清楚，公司的问题解决了吗，团队的问题解决了吗？优先级高起来的时候 CTO 都得拉来一起看，你来帮个忙到底怎么委屈你了呀。

[lucays]

@blindie 不可能是后端(先接到的问题)，关联上下文很难理解吗？怎么就变成问题不可能在后端了
记录里只有前端全程在阴阳怪气，有没有可能每次都是前端阴阳怪气这种事情发生好几次了？
后端能说的最大的错就是不应该直接甩锅应该一起看问题一起找运维，但是就这聊天记录前端问题大了去了

[LeegoYih]

HTTP Status 5xx 肯定是服务端抛出来的问题，但不一定应用服务有问题，显然这个是 Nginx (OpenResty) 返回的错误页面，前后端分离架构不太可能是因为 API 导致出现这个问题，建议自己冷静分析一下再去问责

[wolfie]

@blindie
你是真菜，人都说了去找运维，这属于网管层面的东西了。
而且也给指明了排查方向。

[htoooth]

前端确实不会弄 nginx ，这个也不应该是后端，看 nginx 谁部署的。谁部署谁的问题

[MrWhite]

我也感觉这个后端算脾气好的了。我说的这个后端不是说某人也写过后端的那个后端哈。。。

一上来就发个问号我就想给你一棒槌。。说实话真受不了。。 前几句话就很没有礼貌。。

[wanacry]

你这前四句我直接脑溢血冲到你的工位前去

[ccppgo]

@blindie 又是拉群又是帮个忙委屈你啦, 又是甩锅 比拉巴拉一大堆, 就是没说到楼主的问题, 最大的问题在哪里, 真勾巴恶心啊, 我最讨厌的就是拉群狗, 没事找事, 自己的问题自己解决, 真的需要协助, 要么来工位当面沟通, 想拉个群多弄个背锅的? 自己背去

[allahest]

单纯 500 错误是没法确定错误原因在于前端和后端的，可能 http 请求参数问题导致后端报错也可能的。

[blindie]

@lucays @wolfie 你们开心就好了啦，祝你们仕途一帆风顺。

[zhaomeicheng]

莫名能理解 op 的心理破防的原因。
页面 500 了，大概率不是前端的问题。然而 op 还是去询问了运维，运维说让找后端，后端又说找运维。
请问各位，如果是你，你的心态还会依旧依旧平稳吗？
只是 op 有点冲动了，其实把大家拉到一个群里，心平气和地讨论就好了。
这个事前端没办法解决，最终肯定赖不到前端这。

（还有人在嘲讽前端不懂 Nginx 的，我也不认同。就算前端需要懂 Nginx ，必须每个人都懂吗？
前端都有自己的定位，有人写业务，有人负责基建，有人负责服务适配，没有全能。

[blindie]

@ccppgo 都微信聊了，还工位，还自己问题自己解决。祝您这辈子只能待见面就可以聊的小公司并祝您这辈子所有的问题都只能自己解决。
145 楼 @Livid 此人言辞粗鲁并辱骂正常的工作行为。

[lucays]

@zhaomeicheng 你的话其实可以完美套用给这个聊天记录里的后端，大概率也不是他的问题是运维的问题
我复制黏贴给你看：
页面 500 了，但一看就和 java 没关系，然而前端还是来找我，我说是运维的问题他不信还说自己做过后端肯定是我的问题
请问这个后端如果是你，你的心态还会依旧平稳吗？
这个事这个后端没办法解决，最终也赖不到后端这。
后端也有自己的定位，图里这个就只是写业务的，没有全能。

你觉得不是自己的锅没问题，你不能强行说是某个人的问题，特别是在，结果很可能不是他的问题的情况下，那这个人处境本质和你一样和这个问题没关系你只是多拖一个人下水。
这就是 OP 的问题，而且全程阴阳怪气不会说话然后还丢到网上来。

[lucays]

我就很想知道 op 有没有怼运维
不会这个公司的运维更不好惹吧

[neptuno]

讲道理，提问的智慧，先得找出证据，postman ，请求体，参数，后端返回数据。三者合一，而不是截一个图，就是这个怎么是你的问题（当然很大程度是后端问题），但踢皮球前，你得摆出明显的证据。

[yhxx]

在有些前端眼里，后端 == 浏览器以外的所有部分
在有些后端眼里，后端 == Java 服务本身

可能这就是问题所在吧

[NeroKamin]

@blindie #134
-- 我根本就没用过 openresty 没办法跟你讨论技术细节。我也不想跟你讨论技术细节
本来就是个技术问题不讨论技术细节？这和抛开事实来说有什么不一样？

[iseki]

@imycc 不，对于 API 接口，完全没有破坏原始响应体的理由，500 的响应体对前端可能也是有意义的；对于浏览器直接访问的页面，显然不应该返回一个这么粗糙的错误页

[olaloong]

技术菜就算了，沟通还差，甚至不如培训班的。和你搭档真是有福了

[infactory]

现在前端连 web 应用服务器都不需要知道了吗？不了解 openresty 还不了解 web 应用服务器的作用？哪来的勇气上来要求后端查日志？真是菜的可以

[lucays]

@NeroKamin 别和他说了没意义的
这就是运维前端后端三个人，出问题了，实际问题大概率在运维这，结果运维觉得自己没问题转给前端，然后前端盯着也不相关的后端疯狂输出，后端说应该回去找运维也不听。
然后他上面说的是，后端被找了怎么可以不主动拉群，就算和你没关系你甩锅了就应该被开，你还指望啥？

[blindie]

@NeroKamin #154
你可不可以看一下我跟 #136 的对话，他都说了确实是团队的问题了。您在这儿却自己找上来一定要说这是个技术问题，还说这跟抛开事实来说有什么不一样。你说一年只有三个季节那就是吧。

[Aumujun]

我觉得后端没毛病，有毛病的是 OP 你自己

[xinple]

既然说前端的错误，那 ok ，不用前端任何程序就行了吧？

用 postman 设置相同的参数请求该接口，然后再留下 postman 的官方联系方式，让后端直接联系 postman 修 500 bug 就行了。

[hankli]

笑死，我觉得这后端大哥没问题啊，我甚至还支持他，你让他给你什么日志呢，你写过后端你自己去看日志啊，语气就有很大问题 OP

[heIIokitty]

这个问题最根本的原因好像是不清楚公司项目的架构，前端数据经过了哪些环节最后才到了后台，而且这个中间，哪个环节是谁来负责的，好像也不清楚。。。

[VeryEase]

运维太水了，或者太不负责任了。 问题这么明显，openresty 报错， 要分析定位也是运维先去查配置和日志， 而且应该也是运维才有权限查看这些信息， 然后整个调用链路挨个环节查下去。 后端分析不出来很正常， 请求都没到后端， 啥日志信息都没有， 分析个锤锤， 已经指明了路先去找运维，前端还一直找后端来怼。

[RoshanWu]

火钳刘明

[NeroKamin]

@blindie #159
我为什么需要看你和#136 的对话？他是当事人还是你是当事人？但凡你了解一点相关的技术，你就能明白 OP 给出的聊天记录中后端已经给出了明确的处理链路了，还隔着儿甩锅团队问题？

[rockkakala]

作为后端，从排查问题的思路上已经说得算明白了，只是没有走出最后一步详细地给你解释，拉人帮人一步步确认。再说他不走出这一步，你主动走出主动拉个小群确认这一步又能怎么样。

但截图里“肯定是 xxx”、"这是基本常识"、“哈哈哈哈，厉害了”、"我也做过后端啊"，这些在我个人看来都非常具有侮辱性。即使是后端的问题导致的也不应该这么沟通啊。如果是脾气不好的我，可能就直接喷起来了。这沟通方式根本不是朝着解决问题去......

[blindie]

@NeroKamin 真·夏虫不可语冰。你说为什么要看对话，你到底明不明白你一开始就在看对话？？那你插什么嘴啊？你跟这个后端一样，觉得自己对，那就多看一眼也不愿意。

[wake156]

剧情解读，运营找运维，运维是个水货并且不负责，甩锅前端，前端是个水货，根据 500 得出了错误结论甩锅后端，后端看懂了报错，告诉前端是前端页面资源报错，属于找不到资源，不是后端服务，前端觉得很离谱，500 还想把锅甩过来？后端告诉前端自己职责的是 java 服务，让前端找运维(这是对的)，前端十分自信自己的判断，就是后端的锅，后端不想解释了，建议找另一个懂公司请求链条或者技术体系的前端丁丁，前端根据经验不与信任，后端解释他的猜测，这是生成的目录，前端觉得后端不可理喻，500 你还让我前端排查，阴阳怪气后端厉害了，后端没看懂阴阳怪气，前端想让后端查日志解决问题，并嘲讽后端不懂常识，后端再次指出找运维排查路由指定服务，前端对后端不解决问题的态度极度恼火，于是怒而😡挂人
评论才是最搞笑的，连问题都看不懂

[wake156]

后端看不懂前端的阴阳怪气
评论一大波人看不懂问题
属实是今日份的欢乐又到手了

[wake156]

前后端人员分离和微信沟通真的有毒

[fzdwx]

@blindie #168 我也觉得这个后端对。

[byte10]

@wake156 🤣 很多人语文能力差 没办法，高考的阅读理解的比重得加强，害。

[lneoi]

这问题明显不是前端问题，楼主找过运维了，运维踢皮球，又去找后端，后端觉得服务器不是我负责的，让他找运维或者前端。没人接问题，这下就死循环了。
这种问题只能是，自己有权限，就自己排查，免得踢来踢去。没权限，就把问题扔出去给有权力协调的。

[laogui]

心疼这个前端，运维看到 500 不找后端找前端，后端又让前端找运维，感觉是运维和后端有仇不想说话。

[winglight2016]

这瓜吃得过瘾，lz 肯定是有沟通问题的，虽然沟通的责任在双方，但是发起者作为“期望解决问题”的一方，更有责任推进问题的解决，而不是奔着甩锅、职责的目标去沟通——如果是为了这个，很难在职场混下去了。

至于技术问题，别这么绝对说 500 就是后端问题，相对于 web 来说，的确是整体架构的其他部分都算后端，但是对于某个后端来说就不一定。具体到 lz 的这个问题，本来应该是运维负责判断问题出现的具体位置，但是运维是准备提桶跑路了吧，完全做了复读机，把问题转给了前端，前端大概受了运维的委屈，试图赶快甩锅后端，所以后端解释了一句不是他的问题，马上就爆炸了。

[dlmy]

感觉后端没问题，运维的行事作风很懒散，前端也有问题（在潜意识中认为 500 一定是后端的问题）。
盲猜一波：可能以前也出现过这类情况，积怨已久，并且团队有互相踢皮球的传统。

[AA5DE3F034ACCB9E]

我觉得前端的语气确实有问题，但后端知道应该找运维或丁丁，不应该只是简单地让前端找，最好主动拉个群，减少大家的沟通成本。职责分工每个团队都有自己的情况，但如果每个人可以进一步做多一点，或者换一种做事方法，而不是简单地“推诿”，会更好。

[zhaomeicheng]

@lucays
我觉得把前端的心理动态套在后端上，确实是合理的。
按照咱们俩这样解释前后端的心理动态的话，也许问题还是出在了运维那里。
（ 我并不是说前端没犯错，只是始作俑者确实不在前端这。

[BoiledEgg]

把后端和运维拉个群就避免踢皮球了

[EminemW]

@laogui #175 大哥，这个问题跟后端没半毛线关系，就是运维的锅

[wolfie]

@AA5DE3F034ACCB9E
好家伙，这后端都给指路了，还要让后端给处理吗。《后端就没有 1% 责任吗》 系列？
也就是这个后端可能年龄比较大，没看懂菜鸡 OP 在那阴阳怪气。

[WFDAK]

急死个人了，后续怎么样？解决问题没有？别忘了回复啊，还等着看呢。

[stillsilly]

看内容左边是对的，看态度右边先阴阳怪气……

[3032]

凡是菜的都觉得别人挺菜。

[wenqiang1208]

蹲一个后续啊，到底是谁的锅， 想看看 op 是怎么处理的

[ily433664]

周末都过去了还没后续？

[stroh]

@ily433664 周五就好了，每个人都说什么也没改，他自己就好了，估计是运维的锅

[4771314]

遇到这种情况，直接拉群才能有效沟通，避免信息不对称从而导致排查问题进度缓慢
不过这个后端也确实没有什么责任心，遇到问题而且还是自己的模块，协助解决是基本素养吧
除非能 100%断定和自己的业务无关

[stroh]

@4771314 都在群里，相互甩锅，都说前端页面丢失...我咋办

[AA5DE3F034ACCB9E]

@wolfie 是前后端都有问题，但我觉得后端应该选择高效的做事方法。这一点因人而异，没有强求，你觉得只是告知找某某解决，也是一种正确的做事方式，那当然也是对的。我本身也是后端，我喜欢对解决问题的时候，能提供更多的推动力。

[stroh]

@AA5DE3F034ACCB9E 冰冻三尺，非一日之寒

[h1104350235]

早上花了半小时看完评论，我发现日常争论并不是没有理由的。东扯西扯，没关注问题本身。

[h1104350235]

顺便问下 OP 解决了吗，挺久的了。

[stroh]

@h1104350235 op 是啥？

[ypzhou]

@koloonps 出了问题先找前端的多吧，还是什么都后端

[zhaol]

op 不懂甩锅之道。这种情况，我根本不会下判断是谁的锅。只要我确定不是前端的问题，我就在群里艾特运维或者后端，说前端排查的过程以及没问题的理由，然后让他们排查然。甚至我一开始就不会接运维的锅，500 ，怎么着第一时间不应该是问前端

[raolight]

@stroh Original Poster

[ypzhou]

像 zhaol 说的排查自己没问题的直接大群里说比较好。 @后台 ，运维。不用管他们谁的锅，让他们自己去查。

[zhw2590582]

哪怕是因为前端传错了参数而导致的 500 ，后端也不能推卸这个责任吧