Author: AWS Team


如今的首席信息官正在合并业务和技术

“成竹在胸。” — Stephen R. Covey

上一篇文章中,我断言今天的技术执行官需要扮演首席变革管理官 (CCMO™) 的角色,领导其组织完成企业云之旅。本文将探讨与该职责相关的三个主题中的第一个:合并业务与技术 (统一管理)。另两个是提供明确的目的 (对下管理) 和制定 (或打破) 新的规则 (管理执行),我将在后续文章中进行讨论。

今天,成功的技术高管必须帮助他们的行政助理了解技术如何适应 — 甚至推动 — 其业务发展。如果组织理解这一点,您的执行团队就会意识到您对组织的业务目标负有领导责任,您是执行团队的重要成员。

当前的业务领域受到一些新兴公司的冲击,创建和运营这些公司的高管和企业家不仅了解如何将技术应用于其业务,还将确定在整个行业中发挥作用的角色技术。例如,运营酒店业务的 AirBnb、提供汽车相关服务的 Uber、实现家庭自动化的 Nest Labs、提供存储服务的 Dropbox 等。虽然这给传统企业带来了压力,但也为世界各地的 IT 高管们创造了机会。与从事技术工作的人员相比,没有人比他们更了解如何运用技术来满足市场日益增长的需求。对于大部分职业生涯都是在大公司中度过的我们来说,这一点尤其正确。我们说着相同的企业术语,了解哪些限制条件是硬性的,哪些是可变通的,也知道如何跟您的每位高管沟通。公司不能再指望让技术高管们在幕后默默工作就能取得成功。

而且,由于云承担了传统上与企业 IT 相关的许多千篇一律的繁重工作,今天的 IT 主管可以将更多的时间和资源投入到推动业务发展和保持组织竞争力的活动中。云是这些新兴颠覆性力量使用的关键工具。使用这种工具不意味着为您提供发展业务所需的想法,但这样可为所有人提供更多的可能性,让竞争环境更加公平。

下面是一些提示,供准备引领组织踏上云之旅的您参考:

关爱同事

迁移到云并不只是一次技术转变。它是一次业务变革,管理层的所有人都应该关心这一点。您的工作是考虑执行团队及其职能会受到哪些影响,或可能会受到云之旅的哪些影响。

我无法在一篇文章里介绍太多类型的高管,但是:

首席财务官通常关注如何降低前期成本以及只支付所用费用的能力。我发现每月成本变化时常会引起一些摩擦,但总拥有成本始终较低,特别是当您摆脱了容量规划和维护活动的负担时。与您的财务主管密切合作,预测支出、管理资源利用率、错开预留实例 (RI) 的购买时机 (因为您更熟悉自己的环境),并考虑如何利用劳动力成本 (因为随着时间的推移,您的资源会越来越多地专注于产品开发和创造资产)。

首席营销官通常关注如何保持公司品牌的新鲜度,以及应对不断变化的市场形势。如果您的品牌网站能够一天更新数次而不是一月才更新一次,会产生什么样的影响?能够无限扩展的数据仓库如何帮助首席财务官更好地了解客户?如果试错成本很低甚至不需要付出成本,他们可以对一小部分用户尝试哪些试验?

人力资源副总裁希望看到您适当地关爱员工,了解您如何聘用具有新技能的员工。充分利用 AWS 培训和认证,在您自己培训课程中采用我们的培训专业知识。在关于该主题的后续文章中,将探讨如何指导您的员工 – 小心剧透 – 只要愿意学习,您团队中的每一个人都能为您的云之旅做出贡献。此外,请与其他要迁移到云的公司建立合作关系,了解他们如何聘用新角色以及如何管理现有员工的职责转变。例如,DevOps 文化如何融入您的组织,运行您构建的内容意味着什么?

首席执行官关注以上所有事务,以及公司如何保持竞争力。运用您从其他高管处获得的信息塑造完整的愿景,并展示如何利用现代技术在同样的限制条件下完成以前无法实现的任务。

在道琼斯,我设定了一个目标:每个月邀请几名高管一起就餐。就餐期间,我什么都不做,只听他们有什么抱怨。然后,我根据掌握的信息调整我们的策略,并确保向他们传达其影响力会如何改变我们的方向。这是一个展现对高管需求的关心、建立信任并获得他们支持的简单愉悦 (如果您喜欢社交和美食) 方法。运用这个方法的关键在于:您不仅要倾听,还要根据获得的信息采取行动。

寻求帮助

您不必独负重担。您可以将客户经理看作旅途中的领队。他们会很乐意与您及您的执行团队合作,帮助传达讯息并从迁移到云的过程中获益,使其与您的业务保持一致。如果您需要的影响力超出了客户经理的专长范围,他们会寻找合适的人员,不管是在 AWS 内部还是外部。我们很乐意为您创造机会,让您能够与志同道合的人同行 — 不只是在我们倡导的活动中,而是您旅途中的任意时刻。我在担任上一个职位时,跟其他公司做过一些交流,与其他高管交流不仅能够获得启发,还可验证自己的想法。

AWS 合作伙伴网络 AWS 培训和认证也是加快您的云之旅的绝佳资源。在讲述最佳实践时,我会更详细地介绍。但是,我发现很多公司会与人力资源部门合作,将基于我们计划的 AWS 培训制度化。在道琼斯,我们的 DevOps 团队与人力资源部门合作设定了 DevOps 日,定期推广我们不断改进的工具和最佳实践。这是向地理位置分散的大型团队扩展技能的好办法。同样,您的客户经理可以帮助您在这些区域之间建立适当的联系。

提升 IT 品牌形象

我与许多希望提高部门品牌形象的 IT 主管交谈过。我在彭博花了十多年的时间开发业务拓展软件。我到道琼斯的原因之一是想帮助他们改变 IT 是成本中心的心态,我想要将 IT 建成一个推动业务发展的部门。我必须得感谢我们部门里的每一个人,谢谢他们的辛勤工作和奉献精神,是大家齐心协力才实现了我们所要达成的变革。

AWS 是实现这一转变的基础之一,但执行层面的大部分努力的核心是:了解每位高管的痛点、他们想要解决的 IT 问题,然后调整技术来帮助他们实现目标。在使用云技术更快地交付更好的结果几个月后,我们花了几个月的时间重新培训执行团队及其部门,使他们将我们看作是技术而不是 IT。这看似无足轻重,但它使我们对话的语调和生产力发生了重大的变化,体现了该部门对整个公司变革的贡献。

这与您的经验是否相符?我们很乐意倾听。

不断前进
-Stephen
orbans@amazon.com
@stephenorban
http://aws.amazon.com/enterprise/

注:提供执行支持是我在新的企业云之旅系列文章中撰写的七条最佳实践中的第一条。其余六条是:教育员工、培育试验文化、寻找合作伙伴、创建云卓越中心、实施混合架构和实施云优先策略。请保持关注以获得每条最佳实践的更新。

 

慎重选择云计算迁移方案

就算没有故意保送上垒规则,他的队友还是会保送他上垒,队友只需要装作无意地故意保送他上垒就行了。您心里知道的远比眼睛看到的东西要多得多。-George Brett

我经常说我认为采用云技术能够给企业带来变革,但这是个需要时间的旅程。虽然每一个企业的云之旅都将是独一无二的,但我发现变革最快的企业都采用了深思熟虑和有条理的方法。这篇文章概述了 AWS 企业解决方案架构师 Peter Buonora 的一些想法。言归正传。

(more…)

使用 Amazon Polly 和 简单 Python 脚本将你的文本转换成 MP3 格式

文本转语音技术可将任何数字文本转换为多媒体体验,让用户能够在处理多任务或进行其他活动时收听新闻、博客文章、甚至是 PDF 文档。借助 Amazon Polly,您可以转换 RSS 源或电子邮件,以音频文件形式存储合成语音。

目前,Amazon Polly 控制台支持粘贴长度不超过 1500 个字符的文本、选择语言和区域以及选择语音。之后,您可以聆听转换后的文本或将其下载为 MP3 文件。此外,您还可以使用 AWS 命令行界面 (AWS CLI) 从 AWS 管理控制台执行转换。

复制少量要试听的文本,然后打开控制台。

1. 在搜索框中键入 Polly。

2. 要试用 Amazon Polly 服务,请在 Plain text 选项卡中粘贴文本并聆听输出。

如果要使用 Amazon Polly 将书籍等长格式文本转换为语音,则需要将文本切分成 1500 字符长的数据块。如果 AWS CLI 命令能够接受不限大小的文本文件作为输入并自动转换成 MP3 文件,岂不是更好?

(more…)

制造一辆无人驾驶车辆 Part2:全力加速

本文是我们的系列中的第二篇博客文章,旨在指导您制作 1/16 比例的无人驾驶车辆。您还可收听我们的 Twitch 网络直播以回顾这些博客文章中讨论过的概念。在跟随我们操作之后,您可以将您自己的车辆带进 re:Invent Robocar Rally 2017 的赛道,也可以使用我们提供的车辆。

在我们的第一篇博客文章中,我们制作了一辆 Donkey car 并将导航服务器部署到您的 Amazon EC2 实例上。在本篇博客文章中,我们将布置一个赛道并教您的车辆使用 Amazon EC2 Systems Manager 和 AWS IoT 进行驾驶。如果您已经关闭了 Donkey Server EC2 实例,现在请将它打开并获取其公共 IP 地址。获取公共 IP 地址后,我们会将您的车连接到 EC2 Systems Manager 以远程访问它。之后,我们会将您的车连接到 AWS IoT 以跟踪可用来与好友比较圈速的遥测数据。

赛道布置

教您的车驾驶的第一步是布置赛道。准备好赛道后,您需要驾驶您的车辆在赛道上跑第一圈以开始训练其神经网络。我们要使用的车的速度相当快并且转弯半径不太大,因此您需要从没有急弯的赛道开始。

除此之外,您布置的赛道的大小受您的可用空间和您手头的胶带数的限制。您可在设计中尽情发挥创意,但要确保将各个角度的左转和右转考虑进去以便让您的神经网络接触多种不同的情况。请记住,您的车辆使用其前置摄像头观察您布置的赛道,因此您需要确保能够轻松区分胶带与地面。

赛道设计提示和技巧

  • 与具有各种光亮和阴影水平的室外赛道相比,室内赛道提供的持续照明产生更好的效果。
  • 您的车通常具有最小 30 度的转弯半径,因此在设计拐角的弯度时应记住这一点。
  • 您可使用白色丝带和蓝色喷涂胶带制作临时赛道。
  • 您还可使用一条白线作为赛道。行为克隆方法将学习沿着线驾驶。
  • 无光表面胶带的效果比光面胶带的更好。

(more…)

Amazon Elasticsearch Service 现已支持 VPC

从今天开始,可以从 Amazon VPC 内部连接到您的 Amazon Elasticsearch Service 域,而无需 NAT 实例或 Internet 网关。Amazon ES 的 VPC 支持易于配置、非常可靠,还可以提供额外的保护层。凭借 VPC 支持,Amazon ES 与其他服务之间的所有流量都可以留在 AWS 网络中,从而与公共 Internet 隔离。您可以使用现有 VPC 安全组管理网络访问,也可以使用 AWS Identity and Access Management (IAM) 策略提供额外保护。Amazon ES 域的 VPC 支持不收取额外费用。

入门

在您的 VPC 中创建 Amazon Elasticsearch Service 域很容易。只需要遵照正常创建集群的所有步骤,然后选择“VPC 访问”。

就是这样。无需其他步骤。现在就可以从 VPC 中访问您的域了!

需知信息

为了支持 VPC,Amazon ES 至少在您 VPC 的一个子网中放置终端节点。对于集群中的每个数据节点,Amazon ES 都会在 VPC 中放置弹性网络接口 (ENI)。每个 ENI 都会使用您的子网 IPv4 地址范围中的一个私有 IP 地址,并收到公有 DNS 主机名。如果您启用区域感知,Amazon ES 会在位于不同可用区的 2 个子网中创建终端节点,这样可提供更高的数据持久性。

您需要留出相当于集群中节点数量三倍的 IP 地址数量。如果启用了区域感知,可以将这个数字除以二。最理想的情况是,您可以为 Amazon ES 创建专门的子网。

几点注意事项:

  • 目前,您无法将现有域移动到 VPC,反之亦然。您必须创建新域并迁移数据,才能利用 VPC 支持。
  • 目前,Amazon ES 尚不支持 VPC 内部域的 Amazon Kinesis Firehose 集成。

要了解更多信息,请参阅 Amazon ES 文档

Randall

Amazon Lightsail 更新 – 启动并管理 Windows 虚拟专用服务器

我首次介绍 Amazon Lightsail 是通过去年的一篇博客文章:Amazon Lightsail – 兼具 AWS 的强大功能与 VPS 的简易性。Lightsail 自去年推出以来,数千名客户已使用它启动了基于 Linux 的虚拟专用服务器,从而开启了 AWS 之旅。

今天,我们又增加了对基于 Windows 的虚拟专用服务器的支持。您可以启动运行 Windows Server 2016、Windows Server 2012 R2 或 Windows Server 2016 (结合 SQL Server 2016 Express) 的 VPS,并在几分钟内投入正常运行。您可以使用 VPS 生成、测试及部署 .NET 或 Windows 应用程序,而无需安装或运行任何基础设施。只需一两次点击,备份、DNS 管理和运行指标,一切尽在掌握。

提供五种规模的服务器,512 MB 到 8 GB 的 RAM,1 或 2 个 vCPU,以及高达 80 GB 的 SSD 存储。最低价格为每月 10 USD (包括软件许可证):

您可以免费试用一个月 (最多 750 个小时) 512 MB 的服务器。

启动 Windows VPS
要启动 Windows VPS,请登录 Lightsail,单击 Create instance,然后选择 Microsoft Windows 平台。如果您希望运行 SQL Server 2016 Express,请单击 Apps + OS,如果只需要 Windows,请单击 OS Only

如果您希望在实例首次启动后使用 Powershell 脚本对其进行自定义,请单击 Add launch script 并输入脚本:

选择实例计划,输入实例名称并选择要启动的数量,然后单击 Create

您的实例将在大约一分钟后开始正常运行:

单击该实例,然后单击 Connect using RDP

这时将通过基于浏览器的内置 RDP 客户端连接 (您也可以使用其他客户端的 IP 地址和凭据):

当前可用
此功能已在以下区域提供:美国东部 (弗吉尼亚北部)美国东部 (俄亥俄)美国西部 (俄勒冈)欧洲 (伦敦)欧洲 (爱尔兰)欧洲 (法兰克福)亚太地区 (新加坡)亚太地区 (孟买)亚太地区 (悉尼)亚太区域 (东京)

Jeff

关于“使用云的混合架构”的三大误区

“人生最难的就是要学会哪座桥可以过,哪座桥可以烧。”–David Russell

在以首席信息官的身份负责多个基于云服务的业务解决方案的交付工作时,我开始对混合架构有了一些自己的看法。在过去的 5 个月里,我有幸与大公司的首席信息官和首席技术官进行了数十次对话,这进一步加深了我对这个主题的想法。与此同时,我阅读了许多讨论混合架构的文章和博客,我看不出行业对采用云技术的混合架构是否达成了共识。

公司出于各种不同的原因采用云技术。云采用者已获得敏捷性提高、成本降低和全球影响力扩大等优势。对于我接触过的许多首席信息官来说,实际上可归结于它能够将宝贵资源充分转化为能够促进业务发展的资源。换句话说,将与管理基础设施相关的千篇一律的繁重工作转化为与构建其品牌知名产品和服务相关的活动。

也就是说,大多数企业的 IT 组织已经建立了他们今天所运营的基础设施和管理模式。我接触过的许多首席信息官希望尽快将这一基础设施迁移到云,但必须认识到,有意义的云采用是一个需要时间的过程。在迁移到云的过程中,公司需要一种能够保持系统正常运行同时充分利用其现有投资的方法。在我撰写的有关企业云之旅的文章中,我讨论过公司应该如何使用 AWS Virtual Private Cloud (VPC) 和 Direct Connect 将其本地基础设施拓展到 AWS 上,以创建混合架构。对我来说,这是最有意义的混合架构,也是许多公司在最大限度地利用云的优势时所采取的步骤。

除此之外,关于混合架构的对话就变得有些复杂了。我在市场评论中发现了三个趋势,初看起来挺有道理,但稍一深入分析,就会发现这些观点站不住脚。这三个误区是:

误区一:混合架构是永久目的地。用“永久”来形容这一观点有些太过绝对了。拥有大量陈旧系统的大型公司将运行混合云架构一段时间 (可能是以年计数)。每个组织的云之旅会有所不同,每个人都将按照自己喜欢的步伐前进。但是,我认为未来不会有太多公司运营自己的数据中心。其淘汰过程可能需要 3 年以上的时间,但我确信这一定会在 15 年内实现。能够加速这一转型的因素至少有四个:
1. 云提供商实现的规模经济效应将随着采用范围的扩大而不断增长。这些优势终会通过这样或那样的方式令云消费者受益。
2. 云技术的创新步伐是前所未有的。2014 年,AWS 发布了超过 515 项增强功能,近 3 年来创新速度几乎翻了一番。
3. 公司运行业务所依赖的技术 (如电子邮件、生产力、人力资源、CRM 等) 越来越多地构建在云中。
4. 有助于企业迁移到云的技术和业务的数量正在迅速增长。您看看 AWS Marketplace 和 AWS 合作伙伴网络就知道了。

误区二:混合架构允许您在本地基础设施与云之间无缝迁移应用程序。表面上看起来好像很有吸引力,但这个前提有一个根本性的缺陷。它假定云和本地基础设施具有同样的能力。我知道很多公司都具备管理其基础设施的能力。与此同时,有很多公司是想要获得其数据中心不具备的功能和特性才迁移到云的,这些功能和特性有:真正的弹性、安全性、随用随付、持续不断的创新流等。您在设计应用程序的架构时,如果想要在自己的数据中心和云间无缝切换,则您的应用程序的功能就只能限定为数据中心和云都具备的功能集合。

误区三:混合架构允许您跨多个云提供商无缝地代理您的应用程序。我认为,这个论点有一个细节值得探讨。公司正在使用各种不同的云解决方案来满足其业务需求。这通常包括基础设施服务的混合,以及运行在公司数据中心之外的其他地方 (通常是在 AWS 上) 的打包解决方案。这完全讲得通。IT 高管应该关注他们试图解决的问题,并根据其面临的限制条件挑选最佳的工具来解决它。

但令我感到惊讶的是,很多公司掉入了陷阱之中:他们尝试构架单一应用程序来在多个不同的云提供商的服务上运行。我明白工程师为什么喜欢这样做 —  – 对工程师来说,造出能够使不同的云协同工作所需的“胶水”是一项莫大的成就。但遗憾的是,这种工作会抵消组织迁移到云所获得的生产力提升。我一直认为这是一种倒退的举动。除了管理自己的基础设施以外,您现在还需要解决多种服务的差异性问题。跟误区二一样,这也会将其应用限制到所有架构共有的功能集合。

我也明白,公司选择这条路线是想让供应商保持诚实,同时避免束缚于单个云提供商。我认为,首先,大型云提供商倒闭的可能性不大,而且云计算行业不太可能会朝着惩罚性商业策略的方向发展。其次,我觉得一定有更好的办法来减轻这种顾虑。使用已知的自动化技术构架应用程序的公司将能够可靠地重现其环境。这种最佳实践使他们能够充分发挥云的弹性优势,并将应用与基础设施分离。如果这一点做得足够好,迁移到其他云提供商 (如果有充分理由需要这样做的话) 就变得不那么重要了。

做出技术选择有时并不容易,而且很难做到完美无憾。但创建混合架构并不一定如此。我很乐意倾听您的想法。请留言加入讨论。

不断前进
-Stephen
orbans@amazon.com
@stephenorban
http://aws.amazon.com/enterprise/

 

开启云之旅的 4 项基本投资

“好皮肤是妆容的最佳基础”- Holland Rolland

最近,我在一篇文章中介绍了一种称作“采用阶段”(SofA) 的心理模型,它描述组织在实现云优先时所经历的旅程。我发现,这个旅程与其说是技术行为,不如说是一种领导力和变更管理行为。尽管没有通用的答案,我还是希望在高管们引导组织踏上云之旅时,把 SofA 看作是一个有用的模型。

我的上一篇文章主要介绍第一个采用阶段 (我称之为“项目”),其中介绍了我在开启云之旅的组织中的所见所闻。

通常只需要几个项目,大多数组织就能意识到云上的交付速度能够快多少。这篇文章介绍我发现各组织投资的四个典型领域,他们通过这些投资将云优势拓展到整个组织;我把这称为“基础”阶段。

1. 创建云卓越中心 (CCoE) 团队

我认为创建 CCoE 是组织最重要的基础投资之一,特别是在您需要发展自己的企业文化时。与我对话的许多组织使用其 CCoE 作为支点在组织中的各个层面推行变革,这是我在企业取得云迁移成功的飞轮中提到的趋势。

正如我在组建 CCoE 团队中所说的那样,我希望看到组织组建一个具有多样化视角的跨职能团队。随着系统管理、数据库管理、网络工程和运营等领域通过代码实现自动化,其传统角色正在逐渐融合。我坚信您已经拥有成功实现云迁移所需的人才,只要渴望学习新知识,今天这些岗位上的任何人都适合成为 CCoE 团队的成员。您可能已经知道哪些人适合,哪些人不适合。

在组建 CCoE 时,请考虑各个业务部门如何与之协作,以及组织如何掌控 (集中/分散) 技术选择。

例如,我们在道琼斯组建 CCoE 团队时,将其命名为 DevOps,有意将它与描述运行您构建的内容理念的术语混杂使用。我们的目标是让 DevOps 团队规定运营模式,体现我们倾向于在企业中实施的最佳实践、管理方式和护栏,同时仍然允许各个业务部门自主做出其所需的决策,从而在受控的时间期限内完成其目标。随着 DevOps 团队的日渐成熟,我们的参考架构 (见下文) 也不断完善。我们发现,越来越多的业务部门希望使用 DevOps 团队提供的内容,因为它们可以加快其工作速度、提高其运营效率,而不是因为我们强迫他们使用这些内容。

2. 构建参考架构,在企业各处反复使用

鼓励您的团队在其负责的应用程序中寻找通用模式。如果找到可满足多个应用程序需求的参考架构,则创建脚本来实现该参考架构的自动构建,同时将其纳入安全和运营控制体系。它可能非常简单,如为各种操作系统创建“黄金映像”供您的团队使用;也可能十分复杂,如用于描述托管的所有网站的架构和运营模式的蓝图。

每个参考架构都应考虑如何与您的本地资产通信。我在有关混合架构误区的文章中说过:“我接触过的许多首席信息官希望尽快将基础设施迁移到云,但必须认识到,有意义的云采用是一个需要时间的过程。在迁移到云的过程中,公司需要一种能够保持系统正常运行同时充分利用其现有投资的方法。”有些组织创建一些安全组,以符合其现有控制体系规定的方式穿过本地防火墙进行通信。然后,他们在不同的参考架构中重用这些安全组。

使您的 CCoE 能够观察整个 IT 产品组合,让他们更容易发现和扩展参考架构。在进行扩展时,AWS Service Catalog 可以帮助您在整个组织中存储、许可和分发参考架构。

3. 培育试验文化和发展您的运营模式

云是我职业生涯中见过的最大试验推动力,许多组织使用云之旅作为一项有力的功能来重新考虑其传统 IT 运营模型。

我发现越来越多的组织开始重新考虑为每个业务部门提供多少技术选择自主权。此外,他们还仔细思考如何管理角色和权限、谁负责成本、可以/应该使用哪些工具进行监控和日志记录,以及谁能影响环境中的变化。

例如在 Amazon,每项服务都由一个“双披萨团队”负责,该团队对其提供给客户的服务承担全部责任。这包括所使用的技术、服务的路线图、服务的运营等。

尽管这种运行您构建的内容的心态可能让一些人感到不舒服,我还是发现越来越多的组织开始朝着这个方向发展。许多组织督促其 CCoE 确定合适的运营模型,并将其融入到交付给每个业务部门的参考架构和持续集成工具中。建好适当的“护栏”后,这可大大提升各个业务部门发布更改的频率。

例如,我在道琼斯工作时,我们的 CCoE 构建了一个简单、有效的持续集成管道,借助该管道,我们不再每两周发布一次更改,而是在微小更改准备好后立即推送。2014 年 9 月,在我离开道琼斯之前,我们的 CCoE 团队向我提供了一份文档,单在这一个月,他们就向 MarketWatch.com 发布了 600 次更新。这是我收到的最宝贵的离别礼物。

4. 教育员工,给团队提供学习机会

教育是您带领团队一路向前的最有效的机制。关于这个主题,我已经在以下文章中进行了全面的介绍,我认为,它对于组织在当今的人才市场中保持竞争力极其重要,无论怎样强调都不过分。

在我看来,Capital One 是行业领先的人才发展组织之一。Capital One 云工程技术总监 Drew Firment 在其关于人才转变是云采用中最困难的环节之一的文章中分享了其先进的思想。

结语…

将这些基础投资视为有利于组织未来数年发展的事情。 不要好高骛远,请注意,您可以不断迭代和改善基础。在您学习的过程中,它应该功能强大并且具有灵活性。

您的基础经验是什么?我乐于倾听,欢迎与我讨论如何发表在我的博客上!

不断前进
– Stephen
orbans@amazon.com
@stephenorban
http://aws.amazon.com/enterprise/

 

Amazon S3 深度实践系列之一:S3 CLI深度解析及性能测试

背景

作者在实际的工作当中遇到越来越多关于S3的实践问题,其中被问的最多的也是使用最广泛的工具就是AWS S3 CLI命令行;AWS S3 CLI命令行工具对大文件提供了默认的分段上传下载的能力,同时支持并发上传下载多个文件;AWS S3 CLI 命令行不仅仅提供了高级抽象的cp、sync等操作同时还提供了相对底层的s3api相关的操作以帮助客户应对各种高度定制化的应用场景。

本文通过实验帮助大家更好地理解AWS S3 CLI常用命令的底层原理及在AWS EC2上使用该命令行工具与AMAZON S3交互场景下,影响性能的几个关键要素及几个常见EC2实例类型上的上传下载测试性能情况。

本文是AMAZON S3深度实践系列之一,接着作者会带着大家从AWS CLI探索到Python boto3 S3多线程应用开发实践,再到如何利用前面学到的知识,基于AWS平台利用托管服务构建一个实用的跨区域迁移S3数据的解决方案架构探讨及实践。

基本概念

并发上传vs 分段上传

刚刚使用AWS S3命令行工具的时候,总是混淆分段上传和并发上传的含义;分段上传是指将单个大文件切分成多个小数据块进行上传,而并发上传特指有多个待上传文件或小数据块的情况下,利用多线程同时并发上传多个文件或小数据块。

如下图所示,分段上传首先将文件切分成固定数量的小数据块,再利用多线程并发上传这些小数据块,等 S3收到该文件所有的数据块之后再将它们合并成原始的文件存放在存储桶里。分段上传功能默认会帮你实现并发上传;这样做的好处,显而易见,既可以充分利用网络带宽进行文件处理,同时还可以在网络带宽有限的情况下,减小因网络抖动导致的整个大文件需要重传的问题,即当分段上传中的某个数据块因各种异常没能上传成功时,只需要重新尝试上传该数据块即可。

分段上传vs 断点续传

AWS CLI S3命令行工具默认并没有帮大家实现断点续传的功能,也就是说哪怕我们用cp或sync命令上传一个文件的时候,默认后台会做文件分片进行分段并发上传,但如果由于网络抖动导致其中某些数据块传输失败,那么整个文件又得需要重头开始上传。

但同时我们可以利用 AWS CLI s3api底层接口非常容易地实现断点续传,后面章节我们再展开探讨。

AWS CLI S3 cp命令是如何工作的?

AWS S3 cp 命令是最常用的单文件和多文件复制方法,很多人使用过该命令,但大家知道该命令是如何帮我们执行文件复制的吗?

  • 该命令有帮我们自动做分段上传和下载吗?
  • 分段上传切分文件的依据是什么?每个数据块大小是多大?
  • 这么多数据块,有多线程并发上传吗?我们可以指定线程数量吗?
  • 多个文件的上传下载是如何工作的?

下面我们通过实验来观察和研究下这些问题,整个测试环境基于如下Amazon Linux上如下版本的AWS CLI命令行:

aws-cli/1.11.132 Python/2.7.12 Linux/4.9.51-10.52.amzn1.x86_64 botocore/1.5.95

AWS EC2机型是R4.2xlarge,挂载了一个500GB的gp2测试盘

本地单文件上传场景

第一步,我们首先生成一个48MB的本地测试文件,并通过cp命令上传到S3存储桶,并通过debug开关把详细的日志记录到本地的upload.log文件中,详细命令如下:

$ dd if=/dev/zero of=48Mfile bs=1M count=48
$ aws --debug s3 cp 48Mfile s3://bjslabs/s3/ > upload.log 2>&1
$ ls -lh
总用量 49M
-rw-rw-r-- 1 ec2-user ec2-user 48M 10月 18 00:26 48Mfile
-rw-rw-r-- 1 ec2-user ec2-user 13K 10月 18 00:31 upload.log

第二步,我们通过底层的s3api命令来了解存储到S3上的对象的基本情况,如下所示,通过head-object命令我们可以了解该文件的最后修改时间,对象大小以及一个用于完整性校验的ETag值,那我们如何知道该文件是否是分段上传的呢?

$ aws s3api head-object --bucket bjslabs --key s3/48Mfile
{
    "AcceptRanges": "bytes",
    "ContentType": "binary/octet-stream",
    "LastModified": "Wed, 18 Oct 2017 00:32:56 GMT",
    "ContentLength": 50331648,
    "ETag": "\"64db0c827ecffa128fa9440d3b04ff18-6\"",
    "Metadata": {}
}

要知道该文件是否是利用了分段上传,我们只需要在以上命令中加一个参数就可以判断,如下所示,如果该文件是利用分段上传的功能,通过head-object查询第一个数据块的基本信息就可以得到该文件一共包含多少个数据块,测试文件48Mfile一共包含6个数据块(PartsCount)。

$ aws s3api head-object --part-number 1 --bucket bjslabs --key s3/48Mfile
{
    "AcceptRanges": "bytes",
    "ContentType": "binary/octet-stream",
    "LastModified": "Wed, 18 Oct 2017 00:32:56 GMT",
    "ContentLength": 8388608,
    "ETag": "\"64db0c827ecffa128fa9440d3b04ff18-6\"",
    "PartsCount": 6,
    "Metadata": {}
}

这里我们可以得知,默认情况下cp命令就会采用分段上传功能。而且从以上命令返回信息我们可以看出来,该文件第一个数据块分片大小是8388608 bytes(ContentLength)即8MB,48MB大小的文件一共被分了6个数据块,所以,可以大胆猜测默认的AWS CLI S3命令行工具默认的文件分片大小就是8MB。

第三步,我们已经判断出cp命令的默认是分段上传,接下来我们通过第一步保存的详细日志(该日志文件比较大,可以点击下载)来分析下,cp命令基本的工作流及它采用的多线程并发上传的具体情况:

通过该实验的日志,我们基本了解了cp命令的基本内部流程,因此,这里面有些参数肯定是可以通过配置来进行修改的,接下来我们来根据官方文档:http://docs.aws.amazon.com/cli/latest/topic/s3-config.html 的说明来试验下,修改相应配置,是否如我们所理解的那样运行,这几个参数是:

接下来我们修改参数并对比下,实验内容为同样大小的本地文件在不同参数条件下,通过cp上传到s3,两次运行的结果对比:

在AWS Configure配置文件中,指定S3的配置参数:

$ cat ~/.aws/config
[default]
region = cn-north-1
[profile dev]
region = cn-north-1
s3 =
  max_concurrent_requests = 5
  multipart_threshold = 10MB
  multipart_chunksize = 6MB

执行profile 为dev的上传测试命令:

$ aws --debug s3 cp 48Mfile s3://bjslabs/s3/ --profile dev > 2>&1

对比upload.log和upload2.log,我们可以看出,multipart_threshold和multipart_chunksize参数是对分段上传的影响是很好理解的,但 max_concurrent_requests参数与单个文件的分段上传的并发线程总数的关系,从日志中只能看出单文件的分段上传的并发线程总数受max_concurrent_requests参数影响,但并发线程的总数上限值还取决于文件分片后进入队列被消费者线程消耗的速度。

感兴趣的读者可以在以上实验的基础上,保持其他参数不变,只修改max_concurrent_requests参数,观察并发线程数的情况,作者在max_concurrent_requests参数值分别为8、15、20、30的情况下观察cp同样的文件的线程数情况如下:

$ aws --debug s3 cp 48Mfile s3://bjslabs/s3/ --profile dev > upload2.log 2>&1

对于单文件上传,我们经过前面的实验有了基本的认识,那我们接下来再看看cp命令在分段上传中途发生网络故障,能否实现类似断点续传的功能效果呢?

整个实验思路如下:

  •  利用dd命令产生一个26GB大小的文件
  • 在cp传送中途强行断开
  • 检查此时在S3桶里面的分片情况
  • 尝试再次上传并观察结果
$ dd if=/dev/zero of=26Gfile bs=1G count=26
$ aws --debug s3 cp 26Gfile s3://bjslabs/s3/ > upload.log 2>&1
$ Ctrl-Z(强行中止)

AWS CLI s3api提供了list-parts和list-multipart-uploads两个命令分别可以查看已经完成的分片上传及正在进行的分片上传:

$ aws s3api list-multipart-uploads --bucket bjslabs

list-multipart-uploads 命令会列出指定的bucket桶里面所有的正在进行上的分片信息,如上所示,对我们有帮助的是其中的UploadId的值,在执行list-parts命令时需要传入:

$ aws s3api list-parts --bucket bjslabs --key s3/26Gfile --upload-id OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA-- > parts.info 2>&1

打开parts.info文件可以看到所有的已经上传好的分片信息,包含每个分片的最后修改时间,大小,ETag以及PartNumber:

接下来,我们看看如果再次运行同样的cp命令,会帮我们进行断点续传吗?判断逻辑有两点(1)两次的UploadId是否一致(2)同一个PartNumber的数据块的最后修改时间是否一致。先记录好目前的这两个值:

UploadId:

OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA—

选取PartNumber=1的数据块,该数据块最后修改时间是:

"2017-10-18T14:43:54.000Z"

重新执行一边cp命令并记录结果:

$ aws --debug s3 cp 26Gfile s3://bjslabs/s3/ > upload2.log 2>&1
$ Ctrl-Z(强行中止)
$ aws s3api list-multipart-uploads --bucket bjslabs > processing.info 2>&1

从结果我们发现,有两个正在上传的数据分片,一个是我们前一次命令产生的,一个是最近一次cp命令被中断产生的。

$ aws s3api list-parts --bucket bjslabs --key s3/26Gfile --upload-id OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA-- > parts2.info 2>&1
$ aws s3api list-parts --bucket bjslabs --key s3/26Gfile --upload-id 7P10pMiJ.Tj.xsogV7JeG99G4Ev6kV_5SqsdcEBKXzVi9Kg1SgvcWkTmay0wpB2WYsdnXtsFyofRIjOMfu9hZnh6DXmggVzSpyiKbAgw0qSyZDHVt5OdkcqpfX52uHpM5tc9BQUkIVD3dWu29xUeyg-- > parts3.info 2>&1

我们会发现执行两次cp命令对同一个文件,会帮我们保留两个UploadId及其对应的已经上传的分段数据,根据complete-multipart-upload的文档说明,我们知道,分段上传在合并分段数据的时候,是根据UploadId进行合并的,两个不同的UploadId说明AWS CLI cp命令不会智能帮我们判断已经上传的分段之后开始续传我们的文件分片即没有直接支持断点续传。

一个文件如果经过分段上传了一部分数据但没有传完的情况下,已经传完的数据块和正在进行上传的数据块占用的存储是需要收费的,因此,我们需要清除掉这些无用的数据块,一种办法是通过命令,另外一种方式可以利用AMAZON S3的生命周期管理定期自动删除掉这样的数据块。

$ aws s3api abort-multipart-upload --bucket bjslabs --key s3/26Gfile --upload-id OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA--
$ aws s3api abort-multipart-upload --bucket bjslabs --key s3/26Gfile --upload-id 7P10pMiJ.Tj.xsogV7JeG99G4Ev6kV_5SqsdcEBKXzVi9Kg1SgvcWkTmay0wpB2WYsdnXtsFyofRIjOMfu9hZnh6DXmggVzSpyiKbAgw0qSyZDHVt5OdkcqpfX52uHpM5tc9BQUkIVD3dWu29xUeyg--

S3下载到本地单文件场景

该场景下,我们关注的点主要是,对于在S3桶里面的对象,cp命令都会自动帮我分段分片下载吗?

首先尝试通cp直接下载上一个章节通过cp命令上传到S3桶里面的对象:

$ aws --debug s3 cp s3://bjslabs/s3/ . > download.log 2>&1

从日志文件里面可以看出,cp命令确实是默认采用了分段下载,调用GetObject接口,在Header里面设置range值并通过多线程并发下载;似乎非常完美,但等等,我们还忘了一个场景,假如文件上传到S3桶的时候没有使用分段上传呢?我们试验一下:

  • 还是利用本地dd出来的48Mfile的文件
  • 修改AWS CLI S3的参数,将multipart_threshold改到50MB,这样对于小于50MB的文件上传就不会采用分段上传
  • cp上传该文件并确认该文件没有被分段上传
  • cp 下载,看看是否是分段下载

第一步,修改aws configure配置文件:

第二步,通过cp上传该文件,并通过head-object命令发现该文件没PartsCount 信息即没有被分片分段上传(因为前面我们设置了自动分片的最小文件大小是50MB,该文件48MB小于50MB)

$ aws s3 cp ./48Mfile s3://bjslabs/s3/48Mfile_nonparts --profile dev
upload: ./48Mfile to s3://bjslabs/s3/48Mfile_nonparts
$ aws s3api head-object --part-number 1 --bucket bjslabs --key s3/48Mfile_nonparts
{
"AcceptRanges": "bytes",
"ContentType": "binary/octet-stream",
"LastModified": "Wed, 18 Oct 2017 15:52:34 GMT",
"ContentLength": 50331648,
"ETag": "\"f6a7b2f72130b8e4033094cb3b4ab80c\"",
"Metadata": {}
}

第三步,通过cp下载该文件,并分析日志文件

$ aws --debug s3 cp s3://bjslabs/s3/48Mfile_nonparts . > download2.log 2&>1

$ aws s3api head-object --part-number 1 --bucket bjslabs --key s3/48Mfile_nonparts
{
"AcceptRanges": "bytes",
"ContentType": "binary/octet-stream",
"LastModified": "Wed, 18 Oct 2017 15:52:34 GMT",
"ContentLength": 50331648,
"ETag": "\"f6a7b2f72130b8e4033094cb3b4ab80c\"",
"Metadata": {}
}

透过日志,我们可以看到,虽然我们上传该文件是没有使用多文件上传,但利用cp命令在默认的S3参数的情况下也会自动分片分段下载我们的对象。

本地目录与S3批量上传下载场景

前面两个小节,我们通过实验深度探索了,单文件通cp操作的一些细节;本小节我们一起来看看,在本地批量上传文件到S3及从S3批量下载文件的场景。对于性能这块我们放到后面章节,本小节主要探讨:

1.    max_concurrent_requests参数对于文件并发上传下载的影响

2.    cp命令中的一些高级特性

第一步,随机生成20个100MB的测试数据文件,并准备aws configure 配置文件,修改最大并发数的参数值,保持其它参数默认,并通过不同的profile指定不同的max_concurrent_requests的参数值:

$ seq 20 | xargs -i dd if=/dev/zero of={}.data bs=1M count=100
$ vi ~/.aws/config

第二步,跑测试命令,记录详细日志:

顺序分析dev1.log到dev30.log日志文件,可以观察到Thread数量变化,最大编号分别为Thread-7,Thread-9,Thread-14,Thread-18,Thread-26,Thread-36; 为了观察最大的线程数量,作者增加测试了max_concurrent_requests分别为100,1000的结果:

由上表可见,当我们逐渐增大max_concurrent_requests参数值的时候,实际的并发线程数是随着线性增长的,直到一个合理的线程数量,此案例里面256个8MB的数据分片,AWS CLI cp命令使用到309个线程就足够速度消费添加到队列里面的上传任务。

同理,我们从S3批量下载的情况,执行如下命令:

$ aws --debug s3 cp s3://bjslabs/s3/data1000/ ./data1000 --recursive --profile dev1000 > dev1000.log 2>&1
$ aws --debug s3 cp s3://bjslabs/s3/data100/ ./data100 --recursive --profile dev100 > dev100.log 2>&1

从日志文件中分析出,max_concurrent_requests为100或1000时,cp命令并发下载的线程数最大编号为107和275。


对于批量操作,不可避免有时会有选择的上传和下载某些特征的文件,cp 命令可以通过include和exclude参数进行文件模式匹配,看以下几个例子:

通过以下命令仅仅下载所有 ”.data” 结尾的文件:

$ aws s3 cp s3://bjslabs/s3/data1000/ ./data1000 --recursive --profile dev1000 --exclude “*” --include “*.data”

通过以下命令上传当前目录中,除子目录 “data100” 之外的所有文件到存储桶:

$ aws s3 cp ./ s3://bjslabs/s3/data1000/ --recursive --profile dev1000 --exclude “data100/*”

S3到S3的复制场景

首先,我们先来看一个同区域的文件复制案例,执行如下命令并记录详细日志:

$ aws --debug s3 cp --source-region cn-north-1 s3://bjslabs/s3/data100/1.data s3://bjslabs/s3_2/ --profile dev100 > sameregion100.log 2>&1

查看日志文件,可以了解两点(1)默认也是支持分段并发的(2)每个分段是调用的upload-part-copy 接口执行复制操作的:

而如果不是S3到S3的复制的话,比如前面两个场景,源是本地目标地址是S3的话则cp命令最终会调用upload-part 方法进行上传,这两个命令有什么区别吗?

参见upload-part-copyupload-part在线文档,仔细对比如下两个命令最终的REST请求,可以看到,UploadPartCopy请求只需要将源数据指向源的对象(x-amz-copy-source)以及相应的数据范围(x-amz-copy-source-range);但UploadPart请求中必须要讲该分段的数据包含进去;也就是可以推断,S3到S3的复制不需要经过我们执行该命令的机器进行数据中转;

样例请求(UploadPartCopy):

样例请求(UploadPart):

本章小结

本章节,我们深度解析了cp命令在不同场景下的数据传输行为,基本的一些结论见下表;其中,S3到S3的复制,从底层API可以分析出不需要经过运行命令的机器进行中转,这样节约进出执行cp命令的机器流量;同时我们s3api提供了很多底层S3底层接口,基于这些接口,可以方便地在分段上传的基础上实现断点续传。

AWS S3 CLI上传下载性能测试

本章继续和大家一起来探讨下影响AWS S3 CLI进行数据传输的性能的基本因素以及实际场景下基于AWS EC2的一些数据传输性能测试情况。

同区域不同S3桶数据的复制性能测试

测试环境:

  • BJS区域
  • R4.2xlarge 跑cp命令
  • AWS CLI S3参数max_concurrent_requests为1000
  • 测试方法,脚本跑10次取平均时间

测试结果如下,时间单位是秒:

总体平均时间:(29+29+28+6+29+5+6+6+6+29)/10=17.3秒,root.img的大小为8.0GB,AWS北京区域不同桶之间的数据平均传输速度为473.52MB/s,最高速度可以达到1.6GB/s,最低282.48MB/s。

为了验证该场景下对网络的影响,我们截取了这阶段的网络方面的监控,我们观察到这段时间,该测试机的网络输出和网络输入有几个波峰,但峰值最高没超过12MB,从侧面验证了我们的前面的判断,即cp在S3到S3复制的场景下,数据不会经过命令行运行的机器转发,而是直接由S3服务直接完成:

S3桶数据到AWS EC2下载性能测试

测试环境(针对下面表格的场景一):

  • BJS区域
  • R4.2xlarge 跑cp命令,
  • EC2挂500GB的gp2 ssd磁盘
  • AWS CLI S3参数max_concurrent_requests为1000
  • 测试方法,脚本跑10次取平均时间

测试结果如下,时间单位是秒:

总体平均时间:(67+64+66+65+65+65+66+65+64+65)/10=65.2秒,root.img的大小为8.0GB,该测试场景的数据平均传输速度为125.64MB/s,下载速率比较平稳。

在继续试验之前,我们总结下,影响EC2虚机下载S3数据的速度的几个因素:

  • 磁盘的吞吐率(SSD还是实例存储还是HDD)
  • EBS带宽,是否EBS优化(EBS本身也是通过网络访问,是否有EBS优化为EBS I/O提供额外的专用吞吐带宽,否则和EC2网络共享带宽性能)
  • S3服务的带宽(通常我们认为S3服务不是性能瓶颈)

我们已经测试了R4.2xlarge的下载性能,接下来我们选择几个典型的虚机类型分别进行测试,由于测试时间跨度比较大,测试场景中的EC2操作系统层没有任何调优,测试结果仅供参考。所有场景测试都针对一块盘,进行同一个8GB的文件下载,下载10次,根据时间算平均下载速率。

通过简单的测试我们发现,

1.    虽然随着机型增大比如从R4.xlarge 到R4.4xlarge,同样是单块SSD磁盘的情况,磁盘就成为整个下载速度的瓶颈,因为R4.4xlarge EBS优化的专用吞吐量理论值可以达到437MB/s,而简单测试下来的下载速度最高到130MB/s左右;

2.    SSD磁盘在整个测试场景中,是最优的选择,而且SSD盘的大小无需到3TB就可以有很好的性能表现

3.    实例存储在没有预热(dd整个盘)的情况下表现很一般

4.    st1盘6TB左右的测试盘,下载测试性能不如500GB的SSD盘

5.    3334GB的SSD盘的表现跟比预期要差很多

6.    测试场景中EC2下载S3的平均速度没有超过150MB/s

以上表格中的虽然我们测试了不同系列的不同规格的机型,但是我们可以通过修改实例类型非常方便地切换,因此监控上我们可以看出测试时间跨度中,我们的机器资源使用情况。

整个测试过程中R4系列机器的CPU的利用率总体还算正常,在15%到60%之间浮动:

整个测试过程中500GB的gp2磁盘的写入带宽变化如下图所示:

整个测试过程中3334GB的gp2磁盘的写入带宽变化如下图所示:

整个测试过程中6134GB的st1磁盘的写入带宽变化如下图所示:

AWS S3 CLI的一些限制

S3 CLI提供的分段上传算法有些限制在我们实际使用的时候,特别要关注比如分段总大小不能超过10000,每个分段的数据块最小为5MB,分段上传最大的对象为5TB等等。详细情况请参考AWS官方文档

下一篇将要探讨和解决的问题

在了解AWS S3 CLI命令底层原理和影响基本性能的基本因素之后,我们接下来会继续来探讨,如何利用S3的底层API实现S3中的数据的跨区域可靠、低成本、高效传输。

总结

本文和大家一起深度研究了AWS S3 cp命令在各种场景中的底层实现原理,同时利用实验,总结了关于AWS EC2下载S3数据的基本性能测试结果,期待更多读者可以实践出更多的性能优化方法。随着大数据分析的蓬勃发展,存放在S3上的数据越来越多,本系列主要会和大家一起深度探讨S3数据复制迁移的最佳实践。

作者介绍:

薛军

AWS 解决方案架构师,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证。负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在互联网金融、保险、企业混合IT、微服务等方面有着丰富的实践经验。在加入AWS之前已有接近10年的软件开发管理、企业IT咨询和实施工作经验。

将 AWS 认证工程师的数量从零增加到数百个的 12 步计划

“不要总希望得到您还未得到的;这会使您看不到目前拥有的可能性”

作为 AWS 企业战略家,我拥有与全球各地面对着各种业务和技术难题的高管们会面的特权。每个客户都是独一无二的。但是,许多难题,如同历史一样,往往具有规律性。

其中一个规律是,市场中的技能难题以及“不在相应岗位上配备合适的人员就会妨碍您提高行动速度、节省资金和在云上拓展业务”这一想法。可以肯定的是,随着人们认识到让 AWS 完成基础设施领域的无差别的繁重工作的好处,包含单词“AWS”和“云”的招聘广告显著增加了。但是,我认为这种不断增加的需求或者您没能获得所需人才的感觉并不会阻碍您的企业在云方面获得成功。

AWS 企业战略部主管 Stephen Orban 在一篇最新文章中就这一问题有力地指出,“您已经拥有成功实现云迁移所需的人才。”而且,为了加强这一说法的说服力,我想要分享我本人遇到一个主要技能难题时发生的故事。事情要追溯到 2014 年,我的云之旅才刚刚开始。

当时我在英国的 Capital One 担任首席技术官,然后,我发现自己在深入思考我在我的工程师身上发现的技能差距。这些工程师确实很有才华,但他们只是精通传统的内部技术;因此,他们掌握的大部分是孤立的基础设施技能。

为了寻求改变,我随后又犯了一个经常犯的错误:创建一个独角兽式的工作规范并自以为是地将它应用于外部就业市场。当我发现在收件箱中没有收到任何对这则招聘广告的回应时,我感到十分惊讶和失望。

很明显,我漏掉了一个重要的事实。

我拥有的技能高超、积极主动且全心投入的团队就是我需要的团队。只不过,团队成员们需要一个途径、一个动机以及一个善于倾听和帮助他们消除自身与生俱来的对未知技术恐惧的人。

有关人才转型的这种认识和企业云之旅为我积累了大量最佳实践,也让我更深刻地了解人类。但我必须说实话;在这个过程中,我们犯了很多错误并且浪费了很多时间。但是我们还是找到了一条途径,最终发挥了作用并且为 Capital One 在英国的成功做出贡献。这帮助 Capital One 将全球的技术人才提升到了极高的水平。实际上,所有 AWS 认证开发人员中现在足足有 2% 的人在 Capital One 工作

在说明优势之后,下面将介绍适合我们的 12 个步骤 —

步骤 1 — 接受

心理健康专家们表示,接受是走向恢复的第一步;这种说法在此处也完全适用。您的工程师们必须接受他们有能力学习 AWS 云技能并成为专家的事实。接受这一事实对于您组织内的技术主管来说也同样非常重要。正如 Stephen Orban 在文章中所述以及我在 Capital One 任职期间的经历所表明的那样,您拥有的人才就是您需要的人才。这些是在开发和运行您的现有系统方面拥有多年的重要经验的人员。

步骤 2 — 培训

在接受之后,您应该迅速开始 AWS Technical Essentials 课程。此课堂教学课程能让人大开眼界并愉快地一窥无限可能的艺术。对此,AWS 自己的培训团队或我们的其中一位获批培训合作伙伴可以起到很大的推动作用。

步骤 3 — 动手实践时间

对于经验的获得,没有任何捷径可言。因此,现在需要进行动手实践。即使略显笨拙,工程师也需要花费这些时间并在一个安全的位置实施配置。此外,目前似乎有数百万个实现这种可能性的方法,并且这些方法都有点难以掌控。您的工程师可能会非常兴奋,也可能会有点垂头丧气。识别每个人经历的正常变化曲线 (有些人的很短,有些人的很长 — 因人而异) 非常重要。持续激励也很重要。

步骤 4 — 创建您的双比萨团队

您组建的第一个工程团队应彻底包含各项核心技能的组合 — 网络、数据库、Linux 服务器、应用程序、自动化、存储和安全性。该团队将取得一些进步。它可能着眼于 Terraform 之类的工具以及其他东西。它还将编写一些 CloudFormation 代码。该团队会犯错。这是非常自然的事情。

步骤 5 — 引进一些专家

对于经验的获得,没有任何捷径可言 (续)。现在,您应该引进一些真正的专家。事实上,增加一些乐意分享经验教训和最佳实践的专家级工程师是目前至关重要的事。在英国的 Capital One,我与 CloudReach 密切合作,引进大量具有专业认证且经过现场证实的 AWS 工程师来达到此目的。我将这些专业工程师分配到不同的团队来满足他们对专业知识的需求。这一举措产生了变革性的影响。员工们通过观察、提问和“照着做”来互相学习。更好的一点是,工程师们喜欢向工程师同事学习。此外,由于在小型团队中工作,他们有机会提出问题并尝试在课堂环境下不会尝试的事情。我们甚至将这一过程所需的时间缩短至一天。在这样短的时间内,一位新工程师加入了团队,与一位专家结成搭档,然后通过 CloudFormation 和已出现的关联的持续集成/持续开发 (CI/CD) 最佳实践展示了自己。

步骤 6 — 实现目标

在这个阶段,敏捷双比萨团队的目标应是构建真实的环境并投入生产。这可能是用于托管小型应用程序和相关网络设置的基本 Amazon 系统映像 (AMI)。目的是找出对于着手工作来说很重要但并非关键的东西。设定在数周内而不是数月内完成这一目标。跟踪进度。展示好处。设置演示截止时间。随时查看进度以及最终结果。一句忠告 — 切忌让团队好高骛远。仅使用所需的 AWS 构建块。(您无需从一开始就掌握所有 90 多个构建块。)以后将有大量时间来扩展到其他构建块,因为您的解决方案会需要它们。实验的好处很关键,在学习过程中可以根据需要不断地丢弃然后重新开始,就像 AWS 在教您“走路”一样自然。

步骤 7 — 利用“细胞核分裂”推广学习成果

由于第一个团队达到了一定的 AWS 熟练度并且交付了一款产品,您现在需要观察这第一个团队的细胞核分裂。此外,您还需要逐渐但有意识地将已获得经验和最佳实践的这第一个团队分为两个全新的 4 人团队,然后为每个团队再引进 4 位工程师。这项工作将会很困难,应该小心处理。坦诚对待团队成员并肯定他们的共同成果将至关重要。此外,还要请求成员帮助您将经验教训和最佳实践传递给新的队友。采用这种细胞核分裂式方法继续拆分和重组团队,直到所有工程师融合成一个技术水平相当的团队。

步骤 8 —认证

通过与 AWS 技术培训或我们的其中一位出色的合作伙伴合作,您现在可以开启认证之路。鼓励使用 A Cloud Guru 之类的服务还可以为工程师提供让他们根据自己的时间和节奏通过认证的流程。我提倡从助理级认证开始,然后逐渐提升到专家级认证。我在这里要暂停一下来重点说明这一点。对于这个经常被忽视的步骤,无论我怎么强调其重要性都不过分。在 Capital One,我们在工程师认证、应用程序的迁移以及 AWS 上的新系统构建之间发现了一种直接关联。Capital One 甚至为一个用于度量转型的过程申请了专利。工程师的认证过程展示出显而易见的专业上的进步,它还使通用 AWS 语言能够传播并形成支持解决方案开发的事实方法。

步骤 9 — 推广认证和相关领导力

Capital One 本身的经验、与我们许多客户的合作经验以及科学研究表明,在网络效应产生作用之前,您的拥护平台的工程师需要达到 10% 的临界数量。因此,将这种学习和认证推广到您的 10% 的工程师是您的云之旅中的重大里程碑。从这个阶段开始,您将获得强有力的晕轮效应,这种效应将开始影响外部人员看待您公司的方式,而不只是影响内部人员。您组织外的那些仅希望与原生云公司合作的工程师将开始认真考虑为您工作。因此,随着您吸引更多人才或将原有人才转变为具有云素养的人,您转型的速度将呈指数级提高。

步骤 10 — 认可并奖励专业知识 (以非常公开且自豪的方式!)

作为 IT 主管,您的目标是公开宣布通过每个认证考试的每个工程师的姓名。以您能力范围内的任何方式奖励并认可技术进步。这包括宴请、优惠券、饮品、特别团队岗位、新奇的奖励,总之就是您能够想到的各种奖励。在 Capital One,我们拥有一份包含所有员工姓名以及他们获得的所有 AWS 认证的全球花名册。认证被视为一种有形的发自内心取得的成就。我遇见的几乎每一位工程师都渴望得到同行的尊重,而认证以及您获得的成就将为社区荣誉做出贡献。

步骤 11 — 挑战自我

当我在市政厅会议上表彰和奖励取得进步的工程师时,听众席中的一位言辞尖锐的人大声地说:“既然您如此热情洋溢地相信认证,那么您将在什么时候参加考试?”这很直接地打断了我的话。我有很长一段时间没有参加过行业考试了。但是,正如喜欢实践我宣扬的理论的人一样,我走进了考场。然后,我通过了 AWS 助理架构师认证考试。现在,我也能骄傲地站在这个舞台上!参加考试对我而言是一种极好的强迫机制,进而确保我获得了对关键 AWS 构建块的广泛但足够详细的了解。

步骤 12 — 创建统一的同类职业组合

最后,在适当的时候,您需要为您的技术员工提供具体的同类职业跟踪。以下是英国的 Capital One 在 IT 中创建的一些同类职业跟踪 —

技术项目经理 (TPM) — 通常负责敏捷执行、版本系列一致性和团队相互依赖性。

AWS 基础设施工程师 (IE) — 之前的数据中心系统工程师,过去通常负责 Linux/Wintel/Network 等。现在负责根据产品团队的需要创建用于不同的 AWS 构建块的 CloudFormation 代码。AWS 专家。

软件开发工程师 (SDE) — 编写逻辑并处理采用各种软件语言的数据结构。

软件质量工程师 (SQE) — 使用测试驱动型设计原则。确保在整个生命周期中都考虑并执行测试。

安全工程师 — 确保安全问题的全面性。

工程经理 — 该经理负责设计意图以及管理由上述技能团体的工程师组成的团队。

在您采用此途径时,应注意一些无形的晋升障碍可能会被打破。具体来说,不负责管理人员的工程师现在能够晋升到非常高的职位 (包括主管或主管以上职位) ,并且仍然不需要管理人员。这些晋升应考虑技术深度和相关能力发展以及逐渐提高的技术领导力成熟度。作为领导者,看到员工攀升到新的高度并获得来之不易的晋升始终是在该职位上令人欣慰的事情。我的团队中抓住绝佳机会的很多成员都自豪地获得了晋升。我们还自行打破了这种无形的障碍,而当我从英国 Capital One 离职时,我最自豪的时刻之一就是将我们的云卓越中心中的一位创始成员提升到了基础设施工程部门主管级别。这个人一直是一个独立贡献者和动手实践 AWS 专家,同时也是大家的好朋友。

将上述 12 个步骤作为人才转型的途径可以发挥您的团队成员的潜力,让他们为您的客户带来巨大的成果。

记住 — “您的所有假定的限制条件都是可辩驳的。”

Jonathan Allen
@jonathanallen02
jnatall@amazon.co.uk
EMEA 企业战略家和推广者