(;´Д`)医生！你说话啊！

po现在的服务线上几百台容器
不仅得开发需求，还得管着这些玩意别挂了
扩容缩容压测都得开发搞(　ˇωˇ)
如果只是推CI/CD的话，po觉得挺好
这种完全把运维的活丢给开发，真的是工程上的考虑吗

只是你们缺运维吧（

只是你们缺运维，是管理问题

我为了找可以远程办公的工作，还学了几天Ruby准备转DevOps( ﾟ∀。)

运维的活让开发来干，我觉得不是工具的问题( ﾟ∀。)

per 原教旨主义者，这不是 DevOps，而是单纯地把 Ops 的活丢给 Dev 做

原教旨的 DevOps 提出的设想是：把环境（包括操作系统 (FROM)、依赖库 (RUN apt-get install)、环境变量 (ENV)、命令 wrapper (ENTRYPOINT)、编译过程 (RUN make)、启动参数 (CMD)）以代码的方式进行形式化，是为了将 Dev 和 Ops 的界面打通。
然后，实际上，如此一来，你会发现实际的 Ops 层极其薄，才出现了将 Ops 干脆并入 Dev 的想法，但这个想法实际上意味着把 Ops 更进一步地自动化。它的结果其实就是直接购买云服务提供商现成的服务。

>>No.51703834
与上述原教旨 DevOps 的 diff：

> po现在的服务线上几百台容器
原教旨认为，你不可能准确得知容器的数量，它的伸缩只能是自动的，仅仅你在说出这句话的时候，容器就可能自顾自地伸缩了几十台

> 不仅得开发需求，还得管着这些玩意别挂了
它挂了就自动重启，挂到起不来就回滚

> 扩容缩容压测都得开发搞
扩容缩容是自动的，压测是一键的

>>No.51852011
理想 美好 但是现实里……

>>No.51855361
现状分两种，一种是能搞掂自动化运维的把自动化运维当产品卖，另一种是自己搞不掂的买别人的自动化运维产品。
AWS 阿里云 腾讯云 这些云，都有现成产品，只不过也有供应商绑定的风险在。

>>No.51852011
那我只能说我们自研的devOps平台纯纯就是个花架子而已。
我发现你说的这些功能，我去查了下文档，虽然都是支持，但是实际上还是要走人工审批这一步，devOps平台不敢替业务方担责( ﾟ∀。)
压测是一键的，但是还得测开/开发提前写好脚本然后一级一级审批。
流程正确压倒效率
不背锅可能才是最终追求

>>No.51870092
草，那确实。

所以 no warranty 能促进科技发展，确实是有几分道理的（