为什么一个线上运行“稳定“的系统要持续运维?

本文由Markdown语法编辑器编辑完成.

1. 问题提出:

在互联网行业, 有一个岗位叫运维工程师. 而且开发人员, 也需要在一个项目上线后, 在前几天/几周/几月的时间里, 持续维护这个项目, 以确保这个项目能够平稳地运行.

我以前其实不是很理解, 为什么一个系统之前运行得好好的, 突然某一天, 看似也没有发生什么特别的事情, 这个系统突然就出毛病了? 为什么同样的代码, 在不同的客户机器上, 会有不同的表现?

难道代码还会选择性工作吗? 还会选择性奔溃吗?

最近几天, 我就在查找一个在医院已经上线几个月的项目问题. 这个项目刚上线时, 经历了一段时期的阵痛. 经过前期的修复, 已经能够较持续平稳地运行了. 我本来以为问题已经彻底解决, 从此可以高枕无忧了. 结果运行了几个月后,在医院运维的同事已经向我报告现场的问题了.

真是应了那句话, 有时候没有消息就是好消息.

既然已经出现了问题, 而且已经明显地影响到了客户的使用体验. 那么就必须查出个所以然来, 给客户一个交代才可以.

2. 问题调研:

在调查问题的时候, 我想到了之前陈皓老师在他的博客(酷壳-CoolShell)中写的一篇文章: https://coolshell.cn/articles/10804.html (X-Y Problem). 这篇文章的大意是说, 一个人问你问题A, 你费了很大的劲, 去回答问题A. 最后发现, 这个人其实想问的问题是B. 因此, 我们在倾听别人的提问时, 可能不能直接就上来回答问题A, 而应该试图去发现, 是否他真正想问的问题是B.

之所以说以上这段话, 是因为我在查找线上问题时,就是根据运维同事反馈的问题A查找解决方案. 但是查找到后来, 我才意识到, 其实问题A只是一个假象, 真正的问题可能是别的问题.

回到上面的话题, 经过差不多两天的debug, 我后来发现产生该问题的原因, 是随着这个系统的不断运行, 数据库MySQL里面的记录越来越多. 而这个系统的几乎每个处理步骤, 都要频繁地和数据库进行交互, 因此运行速度会越来越慢. 最后慢到了客户已经能够感受到的地步, 于是问题就出来了.

找问题花了很长时间. 找到问题后, 解决方案就明确了, 就是将很多过期的数据及时地从数据库中删除. 经过这个处理后, 系统又恢复了往日的速度.

3. 问题感想

以上提到的, 只是由于数据库的数据量迅速增大而引起的, 在线系统运行速度减慢的问题.
这个问题, 我在平时的开发中, 是不会特别留意的. 开发人员也是将很多精力都放在了功能的开发和实现上, 但是对于系统的整体性, 持久性, 鲁棒性等, 可能没有关注太多. 而测试人员, 有时候限于环境的问题, 也无法完全模拟线上的复杂环境. 所以, 就会出现很多在公司无法暴露, 在客户的机器上暴露的问题.

这就需要软件开发人员, 在平时的工作中, 除了本身的功能开发外, 一定要多思考, 多总结. 同时也要拓展自己的知识面, 而不是只局限于自己的那点工作。试想,假如我对数据库更了解的话,那么在设计数据库的时候,通过增加索引,就可以极大地提高数据库查询的效率;同时,也会想到随着数据库数据量的增大而可能引发的问题。

总之一句话,台上一分钟,台下十年功。

参考链接:

  1. https://coolshell.cn/articles/10804.html (X-Y Problem)
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

inter_peng

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值