Category: 方法论


将 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 企业战略家和推广者

针对云迁移的 21 个最佳实践

熟能生巧。-Bobby Robson

在过去几个月里,我花了很多时间与各种 AWS 客户和团队合作来打造帮助企业加快云迁移工作的全面计划。此计划包含许多方面,包括 (但不限于) AWS 服务 (例如,AWS Database Migration Service、AWS Snowball、VM Import/Export)、一个由 AWS 专业服务打造的迁移方法、一个即将推出的“迁移到 AWS”培训计划以及与工具提供商和咨询商店建立的合作伙伴关系 (旨在加快各行各业各种规模的企业的云迁移速度)。

今天,我很高兴介绍由本公司的员工 Sadegh Nadimi 编写的一篇客座文章,此人详细说明了我们在执行到 AWS 的大型迁移的企业中观察到的 21 个最佳实践。言归正传 . . .

-Stephen
orbans@amazon.com
@stephen

(more…)

在使用云进行试验时,4 件要做的事情和不要做的事情

“证明一根木棒是弯木棒的最佳方法不是争论或花时间去抨击,而是将一根直木棒放在它旁边”― D.L. Moody

在我的上一篇文章中,介绍了云如何使所有类型和规模的公司能够以更低的成本更轻松地进行试验且风险更小。公司越是意识到这一点,就越有更多的试验文化成为在今天的市场中保持竞争力的筹码。 试验引发创新,从来没有这么好的机会实施新想法。

您从何处开始?下面是在您的组织内打造试验文化时要考虑和避免的四件事。

1. 需要管理期望

虽然并不是每个试验都将提供您预想的结果,但每个试验都是一个了解和改善运营的机会。如果您的组织不习惯“未能学习”这个概念,请从小事做起,确保每个人都摘掉您考虑试验的项目。通过清楚了解实验目的、预期结果、测量和测试结果的方式以及您希望从中学到的知识来管理您的利益相关者的期望。我发现,如果大多数高管知道组织更乐意进行试验并学习知识,他们将欣赏那些结果不确定的试验。

不要从每个人都有一个特定结果的项目开始

如果您充当尝试打造试验文化的变革代理,请不要在您的旅程中过早地试验您的利益相关者期望获得特定结果的项目。我不是建议您开始试验年末账单运行 (举例来说)。我曾经为其工作的一位首席执行官告诉我,失败是可以接受的 (除非没有失败)。要对逐步积累的进展感到满意,并慢慢地增加你所进行的试验的数量,但不要超过组织。

2. 需要鼓励您的团队计划试验

每个组织都有自己的方法来确定哪些项目获得了技术资源。不幸的是,一些组织现在将技术或 IT 部门视为成本中心,并且已将理念推到离实现位置太远的地方了。好的想法可以来自任何地方,当然,当它涉及外部项目时,大多数技术专家都有一个独特的观点。这在刚开始使用云的组织内尤为如此 - 对项目使用云的个人处于计划试验的最佳位置,这些试验利用云的独特功能来使业务受益。帮助支持您的团队的计划,并安置好您的员工以影响高层管理团队所投资的项目。

在知道如何测量试验之前不要进行试验

您希望将时间花在正确的试验上,并确保从中学到的经验将改善您的运营和产品。在您让您的团队向前推进试验之前,您应同意他们将在试验期间测量的内容和测量方法。如果您正在测试网站上的新功能,哪些指标将使测试成功?页面视图?单击次数?放弃?这种小而重要的尽职调查将迫使您的团队去思考为什么他们要首先计划一个试验。它还将强制您的团队设定正确试验的优先级。

3. 需要考虑开发运营使试验制度化

开发运营文化是一种将试验融入组织中的强有力的方式。通过将运行您构建的内容与自动化相结合,可以大大减少发布更改所花的时间,从而允许您更频繁地发布更改并在失效时更快地回滚更改。成熟的开发运营组织还开发了 A/B 测试框架,这些框架可使其在不同的用户群中尝试不同的用户体验以了解什么是最有效的。

不要怀疑您的团队

怀疑是对团队造成打击并打开失败之门的最有力的方法之一。当您学会适当地审视试验、测量试验并对其进行快速迭代时,您应会发现在需要怀疑之前,您能够适应您的方法。确保您的团队正在考虑正确的方法来测量试验并提出尖锐的问题是正常的,但您应考虑帮助团队解决问题而不是怀疑他们的交付能力。 人们倾向于追随那些相信他们会成功的领导者

4. 需要鼓励整个组织进行参与

当您开始通过试验更快地交付结果时,组织的其他方面将被您的方法吸引。吸引这些人的参与。尝试一个包含不同业务领域的黑客马拉松,让您的利息相关者帮助确定测量试验的方式,并询问组织他们一直想要进行试验的领域。虽然不是每家公司都会选择为其员工提供试验时间,但这些公司通常会将它宣传为竞争优势。至少,这些具有包容性的活动可以提高员工士气和员工保留率。在 Amazon 的短暂任期内,我发现任何能够写作进行思考和表达试验的人员通常都会有机会进行尝试。这是我们的文化的一个特殊部分,也是吸引和留住创新者和建设者的出色工具。

不要让试验减速或停止交付

不要让您的团队仅因某件事是一个试验而逃脱责任。虽然失败和学习是允许的,但在试验中无法交付是不允许的。软件仍需要交付测试;它通常需要用实际的生产流量来进行测量。仅仅因为这是一个实验并不意味着您应稍后开始测量它,或者让其质量受到影响。毕竟,您仍在运营业务。

您的组织通过什么来支持试验文化?请一定告诉我!

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

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

 

应成文规定企业文化和聘用与企业文化相契合的人才的 3 个理由

“公司刚成立时,我们没有太多地讨论企业文化。根本没有任何成文规定。我们只是成立了一家自己感觉工作氛围良好的公司。在那时看来,这很不错了。但当我们开始进行更深层次的思索时,意识到企业文化是必不可少的。我们需要把它写下来,共同讨论。分解,精心讨论细节,再融合在一起。如此反复。一遍又一遍。” — 史蒂夫·乔布斯

大多数高管都认同“人才使组织变得独一无二”这句话。高绩效者的加入可以形成推动力,加快其参与的计划的进展,同时改善他人的成果。相反,如果缺少高绩效者,可能会形成“真空环境”,不能正常完成相关计划,同时降低组织的士气。无论哪种方式,团队增加或减少的每一个人都会影响组织的 DNA 或文化 — 这种影响有时微妙,有时深远。

在过去的几十年里,我有幸在几个具有高绩效文化的公司里工作过。

我花了 11 年时间从适应 — 到拥护 — Bloomberg LP 的企业文化,从工程师、工程经理一步步成长为业务负责人。在随后的 3 年里,我以首席信息官的身份在道琼斯内部推行了企业文化变革。在过去 3 年里,我作为 AWS 全球企业战略主管,四处推广 Amazon 强大的企业文化,帮助世界上一些最大的公司变革其企业文化。

通过这段经历,我发现,具有高绩效企业文化的组织在招聘人才时,对文化契合度的要求不亚于对专业领域和/或专业知识的要求。坚实的专业知识 — 无论是工程、销售、市场营销还是其他领域 — 不应忽视,但并非全部。

在我所经历的每一个高绩效企业文化中,组织对企业文化所扮演的角色都有其目的性,得益于它产生的上升力,有助于员工更快地发挥个人潜力。因此,在说明为什么我认为组织的聘用决策考虑文化契合度会对组织有益之前,您的组织需要明白自己的企业文化是什么,最好把它记录下来。

每一家公司 — 不管其规模、行业、资历如何 — 都有自己的企业文化。

企业文化是公司现状的结果 — 而不是其成因 。

并非每一家公司都会以书面形式记录其企业文化。

如果没有明确成文的企业文化,员工可能会猜测自己该以何种方式工作,这对企业来说是一种风险。因此,就算有很多员工向生产力低下的方向发展或与工作环境格格不入,也不足为奇。

例如,我在彭博工作期间 (2001 年到 2012 年),我们的部分企业文化是有成文规定的,有些更像是“部落文化”。每个部门都有一系列明确的指标 (如所有权、技术能力、沟通度),公司会对员工开展测评以强化某些行为;此外,公司还有一项隐含指标,我们简单地称之为“彭博价值观”(如勇往直前、不屈不挠、完成工作 (GSD)),这是需要随着时间的推移才能慢慢感受和体会到的。事后看,我发现有一些貌似高绩效者 — 特别是具有很多以往经验的人士 — 因为抵触“彭博价值观”而成长较慢 (稍后再详细说明这一点)。

同样,Amazon 也将我们的部分企业文化以 14 条领导准则 (在 Amazon 内部,我们将其简称为 LP) 的形式记录了下来。每条 LP 都在我们的日常工作中发挥着巨大的作用,它们是在 Amazon 做任何工作 (从招聘、绩效管理到业务决策) 的关键因素 (稍后详细说明)。

在一篇相关文章中,我在 AWS 的一位同事 Joe Chung (我很荣幸认识他,我从他身上学到了很多东西) 介绍了制定明确的准则在任何大型云项目期间帮助指导决策的重要性。Joe 的许多观点适用于任何大型变更管理或企业文化原则制定活动。

不管组织有没有明确的“准则”或“价值观”,或者以其他形式描述企业文化,历史经验表明,以成文形式规定企业文化优于什么都不做 (至少对 Apple、彭博和 Amazon 是这样)。

而且,以书面形式规定企业文化有助于甄别契合企业文化的人才。您应该考虑以成文形式规定企业文化并聘用契合企业文化的人才,主要原因有以下 3 个:

原因 1 — 招聘契合企业文化的人才有助于始终如一地指导招聘工作

© Roger W https://www.flickr.com/photos/24736216@N07/5869083813

聘用人才非常难。要聘用的人越多,难度越大。

我认识的大多数高绩效者 (您的团队需要的那些人) 已经有了他们喜欢的工作,这可能也是他们绩效较高的原因之一。我发现,这些高绩效者倾向于寻找能够帮助其取得成功的企业文化。(包括我自己在内;我那时*真的*很希望到 Amazon 工作,想感受这里的工作驱动力。)也就是说,您越拥护、丰富和尊重自己的企业文化,契合您企业文化的人也越容易发现它。

在 Amazon,我们聘用员工的速度很快。我们通过多种方法来满足我们的招聘需求 — 例如,摇滚明星式招募团队、不懈创新追求、能吸引其他能人的能人,等等。在所有这些方法中,我认为,按照最相关的 LP 评估每位候选人能够最大限度地加快我们的招聘流程。每位面试官都非常了解如何依照对招聘经理最重要的 LP 来评估候选人,我们的所有“汇报”(决定每位候选人聘用与否) 讨论都基于候选人与 LP 及风险的匹配度 (没有不存在风险的招聘)。如果没有这些 LP 和周密的过程,我们的招聘活动不会这么快速。

我在彭博任职期间经历过几次招聘高峰,那时,我们每年都会在大学校园直接聘用 100-150 名工程师。我们设立的技术门槛极低 — 每位候选人必须能够设计一个基本的系统,并且编写出解决一个简单问题的代码 — 其余的聘用决策都基于文化契合度。彭博招聘团队的大部分成员都已在该公司工作多年,非常熟悉自己的企业文化,足以衡量候选人是否具备适当的问题解决能力以及是否契合组织的“彭博价值观”。凭借这些洞见,我们能够在现场做出聘用决策,这引出了我们的另一个观点。

原因 2 — 招聘契合企业文化的人才有助于新员工融入新环境

开始一项新工作可能令人兴奋,也可能是一场可怕的经历。新员工一般不知道自己面临的是什么样的环境、同事,通常也不完全了解其角色所带来的细微差别。但是,候选人对企业文化了解越深 — 越理解自己与这种文化是一致的 — 就越容易适应新环境。

我经常将高绩效文化想象成一种气流。契合企业文化的新员工将得到助力,不契合者最后会非常疲惫,要么调整自己的行为,要么离开组织。

在 Amazon,我们相信新员工是顺流而不是逆流而行的人,因为在聘用决策前,面试过程中重视 LP 帮助我们做到了这一点。除此之外,在汇报期间讨论候选人风险时,我们还可以讨论降低这些风险的方式 — 指派辅导老师,提供培训计划或辅导课程 — 因此,候选人在我们的企业文化氛围中有最好的成功机会。

由于我们有成文的 LP,这就不限于任何个人、经理或计划。新员工更容易一贯如一地理解我们的行事方式。在我的职业生涯里,见过、听过很多高绩效者因为没有意识到自己与企业文化不一致而导致工作不开心或不成功。

原因 3 — 招聘契合企业文化的人才有助于部署 (或重新部署) 人才

有很多信源 (此处此处此处) 表明,当今企业的平均员工任期持续缩短,这也符合常识。

这里可以得出很多结论,其中一个合理的结论是高绩效企业文化的组织的员工任期更长。

此外,我还发现,聘用契合企业文化的人才不仅有助于为组织注入他人难以复制的灵活性,而且更有可能招聘到可确保组织在许多方面长期保持领先地位的人才。我尽量向我在 Amazon 聘用的每位候选人传达这样的信息:我们期望建立互惠关系,这样我们可以在较长的时间内 (我们乐于长远思考) 探索多个不同的角色和领域。

说点题外话,在 11 年的彭博职业生涯里,我担任过不同领域的 6 个不同职位。拥有如此多的机会是我一直呆在彭博的主要原因之一。而且,尽管我犯过无数的错误,但在彭博文化价值观的指导下,我的领导团队仍愿意为我提供各种机会。回想起来,在这 6 个职位中,有 3 个是我在之前的领域做出一定贡献后获得的;而另外 3 个职位,我很确信是因为契合彭博企业文化而得到的。
您的经验是什么?您的企业文化是否有成文规定?如果没有,为什么?您会写些什么?您在聘用人才时是否考虑企业文化契合度?我很乐意倾听您的想法!我将继续发表关于企业文化的文章,欢迎发表意见和提供新想法!

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

 

将 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 企业战略家和推广者

 

在云中自动实现合规性的 3 个好处

“建立声誉需要 20 年的时间,而毁掉声誉只需 5 分钟。” — Warren Buffett

在我的技术生涯中,我一直支持遵从性和安全需求。在某些情况下,这些要求是极其苛刻的 - 例如,当我的团队为国防部审核做准备时,花费了几个月的时间,超出了我们时间的 50%。但是,在几乎所有的情况下,我都能够促进使用自动化的解决方案来使我们的生活更轻松,同时提高我们的安全性和遵从性水平。现今,移至云为您提供了明显改善合规性工作的可能性,而不需要在人力和成本上有同样的显著提升。

我来解释一下 –

合规官通常负责评估和管理企业财务、组织和声誉的风险。在企业环境中,这是一项艰巨的任务,因为人员、流程和技术的复杂性,加上跨行业和地理区域的监管差异。

企业和合规性之间也存在着一种天然的紧张关系。企业必须进行产品创新并改善客户体验。另一方面,合规性团队专注于限制或防止风险暴露,这可能与引入新产品和新特性相冲突。这就是合规性团队经常寻求维持现状的原因。底线是企业和合规性之间的自然紧张关系 - 有时运行状况 - 可能会导致关系紧张并经常导致成本增加,以及减慢上市速度。

通常,合规性团队会进行年度合规性评估、撰写报告和设定补救目标。随后,为业务和技术团队提供对任何发现结果进行补救的时间安排。产品经理和技术领导者了解合规性的重要性,但他们通常将评估视为“练习”并且从价值生成中分散注意力。对他们来说,企业领导者担心年度合规性报告的结果,因为他们认为这些“非功能性”要求会将资源重定向到未来几个季度的战略路线图中未包含的事情上。此外,在开发过程中,合规性常常被作为事后的补充。但遗憾的是,经验告诉我们,如果放任不管,合规性问题最终可能会转化为技术债务。

尽管合规性过程通常被认为是繁重的,但结果可以为客户增加有意义的价值。实际上,根据法律和道德的考虑,合规性应该被看作是一种质量的度量,确保了良好的客户体验,特别是在审查包含了安全性、可靠性和响应性的情况下。您的云策略可在这里扮演重要角色 - 方式是转化企业和合规性利益相关者之间的关系,从而改善企业及其客户的结果。更具体地说,通过在产品或服务生命周期的早期包含合规性要求,您可确保您满足政策和法规目标,同时改善您的价值主张。

方法如下 –

首先,迁移到 AWS 是一种直接的节省。在我自己的云之旅中,我发现 AWS 责任共担模式可让我们获益。以前,我们必须管理物理基础设施才能确保法规遵从性。当我们不得不采购硬件以支持技术计划时,这就造成了额外的延迟。它也总是增加我们的运营负担,因为它通常意味着基础设施团队的工作更多,而不需要额外的人员。通过将我们的工作负载迁移到云,我们将维护一个安全的、合规的物理基础设施的责任转移给了 AWS,从而带来了我们永远无法提供的资源和专业知识。换句话说,我们能够提升我们的能力,同时减少我们必须自己保护的表面积。这为我们的运营团队腾出了时间来专注于其他的增值工作,例如,创建其他自动化。

AWS 责任共担模型

其次,将工作负载转移到云可鼓励更大的自动化。可以基于标准化的和经过批准的模板部署环境,然后可以进行版本控制。此概念称为“基础设施即代码”,安全性和合规性的好处是深远的。在将基础设施作为代码进行管理时,可使用脚本自动验证基础设施来确保遵循安全最佳实践。AWS 还支持在 AWS Config 中定义可自动验证的合规性规则。因此,在使用自动化时,合规性团队可在每次系统更改时验证法律和安全需求,而不是依赖于定期的系统审查。此外,合规性和安全性测试自动化可推入软件开发过程中,并有可能在部署到生产环境之前防止策略违规。最后,可以在每日的报告中捕捉到这些发现,并发送到一个将问题分配给某个特定个体的票证系统,甚至可以触发一个自动修复响应。例如,Capital One 已开发出名为云 Custodian 的规则引擎,此引擎用于在其云平台中定义策略并以编程方式强制实施策略。

第三,当自动化过程或手动审查发现问题时,可更轻松地部署补救措施。例如,在基础设施存在漏洞的情况下,基础设施模板可在代码中进行修改并将自动应用于所有未来的实现。如果应用程序中存在此问题,则可通过将修复部署到应用程序,或通过实现补偿控件 (例如,将规则添加到 AWS Web 应用程序防火墙) 来缓解风险。

随着时间的推移,您的云策略可形成一种积极的合规性文化,将合规性和安全性作为增值的以客户为中心的活动。当您的产品团队在产品待办事项列表中将合规性要求作为用户案例包含时,或当开发人员定期向其软件开发过程添加与合规性相关的测试时,您将实现此里程碑。

如果您已在 AWS 中实现合规性过程的自动化,或者您想要了解有关此主题的更多信息,请告诉我。与此同时,这里还有一些其他的资源可能会有所帮助 –

自动在 AWS 上执行管理

如何监控 AWS 账户配置更改和对 Amazon EC2 安全组的 API 调用

AWS 上的 DevSecOps 简介 — Slideshare

期待再次相会,

– Thomas

thoblood@amazon.com
@groberstiefel
http://aws.amazon.com/enterprise/

 

来自成功云企业的十项诀窍

“对于需要先学后做的事,我们不妨边做边学。”——亚里士多德

今天的这份推荐清单也可被称为“我希望自己刚刚踏上云旅程时即已了解的十件事”。在道琼斯的工作经历让我意识到自己非常幸运——我们能够从其它企业身上学习经验,同时亦有机会在加入AWS之后同数十家在云领域获得成功的客户沟通,从而了解其与技术乃至业务变革密切相关的或积极、或保守的具体状况。

1.拥有高管层支持。事实上,大多数倡议都会获得高管层人员的支持。特别是在大型企业当中,拥有高管作为后盾的项目往往更容易取得成功。大家用不着苦苦哀求其划出一块“实验田”,而应切实表达自己希望帮助企业走向成功的意愿。只要理解了云技术所能带来的长远收益与重要意义,其它的工作将水到渠成。

2.利用现有员工建立卓越中心。现有员工虽然未必具备对应的技能储备,但这并不代表他们就没有能力完成此类任务。成功的云企业能够快速构成卓越中心,同时推广最佳实践与坚实的治理手段。尽管云方案的打理方式与传统技术有所区别,但其计算本质仍然是统一的。大家不妨将其理解为企业资本投入的一种拓展方式。合作伙伴与顾问亦能够起到巨大助益,特别是在加快业务产出或者提升独立性方面。但是需要注意的是,务必要确保各合作伙伴及顾问充分了解我们已经掌握的云专业知识。从长远角度实现云技术过渡的方式可谓多种多样,包括DevOps、双峰IT以及全堆栈工程等等。考虑到丰富的潜在选项,我们并不一定需要马上拿出结论。大家不妨将此作为探索企业结构转换的绝佳机遇,或者制定一套后备方案。我们自己才最了解自身企业结构,因此只要能够在正确的道路上获得些许经验,未来的方向也将自然显现。在后续文章当中,我们将对这一议题再进行一番总结。

3.他们对于具体实现速度并不强求。请记住,这是一段探索旅程。企业绝对不可能在一夜之间做出将全部或者部分基础设施迁移至云环境下的决定。他们会首先建立实验机制,逐步了解其中收益并以负责任的节奏慢慢借此获取效益且增长业务能力。

4.他们始终保持开放的心态。适合以云环境作为立足点的项目可谓多种多样。大家应当以业务需求为优先,而非单纯考虑适用性。事实上,云升级所能带来的可能性几近无穷,而相关工作可由高管团队驱动或者交给特定团队/个人负责。如果有人认为他们能够在云环境下完成目标,那么不妨为其提供机会。为员工提供施展舞台无疑非常重要,毕竟就算是金子,也要在太阳下才能发光。

5.他们以谨慎态度审视成本。TCO(即总体拥有成本)问题始终应当得到认真考量——无论是在内部环境下还是云基础设施层面。我发现企业往往面对一类常见陷阱,即倾向于保留大量根本使用不到的资源。举例来说,如果大家拥有6台服务器,每天有4个小时处于峰值使用状态,但其余的20小时内仅需要2台服务器即可应对负载,那么我们每天需要的服务器计算时应为64单位(4 x 6再加上20 x 2)。在这种情况下,我们的TCO计算方式应该按64服务器时考虑,而非传统的144单位——意味着我们只需要一半传统计算资源即可解决问题。而且如果在业务环境下保留大量虚拟化实例,那么我们将很难面对需求变化做出及时调整。大家部署的云资源越多,真正能够用到的比重就越低。AWS围绕TCO建立起一套卓越中心,而且乐于帮助客户进行资源需求分析。虽然整个流程高度自动化,但大家也可以借助AWS提供的经验心得与最佳实践勾勒出更准确的宏观视角。另外,如果大家发现某种成本更低的实现方式,AWS也乐于从中学习并借此改进自身服务。

6.他们无惧于犯错。出现错误其实是件好事。随着经验的逐步积累,大家犯错的可能性将越来越低,而云方案部署过程也会越来越快。当然,允许犯错并不是说初步方案在交付速度上就一定要比传统机制更慢。事实上,大多数AWS实验性项目在起步阶段就能够带来远超传统方案的交付速度——即使计入处理错误所带来的时间浪费。云计算方案的最大助益之一就在于,用户能够以极低的实验成本做出各种探索。大部分最具创新能力的企业都会将实验工作作为创新的表现形式来看待。如果某些组件未能达到预期,大家完全不必灰心——继续推进即可。

7.他们将自动化机制作为必要前提。这也是企业在尝试发挥云计算全部潜能时,必须完成的一项重要技术转换。根据我的个人经验外加与客户们的交流结论,一旦某家企业开始将服务器基础设施视为计算实例组合——而非单纯的设备,那么这种弹性收益也将很快实现。通过这种方式,企业能够获得更理想的安全性水平、环境可预测能力,同时凭借自动规模伸缩应对种种具体需求。在我看来,自动规模伸缩堪称有史以来最伟大的创新成果之一。它也正是云计算方案所带来的最为根本的新型功能之一。与之前提到的TCO一样,自动规模伸缩将显著提升我们削减运营成本的能力。

8.他们主动监控并关注核心层面的警报信息。每一家企业都拥有独特的关注倾向以及风险承受能力。根据业务方向的不同,大家可能更关注资源所能承载的用户数量、账单变化情况以及网络或应用程序性能是否会受到其他租户的影响。无论具体关注点在哪里,我们都应当引导技术团队确切把握相关情况,并利用正确的工具(包括CloudTrail、CloudWatch Logs、Directory Service等等)加以应对。

9.积极使用AWS Marketplace。这套应用市场提供多种解决方案,足以涵盖各类AWS客户所面对的一切实际问题。当初道琼斯公司在决定迁出原有基础设施时,就是从AWS Marketplace当中找到了易于配置及使用的相关解决方案。目前这类管理实践方式也依然有效,大家甚至会惊讶于AWS Marketplace在加快云技术转型工作中的重要作用。

10.他们乐于探讨相关议题。企业中的其它部门肯定希望了解更多与云方案相关的信息,包括哪些预期切实可行、而哪些并不现实。分享个中经验能够强化整体推进流程,同时帮助参与者们意识到自身工作的重要意义。众多AWS客户都在公开发表他们的经验与心得,而这些都可能引导更多其它企业走上这条极具现实意义且成本低廉的转型之路。最后,AWS一直高度重视客户的意见。AWS发展路线图中有90%到95%的内容是根据客户反馈所制定,因此请积极发出您自己的声音。

以上情况是否与您所在的企业相符合?如果大家认为还有更多值得关注及共享的经验,也请不吝指出!

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

作者介绍

史蒂芬﹒奥本

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

勇于制定新规则,方为伟大领导者

“无论有何规则,我都自由无碍。在可容忍时容忍,在无法容忍时将规则打破。我享有自由,因为我愿为自己的一切行为承担道德责任。”——罗伯特·海因莱因

出色的领导者执行规则,而伟大的领导者则能敏锐地察觉到不再适用的旧有规则并将其打破。正如海因莱因所提到,新规则的制定实际上必然伴随着旧有规则的淘汰。但要成为能够影响整家企业的伟大领导者,我们首先需要深入理解现有规则,而后决定是否及何时对其加以变更。

在企业推进云技术探索旅程的过程中,技术领导者亦将迎来制定新规则的绝佳机遇。我个人甚至更倾向于技术高管的角色描述为“首席变革管理官”(简称CCMO),他们将有权检查当前进程并确定哪些规则仍然适用、哪些已经不再适用于云企业管理工作。

为新任务制定新规则

相信很多朋友都熟悉基于进程的框架方案,例如ITIL、ITSM以及规则-构建-运行模式。这些方案往往诞生于过去几十年,旨在规范大型企业当中的IT交付与运营事务。这些框架的创造者也有资格为自己的研究成果而骄傲,因为其能够明确界定企业中的角色、职责与流程,从而提升效率、效益、质量与成本组合。

这些方法在被用于管理其所针对的工作时,确实能够起到非常理想的效果——例如管理基础设施。然而,如今企业正越来越多地将精力集中在吸引客户方面,而这也成为其运营工作的核心主干:Talen Energy希望利用多种不同燃料帮助发电系统实现供电。耐克希望利用灵感与创新帮助每一位运动员提高自身成绩。通用电气希望构建、推动、支撑并改善整个世界。着眼于过去,管理基础设施是实现这些目标的必要手段,但如今云计算的出现带来了新的可能性,因此CCMO应当在继续保持原有基于流程的框架方案的同时,积极制定的规则来管理更为现代且数字化程度不断提高的运营模式。

立足于企业整体寻求机遇

无论大家的云技术探索之旅已经进行到哪一步(或者是否涉及管理程序变更),各位都应当以未来的云环境为基础考量自身角色、职能与流程设计。每家企业都拥有自己的独特需求,因此其探索途径也将有所区别。而在与企业高管探讨规则改变工作时,他们往往高度重视运营、IT审计以及财务管理等几大核心议题。

需要指出的是,今天列出的条目并不详尽——当然,我们也不可能涵盖探索旅程中的每个方面。因此,希望大家能够积极分享您自己的心得与体会!

运营。今年年初,我曾经撰写了关于企业向DevOps转型的一系列文章,其中提到了多项值得关注的规则变更要点:

专注于建立以客户服务不核心的IT部门,其应当充分理解客户(无论内部还是外部)需求并对解决方案的设计与交付方式保持开放态度。

与此同时,贯彻“谁构建谁运行”理念。根据我的经验,这项实践对于企业而言往往是最难推行的事务,这是因为其与传统基于流程的IT框架可谓大相径庭。不过必须强调,“谁构建谁运行”机制拥有诸多优势,亦能够帮助我们顺利完成众多规则变更工作。而且根据我的见闻,这项转变几乎为每一家加以尝试的企业都带来了可观的收益。

最后,在做出这样或者那样的运营变更之前,预先做出效果预测也是非常重要的。另外,请保持耐心——没有任何一项变更工作能够一蹴而就,数十年的习惯需要投入相当一段时间来扭转。

审计流程。审计人员在企业的云技术探索之旅中扮演着重要角色。就目前来讲,众多高管人员误以为审计工作会拖慢自己的变革步伐,甚至有不少人一提到“审计部门”就感到头痛不已并将其与种种负面影响联系起来。事实上,实际情况并非如此,特别是在大家试图建立新型规则、生产或者过渡方式的过程中。审计机制是我们的朋友而绝非敌人。与审计师进行早期协作往往能够明确解释我们打算实现的目标,而认真参考他们的意见绝对能够带来助益并改善实际效果。

在道琼斯公司工作时,我一直疲于向审计人员解释自己为什么要推行DevOps,又希望借此实现哪些目标。这种焦虑让我们身心俱疲,但最终事实证明这些并不必要。当我们开始阐述新规则是如何利用自动化机制改善控制能力时,我们的审计人员们非常顺畅地接受了这些观点——他们甚至比我们更熟悉未来的发展方向。通过早期方案演示,我们不再是两个被迫坐在一起的孤立团队,而开始通过多种沟通方式交流经验,最终显著降低出错可能性并建立起彼此间的信任情绪。同样的情况也将出现在大家与安全及法律团队间的协作当中。他们也需要参与到早期合作中以确保每个人的需求得到满足。请务必体谅他们的立场与要求,同时设法拿出一套能够同时契合自身规则与对方需求的方案。

财务管理。从以往需要投入大量前期资本以购置总量不定且经常超出实际需求的基础设施,到如今的按需付费(即只为实际使用的资源付费)模式,几乎每一家企业都能够借此实现财务改善并节约下大量宝贵的现金流。说了这么多,新的费用管理方式可能彻底转变大家支配现有财务资源的思路。通常来讲,我们最好与财务部门密切合作,利用新的规则以充分发挥云技术提供的资源杠杆,最终得出更为确切的预算额度。在道琼斯公司,我们的云支出增长速度远低于基础设施领域的投资节约幅度。我们确实投入了大量转型资源,但最终账单变化令财务团队非常满意,而他们也以合作伙伴的身份参与进来以进一步优化预算方案。

随着我们将更多资源投入到产品开发当中,我们也最终凭借着预测控制器、预留实例(简称RI)以及人力成本资本比例提升等方式迎来了前所未有的月度生产水平。在实践中,我们意识到财管管理人员将带来巨大帮助,包括如何预测计算资源需求变化以提前购买RI服务并借此节约成本等等。Cloudability公司亦是其中一例,他们最近发布了一篇不容错过的RI采购指南文章。其内容非常出色,因此请大家直接阅读,我在这里就再献丑了。

正如之前所提到,这些都是我们在云技术探索之旅中值得尝试的规则。如果大家对此有何建议、意见以及心得体会,也请不吝分享!

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

作者介绍

史蒂芬﹒奥本

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

七项最佳实践助力企业完成云探索之旅

“生命是一场旅程。当我们驻足时,一定是事情出了差错。”——方济各

去年12月,我曾在文章中提到云计算将成为新的业务常态,而将云要素纳入现有企业架构则是一场极具意义的探索之旅。这一旅程通常包含几个阶段,能够成功将云纳为己用的企业往往在一定程度上拥有共性。

自那时直民,我走访了几个大洲并与多家企业进行沟通,希望了解他们如何利用云平台满足自身业务需求。而在此过程中,我对于云探索旅程的观点也开始有所转变。

今天的文章旨在阐述我在见闻当中了解到的企业交付成果以及由此展开的新思路。在接下来的几个月中,我将更进一步研究各类最佳实践,并与大家分享其中哪些作法切实有效、而哪些无法达成预期目标。当然,也欢迎各位畅谈您自己的经历或者想法。

在进入今天的主题之前,我需要再次重申:云探索之旅是一个需要投入大量时间的漫长过程。由于云技术的出现彻底颠覆了IT资源交付与消费的方式,因此大家应当借此机会审议并回顾企业所采取的原有运作途径。而从另一个角度讲,云探索之旅也是一项变革管理实践,其将触及我们的技术、治理、岗位职能、组织结构以及众多其它业务层面。好消息是,已经有成千上万家企业成功完成了这段旅程,而我们完全可以从其身上汲取宝贵的经验。

下面我们一起来看帮助企业实现旅程成功的七项最佳实践:

1. 提供高层支持

自上而下的支持在推进变革方面极为重要——无论是在技术抑或文化层面。CIO/CTO的角色定位一直在不断演变,如今技术领导者则需要越来越多地承担起首席变革管理官(简称CCMO)的相关任务。要扮演好这一角色,技术管理者应当争取到企业高层的支持,同时立足于自身充当技术团队的后盾。这意味着根据预期结果设定明确目标、调整业务与技术手段并制定新的规则。我将在后续文章中对此详加阐述,并将在re:Invent大会上就这一议题进行探讨。(期待在现场与各位碰头!)

2.培训员工

人们在面对未知事物时往往会产生恐惧心理。一旦恐惧心理占据上风,人们则倾向于坚持自己所熟悉的作法,而这很可能给探索之旅造成阻碍。利用新技能武装员工能够有效缓解他们的紧张情绪。直接招纳拥有对应技能的新人才当然也很不错,但这种方式一般很难得到规模化实现。为员工提供学习专业知识的机会才是扩宽探索道路的最佳选择。

3.建立乐于实验的文化氛围

与本地环境相比,云环境下的实验成本明显低得多。云方案一般很少甚至完全不会带来任何前期投入要求,另外即使实验失败我们也不必压力太大。当着眼于建立实验项目时,大家不妨选择那些能够随时间推移切实为业务带来帮助的选项。有些企业倾向于以IT内部的单一方向作为出发点,也有些则同时推进多个项目。无论具体如何权衡,大家都应当确保对由此带来的成功或者失败保持积极心态。拥有了坚实的高管层支持作为基础,我们将能够逐步建立起这种乐于实验的文化氛围。

4.引入合作伙伴

大多数企业都需要借助一定数量的合作伙伴来实现IT交付。这些合作关系往往拥有不同的表现形式与具体规模,包括人员派遣、解决方案交付、管理服务、正版软件以及SaaS产品等等。每一家主要IT服务供应商都需要探索如何将云要素融入自身业务,也有不少甚至已经加入到AWS合作伙伴网络当中。大家可以审视自己的现有伙伴,思考其能为我们的探索之路带来哪些帮助,或者尝试选择那些自诞生起就一直立足于云环境的厂商。AWS乐于帮助大家在这方面做出探索,而且众多合作伙伴也已经将其解决方案纳入AWS Marketplace——我们可以在这里通过AWS获取并部署相关服务,从而显著降低采购流程的复杂性。

5.建立卓越中心

纵观自己的职业生涯,我发现应用交付团队与基础设施团队之间的关系往往比较紧张。虽然对这套系统的检查与制衡算是种日常工作,但随着新型技术元素的加入,情况正变得愈发复杂。由于云服务承担了大部分传统基础设施的日常任务,并开始以代码与自动化作为主要驱动核心,应用交付与基础设施团队间的界线变得更加模糊。通过探索之旅,企业将有机会重新审视不同部门间的边界与交互协议。大多数成功完成过渡的企业都会建立卓越云中心,旨在以制度化方式实现最佳实践、管理与自动化机制。举例来说,在道琼斯公司担任CIO时,我们通过DevOps团队建立实现方案,且高度专注于客户服务、“谁构建谁运行”理念并深刻理解新系统建立后的预期运行效果。

6.实现混合型架构

绝大多数企业的现有IT投资都能够继续为业务提供助益。每家企业也有着不同的传统与新型方案管理周期,因此变革之路绝非一夜之间即可实现。建立一套混合型架构将允许大家在充分发挥云服务优势的同时,继续保持对现有投资方案的运用能力。而在建立混合型架构方面,AWS的实践经验显然是最丰富的。因此在探索过程中,大家的卓越中心将能够快速建立并运行起混合架构,并直接实现对现有应用程序的强化与迁移。混合型架构能够有效拆分整体型应用并实现服务解耦,而这也是各大巨头级企业在进行现代IT升级中的必要一环。

7. 推行云优先策略

随着经验的逐步积累,企业最终将迈向新的临界点。在这里,大家会发现立足于云平台的IT体系将拥有超过内部模式的运作效率。为了百尺竿头更进一步,大家需要制定一项云优先策略,将IT项目考量中的思维重心由“为什么要使用云?”转换为“为什么不使用云?”这意味着我们将在企业中传递一项重要的信号,即优先利用云实现利益最大化,并将更多内部资源投入到核心业务层面。

如果大家对这一议题有着自己的见解,也请在评论中分享您的观点。

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

作者介绍

史蒂芬﹒奥本

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

优秀的领导者如何更进一步迈向伟大?

“明确性不足必然招致混乱与冲突。这类情绪对于任何目标而言都是一种严重的负面影响。”——史蒂芬·马拉布利

不同领导者的具体领导方式亦有所区别。有些领导者乐于以恐惧情绪实现约束,有些爱举例子,有些依靠人格魅力,也有一些以权力下放的方式层层管理。虽然每位领导者都拥有自己的独特风格,但经验告诉我们:乐于理解他人的领导者往往最受欢迎。

人们总是相信自己愿意相信的事物。而在变革管理方面,人们则更倾向于选择自己长久以来所熟悉的安全港,特别是他们发现自己无法理解领导者的管理方向时。为了解决这类问题,领导者应当提供明确而简洁的前进方向,而这种目标的明确性也成为判断一位领袖是出色还是伟大的重要标准。

我最近在文章中提到,技术高管人员应当将自己视为首席变革管理官(简称CCMO),从而在引导企业推进云技术探索之旅时发挥更为明确的作用。除了处理业务与技术的合并事务之外,CCMO还需要负责设定明确的发展目标。这意味着我们要有能力阐明战略,告知团队该如何适应这一战略,战略中的缺陷,同时高度关注且保持耐心。

企业往往出于不同理解选择云迁移——有些是为了节约成本,有些是为了进军全球市场,有些是为了提升安全性水平,也有一些是为了改善敏捷性。不过根据个人经验,我发现企业多半会在意识到云计算能够帮助自身为业务提供充裕资源时接纳这一全新平台。这类举措主要针对客户及其他利益相关者,而且除非大家身为基础设施供应商,否则这类转型一般与基础设施管理扯不上关系。

无论大家的起步动机着眼于短期还是长远,我都建议大家尽可能提高其透明度与可量化性。向团队明确传达变革的动机与目标能够帮助每一位成员都朝着正确的方向贡献力量并承担责任。

在我的职业生涯早期,我曾天真地认为老板说什么,员工们就一定会做什么。当然,残酷的现实给我好好上了一课,而我也意识到领导绝不能想当然地认为自己的观点能够为员工们所接受。每次向团队提出一个新的想法或者发展目标,我都需要考虑其中每个人对这项战略的适应能力,同时设想其会给企业乃至每个人的职业生涯带来怎样的影响。在这样的背景下,我必须抓住一切有利于观念普及的机会。

这意味着利用每次季会、内部博客、冲刺规划会议等平台作为讲堂,同时在会议当中立足于现有工作内容探讨战略设计。有时候大家可能觉得这种作法有些多余,但随着团队规模愈发庞大,我们就必须想办法让每位成员都有机会定期获取信息。持续关注并致力于沟通,这将成为策略推广的成功关键。

对未知的恐惧也是变革管理规程当中最为常见的问题之一。当我向企业员工推广云技术最佳实践时,每次都需要为此做好充分准备。值得一提的是,在这种情况下领导者应当采取一种“曲线救国”的方式,即并非直接面向摩擦本身,而是着眼于帮助大家立足于自身角色了解团队的当前状况。

如此一来,尽管未来方向总在不断变化,但人们亦凭借着清醒的认识而能够勾勒出清晰的前进路径。他们拥有更强的参与感,同时亦能够借此保持平静的心态。在道琼斯公司担任CIO时,我曾对部门内的每位成员进行培训,同时确保他们有机会担任企业内的其它职能角色。我们明确强调,我们希望每一位员工都能够切实参与到云技术探索之旅当中来,这有时候意味着他们可以接触一些前所未有的新鲜事务。这种面向不同领域或者涉及学科变更的体验能够充分调动员工们的积极性,也意味着他们能够利用自身知识储备充分展示自己。知识是最难以替代的,因此大家应当尽一切努力保持自己拥有丰富的知识储备。

无论采取怎样的变更策略,大家都能够从中发现一些固定不变的元素,其中一些甚至拥有很强的暗示性。将这些信息明确传达给团队,坦言我们可以选择继续在舒适区中继续重复过去,但同时也要强调企业的未来无疑在于不断学习。

在道琼斯公司,我们在云技术探索之旅的起始处就将自动化作为一切实现方案的硬性原则。一旦我们拥有充分的云运营技能,我们就能够说服财务部门批准将各类业务实例迁移至AWS旗下的数十座数据中心之内。到这里,“升级-调整-转型”战略就开始逐步成为运营思路的主体。但这项工作同样要求辅以明确的目标设定——我们需要不断沟通以确定传递信息的正确性。但一旦自动化机制部署完成并全面覆盖应用迁移工作,我们的进展将得以显著提速。

每家企业的云技术探索之旅都必须存在崎岖与坎坷。但我可以肯定地指出,一切都会慢慢好起来,而且整个业界也凭借着无数成功实例证明了这一结论。在AWS,我们致力于通过与客户间的合作提供更具针对性的规范; 不过必须承认,让这整个流程打造成交钥匙方案几乎不太可能。而且我发现,这一过程同时也是个很好的学习机会; 不要责备团队的决策失误(当然,同样的错误也不应出现两次)或者传播怀疑情绪,这些都会给最终目标带来不利影响。另外,别让那些总想躲在舒适区的家伙们影响了我们的判断——这并不容易,但耐心与毅力将助各位走向成功。

请记住,实践是检验真理的惟一标准。哪种方案最适合您?请不吝分享您的心得与体会。

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

作者介绍

史蒂芬﹒奥本

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