oferge0311's recent timeline updates
oferge0311

oferge0311

V2EX member #784293, joined on 2026-01-15 14:36:48 +08:00
Today's activity rank 468
oferge0311's recent replies
@unused 没太明白您的意思,方便稍微的说一下吗,我在自测机试一下,工作环境就不去做这个实验了
@Kirkcong 是的,规避这种不必要的风险,就像是您说的,一旦出了事,都是我的;如果弄好了,没什么收益,并且出事的概率是不确定性的。所以我在几个社区发布了帖子,希望是讨论一下,如果是有效的方法,我也仅做个学习记录。
@dream10201 您的想法是好的,但我想了想,在自测机可以这样试一下,但我所描述的背景环境,不太适合这种方式,不如不做,做反倒都是你的错了。我只是想多学到一种方式方法。哈哈,谢谢!
@june4 我有考虑过如果先执行 mount -a 是不是万事大吉,但生产环境的 mount -a 如果出现挂载点重复等操作,也不是不可能存在的,如果覆盖挂载,比重启起不来去修还要麻烦。
@Kirkcong 目前就是重启前升级失败的问题,这种一般都是跑 playbook 时的 python 被应用改了,或者 rpm 需要 rebuilddb 重构一下,或者也就是存储满了,升级不了。现在就是有点钻牛角,想要简单且不那么冗余的预防这个重启后系统失败拉起的点。前面 6 楼老师说的直接跑 ai 脚本出来也行。我在试 13 楼老师的取消开启不自动挂载方案在我的本地机,但这种应该不适合在大批量生产环境。有种不如不做,做了反而怪你。
@Kirkcong 明白您的意思,但根据这一季度做的这几万台,能正常拉起系统的,一般都甩不到我们身上。我也不去做这个问题报告,和+1 领导说一下这个问题,+1 领导是技术的,如果是他提供的脚本,肯定是比我从 ai 跑出来的脚本,从”安全与执行“要强的。我们也是用 ansible 操作,机器太多,后续要替换其他的了。我们有个镜像仓库,补丁包打到里面,yum update 去指定对应的仓库名称的特定包,都是写好的 yaml [都是+1 写的]
@Kirkcong 生产环境已经算好了的,问题少的,顶多遇到个 fstab 和网络网卡问题,其他都是配合应用解决它们的服务,测试和灾备环境才是真正属于,运行时候就是个雷,重启才发现。几台可不止,测试灾备最多一晚上 1000 台,生产目前最多是 600 多,几乎都是一个业务的。
@Kirkcong Linux 这个开源项目,内核漏洞不断的被发现,厂商不断的发布补丁,不断的打,太多了,压根属于上上上一个还没打完,又来新的,只能是可着优先级高的业务系统进行操作了。而且我也不想去管这个,不是该操的心,只想看看能不能学到一种方法,丰富自己的同时还能减轻工作,毕竟每次遇到机器起不来修也很麻烦,走各种流程
@cslive 要做到的是重启前的检查呀,fstab 文件拿最简单的,defaults 没有 s 都会起不来进入救援。
@Kirkcong 五六台。。。。我们的机器还是蛮多的,测试灾备的主机环境是这个的千倍多,生产比测试灾备的要多几倍
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   4676 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 09:50 · PVG 17:50 · LAX 02:50 · JFK 05:50
♥ Do have faith in what you're doing.