DevOps中的90-9-1规则——当AI成为1%时会发生什么？
90-9-1规则长期以来被用来描述互联网社区的参与动态。它表明在大多数在线生态系统中：
90% 的用户是消费者。他们观察、阅读或观看，但不互动或贡献。
9% 的用户是编辑者。他们与内容互动，修改内容，或与那些这样做的人互动。
1% 的用户是创造者。他们生成大部分推动平台发展的原创内容。
这种模式在早期的网络社区中被观察到，如维基百科、在线论坛和评论区——今天在Reddit、Stack Overflow和GitHub等平台上仍然可见。
但是，当您将这个模型应用到现代DevOps时会发生什么？
更重要的是——人工智能的兴起，特别是生成式AI和自主代理，如何在实践和法律上颠覆这个模型？
理解DevOps中的规则
现代DevOps管道通常由一小群核心工程师构建和维护：
平台工程师
基础设施专家
高级SRE
这些人创建：
自动化脚本
CI/CD工作流
基础设施即代码模块
部署架构
与此同时，大多数开发人员和操作员只是这些系统的用户。他们消费工作流，使用预构建模块，或通过预配置的管道进行部署——而不深入理解或修改它们。
这完美地映射到90-9-1规则：
90% 的工程师和利益相关者使用DevOps工具和管道。
9% 进行上下文更改——修改配置、调整脚本、自定义仪表板。
1% 构建核心框架、工具和可重用模块。
这种不平等本身并不坏——它是高效的。
大多数团队不应该需要从头开始构建自己的部署堆栈。但这种效率假设了一个以人为中心的模型。进入AI。
当1%变成机器时
现在我们有了：
GitHub Copilot
Azure DevOps Copilot
AWS CodeWhisperer
CrewAI
LangChain代理
AutoGPT风格的系统
这些工具可以：
编写Dockerfile、Kubernetes清单或Terraform模块
调试和修改CI/CD YAML配置
生成可观测性仪表板或运行手册
监控性能并自主做出部署决策
突然之间，1%的角色——创造者——越来越多地由AI填补。
这提出了重大问题：
如果AI创建基础设施或系统代码，它算作贡献者吗？
如果该代码导致中断、漏洞或违规，谁负责？
这不再是假设性的。AI生成的代码对以下方面有真正的影响：
安全性
合规性
法律责任
AI参与的法律和道德影响
AI工具在法律上不负责任，但它们正在塑造必须遵守法规并避免安全陷阱的系统。
考虑这些场景：
AI工具错误配置了具有公共访问权限的S3存储桶→PHI被暴露→谁负责？
AI代理集成了具有未授权依赖项的库→您的组织现在违反版权。
修复代理对生产环境应用了错误的修复→中断级联→谁的错？
从历史上看，责任是人类的：
初级工程师可以被指导。
高级工程师可以被追究责任。
开源贡献者可以被联系。
但AI不负责任。它是不透明的、多产的，并且在传统的责任模型之外。
对9%的影响——编辑者和审查者
如果AI成为1%，那么9%——编辑者——现在是最后一道防线。
但这里有个问题：大多数团队不深入审查AI输出。他们假设Copilot和其他工具产生"足够好"的代码。
在DevOps中，"足够好"可能意味着灾难。
解决方案？
将编辑角色提升为包括：
CI/CD中的AI代码检查和验证
AI生成代码的许可证和安全扫描器
AI拉取请求的强制性人工审查
AI代理操作的审计日志
AI工具使用和监督的政策
这不仅仅是技术转变——这是文化转变。正如DevSecOps将安全左移一样，AI治理也必须左移。
90%站在哪里？
90%将继续成为消费者。但他们将越来越多地与AI生成的内容互动：
工作流
日志
警报
仪表板
这意味着AI流畅性现在是必不可少的——即使对非创造者也是如此。
不是在理解LLM内部机制方面——而是在：
识别有风险的输出
了解AI限制
当某些事情看起来不对时升级
最终思考：没有责任的贡献是危险的
90-9-1规则仍然适用——但角色正在演变。
90% 必须学会质疑AI输出
9% 必须成为审查者、审计者和验证者——而不仅仅是修改者
1% 可能越来越多地是机器——但人类仍然负责
AI加速——但它也放大风险。
当贡献者不是人类时，监督变得不可协商。
如果我们不更新对AI时代贡献和责任的理解，我们就有让自动化超越责任的风险。
而这是没有管道可以修复的DevOps反模式。
讨论问题
AI工具是否直接为您的DevOps工作流做出贡献？您如何管理它们的输出？
您是否为AI生成的代码或自动化实施了治理？
谁在您的管道中审查或批准AI决策？
让我们在评论中听听您的想法。
我们现在需要塑造这个——在法律和运营后果迫使我们之前。