亚马逊AWS官方博客

AWS Team

Author: AWS Team

基于Amazon EC2 Container Service的持续集成/持续交付解决方案

基本概念 持续集成/持续交付 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称CI)和持续交付(Continuous delivery,简称CD)。 通过CI/CD构建自动化的代码交付管道,可以实现: (1) 快速交付。通过CI/CD自动化软件发布的过程,可以更快速地发布新的功能,快速迭代反馈并让新功能更快提供给客户。 (2) 提高质量。自动化构建、测试和发布过程致使可以轻松测试每次代码更改并捕捉易于修复的小型漏洞,通过标准化发布过程运行每一项更改,从而保证应用程序或基础设施代码的质量。 (3) 可配置工作流。通过图形用户界面模拟软件发布过程的各个阶段。 容器 本文涉及到的另外一个概念是容器,相信大家都已经不再陌生,并且很多朋友已经在自己的环境中有实际的运行、部署基于容器的应用,这边简单的回顾下容器的几个重要优势: 一是因为容器可以跨平台,从而让程序猿可以享受到研发生产环境一致性的便利,也就是DevOps。在没有容器之前,常常一个应用做好了在笔记本上可以运转起来,在数据中心就运转不起来,因为操作系统版本不同、库版本不对;或者有的时候生产环境里出现了问题,在笔记本的开发环境中复制不出来。有了容器之后,这些问题就大大减少了。 其二,容器在虚拟机里面可以大幅度提升资源利用率。因为一旦把应用容器化,虚拟机资源就可以通过部署多个容器而得到充分利用,而不是每一个应用去申请一个虚拟机,造成资源的浪费。 Amazon ECS/ECR Amazon EC2 Container Service (ECS)是一个托管的容器集群管理和调度服务, 可使您在 Amazon EC2 实例集群中轻松运行和管理支持 Docker 的应用程序。 使用 Amazon ECS 后,您不再需要安装、操作、扩展您自己的集群管理基础设施,可以根据资源需求和可用性要求在集群中安排支持 Docker 的应用程序。借助 Amazon ECS,您可以从一个容器扩展到覆盖数百个实例的数千个容器,而运行应用程序的方式并不会因此而变得复杂。您可以运行包括应用程序、批量作业和微服务在内的任何东西。Amazon ECS 将基础设施的一切复杂因素全部消除,让您能够集中精力设计、开发、运行容器化应用程序。 Amazon EC2 Container Registry (ECR) 是完全托管的 Docker 镜像仓库,可以让开发人员轻松存储、管理和部署 Docker 容器映像。Amazon ECR 集成在 Amazon EC2 Container Service (ECS) 中,从而简化产品工作流的开发。 本文主要介绍如何在AWS云上,使用Jenkins快速构建针对容器应用的持续集成/持续交付管道。 下图是整个CI/CD的流程图: […]

Read More

如何使用AWS CodePipeline,AWS CodeBuild与AWS CloudFormation实现Amazon ECS上的持续集成持续部署解决方案

作者:郭威 1. 前述 通过本文章,您将了解如何通过AWS CodePipeline,AWS CodeBuild,AWS CloudFormation 来实现基于Amazon ECS的持续集成持续部署方案。 开发人员在GitHub中提交的新版本代码,会自动触发代码获取,打包镜像,上传镜像仓库,更新新版本容器服务,注册到负载均衡器等操作。 方案中会涉及使用如下组件: GitHub:示例使用的源,一个提交到GitHub上的PHP示例网站。AWS CodePipeline支持GitHub, AWS CodeCommit服务,或者S3作为源。此次实例使用的Demo软件工程可以从以下链接Fork: https://github.com/awslabs/ecs-demo-php-simple-app Docker:作为发布服务使用的容器。演示方案的Build阶段会使用AWS CodeBuild托管的ubuntu/docker 1.12.1基础镜像。 Amazon EC2:作为ECS的容器宿主机集群。 Amazon VPC:服务所在的网络。 Amazon ECS:AWS托管的容器编排服务。文档链接 http://docs.aws.amazon.com/zh_cn/AmazonECS/latest/developerguide/Welcome.html Amazon ECR:AWS 托管的容器镜像仓库。文档链接 http://docs.aws.amazon.com/zh_cn/AmazonECR/latest/userguide/what-is-ecr.html AWS CodePipeline:AWS 托管的持续集成持续交付服务,可以快速可靠的更新应用程序和服务,集成支持GitHub,Jenkins等主流开源工具。文档链接 http://docs.aws.amazon.com/zh_cn/codepipeline/latest/userguide/welcome.html AWS CodeBuild:AWS 托管的构建服务,用于打包代码生成可部署的软件包。文档链接 http://docs.aws.amazon.com/zh_cn/codebuild/latest/userguide/welcome.html AWS CloudFormation:批量创建和管理AWS资源的自动化脚本。文档链接 http://docs.aws.amazon.com/zh_cn/AWSCloudFormation/latest/UserGuide/Welcome.html 2.方案架构 流程如下: 开发者将一个新版本的代码工程提交到GitHub Pipeline的Source阶段,检测到指定GitHub的repo有新版本的更新,从GitHub上拉取代码工程,开启已设定好的CICD Pipeline Pipeline的Build阶段,AWS CodeBuild将新版本的代码工程打包为Docker镜像 AWS CodeBuild将打包好的镜像推送到Amazon ECR Pipeline的Deploy阶段,AWS CodePipeline触发AWS CloudFormation,其定义了Amazon ECS的Task […]

Read More

帮助企业成功迁移到云的 7 条最佳实践

“生命是一场旅程。如果停下脚步,就无法看到新的风景。”-Pope Francis 去年十二月,我在一篇文章中提到云将成为新常态,并将成熟企业采用云的过程比作一场旅程。这场旅程是一个需要时间的迭代过程。在那篇文章中,我列出了企业云之旅中常见的几个阶段。在去年的十一月份,我还写了一篇详细介绍成功的云企业会做的十件大事的文章。 在那以后,我跨越重洋跟很多公司的领导人会了面,这些公司都使用了云作为满足其业务目标的平台。虽然我以前文章中的观点仍然适用,但我对云之旅的想法有了一些改变。 © Anne Worner https://www.flickr.com/photos/wefi_official/14053017844/ 这篇文章旨在介绍我的新思维,并阐述了我访问在迁移过程中取得累累硕果的企业后总结出的七条最佳实践。在接下来的几个月中,我会深入介绍每条最佳实践,并谈谈我所看到的适合 (及不适合) 每条实践的做法。我很乐意听到您的反馈意见,在撰写此系列文章的过程中,欢迎大家跟我分享自己的经验或想法。 在介绍最佳实践之前,我要再重申一下:云之旅是一个需要时间的迭代过程。因为云颠覆了 IT 的交付和使用方式,这是您反思和重新审视组织 IT 运营方式的大好时机。换句话说,云之旅是一次实施变革管理的练习。它将触及您的技术、管理、工作职能、组织结构图和公司的许多其他方面。好消息是,已有成千上万家公司踏上了云之旅,我们可以相互学习。 以下是我观察到的七条最佳实践,它们都是云迁移企业取得成功的一环: 1. 提供执行支持 自上而下的支持对于创造重大变革至关重要 — 无论这种变化是技术上的还是文化上的。首席信息官/首席技术官的职责总是在不断地发展,在当今的环境下,技术主管需要成为公司的首席变革管理官 (CCMO™)。这项工作包括获得执行团队的支持,并为您自己的团队提供支持和后勤保障。这意味着提供明确的目的,将业务和技术目标映射到期望的结果,并制定 (或打破) 新的规则。我将在下一篇文章中更详细地讨论这个问题,并且打算在 re:Invent 举行几次有关该主题的会议。(希望在会上与您相遇!) 2. 教育员工 人们往往会对未知事物心生畏惧。当人们感到害怕时,就会更坚持自己已习惯的做法。在某些情况下,这会给您的云之旅造成障碍。让您的员工掌握新技能是减轻恐惧心理的好办法。聘用具有适当技能的新人也很有效,但这种方法的实施难度很高。给已掌握系统知识的员工机会去学习和参与可加快您的迁移步伐。 3. 培育试验文化 与本地环境相比,云中的试验成本更低。在云中进行试验几乎没有或只需很少的前期投入,万一试验失败,对您也没有什么影响。当您将每个项目当作一场能够从中汲取经验教训的试验看待时,您就有可能会创造出一个“教育飞轮”,帮助组织慢慢对其加以改进。有些企业会从某个 IT 部门的单一项目入手,有些则立即着手进行多个项目。不管采用何种策略,重要的是,一定要记得总结成功经验,汲取失败教训。配合适当的执行支持,您将有机会培育出一种持续的试验文化。 4. 寻找合作伙伴 大多数企业在交付 IT 时都会或多或少地与他人进行合作。这种合作伙伴关系有许多形式和规模:员工增加、解决方案交付、托管服务、许可软件、SaaS 解决方案等。每一家大型 IT 服务提供商都必须确定如何为其业务采用云,许多 IT 服务提供商都是通过 AWS 合作伙伴网络寻找合作伙伴的。在迁移到云时,您可以寻求现有合作伙伴的帮助,也可以请求近几年从云中诞生并成长壮大的公司提供一臂之力。AWS 很乐意帮您确定最适合您需求的合作伙伴。除此之外,许多合作伙伴会将其解决方案放到 AWS Marketplace 上出售,您可以在此购买和部署他们的服务 (跟采购 AWS 的方法相同),这可极大地减少官僚采购流程。 5. 创建云卓越中心 在我的职业生涯中,我经常看到应用程序交付团队与基础设施团队之间关系紧张。这种制衡体系有时是有益的,但我也见过它产生负面影响的情况。传统基础设施背负的重担正在向云计算转移,再加上代码和自动化的强大驱动力,这两个团队已经变得难分彼此。云之旅为组织创造了重新思考这些边界及其之间协议的机会。据我所知,迅速取得云迁移方案成功的大多数组织都建立了云卓越中心,由其负责整个组织的最佳实践、管理和自动化工作。例如,我在担任道琼斯公司的首席信息官时,就通过我们的 DevOps 团队做了相同的工作。该团队负责实现卓越的客户服务、树立运行您构建的内容的心态并设定实施几个月后要达到的目标等工作。 6. 实施混合架构 几乎所有企业的现有 IT 投资都仍在给组织带来源源不断的回报。每个组织都以不同的方式管理其现有资产和刷新周期,但没有任何组织能在一夜之间完成所有这些工作。构建混合架构可让您充分利用云计算的优势,同时仍能继续享受现有投资带来的回报。在提供混合产品方面,没有任何一家提供商能达到 AWS 的完善体验和广度。只要您避开混合架构的三大误区,您的卓越中心就能随时帮您的组织切换到混合架构。一旦混合架构部署到位,增强和迁移现有应用程序就会容易很多了。混合架构为分解一体式应用程序并实现解耦的服务提供了一个绝佳的机会,这是大多数公司应对大型机所常采用的办法。 […]

Read More

业务现代化的必备秘密武器:团队云培训

现代培训师的任务不是砍倒丛林,而是浇灌沙漠。 — C.S. Lewis 我很荣幸能够知晓数百位来自全球最大公司的高管们是如何使用现代技术和云实现企业转型的。转型并非易事 — 企业内部少数值得做的事 — 并且,在我看来,变化最大的阻力通常来自企业内部。人们 (天然) 对未知事物心存畏惧。任 Dow Jones 的 CIO 和 AWS 的 Enterprise Strategy 负责人时,我都发现,帮助团队成员克服对未知事物的恐惧最好办法    是对他们进行培训。 这也是我认为 Maureen Lonergan — 我个人的朋友,同时也是 AWS 的培训和认证负责人 — 肩负着世界上最重要的工作之一的原因。Maureen 和她的团队致力于对尽量多的人进行全面的云培训和教育。 今天,我十分高兴主持介绍 Maureen 的一篇文章,概述如何进行团队培训。 很多大型和小型企业正在考虑过渡到云技术,但是不知道自己的团队如何才能以最好的方式在业务中应用这项技术。作为 AWS 培训和认证部门的主管,我认为要最大程度利用云投资,最好的办法是投资于培训,帮助组织内的员工掌握云技能。这样可以利用现有员工的技能,更快实现业务目标,并对组织能够最大程度利用云技术充满信心。 这篇文章将探讨为什么培训是重要、有价值的云之旅步伐,以及具体来说,AWS 可以如何帮助您过渡到云并让您的员工变成真正的专家。 您已经有了所需的人 去年,Stephen Orban 撰写文章讨论过现有员工云技能培训的重要性。他说,“推动云迁移所需的所有人才都已经到位,您只需要激发他们即可。” 培训可以帮助您的员工利用他们已有的基本 IT 技能和系统知识转变为云角色。因为不必雇用新员工来担任云角色,所以培训现有的员工可以节省时间和资金。 从根本上说,无论采用什么云平台,越快评估现有角色和所需要的人才,然后投资于培训来培养员工,您的工作就越轻松。 培训可帮助您更快实现业务目标 员工经过培训,可以更好地使用云,从而让您更高效地完成业务目标。云培训可以让员工获得更快速地进行创新所需要的技能。 对于正在进行复杂迁移的组织来说,培训尤其重要。下面是培训可帮助加速角色转换的几个主要方面: 培训将帮助员工了解如何使用云。例如,他们可以学习使用 AWS 有效管理、操作和部署应用程序。 通过对团队进行知识培训,从而缓解团队焦虑感,这种方式可以增进内部认同。 培训让员工有共识,他们可以更高效地合作。 无论是在 AWS 还是其他平台方面进行了培训的员工,都能够更快地找到所需要的服务和解决方案,这意味着可以快速为客户开发更好的解决方案。 通过认证来验证掌握了知识 鼓励员工通过认证,让团队中的每个人都为所拥有的技能感到自信。AWS 认证核心团队有助于领导组织完成转变和实施最佳实践。认证可帮助您确定组织中哪些人可以获得晋升。 如果组织需要更多有云技术经验的人才,可以考察通过认证的人,这样您能够充满信心地任用这些人才。 AWS 培训和认证导览 AWS 培训和认证可帮助培养云技能,让您更轻松地过渡到 […]

Read More

Amazon S3 深度实践系列之二:如何实现 S3 数据跨区域高效可靠传输

背景 在Amazon S3 深度实践系列之一:S3 CLI深度解析及性能测试一文中,我们深度剖析了AWS CLI S3相关命令的实际工作原理及单机下载S3数据的基本性能测试情况。在实际工作场景中,很多客户会在AWS多个区域的S3桶里面存储大量数据,而且会遇到将数据批量从一个区域一次转移到另外一个区域的情形;因此,在本篇中,作者和大家一起来探讨下出现这样的需求我们如何进行架构设计及高效实现。 架构设计 存储在S3中的对象随着时间的推移,对象数量逐渐增加,而且总体的数据量也不断膨胀,如果碰到需要将数据从某一个区域的S3存储桶完全复制到另外一个S3存储桶里面,我们会遇到哪些挑战呢? 网络传输带宽的限制 存储桶里面所有对象的分析和列表 源存储桶和目标存储桶权限的设定 传输失败识别和重试的挑战 如何利用并发来加速传输及降低成本 如何判断目标存储桶中的对象和源存储桶中的对象差异及完整性 在通用架构设计环节,我们将复杂的问题分解成一系列的子问题进行分析,并讨论在不同场景下的具体实现时要考虑的因素。如下图所示,我们将该任务分解成独立的五个环节,从图上我们也可以看出来,如何实现大规模数据或任务的并发执行是每个环节能否高效完成的一个很关键的技术要求;而且,只有在步骤三执行数据传输任务时,才会涉及到具体场景中的技术限制,因此我们在执行数据传输任务章节来讨论,同区域不同存储桶之间,AWS海外不同区域存储桶之间,以及AWS海外和国内不同存储桶之间的具体技术考量点。 S3对象“清单” 了解源和目标存储桶里的S3 对象是非常重要的准备工作,该章节我们讨论,如何获得S3存储桶的所有对象列表,包含对象的基本的信息,比如最新版本的对象大小,ETag等等。 Amazon S3本身提供了存储桶管理功能之清单生成功能,该功能是一个异步的AWS后台定期执行,可以实现每天生成一个存储桶清单保存成Excel格式。 同时我们也看到很多用户提问,如何实现一个自定义的清单功能,满足大家对于对象变化比较频繁的存储桶对象的实时统计场景以及更多高级自定义的业务逻辑。 接下来我们来看看这两种方法的具体实现逻辑。 利用S3 CLI实现高效的清单功能 作者利用AWS S3 CLI实现高效的清单功能基于以下两个事实前提: s3api 的 list-objects-v2虽然文档中说明最多返回1000个对象,但实测可以获得所有对象列表 同样利用s3api 的 list-objects-v2的delimiter和prefix参数,我们可以实现类似文件夹目录逐级扫描功能 基于以上两个事实,我们实现桶清单的主要逻辑如下图所示: 输入参数主要是:bucket,region和IAM 配置的profile名字,profile默认为default;另外depth控制扫描的“目录”层级 当depth为零时,我们直接尝试利用list-objects-v2一次性获取存储桶中所有对象列表并生成一个json格式的文件(但当桶里面对象太多时,该操作会超时) 当depth为零即单线程无法直接生成存储桶清单时,我们就尝试如下迭代逻辑: 生成存储桶当前“目录”里面的所有对象和该目录中所有“子目录”列表 遍历上一步的“子目录”列表,迭代生成该目录下的对象列表和“子目录”列表 如果遍历的深度等于输入参数depth=n,或者“子目录”列表为空,那么停止遍历子目录,直接生成该层级“目录”里面所有的对象列表 以下是几个关键点实现的代码说明,首先,生成某个“目录”前缀下所有对象列表的AWS S3 CLI命令参考,如下命令将在操作系统后台执行并生成存储桶jason中“目录”前缀“qwikLabs/”下的所有对象列表(包括所有嵌套“子目录”中的所有对象): $ nohup aws s3api list-objects-v2 –bucket “jason” –prefix “qwikLabs/” –profile […]

Read More

如何使用Amazon EC2 Systems Manager自动创建数据一致的EBS快照(Part 2)

作者:王宇 上一期我们讨论了如何在不关机的前提下实现AWS上实例的数据一致性快照问题,传送门:《如何使用Amazon EC2 Systems Manager自动创建数据一致的EBS快照(Part 1)》 在本文的介绍中,我们将共同探索如何利用Amazon EC2 Systems Manager(SSM)和Microsoft VSS (Volume Shadow Copy Service)来创建数据一致的EBS快照。 SSM + VSS数据一致快照的原理 VSS (Volume Shadow Copy Service)是一个Windows操作系统内置的服务,用来协调与VSS兼容的应用程序(如SQL Server、Exchange Server等)的备份工作,如冻结或释放这些应用程序的I/O操作等。 VSS服务能够启动和监督副本拷贝的创建。“副本拷贝”是指一个逻辑卷在某一个时间点上的数据一致快照。比如:“C:”是一个逻辑卷,它与EBS快照不同。创建副本拷贝的步骤包括: 请求方向VSS发出创建副本拷贝的请求。 VSS provider创建并维护副本拷贝。 VSS写入器(writer)保证数据的一致性。写入器负责在VSS provider创建副本拷贝之前固化临时数据并冻结I/O操作,并在VSS provider完成创建后释放I/O操作。通常情况下,会为每一个与VSS兼容的应用程序分配一个独立的写入器(writer)。 我们可以使用Run Command在windows实例中运行一个PowerShell脚本: $EbsSnapshotPsFileName = “C:/tmp/ebsSnapshot.ps1” $EbsSnapshotPs = New-Item -Type File $EbsSnapshotPsFileName -Force Add-Content $EbsSnapshotPs ‘$InstanceID = Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/instance-id’ Add-Content $EbsSnapshotPs ‘$AZ = […]

Read More

混合云架构顿悟时刻

每周,我都会与好几个高管会面,他们正在使用云改变技术为其业务带来价值的方式。开始使用云的动机各不相同,但在我的谈话中,一个始终如一的主题是云可让组织将更多的资源投放在其核心业务上、更快地移动且更安全。 这种转变不会在一夜之间发生,我经常将这个过程称为旅程。在此期间,您的企业仍然需要运营现有 IT 资产以保持业务正常运行。虽然我提及的大多数企业都正在将其 IT 项目组合中的部分或全部项目迁移到云,但他们也意识到,云并不是一个“全有或全无”的价值主张。当每个企业都意识到这一点时,他们就能够将其本地 IT 资产与云联系起来,并利用这种联系逐渐将其 IT 项目组合的重心迁移到云。 去年,我写了有关云中的混合架构的三个神话的文章,时至今日,我在与高管讨论混合云架构时仍会遇到这些问题。如果您仍在梳理有关您的组织的混合云架构的观点,我建议您考虑一下我在那篇文章中提到的要点。 这篇文章的其余内容详述了当我担任 Dow Jones 的首席信息官以及我们首次实现混合云架构时,我的团队和我的“顿悟”时刻。 混合顿悟时刻 2012 年,我的老板 (随后成为了 Dow Jones 的首席执行官) 提出了一个假设,我们都认为这是一个巨大的商机:如果华尔街日报 (Dow Jones 旗舰 B2C 产品之一) 的所有订户拥有全球大部分财富,Factiva 和 Dow Jones Newswires (Dow Jones 的 B2B 产品) 的所有订户管理全球大部分财富,那么我们可以为他们提供一种用于相互联系和通信的机制来创建一个有价值的平台。 我们从零开始,并且想快速行动。我们组建了一个非常小的工程师和设计师团队来构建这个概念,让他们能够自由地选择他们认为可以完成这项工作的工具。6 周后,通过几个开源的自动化 AWS 服务以及大量的艰苦工作,我们便启动并运行了一个高可用性且不受灾难影响的应用程序。我们新发现的将技术交付给业务的能力很快成为了我们的“英雄”项目,并帮助我们鼓励我的团队和管理层利益相关者与我们一起踏上旅程。 随着我们将此应用程序集成到我们的更多产品中,我们发现还需要将它与我们的一些仅限内部使用的身份管理系统集成。这些系统中的一些系统不会 (也不应) 公开到 Internet 上,因此无法通过我们的在公共 Internet 中的 AWS 上运行的应用程序进行访问。 我们的网络、基础设施和开发团队的工程师已开始寻找解决这个问题的方法。经过一番研究,我们发现我们可利用 Amazon VPC 在我们内部的 IP […]

Read More

向员工传授云知识时需要考虑的 11 个注意事项

告诉我,我会忘掉。教导我,我会记住。让我参与,我能掌握。- Benjamin Franklin 我在上一篇文章中提到,只要让员工接受适当的教育,您就拥有了充分发挥云技术优势所需的资源。 那么,您 (首席变更管理官) 该如何教育员工,以便他们能够加快您的云之旅?每个组织的云之旅都将是独一无二的,但根据我的观察,取得成功的组织还是有一些共通之处的。以下是有关这些共通之处的 11 个注意事项: 1. 从有意义但很基本的事情做起。 当您的团队完成对业务至关重要的事情后,他们会即刻明白云技术的实际优势。我见过有些公司将工作重点放在了无足轻重的小事上面,结果,他们取得的进展比预想的要慢。当然,您肯定不希望在头几个项目上冒太大的风险,但您需要从足够重要、能够展示业务收益的项目开始。这样的项目有很多 — 简单的网站、移动应用程序、简化数据访问的 API 或文件备份/灾难恢复改进项目。如果将团队教育扎根于实际应用之中,他们就能更快地将学到的知识应用于更多的项目。 2. 利用 AWS 培训。 我在以前的文章中提到过 AWS 提供的几个很好的培训项目。这些项目帮助了成百上千家公司掌握了云技能。AWS 将每次培训合作都当成是改进的机会,开发了多样化的课程和各种授课机制,允许组织定制满足其特定需求的培训。我在道琼斯工作时,我们团队里的几乎每一位技术人员都接受过培训,这些培训内容后来汇总成了 AWS 技术基础知识课程。除了帮助我们的员工获得新技能以外,这些培训还打消了他们刚刚踏上云之旅时出现的莫名恐惧感。 3. 给团队一些时间进行试验。 营造试验文化是云之旅的下一条最佳实践,在激励员工学习时,这一点非常有用。创新来自于试验。借助云技术,您不必进行大量前期投资就能尝试各种新想法,这可帮助您的团队创造出颠覆性的行业产品。给您的团队一些自由度,让他们以新的方式实现现有项目。 4. 设定鼓励学习和试验的目标。 大多数公司会为员工设定目标和/或关键绩效指标,并将这些目标与绩效挂钩。这些现有机制是强化您的策略并产生您所期望的行为的良好途径。您可以围绕各种主题设置目标,例如:相关培训课程的完成度、释放了多少预算、采用适当的云架构后运营卓越性有多大改善等。这样做可以传递“领导层真心希望为每个人创造试验和学习机会”的信号。 5. 设定时间限制和前进步伐。 当您转向试验文化时,这一点尤为重要。毕竟,结果才是最重要的。您可以通过设定每个项目的截止日期来帮助团队成员在试验和运用其已学到的知识之间取得平衡。有时,您的团队可能会因为这些约束而作出妥协。随着云之旅进程的深入,您需要制定一个应对此类妥协的机制。但是,您的团队将一刻不停地学习和提高技能,以便为下一个项目做好准备。 6. 发现并消除变革阻力。 所有这些注意事项都旨在为员工提供帮助他们获得成功所需的工具,以减少员工对变革的抵制。但即使做好所有这一切,您的组织中还是会有人继续抵制变革。在阐明目的一文中,我对这一挑战作了说明。您需要理解团队的忧虑,心平气和地看待做得好和做得不好的地方,并迅速消除不必要的摩擦。这引出了我要讲述的下一个要点。 7. 不要害怕赋予员工新的角色。 以有意义的方式迁移到云不仅仅是技术转型,同样也是一场文化变革。我发现,给予员工担任新角色的机会可以帮助他们克服对变革的抵制。我一直偏向于首先检视公司内部,因为系统知识非常宝贵,通常是不必要的损失。在 Bloomberg 的 11 年任期里,我担任过六种差异极大的角色。拥有如此多的机会是我一直呆在 Bloomberg 的主要原因之一。寻找为员工提供新机会的方法可加强他们的参与感,有助于留住员工。 8. 向员工指明其在组织整体蓝图中的作用。 当您知道自己在组织大局中的作用时,很容易对自己的工作感到兴奋。请务必考虑到每一个角色,并传达其在团队中的重要作用。我再强调一下,了解组织如何将其目标与部门和/或个人目标协调一致,并找到一种方法来针对每个角色进行调整。 9. 参加行业活动,了解他人在做些什么。 大多数人可从他人的成功和失败经历中学到很多东西。到目前为止,我从事为大型公司制定云支持技术战略的工作已经五年多了。但令我惊讶的是,每次出席 AWS re:Invent、AWS 峰会及其他技术活动,我还是能学到不少的知识。请给您的员工一些时间,让他们梳理知识、了解新思想。了解各种各样的想法 (即使是您确定不会赞同的想法) 是创造教育机会和加强您的策略的良好途径。 10. 向您的合作伙伴学习。 […]

Read More

产品更新 – Amazon EC2 P3 实例多达 8 个 NVIDIA Tesla V100 GPUs 提供支持

自从我们于 2006 年发布最初的 m1.small 实例以来,在客户需求的推动以及不断发展的先进技术的支持下,我们后续推出了各种强调计算能力、超频性能、内存大小、本地存储和加速计算的实例。 新的 P3 现在,我们正在打造下一代 GPU 加速的 EC2 实例,这些实例将会在 4 个 AWS 区域提供。P3 实例由多达 8 个 NVIDIA Tesla V100 GPU 提供支持,可用于处理计算密集型的机器学习、深度学习、计算流体动力学、计算金融学、地震分析、分子模拟和基因组学工作负载。 P3 实例使用运行速度可高达 2.7 GHz 的 Intel Xeon E5-2686v4 定制处理器。有三种大小的实例可供选择 (所有均仅限 VPC 和 EBS): 模型 NVIDIA Tesla V100 GPU GPU 内存 NVIDIA NVLink vCPU 主内存 网络带宽 EBS 带宽 p3.2xlarge 1 16 GiB […]

Read More

现已推出 – 兼容 PostgreSQL 的 Amazon Aurora

去年年底,我提到过我们向 Amazon Aurora 添加 PostgreSQL 兼容性的计划。公告发布后不久,我们推出了封闭测试版,并于今年年初发布了一个公开预览版。在测试版和预览版期间,我们收到了很多极好的反馈,我们将倾尽全力确保产品满足乃至超出大家的期望! 现已正式发布 非常高兴告诉大家:兼容 PostgreSQL 的 Amazon Aurora 现已正式发布,您现在就可以在四个 AWS 区域 (将在更多区域发布) 使用它。它兼容 PostgreSQL 9.6.3,可自动扩展为支持高达 64 TB 的存储 (后台采用 6 路复制技术以提升性能和可用性)。 与兼容 MySQL 的 Amazon Aurora 一样,这是一个完全托管版本,非常容易设置和使用。在性能方面,吞吐量最高可达您自己运行 PostgreSQL 时的 3 倍 (可以参阅 Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases 了解我们如何做到这一点)。 您可以从 RDS 控制台启动兼容 PostgreSQL 的 Amazon Aurora 实例:引擎选择 […]

Read More