这是一个创建于 649 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司一套十几年前买的外包写的外贸商城系统，3 个程序员修修补补用了十几年，什么日志都没有，变量名乱起，函数名和作用不一致，平均每月炸两次，一大半能重启解决（莫名其妙数据库连不上，日志里没有任何错误，重启服务没用、nginx 莫名其妙写了 1.6TB 稀疏文件把固态硬盘写满了，重启就会消失 这类完全不知道怎么排查的故障），关键还经常半夜炸，然后时差原因半夜还是客户最多的时候。
不想润，因为系统没炸的时候非常闲，基本都在摸鱼，每周只要工作半小时那种
不想润，因为系统没炸的时候非常闲，基本都在摸鱼，每周只要工作半小时那种
 |
1
imdong 2023-03-03 23:45:57 +08:00 via iPhone
定时器，比如定时重启，
|
 |
3
edis0n0 OP 单函数名和作用不一致这一个就被坑过好几次，例如 /t/899919 在发邮件通知的 PHP 文件里扣手续费导致账对不上，一晚上找不到问题出在哪
|
 |
5
opengps 2023-03-03 23:54:50 +08:00
重启能解决，大概率是资源没及时释放，内存泄漏句柄泄漏等问题
|
 |
6
v2defe 2023-03-03 23:56:20 +08:00 via Android  4
系统稳定了你不就不稳定了🙂
|
 |
8
aureole999 2023-03-04 00:06:07 +08:00 1
快速的办法：把所有不稳定的功能全删了就 ok 了。
开个玩笑。既然都叫屎山了怎么会那么容易就让你改好，这东西只能一点一点改。 比如先加上日志，这不算重构吧应该。然后改一些方法内局部变量名，再到改全局变量名，改方法名，加注释。改完名加完注释应该就通读了代码并有一定的理解了，加测试用例，自动回归测试。然后改小的模块，最后改大模块。别想一口吃个胖子，反正除了炸的时候都很清闲，那就慢慢改呗。 |
 |
9
fisherwei 2023-03-04 00:12:49 +08:00
首先，nginx 的那个问题应该好解决吧，你们这个系统是有大量上传文件的场景吗？
|
|
10
edis0n0 OP @fisherwei #9 都是一些图片上传的场景，仓库出库图片、客户返图一类，十几年数据量 300GB ，nginx 请求 body 最大是 2MB 。
|
 |
11
night98 2023-03-04 00:20:21 +08:00
简单点，上监控，各种监控搞起来，有了监控就能发现大部分主要问题，然后解决掉。
次一些的，把核心链路拆出来重写，其他非核心链路的上监控慢慢调 |
 |
12
Chad0000 2023-03-04 03:38:26 +08:00 via iPhone
先上日志系统
然后业务代码迁移到.net standard 项目以做好迁移到 core 的准备 |
 |
13
netnr 2023-03-04 05:56:02 +08:00 via Android 2
长时间稳定运行，会增加你 OUT 的风险
|
 |
14
azusematsuri 2023-03-04 06:31:55 +08:00 via Android
按功能后端，一部分一部分重构到 go
|
 |
15
searene 2023-03-04 07:04:39 +08:00
有可能是内存泄漏，建议加监控、日志
|
|
16
Chad0000 2023-03-04 07:33:25 +08:00 via iPhone
@azusematsuri
迁移到 go ？写惯了 C#就很难（不想）迁移到其他语言了。 |
 |
17
litchinn 2023-03-04 08:26:12 +08:00
“系统没炸的时候非常闲”，万一搞好了，它不炸了，领导觉得不需要你了咋办 doge
|
 |
18
forgottencoast 2023-03-04 08:26:29 +08:00
平时很闲，就平时慢慢改啊。。。。
|
 |
19
pengtdyd 2023-03-04 08:39:55 +08:00
《计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决》
|
 |
20
yjd 2023-03-04 09:14:35 +08:00
连半小时都省了，是不是离离职不远了^_^
|
 |
21
lingex 2023-03-04 09:18:26 +08:00
看着有点兴奋哈，每解决一个都是很有成就感的。
先加日志吧，出问题的操作多加点，如有可能每个跳转都加上。 |
 |
22
jaggle 2023-03-04 09:22:05 +08:00 via iPhone
好奇问一下楼主你们的日订单数量多少多少，能重启而没用户不抱怨吗
|
 |
23
centralpark 2023-03-04 09:49:59 +08:00
加日志，加单元测试，加监控。切割好了才好改。当然，就像楼上说的，这一切都不要让你领导知道，不然你的地位危矣
|
 |
24
awalkingman 2023-03-04 10:00:29 +08:00
@v2defe 哈哈哈哈哈你是懂稳定的
|
 |
25
vacker 2023-03-04 10:07:28 +08:00 via iPhone
你是老板的话你可以直接重构，否则 保持现状修修补补就好
|
 |
26
charlie21 2023-03-04 10:09:39 +08:00 via Android
jQuery 时代的吗？
|
 |
27
falcon05 2023-03-04 10:25:30 +08:00
我现在也有一套这种的，非常恐怖，nginx 的配置太蛋疼了，换成 openresy ，准备学点 lua ，相当加了一层。
|
 |
28
enchilada2020 2023-03-04 10:37:20 +08:00 via Android
@pengtdyd 求出处
|
 |
29
liangxin1998 2023-03-04 11:10:00 +08:00
git 有一项规则，就是重构
|
 |
30
fds 2023-03-04 11:21:08 +08:00
先给主要逻辑加上些测试？
数据库连接断开可以加些 log 吧，还有压测或者手动 kill 连接试试。 |
|
31
pengtdyd 2023-03-04 11:40:22 +08:00
@centralpark 《“Any problem in computer science can be solved by another layer of indirection.”》
|
 |
32
billytom 2023-03-04 13:22:56 +08:00
@edis0n0 首先，你这是内存无法回收造成的 boom ，那就要定时重启，而不是出问题连不上再重启。把故障率控制到从 40% -> 20% 就够了，不要去碰程序主体（防止手贱问题越来越大），之后好好公司呆着就行。
最后，偶尔半夜 boom 是好事，要让老板知道你在辛勤工作，这工资给得值 |
 |
33
zhengfan2016 2023-03-04 15:32:03 +08:00
楼上说的很对，维持现状修修补补就好了，
重构好了，没有功劳，一旦经济下行，可能第一个毕业的是你，反正炒了系统也很稳定不会 boom 重构不好，锅全是你的，该卷铺盖被炒的，还是你，搞不好让公司蒙受损失，毕业以后还得吃官司😂 |
 |
34
mafanding 2023-03-04 18:16:07 +08:00 via iPhone
弄一个定时重启+一个磁盘使用量预警 足够了 总要有点工作量 不然你干嘛等老板来开你么
|
 |
35
em0miao0 2023-03-04 18:38:28 +08:00
@netnr 很有道理，我就是被这么干掉的，系统弄得太好，一度没有啥新需求，导致系统长达 4 ，5 个月没啥问题不用重启升级啥的然后被干掉了；所以。。OP 还是慢慢改吧。
|
 |
37
esile 2023-03-05 12:34:33 +08:00
如果你修好了就证明你随时可以被优化掉。
|
Select Language