1
pelloz 2022-02-20 18:13:00 +08:00
开发或者需求要提供文档,没文档自己看搞毛线。没文档的情况下,你只要负责网络是正常的就行。
|
2
miscnote 2022-02-20 18:15:00 +08:00
用 logstash 之类的采集好日志就行,让开发自己看去。
|
3
zhaoyeye OP @miscnote 主要是我每次都是在客户那里活动,而且是纯内网的环境,拷贝文件都得用光驱比较麻烦,所以想学着怎么解决问题。
|
4
YaakovZiv 2022-02-20 18:21:56 +08:00
这得看团队内研发的技术、态度、脾气和时间。
有的研发会有自己的问题排查手册,可以要一份,只要不是很懒的,基本都有,以前带我的老大说,先标准化,规范化,才能自动化,自动化之前得积累一些文档,里面记录了问题相关信息,以备后续自动化用到。 有的研发时间充裕,愿意讲解,就录屏存档,顺便问下排查排查思路,优先哪几个组件,优先哪些日志。异常信息特征。 有的研发技术好,但是其他几个因素都不好,这种要么有时间请顿饭,要么其他方式拉近关系,然后请教对方在处理问题时,需要重点关注哪些组件,需要重点关注哪些异常特征。 |
5
HOU 2022-02-20 18:47:58 +08:00
你们可以的,我们这除了明显的前端或者网络问题,其他都是直接抛给后端,由后端定位问题再找前端或运维同学协调处理,运维最多是给导出一下日志,或者给开发提供一下远程桌面让开发自己看日志
|
6
wzzzx 2022-02-20 20:12:25 +08:00
你没懂项目的代码细节时,读日志也是读不懂的丫
|
7
ClericPy 2022-02-20 22:24:03 +08:00
我擦 内网还没有 elk, 硬看的话时间长了会积累越来越多的事情, 运维也有掉头发和不掉头发两种干法的...
这运维要搀和开发的事情, 如果条件允许先制定一套企业级的日志输出规范吧, 不过治标不治本... 反正感觉有点强人所难了 |
8
MuscleOf2016 2022-02-20 22:48:42 +08:00
@HOU 我们是,一股脑扔给前端,前端定位好哪里问题,再转
|
9
toptyloo 2022-02-21 01:21:26 +08:00 via iPhone
接 ELK
|
10
sutra 2022-02-21 01:25:12 +08:00
就算是开发自己,不对照源码,也是很难看懂自己写的日志的。
|
11
killva4624 2022-02-21 10:07:43 +08:00
不懂前端,但后端日志无非是在理解业务大致流程的前提下,多向开发问问题,每次出现 trouble shooting 的时候,通过开发给出的信息尝试自己在日志里组织还原故障情况,一来二去就熟了。
|
12
freeup 2022-02-21 10:33:18 +08:00
出现报错详细 百度搜一搜 了解下报错原理与详细 猜测下产生的原因 然后反馈给开发 听开发咋说的 慢慢积累 就能慢慢看懂了
|
13
luhuisicnu 2022-02-22 09:52:58 +08:00
我一般先判断问题出在哪?运维管辖的就运维处理,开发管辖的就开发处理
|
14
tiga99 2022-02-22 11:54:59 +08:00
如果你没学过前后端,没有自己开发过项目可能比较困难
0. 研究过你们目前产品的完整文档 1. 需要参与整个系统架构设计,可以不参与开发模块,但要有实际开发经验 2. 能够理出整个系统的组件如何交互的,如 C4 图,业务流程图,时序图等 比如用户反馈 a 错误,要能知道用户的请求经过了哪些程序(模块),是哪个程序(模块)抛出的错误,然后去查看错误程序(模块)的日志和其交互的程序(模块)的日志,只要定位到程序(模块)错误就可以了;运维能做的就是判断是否是哪个程序(模块)问题,比如 redis 连不上、数据库的库表不存在、请求某个接口错误、查询不到哪条数据、执行某条语句失败、传参不合规、没有收到 mq 信息; 程序(模块)内部的逻辑就要请开发来看了,然后让开发解释一下,记录下来,多排几次就懂了; |
15
zhaoyeye OP 谢谢各位的建议,新人入行的路上真是困难重重
|
16
perfectlife 2022-02-25 13:44:06 +08:00
看一眼是不是服务器的问题 不是就扔给前后端,或者直接让他们自己去日志平台看
|
17
zhaoyeye OP @perfectlife 那基本上没有我的事情,都是他们的
|