2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

NoOps 的含义及相关论战

  • 2012-03-19
  • 本文字数:1816 字

    阅读完需:约 6 分钟

一年前,Forrester 发布报告“扩大 DevOps 至 NoOps ”,预测在不久的将来,一些企业将越来与多地依赖于云,开发者将能更加自动地进行程序构建(building)、测试与部署等运维操作,最终达到 NoOps。虽然该术语表示这些公司将不再需要运维人员,但是报告的本意谈论的却是开发者将使用更加自动化的工具,而这些工具需要更少的人工干预。

但是,云计算的新发展开创了按需分配基础设施、自动供应资源和弹性应用架构的新纪元,极大地减少了开发者发布程序过程中与运维的沟通。DevOps 所关注的协作发展成 NoOps 关注的自动化。但是,这里并无奇术,即使在这宏伟的 NoOps 的未来,运维人员仍然必须利用基础设施,以不同的方式支持开发者以更少人工干预的方式更好地完成产品归档。他们仍然要追逐 DevOps,但随着云服务的普及,他们需做好准备,扩展 DevOps 至 NoOps。

GigaOM 今年发布的一篇由 AppFog 的创始人兼 CEOLucas Carson 撰写的 infographic ,预测 2013 年将是程序员的 NoOps 年。该 infographic 显示,随着计算模型从 90 年代的数据中心发展成 2000 年左右的虚拟化解决方案,进而发展成 IaaS(AWS),并且迎接了 2011 年系统化 SysOps 管理(对诸如 Chef 和 Puppet 之类的更高级自动化运维产品的使用)的进一步推动,创新企业计算成本在其生产力的指数增长的同时呈指数下降。令 Carlson 欣慰的是,现在开发者用 60% 的时间编程,剩下的 40% 做运维——中间件、网络、虚拟化硬件管理和服务供应及安全。

Carlson 预测,在应用程序的生命周期管理依托 PaaS 解决方案(如 VMware Cloud Foundry 或 RedHat OpenShift)经过又一年的跟进之后,2013 年将是 NoOps 年,到那时采用 AppFog 和 Heroku 等受管的 PaaS 解决方案的创新企业的程序员只需花 5% 的时间用于运维——中间件、服务、故障切换(failover)和审计管理,而其他的运维工作都在云的内部解决了。

尽管 Carlson 的 infographic 提及的是创新企业,但是,据 Netflis 的云架构师 Adrian Cockcroft 称, Netflix 已经 NoOps 了

Netflix 已经 NoOps 了……

所有产品变更都由编码的程序员完成。我们有一些保证工程可靠性的中心协调员,他们拥有 devops 的技能(在开发部门工作,写代码而非运行说明书 [Runbook]),他们不做变更,而是让开发去做。Dev 说,发布新代码版(选择,点击),将该版本的代码传出去(点击)。Autoscaler 根据流量确定运行多少个进程。警告直接发送给开发者,on-call rota 由 pagerduty 管理。我们的产品不需要运维工作也不需要运维团队,一切都是开发。我们有 IT 运维团队,但他们负责笔记本、邮件、DVD 寄送等,但不负责产品的生产流水线。

尽管这一切看起来都是合理的,但是 NoOps 这一术语在运维社区却引起轩然大波。另一个以“No”为前缀并且引起类似反应的术语是 NoSQL。它最初是由 Carlo Strozzi 在 1998 年创造的, 它是为无需 SQL 接口的 SQL 数据库起的名字。NoSQL 在 2009 年被 Eric Evans 再次引用,用以描述不依赖于 SQL 技术的数据存储,但是后来被一些人看作是对 SQL 以及多年来工作在 SQL 上的人们的冒犯。起初,一些人暗指 SQL 将会为 NoSQL 让出空间而逐渐消失。另外一些人则将它友好地解释为不只是 SQL。

NoOps 也有相似的不幸的含义:对运维说不,对运维人员说不。Etsy 的运维副总裁 John Allspaw 就是最强烈的反对者

“NoOps”超过“云”、“敏捷”和“SOPA”成为我们这一领域至今为止最愚蠢的市场术语。

从大方面说,这个术语用“无”描述“有”。

Mark Imbriaco, @LivingSocial的技术运维副总说:

我因为明天要录制的播客(podcast)而心情糟糕,现在我对 NoOps 充满敌意……

你会相信一个满口宣扬 NoOps 的 PaaS 供应商知道怎么运维他们的平台吗?提示:不能信。

还有,enStratus 的产品战略副总裁也表达了他对NoOps 这一术语的失望:“我的担心不是一切都由开发来做的概念,而是对这个术语本身。就像对早期的NoSQL 一样。”

运维将面临改变是一定的。大公司还会在本地运行其设备,运维仍然会扮演重要的角色。也有另外一些公司将依赖于云而维持较小的运维团队,但是云本身却需要大量运维专家。在另外一些公司里DevOps 会继续发展,开发者将学习运维,并担当部分运维角色。而在其他情况下,开发者将承担尽可能少的的运维,大量工作被受管的PaaS 云隐藏了。这些都没有问题,但是NoOps 这一术语却缺乏想象力。也许是因为人们无法“无”中生“有”的原因吧。


查看英文原文: NoOps: Its Meaning and the Debate around It

2012-03-19 08:203952
用户头像

发布了 184 篇内容, 共 89.6 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

小红书数据架构及 TiDB 使用场景

TiDB 社区干货传送门

【TiDB 4.0 新特性系列】BR 特性及原理解读

TiDB 社区干货传送门

国产主流数据库调研

TiDB 社区干货传送门

性能调优 实践案例

TiDB 监控架构解读

TiDB 社区干货传送门

监控

使用Zabbix监控TiDB(一)

TiDB 社区干货传送门

实践案例

伴鱼数据库之监控系统

TiDB 社区干货传送门

TiDB 赋权问题

TiDB 社区干货传送门

故障排查/诊断

TiDB run and debug on M1

TiDB 社区干货传送门

实践案例 安装 & 部署

【TiDB 最佳实践系列】PD 调度策略最佳实践

TiDB 社区干货传送门

实践案例

线上mysql改表操作导致tidb同步延迟解决方法

TiDB 社区干货传送门

Tidb灾难恢复演练-多副本丢失

TiDB 社区干货传送门

故障排查/诊断

PD 关于tso 分配源代码分析

TiDB 社区干货传送门

TiDB 底层架构

伴鱼数据库之SQL审核系统

TiDB 社区干货传送门

Placement Rules 原理

TiDB 社区干货传送门

TiDB 底层架构

PD api基础框架源码分析

TiDB 社区干货传送门

TiDB 底层架构

TiDB Coprocessor 学习笔记

TiDB 社区干货传送门

TiDB 底层架构

TiDB HTAP 深度解读

TiDB 社区干货传送门

微众银行数据库架构演进及 TiDB 实践经验

TiDB 社区干货传送门

实践案例

一次 meet_lock 告警异常处理过程

TiDB 社区干货传送门

实践案例 故障排查/诊断

TiDB AutoCommit OFF 问题

TiDB 社区干货传送门

实践案例 故障排查/诊断 新版本/特性发布

从使用者到开发者,知乎参与 TiDB 社区背后的故事

TiDB 社区干货传送门

实践案例 数据库架构选型

Flink 最佳实践之 通过 TiCDC 将 TiDB 数据流入 Flink

TiDB 社区干货传送门

性能调优

PD api基础框架源码分析

TiDB 社区干货传送门

TiDB 底层架构

TiFlink: 使用 TiKV 和 Flink 实现强一致的物化视图

TiDB 社区干货传送门

实践案例 TiDB 底层架构

TiDB GC 之原理浅析

TiDB 社区干货传送门

TiDB 底层架构

pd集群多副本数据丢失以及修复实践

TiDB 社区干货传送门

实践案例

TiDB大规模删除实践

TiDB 社区干货传送门

管理与运维

TiDB 记录日志原理解读

TiDB 社区干货传送门

TiDB 底层架构

不定期更新,记录一些小知识

TiDB 社区干货传送门

监控 版本升级 安装 & 部署

一个联合索引使用问题以及优化方案

TiDB 社区干货传送门

管理与运维 故障排查/诊断

把云数据库服务变成黑盒子:ServerlessDB for HTAP丨Hacking Camp 进行时

TiDB 社区干货传送门

实践案例

NoOps的含义及相关论战_DevOps & 平台工程_Abel Avram_InfoQ精选文章