写在前面的话
上线前最后24小时,激动人心的时刻,突然Jenkins重启了。。。。。。
下面记录一下一波三折的过程
一波–Jenkins手动重启?No!
Monitor一直显示着Jenkins所有Pipeline状态,保持常绿,心情舒畅,一键CD应该是没问题了,最后调调小Bug准备下班~~~~
”你们谁重启了Jenkins?“
”¥%??˙˙˙∫??#¥%#¥&**!@#%“
”·?˙???˙?˙???˙∫??˙??˙??˙???????“
”等它重启完再提交吧“
…………
”Monitor怎么没了?“
…………
”我们的PipeLine怎么都没了?“
”快看看Jinkens Log!怎么Log都没了“
”这不是重启,谁给我们ReSet了?“
”是不是Ops操作错误?“
”先看看是不是坏了,先建立一个PipeLine能不能正常创建“
”OK建好了“
求救Dev Ops/Tech Leader
一折–容器内存不足挂了!Volume为什么没有?!
夏:“你看Kubernetes上显示,你们的Jenkins在45分钟前连续内存占用警报,然后容器的down了”
“你们的配置为什么也没了?看来是Volume没配置”
冰:“那为什么还有一个幸存的Pipeline”
……“那是我们自己建立一个实验的”
夏:”那现在容器自动重启了,没问题了,你们自己重新配置一下Pipeline就可以了“
………
XY:”我们负责装一下插件“
HH:”我们负责把Pipeline建好“
XY:”插件装不上,connect error”
夏:“安装插件权限你们有”
经过多次尝试,终于装好了
夏:“可能是资源有限,下载总失败”
10分钟后,距离下班不到1小时
XY:“插件都没问题了”
HH:“Pipeline Ok”
夏:”Credentials配置好了“
ALL:”构建然后上线,尽快搞定“
Keynotes
容器配置一定要将服务的配置文件、数据文件都设置Volume
Log文件也很重要,给自己留一条查看问题的路
容器配置好后,最好模拟一次down up,看看care的数据是否还在
二折–红着不能下班#¥%&那就加班吧
一波Build操作,从灰色全部变成了红色
“我们都配置好了,为什么还是无法运行?”
”让装的插件都装了“
”再试一次“
”还是不行“
HH:”是不是装了插件要重启?“
L:”如果提示了就要重启“
HH:”我怕重启了又Rollback了“
L:“放心,重启吧” P.s.反正现在也是空的
重启后所有后端项目都OK了,前端还是一直红
??:“front-end一直报node sass”
Node Sass could not find a binding for your current environment: Linux 64-bit with Node.js 8.x ? Found bindings for the following environments: - Linux 64-bit with Node.js 8.x ? This usually happens because your environment has changed since running `npm install`. Run `npm rebuild node-sass` to download the binding for your current environment.
描述问题要清晰,紧急时刻要保证交流效率
先确定流程的每一步,筛选出可能出问题的步骤,逐步验证每一步的正确性
对于工具的使用不能只浮于表面
Jenkins构建的Image涉及到Build Number,不应让number重复
对环境的配置/部署尽量使用代码(写到对应的.sh里),而不是直接进入容器操作,以便追踪/复现……
Keynotes
XF:”再Bulid就行了,试试可以么,把其他的也改了,确认一下都没问题么“
XF打开了一个Pipeline,“Set Next Build Number”,设置了10000
”知道,应该包含了Build Number“
XF:”你们知道Jenkins最后构建的image是怎么命名的么?“
XF大佬最后终于出手了
夏:”这个有可能,我们试试能删除么“
L:”把以前build后的删除行么”
…………
冰:“你们Jenkins初始化了?每次构建的Id从1开始了?会不会是和之前的id重复,导致编译后的包无法覆盖”
冰姐闪亮登场
HH:”我又测了一次不行” ——P.s是不是这个时间段,有人又重新构建了一个版本的?无从考证了
夏:”我们这测试访问成功了第二次迭代的接口“
夏:“给我你们没个迭代新增的后端接口”
HH:”后端接口也有问题Postman访问不了“
每个人的电脑在隐身模式下看到的都不一样
一个人的电脑刷新前后看到的不一样
MM:”我这清空了缓存也是第一次迭代的“
HY:”我这清空了浏览器缓存,看起来是第二次迭代的“
娟姐:”你们清除一下浏览器缓存,用隐身模式也行,是不是缓存的问题“
头戴光环的娟姐出现了
”我又上传了一次,怎么成了第一次迭代的了?“
”我们上线了第三次迭代的版本,为什么当前功能是第二次迭代的?“
时间到了上线前最后2小时
三折–人生何处不精彩!staging模拟环境版本神奇Rollback
时间到了上线前最后2小时
”我们上线了第三次迭代的版本,为什么当前功能是第二次迭代的?“
”我又上传了一次,怎么成了第一次迭代的了?“
头戴光环的娟姐出现了
娟姐:”你们清除一下浏览器缓存,用隐身模式也行,是不是缓存的问题“
HY:”我这清空了浏览器缓存,看起来是第二次迭代的“
MM:”我这清空了缓存也是第一次迭代的“
每个人的电脑在隐身模式下看到的都不一样
一个人的电脑刷新前后看到的不一样
HH:”后端接口也有问题Postman访问不了“
夏:“给我你们没个迭代新增的后端接口”
夏:”我们这测试访问成功了第二次迭代的接口“
HH:”我又测了一次不行” ——P.s是不是这个时间段,有人又重新构建了一个版本的?无从考证了
冰姐闪亮登场
冰:“你们Jenkins初始化了?每次构建的Id从1开始了?会不会是和之前的id重复,导致编译后的包无法覆盖”
…………
L:”把以前build后的删除行么”
夏:”这个有可能,我们试试能删除么“
XF大佬最后终于出手了
XF:”你们知道Jenkins最后构建的image是怎么命名的么?“
”知道,应该包含了Build Number“
XF打开了一个Pipeline,“Set Next Build Number”,设置了10000
XF:”再Bulid就行了,试试可以么,把其他的也改了,确认一下都没问题么“
Keynotes
描述问题要清晰,紧急时刻要保证交流效率
先确定流程的每一步,筛选出可能出问题的步骤,逐步验证每一步的正确性
对于工具的使用不能只浮于表面
Jenkins构建的Image涉及到Build Number,不应让number重复
最新评论