亚马逊AWS官方博客

AWS Team

Author: AWS Team

程序员的深度学习入门指南

本文根据费良宏在2016QCon全球软件开发大会(上海)上的演讲整理而成。 今天我想跟大家分享的话题与深度学习有关。事实上,深度学习本身是一个非常庞大的知识体系。今天的内容,不会涉及深度学习的理论知识,更多想从程序员的视角出发,让大家观察一下深度学习对我们程序员意味着什么,以及我们如何能够利用这样一个高速发展的学科,来帮助程序员提升软件开发的能力。 前言 1973年,美国上映了一部热门的科幻电影叫做《Westworld》,三年之后又有一个续集叫做《Futureworld》。这部电影在80年代初被引进到中国叫《未来世界》。那部电影对我来讲简直可以说得上是震撼。影片中出现了很多机器人,表情丰富的面部下面都是集成电路板。这让那时候的我觉得未来世界都是那么遥远、那么样的神秘。时间转到了2016年,很多朋友可能都在追看HBO斥巨资拍摄的同一个题材的系列剧《Westworld》。如果前两部电影还是局限在机器人、人工智能这样的话题,2016年的新剧则在剧情、以及对于人工智能的思考方面有了很大的突破。不再渲染机器人是否会威胁到人类,而是在探讨 “Dreams are mainly memories“这一类更具哲理的问题。记忆究竟如何影响了智能这个话题非常值得我们去思考,也给我们一个很好的启示 – 今天,人工智能领域究竟有了怎样的发展和进步。 今天我们探讨的话题不仅仅是简单的人工智能。如果大家对深度学习感兴趣,我相信各位一定会在搜索引擎上搜索过类似相关的关键字。我在Google上以deep learning作为关键字得到了2,630万个搜索的结果。这个数字比一周之前足足多出了300多万的结果。这个数字足以看得出来深度学习相关的内容发展的速度,人们对深度学习的关注也越来越高。 从另外的一个角度,我想让大家看看深度学习在市场上究竟有多么热门。从2011年到现在一共有140多家专注人工智能、深度学习相关的创业公司被收购。仅仅在2016年这种并购就发生了40多起。其中最疯狂的是就是Google,已经收购了 11 家人工智能创业公司,其中最有名的就是击败了李世石九段的 DeepMind。排名之后的就要数 Apple、Intel以及Twitter。以Intel 公司为例,仅在今年就已经收购了 3 家创业公司,Itseez、Nervana 和 Movidius。这一系列大手笔的并购为了布局人工智能以及深度学习的领域。 当我们去搜索深度学习话题的时候,经常会看到这样的一些晦涩难懂的术语:Gradient descent(梯度下降算法)、Backpropagation(反向传播算法)、Convolutional Neural Network(卷积神经网络)、受限玻耳兹曼机(Restricted Boltzmann Machine)等等。如你打开任何一篇技术文章,你看到的通篇都是各种数学公式。大家看到下面左边的图,其实并不是一篇高水准的学术论文,而仅仅是维基百科关于玻耳兹曼机的介绍。维基百科是科普层面的内容,内容复杂程度就超过了大多数数学知识的能力。 右边的那张图则是深度学习很流行的深度学习框架Theano 的一个简单的例子。对于大多数程序员而言学习这一类框架和程序代码的时候更让人抓狂,大段代码我们完全不明就里。我们看到的很多概念,对很多程序员来说觉得非常陌生,所以这确实是对程序员的一个很大的挑战。 在这样的背景之下,我今天的的话题可以归纳成三点:第一,我们为什么要学习深度学习;第二,深度学习最核心的关键概念就是神经网络,那么究竟什么是神经网络;第三,作为程序员,当我们想要成为深度学习开发者的时候,我们需要具备怎样的工具箱,以及从哪里着手进行开发。 为什么要学习深度学习 首先我们谈谈为什么要学习深度学习。在这个市场当中,最不缺乏的就是各种概念以及各种时髦新技术的词汇。深度学习有什么不一样的地方?我非常喜欢Andrew Ng(吴恩达)曾经用过的一个比喻。他把深度学习比喻成一个火箭。这个火箭有一个最重要的部分,就是它的引擎,目前来看在这个领域里面,引擎的核心就是神经网络。大家都知道,火箭除了引擎之外还需要有燃料,那么大数据其实就构成了整个火箭另外的重要组成部分——燃料。以往我们谈到大数据的时候,更多是强调存储和管理数据的能力,但是这些方法和工具更多是对于以往历史数据的统计、汇总。而对于今后未知的东西,这些传统的方法并不能够帮助我们可以从大数据中得出预测的结论。如果考虑到神经网络和大数据结合,我们才可能看清楚大数据真正的价值和意义。Andrew Ng就曾经说过“我们相信(神经网络代表的深度学习)是让我们获得最接近于人工智能的捷径”。这就是我们要学习深度学习的一个最重要的原因。 其次,随着我们进行数据处理以及运算能力的不断提升,深度学习所代表的人工智能技术和传统意义上人工智能技术比较起来,在性能上有了突飞猛进的发展。这主要得益于在过去几十间计算机和相关产业不断发展带来的成果。在人工智能的领域,性能是我们选择深度学习另一个重要的原因。 这是一段Nvidia 在今年公布的关于深度学习在无人驾驶领域应用的视频。我们可以看到,将深度学习应用在自动驾驶方面,仅仅经历了3千英里的训练,就可以达到什么样的程度。在今年年初进行的实验上,这个系统还不具备真正智能能力,经常会出现各种各样的让人提心吊胆的状况,甚至在某些情况下还需要人工干预。但经过了3千英里的训练之后,我们看到在山路、公路、泥地等各种复杂的路况下面,无人驾驶已经有了一个非常惊人的表现。请大家注意,这个深度学习的模型只经过了短短几个月、3千英里的训练。如果我们不断完善这种模型的话,这种处理能力将会变得何等的强大。这个场景里面最重要的技术无疑就是深度学习。我们可以得出一个结论:深度学习可以为我们提供强大的能力,如果程序员拥有了这个技术的话,无异于会让每个程序员如虎添翼。 神经网络快速入门 如果我们对于学习深度学习没有任何疑虑的话,接下来就一定会关心我需要掌握什么样的知识才能让我进入到这个领域。这里面最重要的关键技术就是“神经网络”。说起“神经网络”,容易混淆是这样两个完全不同的概念。一个是生物学神经网络,第二个才是我们今天要谈起的人工智能神经网络。可能在座的各位有朋友在从事人工智能方面的工作。当你向他请教神经网络的时候,他会抛出许多陌生的概念和术语让你听起来云里雾里,而你只能望而却步了。对于人工智能神经网络这个概念,大多数的程序员都会觉得距离自己有很大的距离。因为很难有人愿意花时间跟你分享神经网络的本质究竟是什么。而你从书本上读的到的理论和概念,也很让你找到一个清晰、简单的结论。 今天就我们来看一看,从程序员角度出发神经网络究竟是什么。我第一次知道神经网络这个概念是通过一部电影—1991年上映的《终结者2》。男主角施瓦辛格有一句台词:“My CPU is a neural-net processor; a learning computer.“(我的处理器是一个神经处理单元,它是一台可以学习的计算机)。从历史来看人类对自身智力的探索,远远早于对于神经网络的研究。1852年,意大利学者因为一个偶然的失误,将人类的头颅掉到硝酸盐溶液中,从而获得第一次通过肉眼关注神经网络的机会。这个意外加速了人对人类智力奥秘的探索,开启了人工智能、神经元这样概念的发展。 生物神经网络这个概念的发展,和今天我们谈的神经网络有什么关系吗?我们今天谈到的神经网络,除了在部分名词上借鉴了生物学神经网络之外,跟生物学神经网络已经没有任何关系,它已经完全是数学和计算机领域的概念,这也是人工智能发展成熟的标志。这点大家要区分开,不要把生物神经网络跟我们今天谈到的人工智能有任何的混淆。 神经网络的发展并不是一帆风顺的,这中间大概经历了三起三折的过程。 大约在1904年,人类已经对人脑的神经元有了最初步的认识和了解。1943年的时候,心理学家麦卡洛克 (McCulloch) 和数学家 Pitts […]

Read More

AWS的在线云计算专家,你用了吗?

我们在享受AWS云计算带来的弹性、灵活、高可用、按需使用等优点的同时,相信运维开发人员及商务决策者们会越来越多地关注如何在云上实现成本、安全、性能和容错方面的优化。今天为大家隆重介绍一位就在你身边的AWS在线云计算专家,希望给大家一些最直接的帮助。 ——-专家简介—- AWS Trusted Advisor有着丰富的云计算疑难病症的临床经验,并总结了大量的最佳实践。他会实时帮你从成本优化、安全、性能和容错四个大的方面诊断AWS帐户的健康状况并推送检查结果和建议。 ——–专家支招——- 第一招:免费检查项   对象:所有支持级别 1. 是否有过于宽松的端口安全组设置 2. 是否使用AWS Identity and Access Management (IAM)来进行用户身份和权限管理 3. 是否在根帐户上启动了Multi-Factor Authentication (MFA)加强帐户安全 4. 各服务当前使用量是否接近限额需要联系AWS小伙伴进行限额提升 注:北京区域目前提供服务限制和安全组 – 特定端口不受限制两项 第二招:全套检查项   对象:商用和企业级别支持服务 商用和企业级别支持服务客户可以享受全套检查项(截至到发文止,共54个检查项,还会不断增加),横跨成本优化、安全、性能和容错四个大类。 9个成本优化检查项 15个安全检查项 19个容错检查项 11个性能检查项 *为北京区域目前可用的检查项 第三招:支持API方式获取检查建议和数据 对象:商用和企业级别支持服务 这招比较适合技术咖了,可以用程序的方式获取Trusted Advisor的检查建议及数据。 戳以下链接了解Trusted Advisor (TA)以及AWS支持计划! 全球区域: https://aws.amazon.com/premiumsupport/trustedadvisor/ https://aws.amazon.com/premiumsupport/compare-plans/ 北京区域: http://www.amazonaws.cn/support/trustedadvisor/ http://www.amazonaws.cn/support/support-plans/  

Read More

Amazon CloudFront常见错误配置及解决方法

很多的用户在最初使用CloudFront做Web类内容分发的时候遇到无法调通的情况,本文总结了用户在配置过程中遇到的常见错误,内容涵盖了大部分用户遇到的情况。 错误一  源访问权限未放开 这种错误常见于用S3做源的情况, 引起这种错误的原因是s3的访问控制没有对CloudFront开放。从浏览器中返回的错误通常类似于下图: 更具体些,可分为以下两个场景: 场景1. CloudFront使用了Restrict Bucket Access 在创建distribution的时候选择了Restrict Bucket Access 为yes, 但 Grant Read Permissions on Bucket, 选择的是”No, I Will Update Permissions”, 而用户事后却没有在s3的桶里更新policy。如下图所示。 解决方法: 方法1, 在S3中增加桶的策略,使该桶允许该CloudFront访问,以下是policy示例,其中标黄部分需要替换成用户自己的信息。 {                 “Version”: “2008-10-17”,                 “Id”: “PolicyForCloudFrontPrivateContent”,                 “Statement”: [                                 {                                                 “Sid”: “1”,                                                 “Effect”: “Allow”,                                                 “Principal”: {                                                                 “AWS”: “arn:aws:iam::CloudFront:user/CloudFront Origin Access […]

Read More

VPC中NAT的那点事

NAT就在那里 下图 是EC2实例通过IGW(Internet网关) 接入到Internet的示意图。熟悉AWS的读者会知道,这里EC2实例和Internet通信的两个方向上,实际上发生了如下的转换: 从EC2实例发出的前往Internet的IP包,其源地址10.0.0.10在经过IGW时,会被转换为与实例关联的公网地址 54.232.0.1; 从Internet发给54.232.0.1的IP包,经过IGW时其目的地址会转换为ENI对应的内网地址10.0.0.10并被送到 EC2实例; 可以看到,这里Internet网关就是起到实例的内网地址和公网地址一对一的基本 NAT(网络地址转换)的功能。 相比于没有NAT的场景,大部分的应用、软件不需要任何改变就能在基本NAT的场景下继续工作,例如基于HTTP协议的Web应用等;但是对于某些应用,例如FTP、VoIP等,网络地址转换会给应用带来一些意想不到的挑战。今天我们以历史悠久的FTP协议为例,来和大家探讨一下NAT给FTP这样的应用带来什么样的挑战,以及FTP应用和协议又是如何演进去适应它。 被动模式下的FTP 我们重温一下FTP的工作过程。客户端连接服务端TCP 21端口建立命令通道后,输入用户名密码完成登录;随后的每一次数据传输都需要另外建立数据通道进行; 如果数据通道由客户端发起,服务端接受,我们称之为被动模式;反之,如果数据通道由服务端发起,客户端接受,则称之为主动模式。 为简化讨论,我们以被动模式为例。 同一个私网内 我们在EC2实例10.0.0.10上搭建了一台FTP服务器,它监听在21端口。现在我们从同一个VPC里的另外一台EC2上运行FTP客户端;那么整个过程会很顺利。 从Internet访问 现在我们从位于Internet某处的一台PC上运行FTP客户端。 这里连接超时的原因显而易见,FTP服务端发送给客户端的IP地址是服务端的私有地址。位于Internet上的客户端无法建立与位于VPC内部的私有地址10.0.0.10直接通讯。 解决这个问题有多种方法,我们由简单到复杂分别叙述。 增强协议适配NAT FTP协议针对NAT和其他因素,对协议进行了增强,提供了增强版的被动模式EPSV命令[1]。 下面的例子里,服务端不再显式指定IP地址,只提供数据通道的端口号。客户端默认与控制通道相同的IP地址建立数据通道。 可以看到,解决方案很优雅。实际上如果你在阅读本文的时候,绝大部分FTP服务端和客户端都已经实现了EPSV,而且优先使用它,所以FTP应用目前在EC2上是可以称之为开箱即用的。当然这需要客户端和服务端都支持增强的协议才能达成;如果我们不修改协议,能否解决这个问题呢。 放开那协议!我来! 有些时候,修改协议和实现需要多方协调和很长的时间才能完成。在RFC2428标准化之前,一些FTP实现就已经通过修改实现来适配基本NAT,而非修改协议。 以vsftpd为例,它允许通过配置文件vsftpd.conf中的配置项 pasv_address=54.232.0.1 告知服务端,在PASV被动模式下,应当指示客户端连接到配置项指定的IP(而不是服务端的私有IP)来适配基本NAT。 其他的一些常见应用例如VoIP类应用,也有类似的机制去适配基本NAT;例如引入STUN/TURN/ICE等方式[2]适配各种更加复杂的NAT穿越场景;但是针对部署在EC2上的基本NAT环境,也有通过实现上的简单调整,例如开源VoIP应用Asterisk就支持通过在配置文件/etc/asterisk/sip.conf里指定本机的公网地址和本地网段的方式来适配基本NAT。 nat=yes externaddr=54.223.0.1 localnet=10.0.0.0/16 协议和实现我都不想动! 作为一枚任性的读者,如果您既不想动协议也不想动实现,这里笔者给读者介绍一种剑走偏锋的方式,读者若有兴趣,可以轻松愉快的在AWS上试一试,看看能否解决你的应用适配基本NAT。下面是一段shell脚本,当然是运行在Linux操作系统上的。           #从EC2 实例元数据服务获取本实例的公网IP(如有)、私网IP           public_ipv4=`curl -s http://169.254.169.254/latest/meta-data/public-ipv4`           local_ipv4=`curl -s http://169.254.169.254/latest/meta-data/local-ipv4`           #配置私网地址段,这里应为EC2实例所在VPC的地址范围           local_net=10.0.0.0/16           if [ […]

Read More

Amazon CloudWatch Events监控您应用的安全

每个应用程序时刻都在产生事件,Amazon CloudWatch Events能帮助您针对应用的事件进行有针对性的响应和处理,及时响应,并处理错误事件,存储和分析潜在的告警信息。在接下来的篇幅里,我将利用AWS的CloudWatch Events,Lambda,SNS,SQS等服务向您展示如何及时分析与处理应用事件。 在这个场景中,我将应用事件划分分三个等级(当然,在您的具体业务场景中,您可以根据实际情况划分任意多的等级),Green,Yellow,Red。Green代表应用正常,您不需要进行任何动作。Yellow表示您应用的健康检查失败,通过Lambda来处理该类型事件。Red表示您的应用在至少一台服务器上已经失败,立即通知运维部门处理。 以下是该场景中的架构示意图: 1. 最左边为您的应用服务器群,他们将各自的事件发送给CloudWatch Events; 2. 在CloudWatch Events中设置Rule来进行区分,并将对应的事件发送相应的目标,如Lambda,SNS,SQS; 3. 目标在收到事件后进行相应的处理; 具体步骤: 1.   创建3个目标,Lambda,SNS,SQS; 1.1, 目标1,创建Lambda函数,SampleAppDebugger; 1.2, 目标2,创建SNS主题,RedHealthNotifier; 1.3, 目标3,创建SQS消息队列,ReportInspectionQueue;   2.   创建CloudWatch Events Rule 2.1, 将以下内容保存为YellowPattern.json; 2.2, 使用以下命令创建名为myCustomHealthStatusYellow的规则; 2.3, 使用以下命令创建目标; 2.4, CloudWatch Event需要将事件发送给Lambda,所以需要给Lambda添加适当权限允许CloudWatch这么做; 3.   重复上面的步骤创建第2条规则,并设置目标为SQS和SNS,特别注意,不要忘记给SNS,SQS设置相应权限以允许CloudWatch发送事件过来; 3.1, 使用以下命令创建名为myCustomHealthStatusRed的规则,这里的RedPattern.json文件其实是将2.1步骤中的YellowPattern.json是一样的,只是将内容中的Yellow替换成了Red; 3.2, 创建两个目标,SQS,SNS; 3.3, 添加权限允许CloudWatch Events发送事件; 其他SNS,SQS权限设置相关,请参考该官方链接:http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/events/resource-based-policies-cwe.html#sns-permissions 4.   进行测试,手动放入一些Red事件(我设置了个小脚本,每次运行都会放入61个事件),看看SQS及SNS情况; 这里我运行了三次脚本,所以SQS中有183条消息 看看邮箱中是否会收到邮件 5.   测试Yellow事件及Lambda反应; Lambda被触发的次数 作者介绍: […]

Read More

手把手教你使用Amazon EMR进行交互式数据查询

本文将带您一步步完成一个利用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 […]

Read More

手把手教你快速部署流量压测工具 – Bees with Machine Guns

(可用于测试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 […]

Read More

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

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

Read More

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

“无论有何规则,我都自由无碍。在可容忍时容忍,在无法容忍时将规则打破。我享有自由,因为我愿为自己的一切行为承担道德责任。”——罗伯特·海因莱因 出色的领导者执行规则,而伟大的领导者则能敏锐地察觉到不再适用的旧有规则并将其打破。正如海因莱因所提到,新规则的制定实际上必然伴随着旧有规则的淘汰。但要成为能够影响整家企业的伟大领导者,我们首先需要深入理解现有规则,而后决定是否及何时对其加以变更。 在企业推进云技术探索旅程的过程中,技术领导者亦将迎来制定新规则的绝佳机遇。我个人甚至更倾向于技术高管的角色描述为“首席变革管理官”(简称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)。

Read More

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

“生命是一场旅程。当我们驻足时,一定是事情出了差错。”——方济各 去年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)。

Read More