前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >今天被上个项目组埋的雷炸惨了!

今天被上个项目组埋的雷炸惨了!

作者头像
东风微鸣
发布2022-04-21 13:35:05
1780
发布2022-04-21 13:35:05
举报
文章被收录于专栏:东风微鸣技术博客

前言

今天被前一个项目组埋的雷炸惨了! 事情是这样的:

我今年接手了 K8S 平台的管理, 这套 K8S 平台是前一个项目组(某国际性开源商业公司...)实施的. 包括了一整套完整的 CI/CD 流水线.

这套流水线中有用到SVN , 用作一个简易的制品库, 用来存放软件包, 后续的流水线会从SVN中拉取软件包并打成镜像更新.

但是今天! 在使用这个流水线的一个系统开发向我反馈流水线运行报错了, 报错如下:

然后我登录到这个SVN仓库看了一眼, 惊出了一身冷汗! 😱😱😱 -- SVN仓库空了!数据全没了!

这意味着:运行近2年, 所有使用这个流水线的业务系统历史发布包, 配置, 以及基础镜像相关的代码, 脚本全没了!

分析处理经过

如果真是数据全丢的话问题太严重了! 我整个人真的是过了好久我才从这个打击中恢复过来. 第一个想法就是赶紧想办法恢复数据.

第一种可能

登录了SVN 服务器看了下, 10多个小时前重启过. 第一个想到的可能性就是:

  • 共享存储没挂载?
  • 主机迁移过?

赶紧去找主机和存储组帮忙查了下. 结果如下:

  • 该主机没有共享存储
  • 主机是克隆后的主机, 但是克隆前后数据没有发生过丢失

第二种可能

排除第一种可能性. 接下来就仔细先检查了下 SVN 服务器运行情况, 是服务自启动的, 启动后进程如下:

代码语言:javascript
复制
/usr/bin/svnserve --daemon --pid-file=/run/svnserve/svnserve.pid -r /var/svn/

看了下/var/svn, 空空如也, 所有历史数据都没有.

这时注意到/ 目录磁盘有一定的使用量, 所以就想到了第二种可能:

  • 是不是SVN仓库位置不是默认的/var/svn啊?

所以使用du -sh逐一查看各个目录, 还真有收获, 发现root/project 目录较大, 进一步查看排除/root 目录.

再通过history 查看历史命令, 发现 K8S 上一期项目组确实将 SVN 仓库放到了/project 目录下.

那这次自启动后为啥目录变了? 然后用systemctl查看 svnserve的参数, 如下:

代码语言:javascript
复制
systemctl cat svnserve.service
# /usr/lib/systemd/system/svnserve.service
[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/svnserve
ExecStart=/usr/bin/svnserve --daemon --pid-file=/run/svnserve/svnserve.pid $OPTIONS

[Install]
WantedBy=multi-user.target

这个svnserve.service 服务会调用/etc/sysconfig/svnserve , 查看该文件配置:

代码语言:javascript
复制
cat /etc/sysconfig/svnserve
# 输出如下:
OPTIONS="-r /var/svn/"

就是这个地雷💣!!! --

上个项目组, 安装了SVN(同时设置了自启动), 改了仓库位置, 却没有将修改后的仓库位置加入到启动参数中!!! 导致主机重启后自动带起来的 SVN 仓库不对! 😠😠😠

修复

发现问题后, 修复起来就很简单了, 修改/etc/sysconfig/svnserve:

代码语言:javascript
复制
OPTIONS="-r /project/svn/"

然后重启 svnserve就好了.

代码语言:javascript
复制
systemctl restart svnserve.service

总结

上个项目组的七宗罪

  1. 不敬畏客户的业务和环境! 没有站在客户角度去考虑周全.
  2. 安装配置使用 SVN时, 过于随意和草率, 从没有考虑过主机重启的情况!
  3. SVN 安装过程, 未生成详细的过程文档和配置文档.
  4. SVN 安装后, 未生成详细的运维文档.
  5. 交接期, 只交接了SVN 地址, SVN账号密码. 未进一步交接: 主机账号密码, SVN配置信息.
  6. 项目经理, 对项目细节缺乏把控.
  7. 由此展开, 可能还会埋有更多这样我尚不清楚, 但是与整个K8S 系统紧密相关的雷💣. 它们可能散落在K8S 系统的各个角落甚至K8S 之外, 存在较大风险.

冷汗不止

事后我仍然冷汗不止, 因为刚出现问题的第一时间, 我首先想到的是解决图片上的SVN 报错. 而解决的办法, 就是将错就错, 直接初始化一下, 然后用这个空的SVN 仓库... 当然, 如果这样, 那这个雷💣, 相当于是我发现它炸了一个了, 我把剩下的熄灭后, 又埋下去了! 那下一次爆炸, 威力就不仅止于此了.

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-10-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 东风微鸣技术博客 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 分析处理经过
    • 第一种可能
      • 第二种可能
        • 修复
        • 总结
          • 上个项目组的七宗罪
            • 冷汗不止
            相关产品与服务
            容器服务
            腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档