Category: 方法论


利用云方案进行实验时的四要与四不要

“要证明一根棍子是歪的,最好的办法既非争论、亦非大加谴责——用一根直棍进行比较即可。”——D.L.穆迪教士

在之前的文章中,我探讨了规模不同、定位有异的各类企业该如何以便捷、低成本且低风险的方式进行云技术实验。对于这方面观念的认识程度越高,企业利用实验文化取得竞争优势的可能性也就越大。实验带来创新,而如今我们正迎来前所未有的创新黄金时代。

那么我们该如何起步?在今天的文章中,我们将共同了解在企业当中建立实验文化的四要与四不要。

1. 要进行期望管理

并不是每项实验都能带来理想的结果,但每一项实验却都将成为我们了解并改进业务运营的宝贵机遇。如果大家的企业还不熟悉“从失败中学习”这一概念,则可以从小处入手并确保充分了解打算进行实验的具体项目。管理利益相关者的预期,包括明确实验目标、设定实验结果、制定结果量化与测试手段以及从结果当中积累经验。我发现很多企业高管都会对预料之外的结果予以高度重视,因为正是这些从未出现过的情况才能帮助企业更好地学习与成长。

不要在实验项目当中引入太过明确的预期结果

如果大家打算在企业当中尝试推广实验文化,那么请不要在探索旅程初期就在项目中引入太过明确的相关者需求。举例来说,我认为大家不该把年终结算引入实验性项目。一位曾经共事过的CEO曾告诉我,实验二字本身代表着成功很好、失败亦可的态度。大家应该对增量式进展抱有积极的态度,同时在推进过程中缓慢增加实验数量——当然,千万别超出了企业自身的承受能力。

2. 要鼓励团队提出实验要求

每家企业在确定哪些项目有权获取技术资源时,都有着自己的一套评判标准。遗憾的是,部分企业目前会将技术或者IT部门作为成本中心来看待,这意味着设计思路与具体实现之间相隔甚远。事实上,值得肯定的想法可能来自任何角度,而且大部分技术专家都会对业务项目提出独特的意见与建议。这一点在那些刚刚接触云计算的企业中尤为突出——利用云计算能够证明实验思路,并利用独一无二的云资源优势造福于业务体系中的各个层面。因此,大家应当鼓励各个团队提出实验要求,并为其赋予影响高管团队以调整资源调度的权利。

不要为了实验而实验——量化能力是进行实验的前提

毫无疑问,每个人都希望将时间投入到正确的实验项目当中,同时确保能够从中吸取到有助于改进运营及产品的宝贵经验。在投入一项实验之前,大家应当首先考虑如何对实验中的哪些指标进行量化。如果大家打算测试网站上的一项新功能,那么哪些指标能够证明其取得成功?页面访问量?点击次数?放弃比例?这些细小但却极为重要的细节将迫使相关团队在着手实验之前,认真考量这样做的现实意义。另外,提前量化也能够保证实验项目中的各个组成部分获得正确的优先级排序。

3.要考虑利用DevOps实现实验制度化

DevOps文化将成为企业将实验纳入运营制度的一大重要助力。DevOps提出的“谁构建谁运行”理念再加上自动化强调思路,能够显著降低企业实现变更所需要投入的时间,从而帮助大家更快、更频繁地推出新变更并回滚失败的尝试。成熟的DevOps部门还会开发出A/B测试框架,保证自身立足于不同用户群体的不要体验需求做出并行实验,最终快速找到最理想的实现方式。

不要质疑自己的团队

怀疑情绪往往会严重打击团队积极性,并由此引发一系列严重的失败。在对实验、量化与快速迭代等新机制进行尝试时,大家应当以方案实施为优先考量——而非始终将失败可能性挂在嘴边。确保我们的团队乐于量化实验结果并提出尖锐的问题,同时帮助他们解决问题而非加以质疑甚至是指责。总而言之,人们乐于追随那些相信他们能够获得成功的领导者。

4.要鼓励企业整体参与进来

在着手利用实验项目加快成果交付工作时,大家应当将企业中的其它部门也引导进来。我们可以发起一项黑客马拉松活动,其中涵盖多个不同业务领域,而相关员工则负责定义实验结果的评判方式并提出目前最紧迫的实验性创新方向。尽管并不是每家企业都能为员工提供充裕的实验时间,但可以肯定的是,这种作法能够带来可观的竞争优势。至少此类包容性活动将提振员工的士气与忠诚度。虽然我加入Amazon公司的时间还不长,但到目前为止,我发现这里的每一位员工都能够通过思考与书面方式的表达得到实验机会。这是Amazon公司企业文化的一大独特组成部分,同时亦是一款能够吸引并留住创新者与探索者的伟大工具。

不要拖慢实验节奏或者加以中止

不要因为某个项目仅仅属于实验性质就中止团队的交付尝试。诚然,失败也是种重要的学习过程,而实验无法带来任何实际成果也不算什么大事。但是,大家仍然应当将构建而成的结果交付测试,并利用真实流量了解其在生产环境下的表现。实验项目并不意味着我们可以稍后再行评估,或者直接将其扔进垃圾堆。这也是业务的一部分,而业务是不能轻言中止的。

大家对于实验文化又有着怎样的看法?请不吝分享您的真知灼见!

革命尚未成功,同志仍须努力!

作者介绍

史蒂芬﹒奥本

史蒂芬·奥本 (Stephen Orban) 于 2014 年9月加入亚马逊AWS 担任企业战略总经理。奥本与多名企业技术高管合作,在云如何实现业务成果、加快创新和简化流程方面进行经验和战略分享。在加入亚马逊AWS 之前,奥本曾在道琼斯担任首席信息官 (CIO)一职,他通过借力 AWS 和其他软件即服务 (SaaS) 合作伙伴,引入现代软件开发方法、实现降低成本、执行云优先政策。这些转型变革加快了产品开发周期并提高了全部业务线的生产能力,这其中就包括《华尔街日 报》、MarketWatch.com、道琼斯通讯社及Factiva。奥本还曾在彭博有限合伙公司(Bloomberg LP)工作 11 年,并且在股权和消息平台担任不同的领导职务;2008 年,奥本创建彭博体育(Bloomberg Sports)并担任首席技术官 (CTO)。

为员工进行云培训时的11条箴言

Tell me and I forget. Teach me and I remember. Involve me and I learn.      – Benjamin Franklin

(告诉我,我会忘记;演示给我,我会记住;但让我参与其中,我才能真正学会。      – 本杰明﹒富兰克林)

作为一个CCMO,培训你的员工就能使他们加快你的上云历程吗?每个组织的培训历程都是独一无二的,但我发现在这方面做得很好的一些组织中,它们是有一些共性的。从这些共性中我们可总结出11条箴言:

1.从基础的但有意义的事情开始。当你的团队完成一些业务相关的重要事情时,他们将很快意识到云技术的实际好处。我见过很多公司的项目进展慢于预期,因为他们过于注重细枝末节。你肯定不想把全部身家赌在前几个项目上,你将会想从几个能很好阐明业务好处的项目开始做起。其实有很多适合刚开始着手进行的项目,例如一个简单的网站、一个移动应用、一个可以便捷访问数据的API或者一个文件备份及灾难恢复的改进。如果你的员工培训基于实际的应用,那你的团队将能够更快地把他们所学的东西应用于更多项目。

2.利用Amazon Web Services Training(AWS Training)。AWS可提供良好的培训计划。这些计划已经帮助了上千家公司增强它们的云技能。AWS将每一个培训视为一次提升的机会,并且开发了不同的课程和一系列交付机制以便客户能定制培训计划来满足他们的具体需求。当我在Dow Jones时,我们使用现在称为AWS Technical Fundamentals的课程来培训我们团队的几乎每一个技术人员。除了让我们的员工具备新的能力之外,这个培训也消除了员工对一些项目开始时的未知的恐惧。

3.给团队时间去尝试。构建一种探索文化是这段旅途中的下一个最佳实践,这在激励你的员工去学习时尤其重要。创新来源于尝试,因为云消除了尝试新事物时的前期投入,所以没有什么能够阻止你的团队创造你行业中的新产品。给你的团队足够的自由空间来以全新的方式实现已有的项目。

4.设置目标来鼓励学习和实践。大部分公司为员工设定目标或KPI并将此与员工绩效挂钩。使用这些现有机制来巩固你的策略,并形成以后的行为。你可以设定相关培训课程的完成目标,多少预算被释放,或者通过利用适当的云架构如何改善你的卓越运营。这样做表明,领导很注重让每个人都有机会尝试和学习。

5.设置时间限制,跟上步伐。当你向实验文化转变时这一点尤其重要。每天结束时,以结果为导向。你可以通过为每个项目设定最后期限帮助你的团队成员平衡试验和他们的现有知识。有时候你的团队会因为这些约束而做出一些折衷,随着项目的进行,你需要制定一个如何应对这些折衷的机制。但是你的团队会在将来的项目中不断学习并提高能力。

6.定位并处理变革阻力。所有这些因素都旨在通过给予你的员工成功所需的工具来抑制他们对变革的抵触。但是即使有这些机会,你的组织中也可能会有对此持续抵触的人。观察并理解来自你的团队的担忧,以开放的心态对待有效的和无效的,迅速处理不必要的摩擦。这也是我下一个要谈的。

7.别害怕给人新的角色。以有意义的方式迁移到云不仅是技术变革更是文化变革。我发现给人一个担当新角色的机会将帮助他们克服对变革的抵抗。我倾向于首先观察公司的内部,因为习以为常的知识是一种昂贵的且不必要的损失。在我在Bloomberg任职的11年间,我担任了6个不同且差异很大的角色。有数不清的机会是我在那里呆了那么久的原因之一。想方设法给员工新的机会将让他们保持参与并帮助留住员工。

8.向你的员工展示他们应该如何融入伟大的构想。当你知道你的工作是如何融入组织的大局时,会很容易激发你对工作的热情。确保你考虑到了每个角色并且沟通过他对你的团队有多大意义。再次强调,我期待看到你的组织如何权衡部门和/或个人目标与大局的关系,并设法为每个人量身定做。

9.深入行业活动,看看别人在做什么。大多数人从别人的成功和失败中学到很多。至今我已经为大公司开发基于云的策略有五年时间了,现在我也惊异于我参加AWS re:Invent、 AWS Summits或其他技术竞赛所学到的知识。给你员工时间来让他们组织并带着新的想法回去。设想许多的、甚至有一些你根本不会去实施的想法,这是创造有教育意义的时刻并强化你策略的好方法。

10.向你的搭档学习。AWS Partner Network中有数以万计的不同组织。他们中许多可能已经和你们是稳定的合作伙伴关系,但那可能也有值得你们学习的新的合作伙伴。我很惊异于看到很多大公司正转变成小的、年轻的、诞生于云的,像系统集成商Cloudreach2nd WatchMinjar,加速推进云策略并改变它们的IT文化。

11.在你的组织中制度化具有你特色的培训。当你推进云进程时,你会希望看到你的组织中的一些团队或个人想与他人分享他们所学到的。这将来自你卓越的云中心。我在Dow Jones时我们的DevOps团队定期举行DevOps日,在那里他们相互分享他们开发的云的实践、架构、管理模型等。跟我谈过的其他几家世界500强企业也已经建立了专门针对他们组织的类似的计划。

 

作者介绍

史蒂芬﹒奥本

史蒂芬·奥本 (Stephen Orban) 于 2014 年9月加入亚马逊AWS 担任企业战略总经理。奥本与多名企业技术高管合作,在云如何实现业务成果、加快创新和简化流程方面进行经验和战略分享。在加入亚马逊AWS 之前,奥本曾在道琼斯担任首席信息官 (CIO)一职,他通过借力 AWS 和其他软件即服务 (SaaS) 合作伙伴,引入现代软件开发方法、实现降低成本、执行云优先政策。这些转型变革加快了产品开发周期并提高了全部业务线的生产能力,这其中就包括《华尔街日报》、MarketWatch.com、道琼斯通讯社及Factiva。奥本还曾在彭博有限合伙公司(Bloomberg LP)工作 11 年,并且在股权和消息平台担任不同的领导职务;2008 年,奥本创建彭博体育(Bloomberg Sports)并担任首席技术官 (CTO)。

畅谈CIO该如何合并业务和技术

“以始为终。” — 史蒂芬·柯维(Stephen R. Covey)

与以往相比,现在成功的技术管理人员必须帮助其负责执行的同事了解技术如何融入——或者,更好地促进——他们的业务。向组织阐明这样的思考,其实就是向你的执行同事阐明你有关于组织的业务目标的指令,以及你是这个执行团队的关键成员。

目前的商业格局正在被一些公司打破。因为创建和运营这些公司的管理人员不仅懂得如何让技术融入业务,而且定义了技术在他们整个行业中扮演的角色:酒店行业的AirBnb,叫车服务行业的Uber,智能家居行业的Nest Labs,存储领域的Dropbox就是几个相关的例子。这对传统行业跟上步伐造成了压力,同时也给IT管理人员提供了无处不在的机会。没有人能比那些整个职业生涯都在从事技术工作的人更适合来阐述如何使用技术来满足日益增长的市场需求。这对我们这些已经在大公司度过了大部分职业生涯的人尤其如此。我们讲企业术语,了解哪些约束是硬性的,哪些是弹性的,以及对于每个C级同行你必须做什么。让它们的技术主管在幕后工作的企业已经不可能成功了。

而且,因为云带走了很多传统上与企业IT相关联的未分化繁重负担,所以现在的IT管理人员可以投入更多的时间和资源来从事那些驱动业务和保持组织竞争力的活动。云正是这些颠覆性力量的关键因素。使用相同的要素不一定会带给你拓展业务的想法,但它会为开放竞争环境提供了更多的可能性。

对于那些希望带领自己的组织使用云的人们,我提供以下一些观点:

与你的同事换位思考(Empathize with your peers)

云不仅仅是一个技术转变。它更是每一个管理层人员应该关注的业务转变。你的职责是来考虑云会如何影响你的执行团队的职责或者考虑它可能会带来什么影响。

我不可能在一篇文章里覆盖所有类型的管理者,但是:

首席财务官(CFO)通常被较低的前期成本以及只支付你所使用的东西所吸引。我见过很多因为逐月变化的成本导致的不和谐,但我总是发现特别是当你从容量规划和维护活动的负担中解脱出来时,总的成本会是很低的。随着时间的增长,在产品研发(资产创造)过程中,能够每个月与管理者紧密合作、了解更多成本预期的环境、管理资源的使用、交错购买RI、考虑如何核算劳动力成本等,正在成为关注的焦点。

首席营销官(CMO)通常希望保持公司的品牌新颖,并对不断变化的市场情况做出反应。把品牌网站从每月更新一次变成一天更新几次会带来什么影响?一个可无限扩展的数据仓库将如何帮助CMO更好地了解他们的客户?如果几乎没有什么代价,他们会在一小部分用户身上做什么尝试?

人力资源副总裁(VPs of HR)想看到的是你能照顾好你的员工以及你如何招聘新的人才。充分利用AWS培训与认证(AWS Training and Certification),并随时让我们的专业知识培训成为你的培训课程的一部分。我将在后续有关这个话题的文章中探讨如何教育你的员工。而且只要愿意去学习,你的团队的任何人都可以帮助你去完成这种培训。此外,还能了解参与此培训的其他公司是如何招聘新员工及如何管理老员工的过渡。比如,如何让DevOps融入你的组织,以及“运行你所构建的(run-what-you-build)”意味着什么?

CEO关注所有这些事情,以及如何让公司保持竞争力。用你从其他高管所学的东西来帮助塑造一个完整的视界,并用现代科技展示如何实现。如此一来,你将可以在同样的限制下做一些不可能完成的事情。

在Dow Jones,我设立了一个目标,每个月与几个管理者共餐。在这段时间里,我只听取他们的受挫经历。我用我所学的来调整我们的策略,并且确保我向他们反馈了他们的影响力是如何改变了我们的方向。这是一个简单的关于如何迎合他们需求、构建信任并获取支持的例子。这里的关键是不仅要聆听,还要根据你所学的来采取行动。

谋求帮助(Enlist help)          

你不必单独做这件事。你可以考虑在培训中把你的客户经理当成你的导师。他们乐意与你以及你的管理团队一起工作,帮助塑造周围的信息及迁移到云的好处,使之与你的业务接轨。如果影响已经超出了客户经理的专业知识范围,他们将寻找到合适的人选,不管是AWS的内部或外部人员。我们乐意为你创造与有同样想法的人沟通的机会。而且这不只是在我们的活动中,而是在培训的任何时刻。在最近一次活动中我和其他公司有过几个参考电话,从其他管理者学习既是一种教育也是一种验证。

AWS合作伙伴网络(AWS Partner Network)以及AWS培训和认证(AWS Training and Certification)也是重要的资源,它们能帮助你加快你的培训进程。我多次强调它们是最佳实践,但我发现很多企业与他们的HR部门合作把AWS培训作为我们整个培训的首要部分。在Dow Jones,DevOps团队与HR合作并定期举行DevOps日,来交付优化的工具和最佳实践。这是在分布全球的团队中分享技能的好方法。再次强调,你的客户经理可以帮助你很好地连接这些领域。

发展IT品牌(Evolve the IT brand)

我跟很多渴望提高自己部门品牌的IT主管交谈过。我在Bloomberg花了超过十年的职业生涯来开发促进业务的软件。我去Dow Jones的原因之一是帮助他们转变一种观念 – IT部门是一个成本中心。其实,IT部门也是驱动和赋能业务的部门。我觉得我对我的部门中辛勤工作和奉献的每个人有所亏欠,他们对我们正在推动的改变是很有帮助的。

AWS是作出这些转变的基础的一部分,但大部分在执行层面的工作在于了解每一个管理者的痛点,了解他们在IT中不想要什么,以便调整技术帮助他们实现自己的目标。在使用云提供的更好和更快的结果的几个月后,我们花了几个月再培训管理者团队和他们的部门来使用我们的技术而不是IT。这看似微妙,但它为我们之间的沟通带来有了有意义的变化,并且对由部门到公司整体的变化做出了贡献。

作者介绍

史蒂芬﹒奥本

史蒂芬·奥本 (Stephen Orban) 于 2014 年9月加入亚马逊AWS 担任企业战略总经理。奥本与多名企业技术高管合作,在云如何实现业务成果、加快创新和简化流程方面进行经验和战略分享。在加入亚马逊AWS 之前,奥本曾在道琼斯担任首席信息官 (CIO)一职,他通过借力 AWS 和其他软件即服务 (SaaS) 合作伙伴,引入现代软件开发方法、实现降低成本、执行云优先政策。这些转型变革加快了产品开发周期并提高了全部业务线的生产能力,这其中就包括《华尔街日 报》、MarketWatch.com、道琼斯通讯社及Factiva。奥本还曾在彭博有限合伙公司(Bloomberg LP)工作 11 年,并且在股权和消息平台担任不同的领导职务;2008 年,奥本创建彭博体育(Bloomberg Sports)并担任首席技术官 (CTO)。

在云端试验时的“有所为和有所不为”

“The best way to show that a stick is crooked is not to argue about it or to spend time denouncing it, but to lay a straight stick alongside it” ― D.L. Moody

(“验证一根木棒是弯曲的最好的方法不是争论或花时间去抨击,而是放一根笔直的木棒在它旁边” – 慕迪)

现在越来越多的公司意识到,正确的、科学的使用云可以让入云试验更简单、经济和低风险。而且有这种试验文化的公司会在今天的市场有更多的竞争筹码。试验带来创新,这是实现新想法的史无前例的好时机。那么应该从哪里着手呢?当你在你的组织中创建试验文化时,四类“有所为和有所不为”是值得你去考量的。

1.管理预期

不是每次尝试的结果都符合你的预期,但是每次尝试都是学习和提高你运营能力的机会。如果你的组织未形成一个“从失败中学习”的习惯,那就从小事做起,确保让每个人知道你把哪些项目当作试验项目。你可以通过以下方式来管理你的项目利益相关方的预期 – 清楚地了解试验的意图、你期望什么样的产出、你怎样测试和衡量结果、你想从中学习到什么。据我所知,如果管理者知道他的组织会从试验中学到什么或使它变得更好的话,即使这个试验没有什么确定地产出,他们也会对这个试验心存感激。

不要从每个人都要求有产出的项目着手

如果你是一个试图创建实验文化的变革推动者,在你的变革旅程中不要从每个人都要求有产出的项目着手。例如我不会建议你在年终预算上做试验。我曾经合作的一个CEO告诉过我失败是可以有的,除非当它不可以失败的时候。接受一个增长的过程,慢慢增加你进行的试验,不要超出你的组织的可接受范围。

2.鼓励你的团队计划试验

每个组织都有自己的方式来决定哪些项目获得技术资源。不幸的是,一些组织现在把技术或IT部门当成成本中心并且想象与实际相去甚远。好的想法可以来自任何地方,当然当它来自于项目之外的时候,大部分的技术专家都有其独特的观点。对于那些刚开始使用云的组织来说情况尤其如此——把云应用于项目上的人处于实施试验的最佳位置,这些试验利用了使业务从云中受益的独一无二的能力。协助维护你的团队的提议,将你的员工置于可以影响执行团队投资的项目上。

在你知道怎样评价这个试验时再开始它

你期望把时间花在正确的试验上,确保从中学到的内容可以提高你的运营能力和产品。在让你的团队进行一个试验之前,你应该知道他们会评测什么以及怎样去评测。如果你在测试你的网站新功能,什么样的指标意味着成功?页面浏览量?点击量?放弃量?这种小但重要的尽职的调查行为将迫使你的团队首先去思考为什么他们要进行这个试验。这也将迫使你的团队优先进行正确的试验。

3.考虑DevOps的制度化试验

一个DevOps的文化也许是把试验制度化带到您组织的有力途径。将运行所构建的与自动化结合起来可以大大减少发布改变的时间,允许你更频繁地发布并在失效时更快回滚。成熟的DevOps组织也制定A / B测试框架,让他们同时尝试不同的用户体验和不同的用户群,看看哪一个效果最好。

不要怀疑你的团队

怀疑是阻碍你团队的“最有力”的方法,并且打开了失败之门。当你学会适当地预期试验、评测它们,并对它们进行快速迭代,你会发现在你开始怀疑之前你会接受你的方法。确保你的团队在思考正确的评测试验方式,并且提出尖锐的问题是十分必要的。但是与其质疑他们交付的能力不如帮助团队解决问题。人们倾向于跟随相信他们能成功的领导者

4.鼓励整个组织参与

当你通过试验开始快速交付的时候,组织的其它成员将会被你的方式所吸引。那就拉他们进来。尝试进行覆盖不同业务领域的编程马拉松,让你的股东帮助确定怎样测评试验,向你的组织询问他们想进行哪个领域的试验。但并不是每个公司选择给他们员工时间来试验,他们通常吹捧这个为竞争优势。至少这种活动能提高员工们的士气和黏性。在我在亚马逊任职期间里,我发现任何人只要能够通过思考和书面形式表达试验,通常能得到机会尝试一下。这是我们特殊的文化的一部分,也是一个用来吸引和留住创新者和创造者的重要手段。

不要让试验延缓或中止交付

不要让你的团队因为只是一个试验而拖延交付。虽然失败和学习都是允许的,但在试验中未交付是不允许的。软件仍旧需要被交付测试,通常它也需要被放到生产环境的流量中被测评。试验并不意味着你可以推迟评测或降低质量。毕竟你依旧是在运营业务。

作者介绍

史蒂芬﹒奥本

史蒂芬·奥本 (Stephen Orban) 于 2014 年9月加入亚马逊AWS 担任企业战略总经理。奥本与多名企业技术高管合作,在云如何实现业务成果、加快创新和简化流程方面进行经验和战略分享。在加入亚马逊AWS 之前,奥本曾在道琼斯担任首席信息官 (CIO)一职,他通过借力 AWS 和其他软件即服务 (SaaS) 合作伙伴,引入现代软件开发方法、实现降低成本、执行云优先政策。这些转型变革加快了产品开发周期并提高了全部业务线的生产能力,这其中就包括《华尔街日报》、MarketWatch.com、道琼斯通讯社及Factiva。奥本还曾在彭博有限合伙公司(Bloomberg LP)工作 11 年,并且在股权和消息平台担任不同的领导职务;2008 年,奥本创建彭博体育(Bloomberg Sports)并担任首席技术官 (CTO)。

AWS CTO对过去十年的经验总结 – 十条军规

作者 Werner Vogels 发布于 2016年3月14日

10 Lessons from 10 Years of Amazon Web Services

AWS(Amazon Web Service) 开始于 2006 年 3 月 14 日 Amazon S3 的发布,距今已有十年时间。回首过去十年,我们在构建和运营 AWS 云计算服务中积累了大量的经验教训——这些服务不仅需要确保安全性、可用性和可扩展性,同时还要以尽可能低廉的成本提供可预测的性能。考虑到 AWS 是世界范围内构建和运营此类服务的开拓者,这些经验教训对我们的业务来说至关重要。正如我们多次重申的,“经验不存在压缩算法”。考虑到 AWS拥有每月超过一百万的活跃用户,而这些用户也许会为数以亿计的自家客户提供服务。因此,积累上述经验教训的机会在 AWS 比比皆是, 在这些经验教训中,我挑选了一些分享给大家,希望对各位也能有所帮助。

1.构建可持续演进的系统

从做 AWS 的第一天开始,我们就清楚地认识到,我们在做的这套软件不是一劳永逸的。现在可以用的软件,一年之后很可能将不再适用。我们的预期是,随着(用户)数量级的增加一或两次,我们都需要重新检视和适当修改我们已有的架构,以便解决扩展性的问题。

但是我们无法采取过去常用的通过检修停机进行系统升级的方式来实现上述目标,因为世界各地诸多业务都依赖着我们平台所提供的7 x 24 小时的可用性。因此,我们需要构建一个在引入新的软件构件时不会引起服务瘫痪的架构。Amazon 杰出的工程师 Marvin Theimer 有一次开玩笑说,Amazon S3 这项服务的持续演进用开飞机来形容最为贴切。我们最开始开的是一架单引擎的赛斯纳,一段时间后升级成一架波音 737,之后又换成了一支波音 747 小队,而现在更像是由空中巨无霸空客 A380 组成的一支大型机队。自始至终,我们一边通过空中加油确保飞机的正常飞行,一边在万米高空上将 AWS 的用户从一架旧飞机挪到另一架新的上面去。同时,AWS 的用户对此毫不知情。

2. 预料到不可预料的情况

故障是注定的;随着时间的流逝,一切终将归于失败:从路由器到硬盘,从操作系统到存储单元损坏的TCP数据包,从瞬时误差到永久失效,无论你用的是最高质量的硬件还是最低成本的组件,这都是理所当然的。

在服务规模变得很大之后,这个问题愈加地凸显:举例来说,当Amazon S3 服务处理万亿级存储交易时,即使误差概率极小的事件也将成为现实。在设计和构建阶段,这些故障场景中的一部分事先会被考虑到,但更多的则是未知数。

因此,我们需要构建的是将故障视为自然发生的系统,即使我们并不知道故障是什么。这个系统应该要做到,即使在“后院已经着火”的情况下依然可以继续运行。重要的是在不需要引起整个系统宕机的情况下就能管理好受影响的局部组件。对此,我们已经发展出一套控制故障发生影响范围的基本技能,以期系统的总体健康状态得以维持。

3. 提供基元而非框架

很快我们开始发现,用户大都喜欢在 AWS 提供的服务上持续构建和演进自己的业务系统。在摆脱了传统 IT 硬件和数据中心的束缚之后,他们开始以一种全新、有趣的、之前从未出现过的使用模式开发自己的系统。也正是因为如此,为了满足用户多样的需求,我们的架构需要保持高度的灵活性。

关于这一点,最重要的机制之一就是,我们提供给用户的是一系列基元和工具,用户可以选择他们喜欢的方式来使用AWS云服务,而不是由我们提供一个大而全的统一的框架。这个机制给我们的用户带来了巨大的成功,甚至 AWS 自身后续的一些服务也用上了这套机制,就像我们的普通用户一样。

同样重要的一点是,我们很难在用户还没开始使用一个服务之前,就准确预知到对用户而言该服务需要优先考虑的问题。这也是为什么所有的新服务最初都会以最小的功能集发布,然后借助用户的反馈,再对该服务进行后续的扩展。

4. 自动化是关键

开发一个需要持续维护的软件服务和开发一个最终交付给客户的软件有着巨大的差异,管理一个像 AWS 这种规模的系统,需要一种完全不同的观念,才能确保满足用户对可用性、性能以及可扩展性的要求。

实现这个目标的一个主要的机制,就是避免容易产生误差的手工操作,尽可能地将管理工作自动化。为此,我们需要构建一套可以控制主要功能的管理 API。在这方面,我们同时也对自己的用户给予帮助。通过将应用分解成一个个独立的模块,每个模块都有自己的管理 API,你可以很方便地定义自动化规则来进行大规模的维护。判断自动化做的是不是到位,可以思考一下你是不是还需要使用SSH登陆到某台服务器进行运维操作?如果答案是 yes,说明你的自动化做得还不够好。

5. API 定义要严谨,因为一旦上线就无法更改

我们在 Amazon 零售项目中已经接受过类似的教训,但对于 AWS 这种以 API 为中心的服务,这个原则变得更加重要。一旦用户开始用我们的 API 开发他们的应用和系统,我们就不可能再对这些 API 进行变更了。因为 API 的任何改动都会影响到用户已有的项目。因此我们充分意识到,在 API 给到用户之前,我们只有一次将 API 做对的机会。

 

6. 监控你的资源使用情况

当你为一项服务确定计费模式的时候,请务必确保你有一份关于该服务的资源成本和运营的数据。对于边际成本很低的业务尤其如此。作为服务提供 商,AWS 需要对服务成本保持足够的敏感,以便我们能清楚地认识到我们是否承担得起某项服务,同时也能够定位到一些可以通过提高运营效率而进一步降低成本的地方,并借此降低服务价格,最终惠及用户。

举一个例子,早期的时候,我们对于 Amazon S3 服务所用到的资源成本并不是很清晰。我们当时假定,存储和带宽应该是我们首要考虑的收费点;后来运行了一段时间之后,我们才意识到,请求数量跟存储与带宽同 等重要。如果某个用户有大量的小文件要存储,这种情况下,即使是百万量级的请求,都不会占用太多的存储和带宽资源。最终我们做了调整,将请求数量也纳入了计费模型,以便 AWS 在收支上可以保证这项服务的可持续性。

7. 从头开始建立安全机制

保护你的用户,这一点的优先级永远都应该排在第一位,在 AWS 也不例外。不光要从运营的角度,还要从工具和机制的角度保证这一点。对此,我们也将继续保持最高的支持与投入。我们很快就学到的一个经验就是,为了实现安 全的服务,我们需要在服务设计的最初阶段就抱有这种安全意识。安全团队的任务不是在一项服务实现完了之后才开始安全检查,相反地,安全团队的工作应该和开 发团队一道,贯穿于整个项目的生命周期,以确保项目的安全性。总之,涉及到安全的问题,没有任何妥协的余地。

8. 数据加密是头等大事

数据加密,是保证用户数据安全的重要机制。十年前,数据加密相关的工具和服务还不够完善,直到 AWS 刚开始运营的最初几年,我们才逐步积累了很多关于在服务中集成数据加密的最佳实践。

Amazon S3 最初提供的,是服务器端的加密机制。当我们在数据中心移除带有用户数据的磁盘的时候,这些数据就无法被访问到了。但是后续上线的诸如 Amazon CloudHSM 和 Amazon Key 管理服务,均向用户提供了自定义加密密钥的机制,这样一来,AWS 就不需要替用户维护这些加密密钥了。

现在,AWS 所有的新服务,在原型设计阶段就会考虑到对数据加密的支持。比如,在 Amazon Redshift 服务中,每一个数据块都通过一个随机的密钥进行加密,而这些随机密钥则由一个主密钥进行加密存储。用户可以自定义这个主密钥,这样也就保证了只有用户本人才能访问这些机密数据或敏感信息。

数据加密在我们的业务中的优先级一直非常高。我们也会持续改进,让数据加密机制用起来更简单,最终,让用户能更好地保护自己的数据安全。

9. 网络的重要性

AWS的服务支撑了各种各样的负载场景。从高并发处理到视频转码,从高性能并行计算到海量的网络请求。这些不同的负载场景,对网络的要求也各不相同。

关于数据中心的设计和运营,AWS 开发了一套独特的机制,这套机制提供了灵活的网络基础设施,以便满足任何用户的不同负载场景的需求。在这个过程中,我们也认识到,为了让用户达成自身的目 标,我们必须开发自己的网络解决方案。这样也能满足我们自身的一些定制化的需求,比如在保证高安全性的同时,通过网络来隔离用户的能力。

AWS 自主开发的这套软硬件解决方案,也能给用户带来进一步的性能提升。关于这一点,有一个成功的例子,那就是虚拟机之间的网络通信。由于网络通信是一个共享的资源,在使用 AWS 自己定制的解决方案之前,用户时常会遇到网路拥堵的问题。最终,AWS 通过开发支持单个根 IO 虚拟化技术的 NIC,实现了给每个虚拟机虚拟出自己的 NIC 的解决方案。这一改动成倍地降低了网络延迟,同时提升了高达十倍的网络性能。

10. 不设限,保持平台的中立与开放

随着时间的推移,AWS 团队提供了越来越多的服务和功能,这也给我们的用户创造了一个广阔的开发平台。但是 AWS 远不止我们团队开发的这些功能与服务,一些合作伙伴基于 AWS 提供的服务进一步扩大和丰富了整个系统的生态。比如,我们的合作伙伴 Stripe 提供的支付服务得以让 Twilio 在 AWS 上支持电话业务。

很多用户基于 AWS 本身的服务,开发出自己的产品,用于解决特定的垂直领域的问题。比如,飞利浦开发了用于健康数据管理的 Healthsuite 数字平台;Ohpen 则基于 AWS 开发出自己的零售银行平台;Eagle Genomics 开发了自己的计算平台用于基因处理等等,这样的例子不胜枚举。AWS 并不会限制我们的合作伙伴,规定他们什么可以做什么不可以做。“不设限”的原则释放了创新的动力,为意想不到的创新敞开了大门。

对于在接下来的十年里, AWS 的团队会学到哪些经验教训,我们的用户又会创造出什么样的价值,我充满了期待。

永远记得,对 AWS 来说,这仅仅是一个新的开始。