之前不是在这里说过 拿了一个大厂的外包岗位 offer 吗，我当时最终决定去的这个。
我是做 Java 的，一般来说，大部分公司正常的做法是 SkyWalking + 日志平台（比如 ELK ）来排查问题。
这个项目组排查问题只能通过 SkyWalking 你敢信？你想通过日志打印的某个关键字来搜一下具体错误日志？对不起，没有办法。
比如，上周给我派了一个生产 BUG 让我解决，这个 BUG 是在 mq 消费过程中产生的（这个是重点）。
由于将 mq 集成到 SkyWalking 中，导致它的日志没法在 SkyWalking 中找到，取而代之的是把消费过程中发生的异常保存到 MySQL 的一张日志表中，。
我通过这张日志表排查到是一个 SQL 执行出错了，但具体的 SQL 错误信息没有，然后又因为没有日志平台，导致一个很简单的问题（如果有日志平台，直接去日志平台看一眼详细错误就知道了）花了很长时间。
最后解决办法是一张张表去看是否有生成记录（这个 mq 消费过程中会插入很多张表），如果某张表没有生成记录，那问题就发生在这张表上，最后再一个个字段去排查，发现原来是字段值超长了。。。
……
除此之外，还有很多一眼草台班子的地方
不过有一说一，有些地方还是还是做的不错的，比如各种权限管控、各种文档也比较齐全
第 1 条附言 22 天前
还有个让我不能忍受的地方，这边接口的入参和出参都是实体类
本来实体类是专门用于处理数据库表字段映射的，这个项目组倒好，把这个作为接口入参、出参
接口需要加参数怎么办？答案是直接在实体类里加，但不加数据库字段注解，这样就不会映射到数据库
然后加字段还没有一个统一的规范，有的字段加在了一堆 GET SET 方法里面，找起来非常困难
关键不止外包人员这么做，我看了提交记录，甲方自己也这么做
本来实体类是专门用于处理数据库表字段映射的，这个项目组倒好，把这个作为接口入参、出参
接口需要加参数怎么办？答案是直接在实体类里加，但不加数据库字段注解，这样就不会映射到数据库
然后加字段还没有一个统一的规范，有的字段加在了一堆 GET SET 方法里面，找起来非常困难
关键不止外包人员这么做，我看了提交记录，甲方自己也这么做
 | 1 cctv6 23 天前 说实话，skywalking + 日志平台 肯定是少数，别看网上说得多，真的用上的却不多。推动部署这些东西，也是阻力重重。 |
 | 3 dcdlove 22 天前 反正我们公司日志平台就是 docker 容器 的查看日志命令  建议无数次用 elk 或者其他日志平台，这帮蠢货就是不搞，每次接口报错还要前端配合给他们请求接口地址和请求参数，接口数据校验都不做 |
| 4 cctv6 22 天前 via Android 其实我想说的阻力，就是来自技术负责人，和开发，运维在生产环境上加东西是要负责的，也是需要授权的。部署配置这些服务简单，但是要配置好还需要开发支持 需要调整日志输出。以及权限问题，日志谁能看，能看什么。 |
 | 6 Niphor 22 天前 有 SkyWalking 就不错了，现在都还只能登服务器看日志文件 |
 | 7 freeup 22 天前 所谓大厂是因为商业模式的成功而累积了资本才成为的大厂，其研发侧肯定也是只能说比上不足比下有余，至少大部分不是很多人想象中的那种大厂该有的研发环境 |
 | 8 harlen 22 天前 有 SkyWalking 就不错了.日志我们都看不了。代码还是手动复制粘贴部署的 |
 | 9 flmn 22 天前 skywalking 都用上了，真不草台。 我们排错 tail ，less ，grep |
 | 10 ldx78203199 22 天前 。。。同感，我们都是直接上机器，还有我所在大厂运维是支撑所有部分的，所以大部分的 RD 自己就是运维，有问题就上机器梭哈查 |
 | 11 ivanMeng 22 天前 想起前些年日子 直接当一线开发 半当运维 因为公司就一个运维、看日志 直接上生产多个机器 分屏 tail grep 的 |
 | 13 itechnology OP |
| 14 flmn 21 天前 @itechnology 要不说草台呢 |
 | 15 sunwei0325 21 天前 skywalking 不是 APM 工具吗? 看日志不是去 Kibana 吗? |
Select Language