运维怎么学习看前后端日志

[zhaoyeye]

运维太难了，前后端报错都得懂，每次问开发都挺麻烦的。

[pelloz]

开发或者需求要提供文档，没文档自己看搞毛线。没文档的情况下，你只要负责网络是正常的就行。

[miscnote]

用 logstash 之类的采集好日志就行，让开发自己看去。

[zhaoyeye]

@miscnote 主要是我每次都是在客户那里活动，而且是纯内网的环境，拷贝文件都得用光驱比较麻烦，所以想学着怎么解决问题。

[YaakovZiv]

这得看团队内研发的技术、态度、脾气和时间。
有的研发会有自己的问题排查手册，可以要一份，只要不是很懒的，基本都有，以前带我的老大说，先标准化，规范化，才能自动化，自动化之前得积累一些文档，里面记录了问题相关信息，以备后续自动化用到。
有的研发时间充裕，愿意讲解，就录屏存档，顺便问下排查排查思路，优先哪几个组件，优先哪些日志。异常信息特征。
有的研发技术好，但是其他几个因素都不好，这种要么有时间请顿饭，要么其他方式拉近关系，然后请教对方在处理问题时，需要重点关注哪些组件，需要重点关注哪些异常特征。

[HOU]

你们可以的，我们这除了明显的前端或者网络问题，其他都是直接抛给后端，由后端定位问题再找前端或运维同学协调处理，运维最多是给导出一下日志，或者给开发提供一下远程桌面让开发自己看日志

[wzzzx]

你没懂项目的代码细节时，读日志也是读不懂的丫

[ClericPy]

我擦 内网还没有 elk, 硬看的话时间长了会积累越来越多的事情, 运维也有掉头发和不掉头发两种干法的...

这运维要搀和开发的事情, 如果条件允许先制定一套企业级的日志输出规范吧, 不过治标不治本... 反正感觉有点强人所难了

[MuscleOf2016]

@HOU 我们是，一股脑扔给前端，前端定位好哪里问题，再转

[toptyloo]

接 ELK

[sutra]

就算是开发自己，不对照源码，也是很难看懂自己写的日志的。

[killva4624]

不懂前端，但后端日志无非是在理解业务大致流程的前提下，多向开发问问题，每次出现 trouble shooting 的时候，通过开发给出的信息尝试自己在日志里组织还原故障情况，一来二去就熟了。

[freeup]

出现报错详细 百度搜一搜 了解下报错原理与详细 猜测下产生的原因 然后反馈给开发 听开发咋说的 慢慢积累 就能慢慢看懂了

[luhuisicnu]

我一般先判断问题出在哪？运维管辖的就运维处理，开发管辖的就开发处理

[tiga99]

如果你没学过前后端，没有自己开发过项目可能比较困难
0. 研究过你们目前产品的完整文档
1. 需要参与整个系统架构设计，可以不参与开发模块，但要有实际开发经验
2. 能够理出整个系统的组件如何交互的，如 C4 图，业务流程图，时序图等

比如用户反馈 a 错误，要能知道用户的请求经过了哪些程序(模块)，是哪个程序(模块)抛出的错误，然后去查看错误程序(模块)的日志和其交互的程序(模块)的日志，只要定位到程序(模块)错误就可以了；运维能做的就是判断是否是哪个程序(模块)问题，比如 redis 连不上、数据库的库表不存在、请求某个接口错误、查询不到哪条数据、执行某条语句失败、传参不合规、没有收到 mq 信息；

程序(模块)内部的逻辑就要请开发来看了，然后让开发解释一下，记录下来，多排几次就懂了；

[zhaoyeye]

谢谢各位的建议，新人入行的路上真是困难重重

[perfectlife]

看一眼是不是服务器的问题 不是就扔给前后端，或者直接让他们自己去日志平台看

[zhaoyeye]

@perfectlife 那基本上没有我的事情，都是他们的