15
真的有公司搞 devops 吗？成功了吗？
source link: https://www.v2ex.com/t/792410
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
领导想搞 devops，让我找资料。无意挖到禅道的宝藏论坛，里面好多 devops 文章，在自动化测试板块： https://www.zentao.net/redirect-index-19289.html
用禅道用了 3 年，还是在上一家公司，后来回家发展来了这家小公司，什么项目管理工具都不用，每天工作就跟两眼一抹黑一样。
现在好了，说要搞 devops，我们团队人这么少搞得起来么？还不如上个工具先解决项目管理流程问题。
大公司很多搞 devops 的都失败了，感觉这个东西看着火，落地难。 所以，真的有公司搞 devops 了吗？效果怎样？ 10 人以内的团队有必要搞吗？
94 条回复 • 2021-07-30 12:36:33 +08:00
sirius1024 2 天前
DevOps -> AIOps -> NoOps
DevOps 已经非常成熟了，后两个基本还在概念炒作阶段。DevOps 里最典型的就是 CI/CD 体系建设，AIOps 里有监控数据分析、预警之类的，NoOps 是 AI 成熟后的无人值守了我猜~~~
DevOps 已经非常成熟了，后两个基本还在概念炒作阶段。DevOps 里最典型的就是 CI/CD 体系建设，AIOps 里有监控数据分析、预警之类的，NoOps 是 AI 成熟后的无人值守了我猜~~~
swulling 2 天前 
2
DevOps 是整个研发管理的一个步骤，按照顺序一个个做
1. 版本控制，git svn 等等
2. 需求管理，不管用 jira 还是 github issues 等等，把需求管理起来
3. 自动编译并部署到测试环境
4. 自动测试
5. 自动发布并部署到线上环境
做完这些，就及格了，剩下的就是根据项目复杂度增加东西了。
1. 版本控制，git svn 等等
2. 需求管理，不管用 jira 还是 github issues 等等，把需求管理起来
3. 自动编译并部署到测试环境
4. 自动测试
5. 自动发布并部署到线上环境
做完这些，就及格了，剩下的就是根据项目复杂度增加东西了。
zhang77555 2 天前
搞个服务器,装个 docker, 用 docker 装个 gitlab,再搞个 gitlab-ci,
再定几个常用工程的 ci 脚本模板, 从零开始花个半天时间应该就能调教好
再定几个常用工程的 ci 脚本模板, 从零开始花个半天时间应该就能调教好
Hilong 2 天前
@chigeyaowaner 我们当时 4 个人都搞了 。先把 jenkins 那一套搭起来。持续集成，持续部署搞定，会省好多力气。后面再+sentry，把监控也搞起来。如果用的是钉钉，还可以把报错信息通过机器人实时同步到群里
evilStart 2 天前 via Android 3
来到 V2EX 才感觉到这世界的参差。。。我一直以为现在所有团队都有 DevOps 了。
最起码 CI/CD 要有吧，如果是小项目的话这搞起来也不难。而且能显著提升效率。10 个人都是开发的话至少要有一个人全职搞 CI/CD，主要包括维护 CI pipeline，同时你们开发也要知道写 cases 。要是开发都不写的话，那最好有两个人搞这个。问你们老板愿意出人不。
最起码 CI/CD 要有吧，如果是小项目的话这搞起来也不难。而且能显著提升效率。10 个人都是开发的话至少要有一个人全职搞 CI/CD，主要包括维护 CI pipeline，同时你们开发也要知道写 cases 。要是开发都不写的话，那最好有两个人搞这个。问你们老板愿意出人不。
dcoder 2 天前
主要靠领导, 领导先吹牛弄到很多资源(预算经费, 人头 for DevOps engineers)
然后开始堆人，堆出一个(至少看起来)高大上的方案, 忽悠公司内部的 Dev 们使用.
Done !
然后开始堆人，堆出一个(至少看起来)高大上的方案, 忽悠公司内部的 Dev 们使用.
Done !
JJsty1e 2 天前
我的想法是在合并代码的时候自动跑一些单元测试和接口流程测试，但是接口的流程测试这块太麻烦了，首先数据库不方便 mock，其二，一个流程（比如订单系统），涉及到商品上线、用户下单、最后发货，这些流程又会有很多分支，这一系列操作用现有的测试技术太难整了，但是如果按单元测试的思路去进行最小单元测试，比如测试用户下单功能，那又要整备很多 flexures，反而也是一种麻烦。不知道你们是怎么处理这块的，还是说你们有自己写的测试框架？
Hasal 2 天前
看到这个问题，才知道 DevOPS 还有失败的说法。本以为效能工具只会越搞越好，怎么会有越搞越差呢？现在公司、前同事们去的公司，大部分都有 DevOPS，只有一些规模极小的公司，还停留在原始阶段。
bthulu 2 天前
devops 到底是个啥, 我司现在是 gitea -> drone -> docker. 生产发版只要在 git 上打个 release-x.x.x 的标签就行了, 测试发版就打个 test-x.x.x 的标签. 删除标签就会自动回滚到最近的标签.
然后领导现在也天天喊着要搞 devops, 要给开发赋能, 但是到底要搞什么, 谁也说不清
然后领导现在也天天喊着要搞 devops, 要给开发赋能, 但是到底要搞什么, 谁也说不清
xuanbg 2 天前
小团队，搞了很多年了。核心其实就一点：自动化部署。至少要实现半自动部署，就是 Jenkins 里面点一下构建就好的这种。至于 CI/CD 搞到什么程度，视你自己的实际需求而定，并非却多越好。
no1xsyzy 2 天前
eric96 2 天前
1.推送代码，触发 ci，ci 通过后可以合并到 master 分支，基于 master 打 tag
2.打 tag 操作触发 jenkins 构建，这一步又有问题，线上环境和测试环境不是同一份配置文件的，配置文件也不在项目代码中，这里需要自动替换配置文件，然后构建完之后，还要基于 dockerfile 构建镜像，构建镜像之后，推送到私有仓库中
3.触发 k8s 自动部署
现在我们公司第一步是自动化的，第一步到第二步的触发没有做，需要手动去触发，第三步也是手动替换 k8s 。
以下是我的疑问：
1.难道 CI，CD 就是基于一些已有的工具如 jenkins，git 等进行配置，如果不支持就自行开发脚本把流程串联起来吗
2.如果没有单元测试和自动化测试，ci 和 cd 还有用吗
2.打 tag 操作触发 jenkins 构建，这一步又有问题，线上环境和测试环境不是同一份配置文件的，配置文件也不在项目代码中，这里需要自动替换配置文件，然后构建完之后，还要基于 dockerfile 构建镜像，构建镜像之后，推送到私有仓库中
3.触发 k8s 自动部署
现在我们公司第一步是自动化的，第一步到第二步的触发没有做，需要手动去触发，第三步也是手动替换 k8s 。
以下是我的疑问：
1.难道 CI，CD 就是基于一些已有的工具如 jenkins，git 等进行配置，如果不支持就自行开发脚本把流程串联起来吗
2.如果没有单元测试和自动化测试，ci 和 cd 还有用吗
konakona 2 天前
有必要，可以规范和约束运行环境。另外 devops 就是一个实现自动化编排、自动化构建等等以服务运维为目的的功能性流程的统称，无论多小的团队又或者多大的团队，都应该考虑 CICD 带来的优势和便利性。
它可以避免团队成员水平不统一和意识问题造成的一系列问题：
- 环境不同
- 运行结果不同
- 不必自己手动去做一些工程化的事，当有 CICD 时，我们可以让它自动的做诸如：某一个 branch 被 MR 之前或之前自动跑测试或触发外部 API 执行 UI 自动化测试等
- 手动更新、安装、修改长年累月的服务器，还可能导致其他站点 /程序无法运行
- 代码监控
- 代码评级
- 问题探针
等等，工具能做的事就没必要人手再重新敲一次运行命令了。
它可以避免团队成员水平不统一和意识问题造成的一系列问题：
- 环境不同
- 运行结果不同
- 不必自己手动去做一些工程化的事，当有 CICD 时，我们可以让它自动的做诸如：某一个 branch 被 MR 之前或之前自动跑测试或触发外部 API 执行 UI 自动化测试等
- 手动更新、安装、修改长年累月的服务器，还可能导致其他站点 /程序无法运行
- 代码监控
- 代码评级
- 问题探针
等等，工具能做的事就没必要人手再重新敲一次运行命令了。
lamesbond 2 天前
小团队推这个很难，我想让开发建 dev，test，prod 三个分支，提测，发版时合并下分支，push 代码打 tag，根据部署环境不同参数化构建项目，根本推不动，领导觉得自动部署只是解放了运维。
楼上大佬们说的自动测试，发版什么的我都想搞，奈何现实太残酷，不过就 jenkins 搞了自动部署就很舒服了，其他的慢慢来
楼上大佬们说的自动测试，发版什么的我都想搞，奈何现实太残酷，不过就 jenkins 搞了自动部署就很舒服了，其他的慢慢来
netwjx 2 天前
devops 的关键点不是 ops 么?
上线后的才是重点呀, 前面瞎折腾那么多 CI/CD, 只对工程师这个人有用
对业务作用不明显, 你也给别人说不明白
前面一堆说 CI/CD 的都得出去反思 10 分钟
仔细看看 ops 的职能都是干啥的? 供应计算 网络 存储 调度等资源, 以及上述资源的监控能力
业务的运维同学还要关注啥? 业务指标 业务指标 业务指标
上线后的才是重点呀, 前面瞎折腾那么多 CI/CD, 只对工程师这个人有用
对业务作用不明显, 你也给别人说不明白
前面一堆说 CI/CD 的都得出去反思 10 分钟
仔细看看 ops 的职能都是干啥的? 供应计算 网络 存储 调度等资源, 以及上述资源的监控能力
业务的运维同学还要关注啥? 业务指标 业务指标 业务指标
Meano 2 天前
整了一套环境目前主要自己用，非常舒服啊
Gitea + Drone (自己改了 Powershell Native Runner，编译+测试) + MinIO (artifacts/release) + Wiki
另外还写了脚本 CI 可以用一套代码根据不同配置生成多套代码并编译测试给不同需求的客户和同事
不管以后别人用不用，反正我再也不会面对这些问题了：
* 在丢文件给别人的时候给错
* 同步更新多个库代码的时候出错
* 更新代码后发现编译不了
* 一份代码要抄 N 遍
etc.
但是协作就不知道好不好推了，我周围大部分人可能都觉得代码只要写到眼前能编译能用就行...
Gitea + Drone (自己改了 Powershell Native Runner，编译+测试) + MinIO (artifacts/release) + Wiki
另外还写了脚本 CI 可以用一套代码根据不同配置生成多套代码并编译测试给不同需求的客户和同事
不管以后别人用不用，反正我再也不会面对这些问题了：
* 在丢文件给别人的时候给错
* 同步更新多个库代码的时候出错
* 更新代码后发现编译不了
* 一份代码要抄 N 遍
etc.
但是协作就不知道好不好推了，我周围大部分人可能都觉得代码只要写到眼前能编译能用就行...
Meano 2 天前
@netwjx 哈哈 也不是所有的软件开发流程都有明确的运维环节的 比如传统的软件开发行业能从瀑布转向敏捷就已经是很大的进步了 分发之后的反馈周期非常长且渠道单一 这种情况下 对接外部的最后接口就是分发了
dreampuf 2 天前
想到啥说啥
DevOPS 或者 SRE 之类，我统称非产品功能需求开发，做质量、敏捷响应等等。在这个定义下，哪怕你写一行重复执行的 shell 都可以算作 DevOPS （地铁_老人_手机.jpg ）
DevOPS 越推崇的公司，越以员工数量少却维护海量集群为荣，鄙司收购的一个小公司的运维团队之前就两个人，对应后来我们直接拆成五六人的工作量，戏称之为 Dev & OPSize，再发展一段时间，估计这两个词会完全拆分。所以人少和是否贯彻 DevOPS 没有必然联系
使用项目管理工具是否就是 DevOPS ？工程效能是一个更大的话题，DevOPS 只是其中的开发环节一个方法论。虽然 Jira 母公司 Atlassian 一直标榜使用了自家产品的公司“很”有可能是敏捷的，自动化的和高效的，但每家使用问题追踪的公司不一定会上市。Atlassian 股价自 2015 年上市以来，兑现了几乎十倍的回报率，每家公司依旧要么在使用 Jira，或者即将使用 Jira 的路上。
Thoughtworks 的 Tech Radar 很实用的记录了哪些技术是“未被验证的”，https://www.thoughtworks.com/cn/radar/techniques/devops DevOps 2010 年很新颖，2012 年已经是成熟的被采纳的技术
DevOPS 或者 SRE 之类，我统称非产品功能需求开发，做质量、敏捷响应等等。在这个定义下，哪怕你写一行重复执行的 shell 都可以算作 DevOPS （地铁_老人_手机.jpg ）
DevOPS 越推崇的公司，越以员工数量少却维护海量集群为荣，鄙司收购的一个小公司的运维团队之前就两个人，对应后来我们直接拆成五六人的工作量，戏称之为 Dev & OPSize，再发展一段时间，估计这两个词会完全拆分。所以人少和是否贯彻 DevOPS 没有必然联系
使用项目管理工具是否就是 DevOPS ？工程效能是一个更大的话题，DevOPS 只是其中的开发环节一个方法论。虽然 Jira 母公司 Atlassian 一直标榜使用了自家产品的公司“很”有可能是敏捷的，自动化的和高效的，但每家使用问题追踪的公司不一定会上市。Atlassian 股价自 2015 年上市以来，兑现了几乎十倍的回报率，每家公司依旧要么在使用 Jira，或者即将使用 Jira 的路上。
Thoughtworks 的 Tech Radar 很实用的记录了哪些技术是“未被验证的”，https://www.thoughtworks.com/cn/radar/techniques/devops DevOps 2010 年很新颖，2012 年已经是成熟的被采纳的技术
minmini 1 天前 via Android
比较好奇楼上各位已经开始实施 devops 的朋友自动化测试这块是怎么做的。
我是做测试的。我们公司接口自动化测试有的团队弄得多，有的几乎没有，就纯手工测试，也没时间做自动化。大部分开发人员没有写单测的习惯，leader 也不会做这一块的考核。
最近在学 K8S，已经在测试环境吧我自己负责的项目用 k8s 完整的拉起来一套环境了（大部分线上环境还是 Tomcat 部署），结合我们自己的自动化测试用例现在丢给开发人员当自测环境在用 [领导要求测试环境架构要跟现上一致，所以业务测试还有单独一套环境]
我是做测试的。我们公司接口自动化测试有的团队弄得多，有的几乎没有，就纯手工测试，也没时间做自动化。大部分开发人员没有写单测的习惯，leader 也不会做这一块的考核。
最近在学 K8S，已经在测试环境吧我自己负责的项目用 k8s 完整的拉起来一套环境了（大部分线上环境还是 Tomcat 部署），结合我们自己的自动化测试用例现在丢给开发人员当自测环境在用 [领导要求测试环境架构要跟现上一致，所以业务测试还有单独一套环境]
weer0026 1 天前 1
我司 20 人小团队大致路线给你参考下，先全线产品 docker 化改造，然后搞个 docker 镜像私库，把 CI 弄好（ gitee+drone ），接着研究 k8s + helm，这个阶段花时间比较久，期间同时弄了运维管理后台（七牛管理，数据库管理，监控什么的）, 最后项目一个一个上集群。
pkwenda 1 天前 1
@lightjiao #11 https://www.uwintech.cn/devops
拉到中间，基于 F5 灰度发布，发布前 60h，发布后 45s，提升 80 倍 老东家太谦虚了，我感觉提升了 4800 倍
拉到中间，基于 F5 灰度发布，发布前 60h，发布后 45s，提升 80 倍 老东家太谦虚了，我感觉提升了 4800 倍
offswitch 1 天前
你们说的是 DevOps，我怎么感觉大部分人把 CICD 当成了 DevOps，DevOps 里面的持续测试，持续反馈，持续监测那去了？大部分公司怕不还是瀑布模型，只是加上了 CICD 。
xx6412223 1 天前
我理解的 devops 落地几步走，和敏捷工具无关：
1. CICD：每个 PR 都要触发，打 TAG 要触发，日常任务触发包括备份迁移后。
2. 隔离的 dev qa pre-pro pro 环境，规范的发布流程
3. 独立的监控和日志系统，
4. 大型团队的 infrastructure 管理，包括云上环境和各功能组件的维护使用，
5. infrastructure as code , pipeline as code
所以专业 devops 一般要具备 cicd，各种云，K8S 和日志监控类系统的搭建和维护经验
1. CICD：每个 PR 都要触发，打 TAG 要触发，日常任务触发包括备份迁移后。
2. 隔离的 dev qa pre-pro pro 环境，规范的发布流程
3. 独立的监控和日志系统，
4. 大型团队的 infrastructure 管理，包括云上环境和各功能组件的维护使用，
5. infrastructure as code , pipeline as code
所以专业 devops 一般要具备 cicd，各种云，K8S 和日志监控类系统的搭建和维护经验
locoz 1 天前 via Android
@evilStart #27 我曾经也是这么以为的，直到我在国企做过了才知道，原来这个世界上还有人能这么守旧，一大把服务器资源宁愿放着也不愿意布套 Gitlab 替代 Gitee，还说手动操作一下也没多麻烦…几个月搞下来我一直在推动，结果到现在都还是自动化的东西没有、日志收集的没有、异常跟踪的没有、配置管理的没有，我都快吐了。就连项目管理的东西都还是某天他们用的一个老的简陋系统崩了，我在群里说了一声可以用禅道才换的，典型的不碰到问题就压根不会想着变更。
locoz 1 天前 via Android
@locoz #90 补充一下，除了上述的没有之外，还没有多环境的 K8S 集群、没有 Kibana 之类的监控，很多新项目仍然没有做容器化改造，生产环境的 K8S 集群都还只是给部分强行上容器化的项目在用。大部分项目仍然是人工手动部署的，生产环境部署个东西还得找运维，打包好东西、给个部署文档才能正常部署上。
而且吧，这些东西直接就是整个公司都没有，没有统一的一套这些东西，只能每个部门自己解决，一个亿级资本的、按楼层算办公室的大国企，管理层完全不考虑综合成本和效率，只想着堆产品、搞一些实际有现成完善产品的简单替代工具刷业绩…
没有对比就没有伤害，管理层都是 40 左右甚至更大，且不关心新技术、只想着靠加班来堆的公司（公司 CTO 以往战绩就是定一堆任务然后疯狂加班硬堆），真的太 tm 可怕了。
而且吧，这些东西直接就是整个公司都没有，没有统一的一套这些东西，只能每个部门自己解决，一个亿级资本的、按楼层算办公室的大国企，管理层完全不考虑综合成本和效率，只想着堆产品、搞一些实际有现成完善产品的简单替代工具刷业绩…
没有对比就没有伤害，管理层都是 40 左右甚至更大，且不关心新技术、只想着靠加班来堆的公司（公司 CTO 以往战绩就是定一堆任务然后疯狂加班硬堆），真的太 tm 可怕了。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK