吴雪：GitOps的意义在于“降本增效”

「对话GitOps之星」是一档由开源GitOps产业联盟策划并发起的聚焦GitOps技术领域谈话类节目。在这里有技术观点的碰撞、也有程序员谈论秃头的烦恼...我们致力于捕捉大咖们分享的精髓，化繁为简。

总之，我们希望向各位传达从事GitOps的个人、企业、项目、社区最真实的一面。希望得到大家的关注，共同呵护GitOps技术在国内的崛起

吴雪

开源GitOps产业联盟个人会员

wuhan2020开源社区副理事长

X-Lab开源实验室创业顾问

硅谷Plug and Play 孵化器导师

斯坦福商学院校友

Q1：介绍自己

大家好，我是吴雪，在开源圈子里大家也叫我“雪哥”。我是开源GitOps产业联盟个人会员，Wuhan2020开源社区副理事长，X-Lab开放实验室顾问，硅谷Plug and Play孵化器的创业导师。我在通信行业工作了15年，先后在安捷伦科技、中国移动国际等公司就职。

我经历了ICT行业运维迭代，从人肉运维到半自动到全自动的演进。在运营商工作期间，接触了较多的云基础设施头部企业及SaaS公司，对云原生的发展有了更深刻的理解，也对行业的发展方向有一些前瞻性的视野。从传统基础设施迈向软件基础设施，是对我个人认知能力、实践能力的全面提升。这也是我为什么希望积极拥抱云计算和开源，努力实现云网融合基础设施代码化的初衷。

Q2：对GitOps技术的理解

由于我的工作背景，我会从目标和交付为出发点谈谈我对GitOps技术的理解。

大家都知道，GitOps包括几个关键词：Infrastructure as Code(laC)、MR、CI/CD。这些所有的关键词聚焦到一起的核心价值是降本增效，以交付目标（指交付场景）为导向，收敛需求和变化，自动化地进行验证和交付的过程。

从2006年开始，我在做一些行业技术性的工作，比如：核心路由器的集群测试、运营商网络运维的工具和软件。当时我们觉得能把数据都抓下来通过后处理来定位故障都很了不起。后来利用脚本实现了半自动的工作，但这些脚本更多的是命令式的脚本，弊端是花费很长时间调通的脚本根本不敢动，因为牵一发而动全身。

2018年，我为上云的大客户提供网络融合。当时大家都在积极上云，一个问题却被忽略：大量的数据和IT工作负载搬到云上之后，由于网络管道的带宽有限及时延过大等原因，大家上云的体验普遍比较差。不同行业的用户，千变万化的上云场景，用命令式脚本优化体验已经不能满足要求。网络和云之间的接口一定要由场景来驱动。我们发现，使用容器化的方式代码化网络资源的配置和调用，2-3人团队可以完成以前几十个人也很难完成的工作，能达到十倍以上的效能提升。即“降本增效”。

从管理学和组织行为学的角度看，GitOps降低的是开发组织的人力成本，增加了协作效能，用算力资源的增加以及自动化的方式来达到人力成本协作效能的平衡。大家现在都在强调

“Developer first”，以开发者为先导的方法论。做降本增效也让目标人群相对发生了改变：我之前做产品，更多面向B端企业用户和C端消费者，现在我们的工具更多面向的是Developer（开发者）和Entrepreneur（创业者）。他们的特点是更善于利用手中数字化的工具，即利用“外挂”，更精准地执行目标。

综上，我认为GitOps是以目标为导向，让我们更好地利用手里数字化的工具和机器人替我们解决大量重复性和容易犯错的工作的一套工具和方法论。

Q3：和极狐(GitLab)一起优化CI/CD效能

大家现在普遍把工作负载、代码、数据放在云上，有很多服务都是云原生的。但是云和云之间的连通以及从中国访问海外多个云的代码库会因时延和丢包产生各种不可控问题，流水线执行往往非常慢（有些需要花半天以上）。如何减少因为网络的问题引起的CI/CD流水线效能非常差的状况，这就是我们要解决的问题。

跟极狐合作，我们把之前做的Network as Service 逐渐转变为 Network as Code，让流水线动态拉取网络加速服务，最优地使用网络资源，大幅降低耗费时间。

目前优化的效果比较显著，已经达到了十倍以上的效能提升。

Q4：开源心路历程

很多朋友认识我是在疫情期间，当时我们在做wuhan 2020开源社区，我也创办了Hack for Wuhan。其实在此之前，我已经接触开源很长时间了。

图：Hack for Wuhan 海报

图：Hack for Wuhan 介绍

2016年我和朋友在英国成立了创业公司，基本上依赖开源软件快速实现了创业项目，处于“只用而不贡献”的阶段。那时开源对我而言，可以帮助没有融资的小团队快速试错。后来我便考虑如何为开源社区做出更多贡献。

2018年我在斯坦福大学求学期间做了一些研究，对云服务以及开源的商业模式非常关注。在斯坦福，我会经常和我的老师交流这方面的看法。

新冠疫情开始之初，我还在美国，在参与线上抗疫的过程中加入了Wuhan2020开源社区。项目在GitHub上快速获得了6k＋star，社区逐渐形成了开源向善的价值观。

Q5：Wuhan2020开源社区

Wuhan2020开源社区成立于新冠爆发初期，当时公共医疗资源无法满足激增的病情，疫情中心区域出现医疗资源告急的情况。社区发起后，很快涌入了上千开发者与志愿者着手解决这个问题。

图：Wuhan2020社区界面

我们发现，民间的信息采集和公共平台信息分散，同时各种求助信息格式混乱很难统一，假消息满天飞。基于此，社区成员按照 SOP（标准操作流程）和人员特长分为小团队，通过线上配合实现快速协作和迭代。就这样，一群热爱开源文化的开发者在GitHub上自主搭建了Wuhan2020项目网站。

其中，SOP 包括：对信息搜集、验真、录入、发布，用流程规范大家的行为，保证每个人的行动一致，结果偏差就会最小。

图：Wuhan2020协作流程

另外，我们定义了一套数据输入和验证的漏斗。同时和公开信息交叉验证，尽可能杜绝了假消息，医院官方人员直接录入并可溯源。

这一套流程经过迭代而被沿用下来，至今也被运用到应对其他公共事件上，也可供其他组织使用。

Q6.：开源向善

「灾情之下，一个透明、可信的信息平台能够助力去中心化的、自下而上的志愿者网络，并使协作行为迅速规模化。」斯坦福慈善与社会创新中心的中国项目负责人吴莹女士这样评价 Wuhan2020。

后来我们总结得出：通过开源的协作，包括数据的开源、软件的开源、协作模式的开源，直接影响到了灾情之下人类的行为，甚至可以促进人类的发展。开源不光能做公益、能商业化，还可以产生协同的增益，以人为本，以向善为基调。如此大的愿景和目标，又可以带给我们可具体落地的小事情去做，这就是我们把社区的发展方向定为“开源向善”的原因。

Q7：浅谈开源商业化

很多人认为“开源向善”和“开源商业化”二者不能兼得。于我而言，协同创作共享价值更重要。我们并不能认为“开源商业化”的动机不纯，同理，用开源做公益也不是高高在上的。在斯坦福商学院期间，我做过关于开源商业化的访谈及研究，可以就这个话题跟大家进行简单的分享。

目前的主流的商业化模式有：

模式一：RedHat模式——软件免费，通过技术支持来收费。

模式二：双授权模式（Dual-License）——代码具有两套许可证。一套是传统的开源许可证比如 GPL ，另一套是商业许可证。比较有代表性的例子是 MySQL 。

模式三：Open Core 模式——把一部分软件开源，另一部分增值的闭源收费。我们经常见到很多“社区版”的软件可能就是开源的，而与之对应的“企业版”的模式就很可能提供了很多额外功能并收费。

模式四：SaaS （软件即服务）——开源软件公司把自己的代码部署在云上，给最终用户提供最终交付。

这种模式的好处在于：1) 避免前期一次性购买软件和专用硬件的高额成本； 2) 部署快、随时享受升级； 3) 运维责任转嫁到了 SaaS 提供商身上，由供应商提供管理服务。

Q8：和OGA联盟一起做的事情

我是一位实践者，经历着从传统的运营商思维到“infrastructure as code”转变。我发现，联盟不光在做GitOps布道，更重要的能够提升行业的软件能力和数字化能力。

我个人持续地帮助一些公司做行业数字化转型。希望能够借助OGA联盟的平台，助力更多传统垂直行业的数字化与信息化转型。