纯靠手工人力的团队会是大坑吗

[lstz]

昨晚在给自己项目配 script 的时候，想起以前待过不少氛围窒息的团队，部署程序是 ftp 上传，单元测试是上传以后手工执行命令去跑，甚至 API 通不通也要手动去触发，我理解这些都可以通过 DevOps 的流程化进行操作的，都啥年代了还这么老土，也许他们对 automation 的理解和我想的不一样....

我理解的是，可以机器自动化运行的，就不要依靠人手一步步执行，后者经常会因为不熟悉或者疏忽导致结果出错。我曾经跟 manager 反馈过这一块，但是他反问道，"如果 Jenkins 程序也报错了，谁来负责任(背锅)？"

果不其然，见识到几个同事因为犯了流程的错误，即使拿到了上级的 signoff ，也被批成狗，后面各种暗示不胜任被迫离职了

不知道大家对纯靠人力来确保结果正确性的行为怎么看待？你们喜欢这种团队行为风格吗

[enchilada2020]

这不纯草台班子吗 能跑趁早跑了

[lstz]

@enchilada2020 但比较尴尬的是，上面这些都是大企业里亲身经历过的.... 有时候觉得，他们并不需要多么优雅的工作方式，只需要有人来负责任....

也许这是 gpt 永远没办法替代某些岗位的原因

[1145148964]

额，纯自动化，你不就失业了？
这可是老美的经验。

[tool2dx]

我以前也是手动启动程序，第一这个是低频操作，只有更新服务器版本时才需要。第二有可能启动失败，需要查看 log 日志查原因（内存不足之类的，服务器配置很菜，运行了太多的后台程序）

后来随着技术迭代，渐渐换成了服务器模块热加载，同时限制了一些占用内存的大户的使用量，就没关心过这些了。

[xption]

每次看到“草台班子”，我就想到我们公司

十年前刚创业时，纯手工
那时云服务器都没普及，租的物理机
甚至，我们没有运维，部署都是我手动操作
第一个项目上线一晚的深夜，我还在优化线上 mysql 配置
嗯，当时程序员只有两个：我和一位同事

十年后，公司现在两百人
一项项基建设施仍然很欠缺

由于人员规模一直在扩大，技术框架也一直在变
客户端从 cocos 、cocoslua 发展到 unity 、unity + lua ，后来又多了个 h5
服务器端从 php 到 c++、c++ + lua 、java 到现在的 go
前几年上了 jenkins ，但是没有上 dock
代码仓库由于历史原因 svn 和 git 都有
舍不得用云服务，都是自建的代码仓库
我们的官网是 3000 块钱外包的
管理后台是找的开源项目
项目管理系统到达一定人数后第三方开始收费，我们就搭了一款开源的
文档系统我们也舍不得付费用第三方的，自己搭了个 wiki

我们总是在摸索尝试，抠搜的舍不得花钱用第三方服务
但至今也没有一套成熟的能应对大部分问题的自动化方案
每个项目组都有一些差别

是的，我们就是一个草台班子
维护一套成熟稳定还能满足不断出现的新需求的基建，成本挺高的，我们不愿意承担
挺难的，但不影响我们熬过了十年
虽然没有赚到大钱
但至少没有大规模裁员，十年前最初招的几位同事现在还在这

[user919lx]

团队充分利用各种工具实现自动化，提升工作效率，这是一个很美好的理想，但前提是团队需要有工程师文化，在很多公司里并没有足够的技术氛围，也不鼓励你这么做。
对我来说的话，融入团队更重要，我会自己做一些自动化工具来提升自己的效率，但如果团队整体来说不在意的话，我也不会多嘴，这也不是什么不可调和的矛盾，只是一种选择而已，背后可能有各种各样的原因，不好一概而论。

[Seria]

“我想提高团队效率！就让我们做出改变吧！”
“为什么要反对？我这是为公司好为大家好！”
“为社么不理我？这个月我的绩效怎么是 F ？”
“为什么那些整天摸鱼的人涨薪了，我却被降薪？”
“为什么要辞退我？”
“我做错什么了吗？”

[Meteora626]

人要是弱智，手工还靠谱省事些。我在的外包就是 Jenkins+k8s ，上次统推测试，测试自己拉不到代码过来把我们喷了一堆，说点构建构建不了，后面我们看 log 给他改好了又没法 push 了，因为打包出来镜像太大，Jenkins 他们不会设置超时传输，最后不了了之，过了一个月总部来了一纸红文说我们外包不配合测试，然后扣奖金，接手这个项目的大哥成了背锅的，项目负责人年前刚跑了。

[sagaxu]

自动化成都越高，螺丝钉可替代性越强