在 KubeCon & CloudNativeCon 欧洲大会上，两位平台工程师分享了让 Flux GitOps 框架在全公司落地的真实路径——没有产品经理、没有高层授权，仅靠两位工程师，把一个长期无人使用的平台推到了业务方和开发者双向买单的位置。他们的核心结论是：技术采用本质上是一个说服问题，而非技术问题。
Lucas Hornung 和 Christian Matthaei 所在的平台团队，曾长期陷于一种工程师熟悉的困境：造了很多很酷的功能，但开发者根本不用。转折始于一次危机——上司打电话告知即将辞职，团队能否继续运转变得扑朔迷离。
Matthaei 被要求向管理层做一次简短汇报：介绍自己是谁，以及一个重要的技术话题。他引用了 Simon Sinek 的话作为方法支点：
他们随即安排了与利益相关者的会议，阐明问题、征求建议、认真倾听——不是等别人来发现方案有多出色，而是主动走出去沟通。
Hornung 与 Matthaei 最终提炼出五条经验。这套方法看似简单，却是通过艰辛实践领悟的，且借鉴了 Sinek、Carnegie、Knaflic、Collins 四位沟通与组织学者的理论，从零拼出：
关键不在步骤本身，而在双向推广的逻辑：一方面用业务语言向上层推销，另一方面通过让开发者切身感受痛点来争取支持。Hornung 直言：
在商业背景下让自身价值可量化，是他们方法论的核心一环。他们选择在公司内部公开展示 DORA 指标——业界公认的 DevOps 效能度量框架。
大家纷纷抬头点头表示认同。但随即被追问"我们的实际数据是多少"——团队答不上来，当时根本没有这些数据。
开展试点项目，测出部署速度提升 77%，赢得各方支持。后发现测量未捕捉整个部署链中隐藏的异步处理过程，数据不准，被迫公开承认失误。
这次翻车反而带来关键领悟：数据能打开大门，但并非全部真相。团队随后转向叙事化方式——局面才真正发生转变。Matthaei 对 DORA 的评价更务实：
起初，团队试图用试点结果和技术论据说服开发者，收效甚微。真正的突破发生在他们开始用令人感同身受的角色讲故事时——隐藏的运维痛点变得既可见又具体：
转变的关键不是"GitOps 在技术上更优"，而是"GitOps 意味着我能一觉睡到天亮"。一旦开发者在故事中看到自己的经历，参与度和采用率便有了显著提升。
本篇素材来自一场技术大会主题演讲的单方经验分享，引用的 77% 部署提速数据已被讲述者自己承认测量失准，Flux 全公司推广的实际采用率与留存数据未见第三方独立复测。读者宜将其作为方法论叙事而非效果验证来读——它的价值在于把"工程师要不要学沟通"这件事摆到了台面。
值得留意的支线：这套方法论的理论拼装来自四位非技术领域作者（Sinek 讲"为什么"、Carnegie 讲人际、Knaflic 讲数据叙事、Collins 讲组织）——平台工程师正在从管理学经典里找弹药，这本身就是行业信号。
原始演讲主题："以人性化方式推广 Flux"，来自 KubeCon & CloudNativeCon 欧洲大会。
完整报道 → InfoQ 原文