这是一个创建于 2354 天前的主题，其中的信息可能已经有所发展或是发生改变。
具体的问题在这里：v2ex.com/t/584034 此贴纯粹吐苦水。
我们团队空降了老板的亲信当领导，从此过上了苦日子，我们团队本来有位资深运维搭建了 Jenkins + JIRA + Slack （ notify ） + GitLab （ hook ）的环境，日志、备份、部署、发布井井有条的，但是空降的领导觉得这一套环境搞好之后，运维没事做工资又高，新项目上线之后就用各种手段逼走运维。
运维走了之后，我们的这套环境简直像黑箱子一样，没人敢动，说是交给某位后端大哥在管，但是貌似这位后端的 Linux 玩得貌似还没我 6，各种粗暴 root kill 操作，当然了我也只是个业余搭来玩玩的水平。
然后就在一周前，我某个前端项目提交上去之后，自动化构建从此就失败了 \@\_\@ ，心里那个苦啊，我居然踩了这颗雷。更要命的是任何 npm 命令都能跑，唯独 npm 的构建命令不能跑，更没有**任何输出**。
这几天就真的是挠破脑袋了，身边没有任何朋友是做运维的，我想尽任何我能想到的方法去暴露、定位问题：尝试回滚代码（无效）、--verbose 嗦模式构建（无效）、npm audit 包管理检查（无效）、Docker 运行空间和内存检车（无效），甚至看官方文档，进到服务器 Docker 里面用 Jenkins CLI 跑任务，在 console 里依旧没有任何有用的输出，npm 和 jenkins 似乎也找不到任何有效的日志或报错。
但是这个项目 git pull 到任何一台普通电脑都是可以构建和输出日志的。我看到 Docker 里 npm 和 node 的版本跟我本地是不同的，却又不知道 Jenkins Docker 的 node 环境是怎么装进去的，也不知道应不应该花时间处理这个（也许又是没有帮助），完全是一片苍白的知识领域，不知道如何定位和解决问题。
现在这个项目的自动化构建完全停住了，领导怪罪下来我也完全没有办法，估计下一个被逼走的就是我了，难受，上来吐槽一下。
我们团队空降了老板的亲信当领导，从此过上了苦日子，我们团队本来有位资深运维搭建了 Jenkins + JIRA + Slack （ notify ） + GitLab （ hook ）的环境，日志、备份、部署、发布井井有条的，但是空降的领导觉得这一套环境搞好之后，运维没事做工资又高，新项目上线之后就用各种手段逼走运维。
运维走了之后，我们的这套环境简直像黑箱子一样，没人敢动，说是交给某位后端大哥在管，但是貌似这位后端的 Linux 玩得貌似还没我 6，各种粗暴 root kill 操作，当然了我也只是个业余搭来玩玩的水平。
然后就在一周前，我某个前端项目提交上去之后，自动化构建从此就失败了 \@\_\@ ，心里那个苦啊，我居然踩了这颗雷。更要命的是任何 npm 命令都能跑，唯独 npm 的构建命令不能跑，更没有**任何输出**。
这几天就真的是挠破脑袋了，身边没有任何朋友是做运维的，我想尽任何我能想到的方法去暴露、定位问题：尝试回滚代码（无效）、--verbose 嗦模式构建（无效）、npm audit 包管理检查（无效）、Docker 运行空间和内存检车（无效），甚至看官方文档，进到服务器 Docker 里面用 Jenkins CLI 跑任务，在 console 里依旧没有任何有用的输出，npm 和 jenkins 似乎也找不到任何有效的日志或报错。
但是这个项目 git pull 到任何一台普通电脑都是可以构建和输出日志的。我看到 Docker 里 npm 和 node 的版本跟我本地是不同的，却又不知道 Jenkins Docker 的 node 环境是怎么装进去的，也不知道应不应该花时间处理这个（也许又是没有帮助），完全是一片苍白的知识领域，不知道如何定位和解决问题。
现在这个项目的自动化构建完全停住了，领导怪罪下来我也完全没有办法，估计下一个被逼走的就是我了，难受，上来吐槽一下。
第 1 条附言 2019-07-24 18:03:12 +08:00
不好意思，原文里的链接贴得不对，这里可能还是灌水多，技术帮助请移步： https://v2ex.com/t/584034
 | 1 julyclyde 2019-07-24 17:30:51 +08:00  4 那多好，这个 sb 领导手里可用的人就越来越少了 |
 | 2 jmyz0455 OP @julyclyde 领导确实 sb，但是解决不了问题心里好难受，特别是花了一周时间私下想尽办法还是毫无丝毫进展的时候。 |
 | 3 richangfan 2019-07-24 17:36:02 +08:00 via Android 重装系统没烦恼 |
| 4 jmyz0455 OP @richangfan 这是服务器环境，跑着十几个项目呢，不敢轻举妄动。 |
 | 5 Raymon111111 2019-07-24 17:38:43 +08:00 1 hhh 是时候离职了 |
 | 6 tangweiwownb 2019-07-24 17:39:25 +08:00 运维走之前会留下的工作手册的呀。里面不是有他的部署内容吗 |
 | 8 julypanda 2019-07-24 17:42:37 +08:00 9 赶紧走 既然是亲信团，就不要陪跑了 |
 | 9 lithiumii 2019-07-24 17:42:41 +08:00 4 我也不懂，不过感觉这篇文章应该转给你的空降领导，让他理解一下之前那位运维的工资高在了哪里 |
| 10 jmyz0455 OP 1 @tangweiwownb 有留下，但是都是服务器配置、运行软件、账号密码一类的书面文档。 怎么用某些工具，怎么排查问题这些属于他个人的业务知识吧，这些都没留下。 |
 | 11 RorschachZZZ 2019-07-24 17:44:58 +08:00 开发处理这种事肯定没运维专业啊。让你老大给你找个专业的人来搞啊，否则就是在浪费宝贵的时间 |
| 12 jmyz0455 OP @lithiumii 说起这个就来火了，我正面跟他讲过这个事情，他就答我别人手里的项目没问题，自己私底下花时间克服什么的。叫我不懂去问那个后端，但是那个后端一问三不知，而且也在忙，也不好逼他了毕竟根本原因出在领导上。 |
| 13 jmyz0455 OP @RorschachZZZ @lithiumii 新领导估计是想把运维的工作分摊到个别测试、开发的头上，简直是活生生的压榨，而且没人懂这个 Jenkins。 |
 | 14 stupil 2019-07-24 17:51:26 +08:00 让领导招运维。 同时， 搭车招运维人员，有意留言。。。 |
 | 15 maichael 2019-07-24 17:53:21 +08:00 jenkins 的构建环境是在 docker 里面？ 你这里没头没尾的也不好分析。 |
 | 16 SEARCHINGFREE 2019-07-24 17:53:35 +08:00 #12 建议对那个负责的后端加大力度，为啥他一问三不知还负责 |
| 17 maichael 2019-07-24 17:55:40 +08:00 @SEARCHINGFREE #16 对他加大力度也没什么用，估计也就是一个背锅的。 |
 | 18 yiyi11 2019-07-24 17:56:21 +08:00 3 跟领导说还是让他另请高明吧。 |
 | 19 litp 2019-07-24 17:59:34 +08:00 不要去尝试解决，问题不在你 要么走 要么把亲信弄走，运维弄回来，然后你坐高位 |
 | 20 zubincheung 2019-07-24 18:00:38 +08:00 不跑留着过年啊 |
 | 21 justforlook44444 2019-07-24 18:00:45 +08:00 实力允许的情况下，还是走吧，“新项目上线之后就用各种手段逼走运维。”，这种老板人品这么差，迟早会有不好的事情找到你头上。 |
 | 22 Vegetable 2019-07-24 18:03:57 +08:00 不认识那个资深运维吗？楼主居然没想过去求助一下，真是一个合格的前同事。 |
 | 23 defunct9 2019-07-24 18:04:38 +08:00 26 开 ssh，让我上去看看 |
 | 24 Kirscheis 2019-07-24 18:07:11 +08:00 via Android 1 开个 root shell，让我来看看（滑稽 |
 | 25 tohearts 2019-07-24 18:18:16 +08:00 1 #22 同意 22 楼，询问下那个资深运维，如果那个运维不回答，估计就是对公司太不满了，我觉得你也可以收拾走人了，这种领导。一言难尽 |
| 26 jmyz0455 OP @maichael 你说的对，我觉得领导就是想找人背锅而已，我们团队里还是蛮团结的。 原文里的链接贴得不对，是这个： https://v2ex.com/t/584034 我这里说一下，Jenkins 是运行在 Docker 里面，正常工作时候，前端项目具体的分支有提交行为之后，会触发 webhook，Jenkins 会从指定仓库指定分支 git pull 下来，然后跑 npm run build （对应的命令是 npx vue-cli-service build ） |
 | 28 temporary 2019-07-24 18:26:09 +08:00 请前运维吃顿饭 问一下 还有吐槽领导这么好一个话题不会尴尬 |
 | 29 loading 2019-07-24 18:26:43 +08:00 via Android 卸磨杀驴，还不走？ |
| 31 jmyz0455 OP |
 | 32 5dang 2019-07-24 18:35:11 +08:00 via iPhone 这种领导咋到处都是。系统运行没问题就可以不要人了。系统难道吃蟠桃自己长大的…… |
 | 33 mxtob 2019-07-24 18:35:31 +08:00 via iPhone 工具搭好 就 k 掉运维也是没谁了。人家平台弄好的服务都需要贴点钱担保了下服务质量。你 boss 看来就是那种百度下谷歌下谁都可以运维的认知水平 |
 | 34 k9982874 2019-07-24 18:35:48 +08:00 via iPhone 看了一下你这锅是自己主动揽上身啊。本来是后端在管，根本没你啥事，坏了也不要你去修，这种系统躲都来不及你说你动他干嘛。 |
| 35 jmyz0455 OP 1 @temporary 当时他离职里的场面比较失控，估计他心情不好吧，把我们全拉黑了，我确实不好打扰他，你想想一个上有老下有小的中年男性辛辛苦苦几个月把环境搭建好了，突然无故被逼走，能有多生气。 |
 | 36 2379920898 2019-07-24 18:39:31 +08:00 没有错误日志啥玩意的吗？既然是 J 软件的问题，那就看下软件的文档，看看有没有日志啥玩意的 |
 | 38 ironMan1995 2019-07-24 18:44:16 +08:00 via Android 9 我之前有家公司也是老板觉得某位运维没用，各种嘲讽人家，后面人家辞职了，工资涨了一倍，前几天不知道那个老板抽什么风还给人家打电话，人家拒接 |
 | 39 ys0290 2019-07-24 18:49:41 +08:00 via iPhone 只有我以为是留一手吗？ |
41 akira 2019-07-24 19:03:58 +08:00 不在你能力范围内的事情 别强行给自己背锅 |
 | 42 fbcskpebfr 2019-07-24 19:14:07 +08:00 via Android 2 说实话，建议搜索 defunct9 的历史记录 就基本没有回复后他没有解决的问题，站长认证 /t/576076 |
 | 43 cabing 2019-07-24 19:17:06 +08:00 因为发布引发的问题找负责人反馈，大不了跑路，慌啥。反正是环境的问题。 |
 | 44 R18 2019-07-24 19:17:22 +08:00 via Android 2 "不要回答！不要回答” 不是交给后端的老哥管了吗，你就不要管了，让他解决 |
 | 45 infra 2019-07-24 19:19:34 +08:00 果断跑路呀，不和 SB 一起折腾。。。顺便求这位运维的联系方式，我们这边还有坑，可以做更有挑战的事情。 |
 | 46 playnoa 2019-07-24 19:19:53 +08:00 via Android 球踢到你这你就弄不出去了，不会踢球就像你现在一样，两头受气。领导都会推卸责任，你是打算成为他们家亲戚吗？这么大包大揽的，如果把聋子治成哑巴，那就坐实了破坏者。即便是这次解决了，你下次呢？赌谁倒霉？ 想想你的大环境的改变吧，光让自己忍着也不是事 |
 | 47 nooper 2019-07-24 19:21:56 +08:00 via iPad 1 请在 codementor 联系我 winton wang |
| 48 justforlook44444 2019-07-24 19:50:34 +08:00 这个老板可真够恶心的，这位运维兄弟也真够实诚的；我要是周围遇到这种情况，就把辞职报告甩领导脸上。 |
| 49 Kirscheis 2019-07-24 19:53:39 +08:00 via Android 2 @jmyz0455 我说开 root shell 一半是开玩笑，一半是如果你真开了，那还可以排查一下。。这种又没有 log，又没有报错的情况，肯定是要备份然后靠各种实验排查问题的。我之前自己部署的 jenkins，我自己现在都不敢说再弄一次效果和现在一样。。。 |
 | 50 Imr 2019-07-24 20:24:13 +08:00 via iPhone jenkins 执行命令一样是在 PATH 里面找，容器里一定是装了 npm 软件的，跟前端自己电脑一样没区别，至于装不上的问题，就要挨个排查了 |
 | 51 realpg PRO @jmyz0455 #2 算是个资深运维吧，告诫你，如果你现在的技术水平，真的别试图解决问题了。赶紧让老板或者管事的花钱找个一次性运维解决问题。 别怕背锅，本质上你把他用坏了算是正常的，但是你要尝试修的时候把他修得更坏了，那就没人救得了你了 |
 | 52 leedong00 2019-07-24 21:11:28 +08:00 耍赖会不会？我就说一句，你们员工要是不作翻天它，领导根本就不会叼你们。不要想去问离职的运维，不带告诉你们，这跟你们同事感情无关，是公司不地道 |
 | 53 alw 2019-07-24 21:45:07 +08:00 1 大家都建议跑路？ 为何我第一反应是，告诉领导这出问题了，不知道需要花多久时间研究才能解决，然后就可以学这一块知识去搞了，有学习的机会蛮好的呀。（楼上提到了，需要另搭环境来修，不要直接修，修坏了怪你。） |
 | 54 srx1982 2019-07-24 21:55:12 +08:00 via Android 谁接手的找谁问就行了 |
 | 55 friddle 2019-07-24 22:04:41 +08:00 via Android 3 不要去找离职的运维，当时前公司开了我徒弟直接把我惹毛了。虽然能理解公司要缩减编制，但问题是项目经理根本不知道谁更重要。 然后过了两个月我也撤走了(一堆原因)。后来打电话找我，我直接撸了一句:你们项目都要死了。还救个屁。 基本除了技术没人懂运维的价值。这是通病。德治 |
 | 56 hoyixi 2019-07-24 22:08:12 +08:00 放心，等你们都搞顺溜了，他就该觉得闲人又有点多了，该炒你们了 |
 | 57 bigpigB 2019-07-24 22:09:07 +08:00 其实不难。 不过确实需要一个运维 |
 | 58 ryanlid 2019-07-24 22:29:54 +08:00 不要解决，让后端弄，或等领导他自己解决。 目测做好或做不好都会被叼，还不如不做 |
 | 59 salmon5 2019-07-24 22:44:34 +08:00 运维 其实比程序员难度大，注意我说的是同等级别，不是架构师。 |
 | 60 q397064399 2019-07-24 23:08:22 +08:00 1 @alw #53 这本质上是一个政治问题，跟技术没有任何关系，你栽到了这种领导，能跑多快跑多快。 一个公司 只要上了规模，这种运维架子不可能不复杂，我当时看了 2 天 pipeline 我就放弃了，这玩意跑起来没法 debug 又没办法打断点，语法错误都不提示，只能一次次写完 丢到 jenkins 里面去试，后来好像又出了一个拖拽生成 pipeline 构建任务的，后来干脆全部直接撸 Python 脚本搞定好了，反正都是我个人的小项目，每个部件都是标准输入输出流，用 Jenkins 这种 CI 黑箱，学习成本太高，没脚本直接来的快。 |
| 61 q397064399 2019-07-24 23:14:44 +08:00 1 @salmon5 #59 不是运维难度大，还是现在业内没一套标准化的玩意，各家都是各玩各的，从 CI 到 发布环境 ，里面涉及到的方方面面的东西太多 光一个 CI 业内就好几套方案，学习成本很高，这家出个玩意 那家出个玩意，我光是把 git 秘钥集成到 Jenkins pipeline 就花了半天的功夫，而且这些东西 动不动就是上百万级别的代码 要应付很多场景，文档比狗屎还长，一般程序员真的不想花时间去学这些玩意，有这个时间 多研究一些框架 跟 算法 还要架构模式之类，而且这种东西 搞不好明天又流行另外一套了， 自己玩的话没必要，自己玩的我都是全程 Python 脚本搞定一切，有输入有输出 还可以打 Log debug，各项 Linux 的命令行 配合标准输入输出就能搞定，整那么大一套架子 太浪费时间 |
 | 62 zhttty 2019-07-24 23:15:40 +08:00 4 明天就申请离职即可，说那么多做什么？离职申请完了后，再去怼老板就好了，煞笔玩意看不到一个牛逼的运维就是天天闲在那里喝茶的运维，垃圾运维才天天加班忙的要死。 |
 | 63 zhttty 2019-07-24 23:19:39 +08:00 我觉得楼主不吃亏不吃教训是不会主动离职的，偏要等到搞出大问题背锅被公司起诉收律师函赔个几万且在业界被公司搞臭名声长了记性才会后悔！ 言尽如此…… |
 | 64 gouchaoer 2019-07-24 23:31:56 +08:00 via Android 2 搭建个 jira+Jenkins+gitlab+slack 就成资深运维了啊。。。那我也有点资深哦？不过资深的运维我觉得还是对于 cdn、防火墙、安全、数据库、k8s 等容器技术、服务器基础组建等有认识的类型吧 |
 | 65 FishTorres 2019-07-24 23:41:31 +08:00 via Android @lithiumii 小百合 |
 | 66 watzds 2019-07-25 00:30:26 +08:00 via Android 一个前端花这么多心思干嘛？这坏了不怪你 |
 | 67 Dart 2019-07-25 01:20:39 +08:00 via Android 哈哈哈 领导上啊 反正是他不要运维了你要学会甩锅 |
 | 69 reus 2019-07-25 01:26:45 +08:00 为什么你还要继续为傻逼解决问题？ 应该离职，让傻逼自己承担后果 明明是傻逼造成的局面，你收拾好了，也会成了傻逼的功劳 我看不下去了 |
| 70 Dart 2019-07-25 01:27:50 +08:00 via Android 我发现有的公司就是不想用成熟的商业运维产品，不想花钱。就找个运维搭一套。然后逼走，节约。注意，作为商人或者老板这个理论没错。只要出过大事自己吃亏过就知道运维还是不能缺的。一句话，公司没钱了。 |
 | 71 lovestudykid 2019-07-25 01:51:31 +08:00 所以你为什么要承认是你弄出问题的，你只是使用了一下，然后就坏了... |
 | 72 594duck 2019-07-25 06:48:17 +08:00 via iPhone 这个故事告诉我们几个道理，1.DEVOPS 的前提是你得有资深的 linux SA 经验。2.Docker 的 troubleshooting 简直是故意制造困难。3.CI/CD OPS 一锅端就是灾难。4.DEVOPS 不是一个人干完所有活，是 DEV 和 OPS 的有机循环。而链接 DEV 和 OPS 的应该是测试和架构。5.不要做中华田园 DEVOPS。最后“尊重运维，我们专业搞 LINUX 和工程问题 20 年，想几天赶上我们，开玩笑了。 |
 | 73 wenzhoou 2019-07-25 07:56:23 +08:00 via Android 这样的老板，又蠢，又坏，做人不地道。还不辞职等什么。时间长了会影响你的三观。 |
 | 75 695975931 2019-07-25 08:29:27 +08:00 1 哇靠，那运维是不是不敢做太自动化的东西？？一旦自动化了，老板就觉得你没什么用了，就跟楼主的前运维一样。。。。 |
 | 76 Hucai 2019-07-25 08:36:39 +08:00 所以说服务器稳定运行，老板觉得运维没事，就是要时不时宕机玩一玩 |
 | 77 congeec 2019-07-25 08:39:23 +08:00 via iPhone 1 警告楼主，这个问题你解决了，以后活儿就是你的了，会涨工作量，不会涨工资 |
 | 78 hanxiV2EX 2019-07-25 08:43:14 +08:00 via Android 自己搭建一套有啥问题，docker 一把梭 |
 | 79 CallMeReznov 2019-07-25 08:44:24 +08:00 10 运维永远处在以下的状态中. 没事的时候"老子花钱请你来干嘛的?" 出事的时候"老子花钱请你来干嘛的?" 永恒的问题  |
 | 80 pkookp8 2019-07-25 08:47:02 +08:00 via Android 反馈，就说不懂，很复杂，得学 @后端并问有没有解决方案 提出学这个会导致现在的项目延期 要么给人，要么给时间，如果都不给那就请年假 |
 | 81 xuanbg 2019-07-25 08:48:47 +08:00 我们老板倒是明白没事干的运维才是最好的运维这个道理，真是个聪明的好老板。 可惜我们的运维天性爱折腾，折腾完没事干就自己走了。。。自己走了。。走了。。。 |
 | 83 jsnjfz 2019-07-25 08:55:24 +08:00 @CallMeReznov 老哥阔以。说实话我也搞过 jenkins 提交以后 Hook 编译发布，说实话不复杂，可我是后端，而且不在 docker 环境中。前端做到这样可以了。这领导估计就是那种“谷歌就一个画面，一天给我搞定”的这种。跑是肯定的了，建议还是先找好工作。 |
| 84 jsnjfz 2019-07-25 08:56:12 +08:00 话说 jenkins 的日志里面也没信息么？ |
 | 85 huruwo 2019-07-25 08:57:04 +08:00 via Android 搞出问题了？等律师函吧你 |
 | 87 Cyron 2019-07-25 09:00:07 +08:00 首先 sb 领导，其次 jenkins 要学也不难 |
 | 88 lFOqSK 2019-07-25 09:00:16 +08:00 1 设定个定时任务，时间到了就把黑箱里的某些配置改了或者删了某些组件重启，然后自我删除。实现这样的程序不难吧？ 我猜楼主只是运气不好，刚好是黑箱炸了之后第一个用的，所以会产生是自己弄坏的错觉 当然，这种也是死无对证的，毕竟证据肯定已经自毁了。楼主再自己研究下去的话，首先肯定是自己修不好的，其次之后请人来修好的话，责任肯定也是在楼主身上。毕竟楼主能怎么证明自己没有改过或者动过被弄出问题的部分？如果定时炸弹不止一个，下一次弄出生产事故，又会是谁背锅？所以建议楼主尽早跑路。 |
| 89 CallMeReznov 2019-07-25 09:02:13 +08:00 @xuanbg #81 是个狼灭 |
 | 90 jay4497 2019-07-25 09:03:22 +08:00 这种事肯定是不能接的啊，就算会也要说不会、弄不了，又不多给钱，就现在你这环境，只要你说会，以后铁定这事就成你的事了，所以多一事不如少一事，最最不好的结局也就辞退呗，这种公司还想多待？ |
| 91 lFOqSK 2019-07-25 09:05:38 +08:00 其实至少在我的圈子里，交付成品的时候设些绊子防止甲方吞尾款是很正常的事情。拿到全款的时候再给个升级补丁包。楼主可能涉世未深不知道还有这种操作。=_= |
 | 92 hyy1995 2019-07-25 09:06:45 +08:00 开“猿”节流 |
 | 93 7654 2019-07-25 09:09:18 +08:00 这件事不要想着用技术手段解决，既然以前有运维岗，被裁掉了，那就不要用运维手段发布新版本嘛:doge |
 | 94 golden0125 2019-07-25 09:13:21 +08:00 我也倾向是定时炸弹式后门,只是 LZ 运气不好恰好碰到了而已 |
 | 95 cominghome 2019-07-25 09:20:04 +08:00 2 @gouchaoer 你这就 ETC 了吧，UP 主说搭了这个，也没说人家不会你说的那些东西吧？ 而且讲道理，CI/CD 运维都会（可能也不是都会）搭，但是能玩好，开发测试运维都觉得好用的也不是谁都能做到吧，中小型公司有这么一套流程，你知道省多少功夫嘛。 |
 | 96 smilzman 2019-07-25 09:21:33 +08:00 看了你之前的描述，很可能服务器进程没有正确退出，导致一开始编译就“卡死”，登录服务器看下进程，把异常的 kill 掉，然后重启 [手动] Jenkins 服务，然后再构建一次，还有也可以试试构建前执行 rm lock 文件的操作。 |
 | 97 yuzhiquan 2019-07-25 09:22:45 +08:00 运维闲着是贵司之福。。。 |
 | 98 Tezos 2019-07-25 09:24:05 +08:00 全公司 wx 拉黑？我看留一手几率较大啊 |
 | 100 danc 2019-07-25 09:26:11 +08:00 正好可以找个机会离职了 |
Select Language