亚马逊AWS官方博客

本文将带您一步步完成一个利用Amazon EMR进行交互式数据查询的实例，过程包括数据的注入、数据的分析、结果的转存、以及将整个过程自动化的方法。其中涉及的EMR组件主要包括: Hive, Hadoop, presto, sqoop。除EMR外，涉及到的其他服务包括：S3, RDS. 本文所使用的数据源是cloudfront产生的日志。 在按照本文档进行操作之前，读者需了解S3,RDS并能够进行基本的S3,RDS的操作，读者需了解EMR的基本概念。以下是参考资料： 什么是EMR: Amazon Elastic MapReduce (Amazon EMR) 是一种托管数据分析服务的框架，提升企业、研究人员、数据分析师和开发人员轻松、经济高效掌控海量数据的能力。其当前版本中托管的服务包括：Hadoop, Zeppelin, Tez, Ganglia, HBase, Pig, Hive, Presto, ZooKeeper, Sqoop, Mahout, Hue, Phoenix, Oozie, Spark, Hcatalog. EMR让您专注于数据分析，无需担心费时的集群设置、管理或调整，也无需担心所需要的计算能力。 具体参考： https://aws.amazon.com/cn/documentation/elastic-mapreduce/ 什么是S3: Amazon Simple Storage Service (Amazon S3) 为开发人员和 IT 团队提供安全、耐用且高度可扩展的对象存储。S3 可为EMR提供文件存储服务。 具体参考：https://aws.amazon.com/cn/documentation/s3/ 什么是RDS: Amazon Relational Database Service (Amazon RDS) 是一种可让用户在云中轻松设置、操作和扩展关系数据库的 Web […]

(可用于测试AWS ELB、EC2、Auto Scaling、HA) 一群勤劳的小蜜蜂 很多时候我们需要进行负载均衡、Web服务器的并发式压力测试，但像Siege, JMeter等工具都是从一个源IP地址发送流量，这不能很好的模拟出对负载均衡的实际压测效果。这里将详细介绍如何快速部署一个分布式压测工具Bees with Machine Guns，模拟一组不同的IP（可自定义）地址进行压测，这可更加准确的模式实际生产场景。 （注：请合理、正确使用此工具，核对你要压测的目标，避免造成不必要的“攻击”行为。） 接下去将手把手教你如何快速搭建一组分布式的“勤劳的小蜜蜂”。 1. 启动Ubuntu EC2（Amazon Linux机器也支持） 启动成功 2. 连接启动完成的实例，例如 ssh -i “ubuntu-instance.pem” ubuntu@ec2-54-201-96-220.us-west-2.compute.amazonaws.com 3. 运行sudo apt-get install python-paramiko git 4. 进入到/tmp目录，然后下载bees源码，进入到bees目录，通过python安装。 ubuntu@ip-10-200-1-230:~$ cd /tmp ubuntu@ip-10-200-1-230:/tmp$ git clone git://github.com/newsapps/beeswithmachineguns.git ubuntu@ip-10-200-1-230:/tmp$ cd beeswithmachineguns ubuntu@ip-10-200-1-230:/tmp/beeswithmachineguns$ sudo python setup.py install 5. 进入到/home/ubuntu/目录，创建.boto文件 /home/ubuntu/ vim .boto 接着，然后输入credentials相关内容 [Credentials] aws_access_key_id=AKIAJOSWXXXXXXXXXX aws_secret_access_key=RI2h19QXXXXXXXXXXXXXXXXXXXXXXXX [Boto] ec2_region_name=us-west-2 ec2_region_endpoint=us-west-2.ec2.amazonaws.com #elb_region_name=us-west-2 […]

“对于需要先学后做的事，我们不妨边做边学。”——亚里士多德 今天的这份推荐清单也可被称为“我希望自己刚刚踏上云旅程时即已了解的十件事”。在道琼斯的工作经历让我意识到自己非常幸运——我们能够从其它企业身上学习经验，同时亦有机会在加入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)。  

“要证明一根棍子是歪的，最好的办法既非争论、亦非大加谴责——用一根直棍进行比较即可。”——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)。

“成功源自奉献。在前进道路中，我们所处、所行也许并不如意，但惟有远见及坚韧的意愿方可引导我们抵达终点。”——亚瑟小子 随着越来越多企业开始认真审视云方案，如今的IT领导者们也迎来了新的转型机遇，即同时立足于技术与业务层面推动企业发展。 至少如今的IT高管们需要支持企业的云技术探索之旅。高管支持正是我在之前文章中提到的七大最佳实践中的第一项，其它六项则分别为员工培训、建立实验文化、引入合作伙伴、建立卓越中心、实现混合型架构以及推行云优先策略。 结合实际经验，我发现IT高管们在企业探索云技术时往往关注三大主要领域。在今天的文章中，我们将共同了解这些领域及其相关细节。在下周召开的re:Invent大会高管峰会上，我还将就此议题组织对话，感兴趣的朋友不妨加入我们！ 需要强调的是，云探索之旅是一个迭代过程，而且需要投入大量时间。我们不仅需要转变企业的技术储备，更需要调整IT部门交付技术方案及实现业务价值的具体方式。云方案带来的技术转变与新的业务模式将帮助我们转变职能定位、财务分配、产品开发方法以及更多涵盖整个业务组织结构的元素。这同时也是IT高管们千载难逢的职业发展机遇，大家将最终决定业务改进效果以及企业在财务与竞争力之间的平衡关系。这意味着大家需要审视各类机制是否切实可行，同时建立最符合业务需求的环境。 在我看来，当下的IT高管们其实需要扮演首席变革管理官（简称CCMO）角色。技术已经不再作为业务的简单支持要素，我们需要了解技术的本质意义并根据持续升温的竞争形势与持续转变的技术方向管理企业内部的种种变革。立足于各行各业，CCMO都将需要领导并掌控发生在高管团队内部乃至其它领域的变化，同时果断执行管理工作。 要成为一名成功的CCMO，我认为以下三项职责最为重要： 合并业务与技术。云部署绝不只是技术转换那么简单，其同时亦带来了新的业务实现方式。每一位高管成员都应当对此保持高度关注，同时了解每项具体功能会给整个云探索旅程带来怎样的影响。其中既包含明确的积极成果（财务、敏捷性以及全球扩展能力等等），亦会带来一系列挑战（人员招聘、培训以及对未知的恐惧等）。为了切实建立起能够满足每一位高管需求的、不断变化的IT环境，我们首先需要深入理解这些目标与挑战，而后思考如何简化目标实现流程并应对其间可能出现的种种挑战。 提供明确的目标。考虑到将技术与业务相结合的重要意义，大家也应当调整团队角色定位以帮助他们了解自己最适合的施展平台——特别是在推动业务发展方面。在我个人的早期高管从业经历中，我曾经天真地认为只要发出明确的指令，大家就能严格遵循其中的要求。残酷的事实告诉我，只有不断重复传达内容，员工们才能够准确依从并坚持贯彻。总结来讲，云技术为员工带来了大量新的发展机遇，而且只要他们乐于学习，那么将有无数新的业务贡献方式供他们选择。 制定（打破）新规则。 大部分传统IT运营模式并不允许大家充分发挥云技术所能带来的全部潜力。面对Uber、AirBnB、DropBox以及其它众多创新型企业不断创造新技术及实现快速运营的时代背景，大家必须致力于制定新规则以保证自身企业不致被时代所淘汰。而这项工作则能且只能由IT高管人士完成。另外，必须立足于企业结构的各个层面防止一切违规状况。 在未来几周当中，我将进一步就这三点内容展开探讨。如果大家在这方面拥有心得及体会，也不吝加以分享！ 革命尚未成功，同志仍须努力！ 作者介绍 史蒂芬﹒奥本 史蒂芬·奥本 (Stephen Orban) 于 2014 年9月加入亚马逊AWS 担任企业战略总经理。奥本与多名企业技术高管合作，在云如何实现业务成果、加快创新和简化流程方面进行经验和战略分享。在加入亚马逊AWS 之前，奥本曾在道琼斯担任首席信息官 (CIO)一职，他通过借力 AWS 和其他软件即服务 (SaaS) 合作伙伴，引入现代软件开发方法、实现降低成本、执行云优先政策。这些转型变革加快了产品开发周期并提高了全部业务线的生产能力，这其中就包括《华尔街日 报》、MarketWatch.com、道琼斯通讯社及Factiva。奥本还曾在彭博有限合伙公司(Bloomberg LP)工作 11 年，并且在股权和消息平台担任不同的领导职务；2008 年，奥本创建彭博体育（Bloomberg Sports）并担任首席技术官 (CTO)。

“教育是最有力的武器，你可以利用其改变世界。”——纳尔逊·曼德拉 能够有机会与高管同行们就业务及IT发展战略开展合作，我一直感到非常幸运。每个行政机构及商业企业都面临着独特的挑战，但他们亦配备有出色的工作人员及技能储备来解决这些问题，从而帮助组织整体向未来的愿景推进。同样的道理当然也适用于云计算。而且几位高管人员在交流中向我反复强调，缺少云技能人才正是他们很难开展云技术探索之旅的主要原因。 在此前的文章中我曾经提到过七条云转型最佳实践，而员工培训正是其中的第二项重点。员工培训能够把抱有怀疑态度的成员转化为真正的新技术支持者，他们也将贡献自己的力量确保云计算的强大优势切实为我们的企业带来巨大收益。 我们需要的其实就在眼前 人们对未知感到恐惧，而变化则让人感到焦虑。而教育正是我们手中最强大的武器，足以帮助员工克服恐惧情绪。另外，大家也可以通过吸引人才解决部分紧急问题，但这种方式往往很难形成规模。 大多数企业已经拥有非常丰富的组织文化、知识储备与思维传统。利用这些积淀，各企业完全可以立足于自身情况帮助员工灵活地学习云技术以及部署途径。换句话说，每个人都需要承认云技术的客观存在，并以此为基础接受及提升自身水平。 在这里，我建议各位高管人士通过以下几项要点帮助员工尽快掌握云技术。从原则上讲，我一般不会在文章中提到具体的AWS服务或者解决方案，但这里提供确切选项显然有助于大家更好地理解这一思路。我相信大家也能找到更多可行方案，希望各位不吝分享您的心得与体会！ AWS培训与认证 AWS的自我指导与教师指导型培训课程能够帮助大家的团队快速上手，并随着时间推移不断紧跟技术发展节奏。在这里我就不赘述课程的具体内容了，但可以肯定的是，我所接触的每家采用该指导课程的企业都得以更好地利用云服务。另外，大多数原本存在摩擦与冲突的团队都在接受培训后顺利解决了问题。 在道琼斯公司工作时，我们对团队内的几乎每一位技术人员进行培训，并引导他们接受AWS技术基础课程。随着时间推移，越来越多的员工也开始意识到这项课程的重要意义。 我们最终将训练工作形成制度。我们的DevOps团队开始组织“DevOps日”活动，企业中的其他员工则可以在这里了解最佳实践、框架以及治理模式等我们以云为基础开发出的解决方案。 这种基础型教育能够为员工的日常工作方式带来极具现实意义的影响，同时帮助我们巩固起以云计算作为未来发展基础的文化背景。另外，培训工作也让我们顺利克服了过渡过程中出现的种种障碍。举例来说，参与了DevOps日活动的员工很难在工作当中将云方案彻底抛诸脑后。不仅是我们，其它众多大型企业也采取了类似的实现道路——他们亦在利用AWS培训与认证机制帮助团队建立及扩展适合自身需求的培训项目。 如果大家发现员工对此存在抵触情绪，不妨与他们分享来自indeed.com网站的技能与职位统计结果。 云技能与职位数量呈现出明确的正比关系，而且短时间内这种趋势毫无消失的迹象。因此几乎可以肯定地说，云培训将在未来多年当中为企业自身及员工带来显著收益。 利用生态系统 尽管作为企业云技术探索之旅的领导者，大家并不一定需要独力完成所有工作，特别是在员工教育方面。与同业人员进行交流，参与云技术相关会议，同时积极了解其它企业的实践方案。云技术生态系统的增长速度极为惊人，亦有众多自诞生起就利用云技术支撑企业的初创企业存在。我们可以通过网络获取到大量可资借鉴的宝贵信息，而这些也将成为大家自身企业顺利发展的有力指导。 AWS合作伙伴网络正是浏览生态系统的途径之一，其中亦包含大量值得学习的资源。无论大家是希望找到一款工具以解决特定需求，还是希望物色合作伙伴以完成大规模迁移，这里都能够提供丰富的可行选项。大家也可以联系自己的AWS客户经理，由他们推荐理想的可选方案。我将在接下来的系列文章中就此加以探讨。 最后但同样重要的是，AWS专家服务已经帮助成百上千位高管人士准确了解到执行云战略所必需的角色及技能。AWS专家服务团队会评估企业的现有准备情况，并帮助其获取最为急需的AWS使用经验，而且其实际效果已经得到数百家同类企业的验证。通过这些推进举措，AWS专家服务建立起AWS云实施框架，任何企业皆可免费使用并作为将自身组织向云运营模式转移的参考资源。 经验的作用不可替代 我还没见过任何一家企业能够在不必借助任何帮助的前提下搞定云迁移所需要的人才与技能需求。虽然大多数管理人员都能够凭借设想解决不少实际问题，但缺少实践经验将使大家的推进道路举步维艰。 培训当然是帮助员工掌握新概念并了解相关实例的理想方式，但我仍然认为经验才是最好的老师。因此，大家应当确保团队有机会亲自上手并通过时间磨练自己的业务与云技术结合技能。我们可以要求员工们建立一个网站，面向部分数据构建API，托管一套维基页面或者建立其它一些能够与当前业务相契合的项目。实践活动往往能让团队快速成长。需求乃创新之母，我也亲眼见证了众多团队在目标明确且工具到位的情况下仅利用极短时间就拿出了惊人的成果。 这些实践经验最终也将转化为足以改变游戏规则的创新方案，或者构成可资借鉴的未来培训素材。无论如何，实践活动都将帮助大家顺利推进议程，同时帮助团队在学习中快速成长。 革命尚未成功，同志仍须努力！ 作者介绍 史蒂芬﹒奥本 史蒂芬·奥本 (Stephen Orban) 于 2014 年9月加入亚马逊AWS 担任企业战略总经理。奥本与多名企业技术高管合作，在云如何实现业务成果、加快创新和简化流程方面进行经验和战略分享。在加入亚马逊AWS 之前，奥本曾在道琼斯担任首席信息官 (CIO)一职，他通过借力 AWS 和其他软件即服务 (SaaS) 合作伙伴，引入现代软件开发方法、实现降低成本、执行云优先政策。这些转型变革加快了产品开发周期并提高了全部业务线的生产能力，这其中就包括《华尔街日 报》、MarketWatch.com、道琼斯通讯社及Factiva。奥本还曾在彭博有限合伙公司(Bloomberg LP)工作 11 年，并且在股权和消息平台担任不同的领导职务；2008 年，奥本创建彭博体育（Bloomberg Sports）并担任首席技术官 (CTO)。

知识补充： 什么是AWS Lambda？ AWS Lambda在可用性高的计算基础设施上运行您的代码，执行计算资源的所有管理工作，其中包括服务器和操作系统维护、容量预置和自动扩展、代码监控和记录，只在需要时执行您的代码并自动缩放，从每天几个请求到每秒数千个请求，其提供了AWS基础设施的高可用性，高安全性，高功能性和高可扩展性。 具体可参考: https://docs.aws.amazon.com/zh_cn/lambda/latest/dg/welcome.html 什么是Alexa Skills Kit？ Alexa是Echo内置的语音助手，通过它能够唤醒Echo。Alexa的优点在于，它基于云端，因此我们可以随时对其进行改进。Alexa Skills Kit (ASK)是一个由自服务API、工具、文件和实例代码的集合，可轻松构建你自定义的Alexa skills，然后发布。 具体可参考: https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit 1. 打开链接https://aws.amazon.com/，申请亚马逊AWS账号。登录控制台，选择AWS Lambda服务，创建Lambda Function。 2. 选择Alexa Skills Kit 3. 下载需要用到的代码，解压，打开index.js文件，修改文件中的开发者账号ID，如下： https://s3.cn-north-1.amazonaws.com.cn/bjsdemo/LambdaAlexaSkillsKit/RecipeTemplate.zip 修改完成之后，然后打成Zip包上传（注意，这里的打包不需要文件夹，直接把.js文件打包成RecipeTemplate.zip） 接着点击“Create function” 到这里，Lambda 创建成功。 4. 进入https://developer.amazon.com/，创建Alexa Skills Kit。 选择ALEXA 5. 选择“Alexa Skills Kit” 6. 点击“Add a new Skill” 7. 填写Name: Solution Helper，Invocation Name: solution helper 8. […]