亚马逊AWS官方博客

OpenSource | Hygieia 与 Capital One 的 DevOps 之旅

来自 Tapabrata Pal AWS 客户创建了许多有趣且有用的开源项目,这些项目应当为更多的受众所知。我很高兴能够在此博文中宣传这些项目。下面我们将奉上由 Capital One 的 Tapabrata (Topo) Pal 撰写的客座博文。- Adrian


Capital One 是一家顶尖的数字银行,拥有数百万个账户,但我们的 DNA 与许多其他金融机构不同。作为一名效力于多个 LOB 团队的 Capital One 高级工程研究员,我深知我们在自有软件构建、公共云、微服务、开源、DevOps 和持续交付方面的承诺如何让我们变得与众不同。从一开始,我们就踏上了变革并以技术公司而不仅仅是数字银行彰显自身独特魅力的旅程。这一旅程的重要组成部分是我们的 DevOps 和持续交付方法。以下三个因素帮助我们发展了 DevOps 流程:

  • 我们起步早。我们在大约五年前便开始了我们的旅程。那时,我们是最早采用 DevOps 的大型“非独角兽”企业之一。这使我们在竞争中处于领先地位,从而有时间以有机方式开发和管理自己的流程。
  • 领导层推动该流程。许多企业在 DevOps 领域举步维艰,因为其领导层并不完全赞同。我们的情况正好相反。我们的领导层在该流程的早期便对整个模式表示赞同,从一开始就完全支持我们的团队。
  • 我们的工程人才。我们内部拥有大量优秀的工程实践和软件工程师。我们的技术团队大多数都内包任务,这是我们相对于较多外包公司所具有的一大优势。

持续交付,不担心发布

五年前,当我们开始引入大量的 DevOps 实践时,我们的目标是不仅推出软件,而且还要推出高品质软件。我们将持续交付作为实现这一目标的重要环节。促使我们迈向成功的主要因素是我们采用的“不担心发布”方法。在将代码投入生产时,会有很多担心。编写代码的开发人员担心,如果他们的代码损坏,可能需要他们进行修复。产品经理担心,将代码交付生产可能会使生产服务器不堪重负并损坏。高层领导担心,在高峰时段或几天内可能会中断某些关键任务型服务。Capital One 采取了许多措施来避免出现这些担忧。其中许多涉及到测试自动化、蓝/绿部署,以及在我们的交付管道中实现制衡的其他技术。我们希望交付团队在日间部署到生产时不会有任何担忧。我们希望他们了解,如果其中的一些部署失败,没问题,因为我们会使用生产工具的非活动区域并且会控制流量。因此,您可以根据需要部署到生产,如果某些方面失败,没有关系,因为您可以快速进行恢复而不必担忧。

Hygieia 和持续交付

要构建持续交付的软件交付管道,最终要使用大量的工具,从而让管道管理变得很困难。“我的软件处于管道中的什么位置?”“我的构建正确吗?”“我的测试正确吗?”“哪些测试通过了?哪些测试未通过?哪些安全扫描正常?哪些安全扫描不正常?”但是,作为开发人员、产品经理、QA 人员,甚至是高层领导,您需要知晓代码位于管道的什么位置。要了解管道的运行状况,您需要知道管道所处的状态、有哪些问题,以及瓶颈是什么。虽然每个单独的工具可以详细提供这些不同的信息,但您无法从单一视角同时了解所有这些信息。这个单一的视角就是我们尝试使用开源 DevOps 控制面板 Hygieia 创建的内容。Hygieia 从所有管道工具中收集关键指标,并在一个控制面板视图中呈现这些数据,从而帮助您确定管道的运行状况是否良好。

我们为何构建 Hygieia?

在我们 DevOps 之旅的早期,我们基于三大支柱构建了一项策略:

  • 尽量让管道中的所有内容实现自动运行。
  • 转变剩余的全部内容,这意味着,执行交付生命周期后面部分的所有步骤并将其提前,从而在遇到瓶颈之前先将其解决。
  • 实现完全透明和快速反馈循环,以便尽快在管道的每个阶段向利益相关者提供反馈。

我们查找了许多工具 (包括商用工具和开源工具) 来帮助开发此功能,但未能找到一个集我们所需的全部功能于一体的工具。我们开始自行构建内部 DevOps 控制面板工具并做出决定:为了坚守我们的开源第一政策,我们应当将其开源。Hygieia 适合多个团队使用大量工具在可能存在诸多瓶颈的管道上创建或构建产品的大型企业。不论处于哪个行业,这都是大型企业面临的常见问题。Capital One 构建 Hygieia 的时机和场合都恰到好处,原因有以下两方面:

  • 我们是目标受众。作为一家利用 DevOps 的大型企业,对于在采用和扩展 DevOps 中遇到的问题,我们深有感触。因此,我们能够深刻了解如何在这一旅程中取得成功。
  • 我们开始采用的时间较早,对于其他组织目前正在学习的内容,我们早已了然于心。我们根据自身经验展示了某些自认有用的指标,以此将部分学习心得融入 Hygieia 控制面板中。

我们发现 Hygieia 在各个行业的应用越来越多。随着更多大型企业加入我们的用户社区,对其他“企业级”功能的需求将会增加。我们的下一项重大举措就是与用户社区合作,创建一个高管控制面板,让大型企业的高管可以更轻松地访问他们的数据并利用其来推动工程团队的 DevOps 实践。我们仍会全力让 Hygieia 保持开源。2018 年的目标是增强协作、让更多大型企业加入进来,并为 Hygieia 创建一个管理机构。我们希望大家不仅能提供代码,而且还能为我们的 DevOps 和主管控制面板提供意见和解决方案。

2018 年及以后

2018 年,仍有许多公司在驻足观望并设法了解他们是否应当投入 DevOps 运动。此外,有些已经引入 DevOps 多年的公司也在设法弄清如何改进流程并扩展到更新的领域 (例如微服务无服务器)。DevOps 不仅涉及到工具、技术或万能型流程,还涉及到快速反馈、透明化和创新。在 DevOps 中,成功意味着开发人员可以毫无畏惧地将代码部署到生产中。由于流程从来不会停止,并且没有要衡量的最终产品,几乎可以说本身没有成功标准。DevOps 和持续交付是持续不断的改进过程;我们不能说:“嗨,我们成功了,回家开个派对庆祝吧!”这一点同样适用于我们的代码、我们构建的用于管理这些代码的工具,以及 DevOps 概念本身。


Capital One 的 Topo Pal Topo Pal Capital One 高级主管兼高级工程研究员 Tapabrata Pal 拥有 20 多年的 IT 从业经验,从事过零售、医疗保健和金融行业的各种技术工作 (开发人员、运营工程师和架构师)。在过去六年里,Tapabrata 推广并带领公司实施 DevOps 举措。目前,他担任高级主管兼高级工程研究员,致力于在监管环境下大规模实施 DevOps 和持续交付。Tapabrata 也是 Hygieia 开源项目的社区管理员和核心贡献者。此前,Tapabrata 花了一段时间在固体物理学领域从事博士和博士后学术研究。


本博文中的内容和观点均源自第三方作者,AWS 对本博文中的内容或准确性不承担任何责任。

 

Adrian Cockcroft

Adrian Cockcroft

AWS 云架构战略副总裁 Adrian Cockcroft 在技术领先领域有长期的职业生涯,并对未来该领域可能发生的事情着迷。在他担任的 AWS 的角色中,Cockcroft 专注于云本地和“全能”客户的需求,并领导 AWS 开源社区开发团队。在 AWS 之前,Cockcroft 在英国成为开发人员,加入 Sun Microsystems,并于1993年移居美国,最终成为杰出工程师。 Cockcroft 于2004年离开Sun,是 eBay 研究实验室的创始成员之一,并于2007年开始在 Netflix 工作。他最初指导一个致力于个性化算法的团队,然后成为云架构师,帮助团队扩展并迁移到 AWS。随着 Netflix 公开分享其架构,Cockcroft 成为会议和高管峰会上的常客,创建并领导 Netflix 开源计划。 2014年,他加入了风险投资公 司Battery Ventures,推动围绕 DevOps,微服务,云和容器的新想法,并于2016年10月进入 AWS 担任目前职务。2017年期间,他招募了一批经验丰富的开源技术专家,并在 AWS 峰会上发表主题眼睛以及在世界各地开展许多其他活动。 Cockcroft 拥有伦敦城市大学应用物理学学位,并出版了四本著作,其中最知名的有 Sun Performance and Tuning(Prentice Hall,1998)。