Author: AWS Team


使用Oracle Data Pump将数据库迁移到AWS的RDS Oracle数据库

1.Oracle数据库的迁移方法

如何将Oracle数据库从数据中心迁移到AWS云上是DBA经常遇到的问题,迁移Oracle数据库有多种方式:

(1)使用AWS DMS服务迁移

(2)使用Oracle SQL Developer迁移

(3)使用Oracle Data Pump迁移

(4)使用Oracle Export/Import迁移

(5)使用Oracle SQL Loader迁移

如果需要了解不同的迁移方法,可以参考 博客《Oracle数据库迁移到AWS云的方案》 。

2.使用Oracle Data Pump迁移

本文主要讨论使用Oracle Data Pump将Oracle数据库迁移到RDS数据库。示例数据库的信息如图。

 

下面是模拟在数据中心的Oracle11g源数据库中创建用户和表,并将源数据库迁移到AWS云中RDS Oracle 11g数据库的全过程。

步骤一:初始化源数据库并使用Data Pump导出

(1)使用SQL Plus登录源Oracle数据库

sqlplus / as sysdba

(2)创建用户test

create user test identified by welcome1;

(3)为新创建用户grant权限(实际使用请给用户grant合适的权限)

grant dba to test;

(4)为用户test创建表

create table test.aa(id varchar(20) not null primary key,name varchar2(30));

(5)为表插入数据并commit

SQL> insert into test.aa values(‘1111′,’1111name’);

1 row created.

SQL> insert into test.aa values(‘2222′,’2222name’);

1 row created.

SQL> commit;

Commit complete.

(6)在源数据库所在的Linux上逐级创建下面文件目录

mkdir /home/oracle/datapump/datafiles

(7)在SQLPlus中创建数据库Directory

create directory dpump_dir as ‘/home/oracle/datapump/datafiles’;

grant read,write on directory dpump_dir to test;

(8)使用expdp命令导出test用户的所有表

expdp test1/welcome123 directory=dpump_dir dumpfile=test.dmp

expdp test1/welcome123 directory=dpump_dir dumpfile=test1.dmp

步骤二:使用SQL Plus连接RDS数据库,并创建数据库目录对象

(1)在源数据库上配置RDS数据库的tnsnames

cd $ORACLE_HOME/network/admin

vi tnsnames.ora

输入tnsnames的内容如下:

ORARDS=(description=(address_list=(address = (protocol = TCP)(host =    RDS_HOST_NAME)(port = RDS_PORT)) )(connect_data =(SID=RDS_SID)))

(2)使用SQLPLUS连接远程RDS数据库

sqlplus oracle/welcome1@ORARDS

(3)使用tnsping检查RDS连接信息

如果连接有错误,可以使用下面命令查看通讯是否正常

tnsping “(description=(address_list=(address = (protocol = TCP)(host = RDS_HOST_NAME)(port = RDS_PORT)))(connect_data =(SID= RDS_SID)))”

tnsping应该返回“OK (xx msec)”类似文字。

如果tnsping不通请检查RDS对应的security group,RDS的security group中应当允许当前服务器通过TCP协议访问RDS数据库的端口。

(4)创建目标RDS的directory对象

exec rdsadmin.rdsadmin_util.create_directory(‘dpump_dir1’);

创建成功后退出连接RDS的SQL Plus客户端。

步骤三:将源数据库Data Pump导出的文件上传到RDS数据库

(1)连接源数据库并创建database link

create database link to_rds connect to oracle identified by welcome1 using ‘(description=(address_list=(address = (protocol = TCP)(host = RDS_HOST_NAME)(port = RDS_PORT)))(connect_data =(SID=RDS_SID)))’;

(2)运行DBMS_FILE_TRANSFER包将数据传输到RDS服务器的目录

BEGIN

DBMS_FILE_TRANSFER.PUT_FILE(

source_directory_object       => ‘dpump_dir1’,

source_file_name              => ‘test.dmp’,

destination_directory_object  => ‘dpump_dir1’,

destination_file_name         => ‘test.dmp’,

destination_database          => ‘to_rds’

);

END;

步骤四:通过impdp命令将远程的RDS数据库文件导入

(1)在源数据库服务器上运行impdp命令导入数据

impdp  oracle@ORARDS dumpfile=test.dmp directory=dpump_dir1 full=y

执行完毕检查test用户和相关的表。

3.    总结

从上面的过程我们可以看到,将一个Oracle数据库迁移到RDS的过程并不复杂,如果源数据库很大,由于需要导出数据、将数据上传到RDS的Data Pump目录、导入数据,迁移的过程也会比较长。上述过程假设了我们生产数据库的业务有足够的停机时间,在迁移过程中数据不会变化。如果迁移过程中,源数据库会发生变化,那么我们就需要同步数据中心和RDS数据库间的日志了。

如果源数据库很大,我们也可以在AWS上启动一台中间服务器,并在中间服务器上安装Oracle的客户端软件,将源数据库的Data Pump导出文件分片然后scp复制、Tsunami UDP加速上传等方式将文件上传到中间服务器,然后上传到RDS的Data Pump目录,这样能加速迁移的过程。

作者介绍:

蓝勇

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

使用AWS的数据库迁移DMS服务

前面博客《Oracle数据库迁移到AWS云的方案》介绍了AWS数据库迁移的几种基本方法,本文主要介绍如何使用AWS的DMS服务完成数据库的迁移。

1.DMS服务介绍

为了使用户更容易的将数据库迁移到云中,AWS已经在海外区域推出了AWS Database Migration Service服务,如果您的数据库在海外,DMS可以在源数据库不停机的情况下,帮您将数据迁移到AWS云中。DMS的功能非常强大,支持同构数据库的迁移(如Oracle迁移到Oracle),也支持异构数据库直接的迁移,如Oracle到Mysql等)。在数据库迁移期间,源数据库无需停机,并且能将迁移期间数据的更改持续复制到目标数据库。因此迁移完成后,您只需在短暂的停机时间内直接切换数据库,从而保证业务数据的完整性。
在中国BJS区域,还没有推出DMS服务,但是提供了Database Migration Tool(DMT)工具,您可以使用DMT工具来完成数据库迁移。

2.使用DMS完成迁移

使用DMS服务必须确保源或目标数据库有一个在AWS云中。 使用DMS服务的步骤如下:

步骤一:Create migration

登陆AWS全球区域的Console,选择DMS,点击“Create migration”,我们便来到了“welcome”界面,从该界面我们可以看到,通过DMS进行数据迁移我们至少需要一个源数据库、目标数据库和复制实例。当然,DMS 也支持多个源数据库向一个目标数据库的迁移以及单个源数据库向多个目标数据库的迁移。迁移时,数据通过一个运行在复制实例上的任务将源数据库复制到目标数据库。点击“Next”进行复制实例的创建。

步骤二:创建“Replication Instance”

您在进行数据库迁移过程中的第一个任务是创建具有足够存储空间和处理能力的复制实例,通过复制实例来执行您分配的任务并将数据从您的源数据库迁移到目标数据库。此实例所需的大小取决于您要迁移的数据和您需要执行的任务量。具体配置参数见下表1。

如果您需要为网络和加密设置值,请选择高级选项卡。具体参数见表2。

步骤三:创建数据库连接

当您在创建复制实例时,您可以指定源和目标数据库。源数据库和目标数据库可以在AWS的EC2上,也可以是AWS的关系数据库服务(RDS)的DB实例或者本地数据库。在设置源和目标数据库时,             具体参数可以参见表3。您也可以通过高级选项卡来设置连接字符串和加密密钥的值。

等图示上部分的显示变成”Replication instance created successfully”并且“Run test“按钮变成正常,然后测试,确保测试结果为”Connection tested Successfully”,由于需要从AWS服务端连接测试数据库,因此需要设置好security group,设置的security group必须确保复制实例能够访问源和目标数据库。需要的话,可以短暂的将security group 1521 的访问设置为 0.0.0.0/0,测试成功后,点击”Next”按钮。

步骤四:创建“task”

当源数据库和目标数据库建立连接后,您需要创建一个任务来指定哪些表需要迁移,使用目标架构来映射数据并且在目标数据库中创建新表。作为创建任务的一部分,您可以选择迁移类型:迁移现有数据、迁移现有数据并复制正在进行的更改,或只复制更改的数据。

如果选择”Migrate existing data and replicate data changes”选项需要打开Task Settings 中的supplemental loging开关。在Table Mapping中Schema to Migrate选择“Oracle”,点击“Create Task”。

当您创建的task状态从creating变为ready的时候,您的task便创建好了。点击该“task”并点击上方的“Start/Resume”,您数据迁移任务便开始了!

数据库迁移完成后,目标数据库在您选择的时间段内仍会与源数据库保持同步,使您能够在方便的时候切换数据库。

3.总结

从上面过程我们可以看到,只需要简单的配置,DMS就可以帮助我们完成数据库的迁移任务,并且DMS服务是免费的,迁移过程中用到的资源是收费的。

作者介绍:

蓝勇

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

Oracle数据库迁移到AWS云的方案

当前云已经成为常态,越来越多的企业希望使用云来增加基础设施的弹性、减轻基础设施的维护压力,运维的成本等。很多企业使用云碰到的难题之一是如何将现有的应用迁移到云上,将现有应用的中间件系统、Web系统及其他组件迁移到云上相对容易,一般只需要重新部署或复制即可,但如何将数据库迁移到AWS云中,是很多企业需要面对的一个难题。由于数据库的种类繁多,本文将以Oracle数据库为例,介绍将数据中心的Oracle迁移到云中的基本知识,不同方法涉及的迁移过程,请参考后续的博客。

1.云中数据库的模式

如果要在云中使用Oracle数据库,有两种选择:

  • EC2服务器模式

使用AWS的EC2服务器,在EC2服务器上手工安装Oracle数据库软件,用户需要自己准备Oracle的License,这和用户自己在机房安装Oracle数据库类似。如果在中国以外的区域,用户也可以使用AWS Marketplace里面的不同版本的Oracle镜像,直接初始化Oracle数据库,这种情况你也需要自己准备Oracle的License。

  • RDS模式

Amazon Relational Database Service (Amazon RDS) 是一种 AWS提供的Web 服务,可以让我们更轻松地在云中设置、 操作和扩展关系数据库,减少管理关系型数据库复杂的管理任务。RDS包括了Oracel、SQL Server、My SQL,等多种数据库引擎,你可以根据需要选择数据库的类型。

根据我们使用模式的不同,能选择的迁移方式也不同。

2.逻辑迁移和物理迁移

数据库的迁移可以分为逻辑迁移和物理迁移两种方式:

  • 逻辑迁移

逻辑迁移一般只是迁移数据库表、视图及其它数据库对象,不要求源库和目标库在底层的存储及表空间完全一致。逻辑迁移适用于EC2服务器模式和RDS模式。

逻辑迁移一般使用Dump/Load+Log Apply的方式,使用Dump工具将数据库对象从源数据库导出,然后Load到目标数据库,最后根据需要同步数据库日志。

  • 物理迁移

物理迁移可以让迁移的源库和目标库在底层的存储文件、存储介质、表空间、用户等信息完全一致。物理迁移适用于EC2服务器模式。

物理迁移(Oracle)一般是使用RMan等物理备份+Log Apply的方式,使用RMan等工具备份数据库,然后在目标系统还原数据库,最后根据需要同步日志。

3.日志同步

在迁移数据库过程中,如果我们的业务有足够停机时间,可以将源数据库设置成只读数据库,然后使用Dump/Load或者备份/还原的方式来创建目标库。因为源库是只读的,迁移过程中源库不会发生变化,因此只需要根据源库数据创建目标库,无需日志的同步。

在迁移数据库过程中,如果我们的业务没有足够的停机时间,此时除了要使用Dump/Load或备份还原的方式迁移已有数据,还需要将迁移过程中变化的数据同步到目标数据库,此时需要日志同步的工具。

4.Oracle数据库同步的方法

将Oracle数据库迁移到AWS云中主要有下面几种方法:

迁移Oracle数据库有多种方式,本文主要介绍以下五种,这五种方式都是逻辑迁移:

(1)使用AWS DMS服务迁移

AWS在中国以外的区域提供了数据库迁移DMS服务,支持同构和异构数据库间的迁移,也支持日志的同步。在中国区可以使用AWS提供的DMT(Database Migration Tool)工具完成同构或异构数据库间的迁移。

DMS适合于迁移中小型的数据库。

(2)使用Oracle SQL Developer迁移

Oracle提供的SQL Developer工具里面提供了迁移功能,适合于迁移数据较少的数据库。SQL Developer可以在Oracle的官网里免费下载。

(3)使用Oracle Data Pump迁移

使用Oracle Data Pump工具将数据库导出,复制数据到目标平台,最后使用Data Pump将数据导入到目标数据库。数据量较大或数据少的库都可以使用这种方式。

(4)使用Oracle Export/Import迁移

这种方式和Oracle Data Pump方式类似,需要使用Oracle导入/导出实用工具。

(5)使用Oracle SQL Loader迁移

使用Oracle SQL Loader的方式可以让数据导入的过程更快、效率更高。

5.日志同步的方法

如果要实现不停机的迁移,就需要使用日志同步的工具,Oracle数据库支持多种不同的工具同步日志:

  • DMS同步日志

AWS的DMS服务有同步日志的选项,可以使用DMS来同步日志。

  • GoldenGate工具

可以使用Oracle的GoldenGate工具,支持同步日志到EC2上的Oracle服务器和RDS数据库。

  • 其它第三方日志复制工具

根据数据库的使用情况,我们也可以尝试其他第三方的同步工具,如SharePlex等。

6.总结

我们在将数据库从数据中心迁移到AWS云的时候,需要根据数据库的大小、业务允许的停机时间、网络的带宽等多种因素选择我们的迁移方案,每种迁移的具体步骤请参考后续博客。

作者介绍:

蓝勇

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

手把手教你使用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 服务。 它在承担耗时的数据库管理任务的同时,又可提供经济高效的可调容量,使您能够腾出时间专注于应用程序开发。Amazon RDS 让您能够访问非常熟悉的 MySQL、PostgreSQL、Oracle 或 Microsoft SQL Server 等数据库引擎的功能。

具体参考:https://aws.amazon.com/cn/documentation/rds/

准备工作

1.   Cloudfront生成的日志已经存储在s3桶中,并在不断更新, 存储目录是:s3://testcloudfrontlog/log

其中testcloudfrontlog是s3存储桶的名字,在实际操作的时候,需要换一个名字,因为s3存储桶的名字是全局唯一的, 而其他人也有可能使用了这个名字。

可以从以下链接下载本例中使用的示例文件,并上传到s3://testcloudfrontlog/log目录下。

https://s3-us-west-2.amazonaws.com/hxyshare/cloudfrontlog/E36NLFLFEN3X0H.2016-07-11-02+.36b1a433.gz

https://s3-us-west-2.amazonaws.com/hxyshare/cloudfrontlog/E36NLFLFEN3X0H.2016-07-12-21.a92ddc55.gz

2.   创建一个目录来存储按照日期划分的日志数据。 目录是s3://testcloudfrontlog/logbydate

3.   创建一个目录用来做hive表的数据存储,目录是s3://testcloudfrontlog/logpart

4.   注意:直接copy本文的代码有可能会由于字符原因出现错误,建议先copy到纯文本编辑器中再执行。

手动方式完成交互式数据查询

第一步,创建一个EMR集群,方法如下:

1.   进入到AWS的控制台,选择EMR服务,点击创建集群。

2.   点击转到高级选项

3.   软件配置

选择EMR发行版本以及所需要的软件, 在本例中,我们选择emr-5.0.0版本,所需要的工具选择hadoop, hive, presto, sqoop。 本步骤中的其余选项使用默认值,然后点击下一步。如果是使用北京Region,在输入配置中输入以下内容,使得presto可访问s3, 如果使用其他Region,不必输入。

[{"classification":"presto-connector-hive", "properties":{"hive.s3.pin-client-to-current-region":"true"}, "configurations":[]}]

4.   硬件配置

进入到硬件配置界面,默认配置如下,直接使用默认配置。然后点击下一步。

5.   一般选项

在一般选项的集群名称后面输入一个名字,作为集群的名字。其余的可按照默认配置。然后点击下一步。

6.   安全选项

在EC2键对后面的框中选择一个已有的键对,该键对用来在集群创建成功后,从SSH客户端登录到集群中的任意一台服务器。如果选择“在没有EC2键对的情况下继续”,则后续不能登录到集群中的机器。其余选项均可默认。然后点击创建集群。7.   修改安全组规则,并登录EMR的主节点

进入到刚刚创建的集群的信息界面,点击主节点安全组,进入到该安全组的配置界面,在入规则中增加SSH的访问规则,这样才可以通过SSH的方式从外部机器登录到主节点。然后通过任意一个SSH客户端登录到主节点,目标地址是图中所示的主节点共有DNS, 用户名是hadoop, 通过私钥登录,私钥与前面所提到的键对对应。

第二步,创建数据表并进行查询

1.   SSH到主节点后,执行hive命令,进入到hive命令行界面

2.   创建一个用日期作为分区的hive表,用来作为最终被查询的表

将以下脚本copy到hive>提示符下执行,注意LOCATION的参数需要改成你自己的目录。

CREATE TABLE IF NOT EXISTS cloudfrontlogpart (

time STRING, xedgelocation STRING, scbytes  INT, cip STRING, csmethod STRING, csHost STRING, csuristem STRING, scstatus INT, csReferer STRING, csUserAgent STRING, csuriquery STRING, csCookie STRING, xedgeresulttype STRING, xedgerequestid STRING, xhostheader STRING, csprotocol STRING, csbytes STRING, timetaken STRING, xforwardedfor STRING, sslprotocol STRING, sslcipher STRING, xedgeresponseresulttype STRING

)

PARTITIONED BY (datee Date)

STORED AS PARQUET

LOCATION 's3://testcloudfrontlog/logpart';

3.   输入quit命令,退出hive。用aws s3命令将s3://testcloudfrontlog/log中日志copy到s3://testcloudfrontlog/logbydate中按照时间划分的目录下

以2016-07-11这一天的文件为例,命令如下,注意,s3目录需要改成你自己的。

aws s3 cp s3://testcloudfrontlog/log/  s3://testcloudfrontlog/logbydate/2016-07-11/  --exclude "*" --include "*.2016-07-11*" --recursive

这里用到了aws s3命令行工具。你可以在EMR主节点中退出hive命令行程序,然后执行以上命令。或者在任意一个安装了aws cli工具并配置了s3访问权限的机器中执行。本例中直接在EMR的主节点中执行。aws s3 cp不支持通配符,所以用–exclude 和 –include 参数来代替。

4.   针对s3://testcloudfrontlog/logbydate/2016-07-11/ 中的数据,创建一个HIVE表。

假设表的名字是cloudfrontlog20160711, 输入hive, 重新进入到hive命令行工具,并输入以下语句,注意LOCATION的参数需要改成你自己的目录。

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfrontlog20160711 (

date1 Date, time STRING, xedgelocation STRING, scbytes  INT, cip STRING, csmethod STRING, csHost STRING, csuristem STRING, scstatus INT, csReferer STRING, csUserAgent STRING, csuriquery STRING, csCookie STRING, xedgeresulttype STRING, xedgerequestid STRING, xhostheader STRING, csprotocol STRING, csbytes STRING, timetaken STRING, xforwardedfor STRING, sslprotocol STRING, sslcipher STRING, xedgeresponseresulttype STRING

)

ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'

LOCATION 's3://testcloudfrontlog/logbydate/2016-07-11/'

tblproperties("skip.header.line.count"="2");

5.   数据注入

至此,已经创建了两个hive表,通过在hive命令行工具中执行 show tables命令,可以查看到两个hive表。

向带分区的hive表中注入7月11日的数据,在hive命令行界面中分别执行以下命令:

set hive.exec.dynamic.partition.mode=nonstrict;

INSERT INTO TABLE cloudfrontlogpart PARTITION (datee)

SELECT  time, xedgelocation, scbytes, cip, csmethod, csHost, csuristem, scstatus, csReferer, csUserAgent, csuriquery, csCookie, xedgeresulttype, xedgerequestid, xhostheader, csprotocol, csbytes, timetaken, xforwardedfor, sslprotocol, sslcipher, xedgeresponseresulttype, date1

FROM cloudfrontlog20160711;

以下是INSERT语句执行过程的显示信息。

完成后,如果进入到s3://testcloudfrontlog/logpart目录下,可以查看到已经生成了按日期划分的目录,目录下存储了文件。

第三步,数据查询

可以继续使用hive做查询,也可以进入presto做查询。这里,我们使用presto, 由于presto完全使用内存进行计算, 速度更快。进入presto的方式如下:

执行quit, 退出hive命令行程序。

然后执行以下语句进入presto命令行界面:

presto-cli --catalog hive --schema default

该语句表示presto使用hive数据源,并且使用hive数据源中的default数据库。细节请参考presto的社区文档。

执行一个简单的查询:

SELECT time, scbytes, cip FROM cloudfrontlogpart WHERE CAST(datee AS varchar) = CAST('2016-07-11' AS varchar) LIMIT 5;

然后退出presto命令行工具,输入 quit;

第四步,删除EMR集群

在集群列表中,选中刚刚创建的集群,点击终止,以终止该集群。如果开启的终止保护,需要变更一下终止保护的状态,然后再终止。

至此, 我们通过手动的方式完成了一个简单的数据查询。但在实际生产环境中,使用手动的方式会耗费很长时间做重复性的工作,并难免出错。EMR更大优势是能够通过程序的方式去控制集群的创建以及任务的执行,这使得EMR的使用者能够将集群创建以及数据分析的过程自动化。

接下来的部分将以相同的示例指导读者一步步的实现自动化的创建集群、分析数据、转存结果、关闭集群。

自动方式完成交互式数据查询

首先概括几点自动化执行数据分析的需求:

1.   集群在每天的固定时间被创建,然后对数据进行分析,然后集群被自动删除。这显然不能通过图形界面进行一步步的操作了。

2.   在手动操作中执行的每个步骤,需要按顺序自动化执行。这些步骤包括:

–       从/log目录向/logbydate目录中copy特定日期的文件。

–       创建对应特定日期的hive表,例如表名为cloudfrontlog20160711。

–       从cloudfrontlog20160711向cloudfrontlogpart表中注入数据。

–       使用presto从cloudfrontlogpart表中查询出需要的数据。

–       此外,在手动执行的最后一步,我们可以直接看到查询结果,但在自动化执行的过程中,我们需要将查询结果存储到一个长期运行的数据库中,供随时查询。

3.   将hive元数据放在集群的外部。

在手动执行的流程中,创建hive表后,hive的元数据存储在了主节点。而在自动化执行的过程中,当所有任务执行完毕后,集群被删除,存储在主节点的元数据也会被删除,因此要在外部数据库中存储hive的元数据。

针对以上的几个需求,在EMR中对应的解决方法如下.

1.   使用EMR的命令行进行各种集群的操作,例如集群的创建,参数的设置等。

2.   使用EMR的“step”来组织各个任务的执行。

3.   创建一个外部的数据库用来存储hive元数据,并在集群创建的时候指定元数据的存储位置。

接下来详细描述操作步骤和脚本

第一步,准备工作

1.   准备两个mysql数据库分别用来存储hive元数据和查询结果,可以使用AWS的RDS服务来创建。这两个数据库都需要能被EMR访问到, 这两个数据库也可以使用同一个物理服务器或虚拟机。

2.   假设存储查询结果的数据库名字是loganalydb,我们在该数据库中创建一个表,用来存储结果数据,表的名字是loganalytb。根据后面所进行的查询,使用如下语句创建数据库以及与查询结果匹配的表:

CREATE DATABASE loganalydb;

USE loganalydb;

CREATE TABLE `loganalytb` ( `id` int(11) NOT NULL AUTO_INCREMENT, `filepath` varchar(300) DEFAULT NULL, `totalbyte` bigint(20) DEFAULT NULL, `tdate` varchar(50) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=58147 DEFAULT CHARSET=utf8;

对于存储hive元数据的数据库,暂时不必创建,从后面提到的emrconf.json文件可以看到,只需要给出数据库服务器的地址,以及用户名和密码即可,数据库不存在的话,会自动创建。

3.   由于自动化的流程与前面提到的手动流程使用相同的示例,因此,请事先删除手动流程示例中产生的数据。包括:

1)   s3://testcloudfrontlog/logbydate目录下的数据

2)   s3://testcloudfrontlog/logpart目录下的数据

第二步,编写脚本

下面给出各个脚本,并配以注释解释

1.   主程序脚本loganaly.sh

#!/bin/bash

# 变量KEYNAMES是你的SSH key的名字, 用来通过SSH方式访问EC2。

KEYNAME=yourkeyname

# 变量CONFIGFILE是emrconf.json的url地址,emrconf.json这个文件中包含了存储hive元数据的外部数据库的信息。将该文件存在s3中并让这个文件能够从外部访问到。emrconf.json中的内容在下文中会给出。

CONFIGFILE=https://s3-us-west-2.amazonaws.com/testcloudfrontlog/conf/emrconf.json

# EMR集群产生的日志所存放的s3目录。

LOGURI=s3://testcloudfrontlog/emrlog/

# 脚本、配置文件、jar包所在的目录

CODEDIR=s3://testcloudfrontlog/conf

# cloudfront日志的存放位置, 结尾别加 /

LOGSOURCEDIR=s3://testcloudfrontlog/log

# 当天日志的中转目录, 结尾别加 /

STAGINGDIR=s3://testcloudfrontlog/logbydate

# 昨天的日期, 形如:20160711

DATE=$(date -d "yesterday" +%Y%m%d)

# 昨天的日期,另外一种格式, 形如:2016-07-11

DATEE=$(date -d "yesterday" +%Y-%m-%d)

# 被查询的hive表的文件存储位置, 结尾别加 /

PARTDIR=s3://testcloudfrontlog/logpart

# 用来存储结果文件的目录, 结果文件将被sqoop使用,数据会被传到mysql.

SQOOPFILE=s3://testcloudfrontlog/sqoopfile

#用来存储结果数据的mysql的信息。

DBHOST=rdsinstance.xxxxxxx.us-west-2.rds.amazonaws.com

JDBCURL=jdbc:mysql://rdsinstance.xxxxxxx.us-west-2.rds.amazonaws.com/loganalydb

DBUSER=username

DBPASS=password

# EMR集群的配置信息, 这里是以Oregan region为例。如果使用的是北京region,AWSREGION用cn-north-1。

AWSREGION=us-west-2

MASTERTYPE=m3.xlarge

CORETYPE=r3.xlarge

TASKTYPE=r3.xlarge

MASTERNUM=1

CORENUM=1

TASKNUM=1

# 删除当天的数据,目的是防止脚本在同一天被多次执行而造成数据冗余,

aws s3 rm $PARTDIR/datee=$DATEE --recursive

aws s3 rm $SQOOPFILE/$DATE --recursive

mysql -h$DBHOST -u$DBUSER -p$DBPASS --execute "DELETE FROM loganalydb.loganalytb WHERE tdate='$DATEE'"

 

# 创建emr集群,名字是loganaly, 其中:

# --auto-terminate参数表示该集群在执行完所有的任务后自动删除。

# --configurations参数的文件中的参数配置覆盖了该集群运行起来后的默认参数配置。在本例中用来修改Hive元数据的存储位置。

# --step参数规定了该集群在创建后要执行的几个任务,其中Type=Hive的step, 需要给出包含hive语句的文件作为参数。而Type=CUSTOM_JAR的step,需要给出一个JAR包,这里我们使用EMR提供scrip-runner.jar,它的作用是执行其第一个参数中指定的脚本文件,并将其余的参数作为脚本文件的输入参数。

# --instance groups参数规定了集群的中各节点的机型和数量

aws --region $AWSREGION emr create-cluster --name "loganaly" --release-label emr-5.0.0 \

--applications Name=Hadoop Name=Hive Name=Presto Name=Sqoop \

--use-default-roles \

--ec2-attributes KeyName=$KEYNAME \

--termination-protected \

--auto-terminate \

--configurations $CONFIGFILE \

--enable-debugging \

--log-uri $LOGURI \

--steps \

Type=CUSTOM_JAR,Name="cpjar",Jar=$CODEDIR/script-runner.jar,Args=["$CODEDIR/cpjar.sh"," $CODEDIR"] \

Type=CUSTOM_JAR,Name="log2staging",Jar=$CODEDIR/script-runner.jar,Args=["$CODEDIR/log2logbydate.sh","$LOGSOURCEDIR","$STAGINGDIR","$DATE","$DATEE"] \

Type=Hive,Name="HiveStep",Args=[-f,$CODEDIR/hivetables.q,-d,PARTDIRh=$PARTDIR,-d,STAGINGDIRh=$STAGINGDIR,-d,DATEh=$DATE] \

Type=CUSTOM_JAR,Name="Presto2s3",Jar=$CODEDIR/script-runner.jar,Args=["$CODEDIR/presto2s3.sh","$SQOOPFILE","$DATE","$DATEE"] \

Type=CUSTOM_JAR,Name="s3tomysql",Jar=$CODEDIR/script-runner.jar,Args=["$CODEDIR/s3tomysql.sh","$JDBCURL","$DBUSER","$DBPASS","$SQOOPFILE","$DATE"] \

--instance-groups \

Name=Master,InstanceGroupType=MASTER,InstanceType=$MASTERTYPE,InstanceCount=$MASTERNUM \

Name=Core,InstanceGroupType=CORE,InstanceType=$CORETYPE,InstanceCount=$CORENUM \

Name=Task,InstanceGroupType=TASK,InstanceType=$TASKTYPE,InstanceCount=$TASKNUM

2.   准备cpjar.sh脚本

作用是将mysql的JDBC驱动包下载到本地的Sqoop目录下,sqoop在将文件转存到数据库的时候会用到JDBC驱动。

在国外region, 使用以下脚本:

#!/bin/bash

CODEDIR=$1

sudo aws s3 cp $CODEDIR/mysql-connector-java-5.1.38-bin.jar /usr/lib/sqoop/lib/

在北京Region, 使用以下脚本:

#!/bin/bash

CODEDIR=$1

sudo aws s3 cp $CODEDIR/mysql-connector-java-5.1.38-bin.jar /usr/lib/sqoop/lib/ --region cn-north-1

3.   准备log2logbydate.sh脚本

做用是将原始日志文件copy到按天划分的目录下。

#!/bin/bash

LOGSOURCEDIR=$1

STAGINGDIR=$2

DATE=$3

DATEE=$4

aws s3 cp $LOGSOURCEDIR/ $STAGINGDIR/$DATE/ --exclude "*" --include "*.$DATEE*" --recursive

4.   准备hivetables.q脚本

作用包括:创建待查询的表和按天命名的临时表,将临时表中数据注入到待查询的表中,并删除临时表。

CREATE TABLE IF NOT EXISTS cloudfrontlogpart (

time STRING, xedgelocation STRING, scbytes  INT, cip STRING, csmethod STRING, csHost STRING, csuristem STRING, scstatus INT, csReferer STRING, csUserAgent STRING, csuriquery STRING, csCookie STRING, xedgeresulttype STRING, xedgerequestid STRING, xhostheader STRING, csprotocol STRING, csbytes STRING, timetaken STRING, xforwardedfor STRING, sslprotocol STRING, sslcipher STRING, xedgeresponseresulttype STRING

)

PARTITIONED BY (datee Date)

LOCATION '${PARTDIRh}';

 

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfrontlog${DATEh} (

date1 Date, time STRING, xedgelocation STRING, scbytes  INT, cip STRING, csmethod STRING, csHost STRING, csuristem STRING, scstatus INT, csReferer STRING, csUserAgent STRING, csuriquery STRING, csCookie STRING, xedgeresulttype STRING, xedgerequestid STRING, xhostheader STRING, csprotocol STRING, csbytes STRING, timetaken STRING, xforwardedfor STRING, sslprotocol STRING, sslcipher STRING, xedgeresponseresulttype STRING

)

ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'

LOCATION '${STAGINGDIRh}/${DATEh}/'

tblproperties("skip.header.line.count"="2");

 

--make dynamic insert available

set hive.exec.dynamic.partition.mode=nonstrict;

 

--insert data.

INSERT INTO TABLE cloudfrontlogpart PARTITION (datee)

SELECT  time, xedgelocation, scbytes, cip, csmethod, csHost, csuristem, scstatus, csReferer, csUserAgent, csuriquery, csCookie, xedgeresulttype, xedgerequestid, xhostheader, csprotocol, csbytes, timetaken, xforwardedfor, sslprotocol, sslcipher, xedgeresponseresulttype, date1

FROM cloudfrontlog${DATEh};

 

--delete the staging table

DROP TABLE cloudfrontlogstaging${DATEh};

5.   准备presto2s3.sh脚本

作用包括:查询hive表,并将结果存成.csv格式的文件,将该文件上传到S3中相应的目录下。

#!/bin/bash

TIME=$(date +%H%M%S)

SQOOPFILE=$1

DATE=$2

DATEE=$3

sudo presto-cli --catalog hive --schema default --execute "SELECT NULL as id, csuristem, SUM(scbytes) as totalbyte, CAST('$DATEE' AS varchar) as date FROM cloudfrontlogpart WHERE CAST(datee AS varchar) = CAST('$DATEE' AS varchar) GROUP BY csuristem order by totalbyte desc" --output-format CSV > ~/cdnfilestat.csv

aws s3 cp ~/cdnfilestat.csv $SQOOPFILE/$DATE/cdnfilestat$TIME.csv

6.   准备s3tomysql.sh脚本

作用是利用sqoop将s3中的.csv文件中的内容转存到数据库中。注意,如果单次转存的数据量大,你可能需要调大数据库的max_allowed_packet参数。

#!/bin/bash

JDBCURL=$1

DBUSER=$2

DBPASS=$3

SQOOPFILE=$4

DATE=$5

sqoop export --connect $JDBCURL --username $DBUSER --password $DBPASS --table loganalytb --fields-terminated-by ',' --enclosed-by '\"' --export-dir $SQOOPFILE/$DATE/

7.   准备emrconf.json脚本

作用是使得创建起来的EMR集群的hive元数据存储在外部数据库中。注意:根据准备工作中创建的数据库来修改文件中的ConnectionUserName、ConnectionPassword、ConnectionURL三个参数。

[

{"Classification":"hive-site",

"Properties":{

"javax.jdo.option.ConnectionUserName":"username",

"javax.jdo.option.ConnectionDriverName":"org.mariadb.jdbc.Driver",

"javax.jdo.option.ConnectionPassword":"password",

"javax.jdo.option.ConnectionURL":"jdbc:mysql://rdsinstance.xxxxxxxxxx.us-west-2.rds.amazonaws.com:3306/hive?createDatabaseIfNotExist=true"

},

"Configurations":[]

}

]

注意:如果是在北京Region, emrconf.json使用以下脚本

[

{"Classification":"hive-site",

"Properties":{

"javax.jdo.option.ConnectionUserName":"username",

"javax.jdo.option.ConnectionDriverName":"org.mariadb.jdbc.Driver",

"javax.jdo.option.ConnectionPassword":"password",

"javax.jdo.option.ConnectionURL":"jdbc:mysql://rdsinstance.xxxxxxxx.us-west-2.rds.amazonaws.com:3306/hive?createDatabaseIfNotExist=true"

},

"Configurations":[]

},

{"Classification":"presto-connector-hive",

"Properties":{

"hive.s3.pin-client-to-current-region":"true"

},

"Configurations":[]

}

]

8.   准备jar包

需要两个jar,一个是script-runner.jar,下载地址: http://s3.amazonaws.com/elasticmapreduce/libs/script-runner/script-runner.jar

另一个是mysql的JDBC驱动,下载地址: https://s3-us-west-2.amazonaws.com/hxyshare/mysql-connector-java-5.1.38-bin.jar

9.   上传文件

在s3中创建s3://testcloudfrontlog/conf/目录,并将第8步中的两个jar包,以及cpjar.sh,log2staging.sh,hivetables.q,presto2s3.sh,s3tomysql.sh,emrconf.json,上传到该目录。

由于emrconf.json需要通过http的方式访问到,在s3中将emrconf.json的访问权限增加“所有人可下载”。

cloudfront日志文件copy到s3://testcloudfrontlog/log目录下, 两个示例文件下载地址:

https://s3-us-west-2.amazonaws.com/hxyshare/cloudfrontlog/E36NLFLFEN3X0H.2016-07-11-02+.36b1a433.gz

https://s3-us-west-2.amazonaws.com/hxyshare/cloudfrontlog/E36NLFLFEN3X0H.2016-07-12-21.a92ddc55.gz

如果在手动流程中已经上传了日志文件,则不必再上传。

第三步,执行程序

暂时将主程序loganaly.sh中的DATE和DATEE参数修改为示例数据的时间,例如,分别写成20160711和2016-07-11,在任意一个Linux系统中运行主程序脚本loganaly.sh(例如,可以使用EC2实例)。但需注意:

1) 该机器需要安装了AWS命令行工具,并具有s3和EMR的操作权限。

2) 该机器能访问到存储数据结果的数据库,因为loganaly.sh中有对该数据库的操作。

集群创建成功后,自动执行每个step中的任务,所有任务执行完成后自动关闭,从下图中可以看到每个Step的执行:

所有任务执行完成后,进入到存储查询结果的数据库,查看输入的结果:

如果要想每天执行loganaly.sh脚本并对前一天的数据进行处理和分析,将loganaly.sh中的DATE和DATEE分别赋值为 $(date -d “yesterday” +%Y%m%d) 和 $(date -d “yesterday” +%Y-%m-%d),然后创建一个crontab定时任务,每天定时执行loganaly.sh.

如果是在AWS中国以外的region执行,还可以利用竞价实例来大幅的降低成本,使用竞价实例的方法也非常简单,只需要在将loganaly.sh中对创建EMR集群的脚本稍做修改,增加BidPrice参数:

--instance-groups \

Name=Master,InstanceGroupType=MASTER,InstanceType=$MASTERTYPE,BidPrice=0.2,InstanceCount=$MASTERNUM \

Name=Core,InstanceGroupType=CORE,InstanceType=$CORETYPE,BidPrice=0.2,InstanceCount=$CORENUM \

Name=Task,InstanceGroupType=TASK,InstanceType=$TASKTYPE,BidPrice=0.2,InstanceCount=$TASKNUM

第四步,删除资源

为避免额外花费,删除本实验过程中(包括手动过程以及自动过程中)创建的资源,S3, EC2等资源。

总结

本文中使用Cloudfront日志进行分析,但本文中使用的方法稍作修改便适用于其他类型的日志类文件的分析。本文中主要使用了EMR中的Hive,Presto,Sqoop工具,但EMR还有更多的工具(例如Spark)可供用户使用,用户在创建集群的时候增加相应的服务即可实现丰富的功能。

作者介绍:

韩小勇

AWS解决方案架构师,负责基于AWS的云计算方案架构咨询和设计,实施和推广,在加入AWS之前,从事电信核心网系统上云的方案设计及标准化推广 。

手把手教你快速部署流量压测工具 – 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

#elb_region_endpoint=elasticloadbalancing.us-west-2.amazonaws.com
6. 进入/home/ubuntu/.ssh/目录,上传EC2实例的pem文件。

cd /home/ubuntu/.ssh/ (注意,这个地方一定要确保进入.ssh目录下。如果没有成功,请再次确认自己所在路径)

7. 执行启动“压测”的EC2机器

(1)简单执行:-s代表启动几台a bee!机器,-k代表秘钥的名称(注意,代码中已经带了后缀,所以这里只需要输入名称)

bees up -s 4 -k Internal-Amazon-Linux

(2)带参数执行(推荐使用)

bees up -s 4 -k Internal-Amazon-Linux -z us-west-2a -g HTTP -l ubuntu -i ami-113af271 -t t2.micro
执行结果:会发现启动了4台名称为a bee!的EC2机器。

ubuntu@ip-10-200-1-230:~/.ssh$ bees up -s 4 -k Internal-Amazon-Linux -z us-west-2a -g HTTP -l ubuntu -i ami-113af271 -t t2.microConnecting to the hive.

GroupId found: HTTP

Placement: us-west-2a

Attempting to call up 4 bees.

Waiting for bees to load their machine guns…

.

Bee i-0c8ddc14 is ready for the attack.

Bee i-0d8ddc15 is ready for the attack.

Bee i-0e8ddc16 is ready for the attack.

Bee i-0f8ddc17 is ready for the attack.

The swarm has assembled 4 bees.

看到这里说明4台EC2实例都已经正常启动了!

8. 可以看一下目前启动的report

ubuntu@ip-10-200-1-230:~$ bees report

9. 开始“压测”,这里假设压测ELB

bees attack -n 100 -c 4 -k Internal-Amazon-Linux -u http://mylabelb-XXXXXX.us-west-x.elb.amazonaws.com/

这个时候发现报错!

这里注意,需登到bee机器,然后在a bee!机器上安装apache2-utils

ubuntu@ip-172-31-29-100:~$ sudo apt-get install apache2-utils

Reading package lists… Done

Building dependency tree

Reading state information… Done

The following extra packages will be installed:

libapr1 libaprutil1

The following NEW packages will be installed:

apache2-utils libapr1 libaprutil1

0 upgraded, 3 newly installed, 0 to remove and 29 not upgraded.

Need to get 244 kB of archives.

After this operation, 877 kB of additional disk space will be used.

Do you want to continue? [Y/n] y

等到所有的a bee!机器都安装完apache2-utials之后,回到bee control机器,再次运行。成功!

此时再通过CloudWatch监控查看ELB请求总数的情况,发现变了。

说明:这里进行了两次压测,所以会看到监控中两段不同的曲线。

10. 停止“压测” 命令

bees down

此时所有的EC2都会马上处于Terminated状态

附: 源码参考https://github.com/newsapps/beeswithmachineguns

作者介绍:

毛郸榕

亚马逊AWS中国助理解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,毕业于北京航空航天大学云 计算专业,硕士,毕业后直接加入亚马逊AWS中国。在大规模后台架构、企业混合IT和自动化运维等方面有着丰富的实践经验。目前在集中精力学习新一代无服务器架构设计。

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

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

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