欧洲央行政策声明五大要点

周 四欧洲央行相对低调的新闻发布会上,镇定自若的行长德拉吉(Mario Draghi)坚定地表示未来可能会进一步降息,但明确排除了“直升机撒钱”(helicopter money)的可能性。他还回击了来自德国的批评,调侃了德国财政部长朔伊布勒(Wolfgang Schauble)和退休基金经理。此外,他还简要谈及即将到来的英国“脱欧”公投的影响。

以下德拉吉声明中的五个要点:

1. 降息

在此前一次新闻发布会上,德拉吉搬起石头砸了自己的脚,他曾暗示进一步降息可能是不明智的做法。这一言论扭转了各国推出大量刺激措施后出现的欧元下滑、股市和债市上涨的趋势。但这一次,他明确表示降息仍是一个选项,但重申负存款利率有下限。

2. 直升机撒钱

再 次谈到3月份新闻发布会上悬而未决的问题时,德拉吉对他当时的评论进行了阐释,称所谓“直升机撒钱”是一个有趣的概念。由此看来,他似乎暗示这种措施是不 可行的,尽管他没有完全将其永远排除在外。德拉吉称,欧洲央行从未讨论过这种措施,如果采取这种措施,会产生很多问题。

3. 德国的批评

德 拉吉3月份出台的刺激方案招致了包括德国财长在内的不少德国人的批评,但这些指责似乎没有给德拉吉造成任何麻烦或者伤害。德拉吉坚持认为,欧洲央行只是在 履行自己的职责,与美国联邦储备委员会(简称:美联储)和日本央行的做法多少有些类似。他指出,德国财长朔伊布勒已收回最初的批评意见,称他没那个意思。 更重要是,德国的批评适得其反。德拉吉称,每当外界认为央行的公信力遭受质疑,结果就是央行会延迟实现其目标,从而需要采取更多扩张性政策。

4. 英国退欧

德 拉吉称,欧元区经济的温和复苏面临一些“下行风险”,其中包括地缘政治的发展,例如英国将在6月23日就是否留在欧盟举行的全民公投。他说,关于英国退欧 可能性的讨论确实已对市场产生一些重要影响,比如英镑的贬值。他还称,预计在公投举行前市场会持续剧烈波动,至于市场波动是否足以危及经济复苏,欧洲央行 工作人员的评估结果是,发生这种情况的可能性有限。

5. 退休金

德拉吉承认,极低的利率给退休金领取者带 来了难题,但出现如此境况并非欧洲央行的责任。他说,低利率是经济增速和通胀偏低的反映;如果想要重返高利率水平,就必须首先推高经济增长和通胀。他向退 休基金经理指出,他注意到实际利率事实上高于20年前的水平。他说,他知道向储户解释实际利率可能会很困难,但这正是基金经理的职责所在。

Paul Hannon

Advertisements
发表在 未分类 | 留下评论

为确保敏捷行为的实施而制定合约

Martin Kearns在澳大利亚墨尔本的第一会议上发表了一场关于敏捷合约的演讲。InfoQ对他进行了采访,内容如下:敏捷合约与瀑布项目的合约有何不同之处, 合约该如何应对范围内的变化,在开发过程中的主要干扰或延误,可以做些什么来确保合约能提供敏捷行为的权利和帮助所有那些相关的人在基于敏捷思维的基础上 一起工作,当机构想要在敏捷软件开发中使用合约时律师所起的作用,以及为了能够使用敏捷合约,机构必须做什么。

InfoQ:为什么您认为合约对敏捷开发来说很重要?

Kearns:一所机构,无论何时需要第三方的参与来传送结果、提供支持,增强所作用和增加金融业务都是交易的一部分,而合约是成功的基础。最重要的是合约代表着该途径的意旨、预期行为和责任制。

InfoQ:敏捷开发的合约以何种方式不同于瀑布项目的合约?

Kearns:最重要的不同是在支持文件中,总是试图删除瀑布项目的变动,许多费用和重点都在于后续变化(即范围蔓延),这是不可避免的,无论计划多么提前完成。这就自然而言地创造了一种不利关系,即双方都努力专注于他们自己的最大利益。

敏捷合同开始于允许项目失败的构想,因为合约体系必须允许双方基于一个可怜的商业理念构建一个合同。太多的项目因为某一方的自身利益而持续。还需要 有一个延伸的退出条款,因为一旦传输的价值比迭代的成本还要少,那就没有理由继续了。在栅栏的另一边(供应商),如果客户行为和思维不支持敏捷方法,那么 在不产生损失的情况下,退出的能力就是必不可少的。对敏捷合约来说,共同的责任是必要的,不能降低到一种单方的交易。

InfoQ:在大多数“传统合同”中,必须交付的范围是一致的。在这段时间里你想用敏捷来接受变化,适应范围。敏捷合同怎么支持呢?

Kearns:在第二到第四次的任务迭代中,我努力确定的一件事是对积压任务以及用户故事的周期时间的自信度,为了敏捷合同的成功,我们需要对计算交付混合项目的成本有一个很好的处理。为了做到这点,我通常喜欢参与Time 和Materials建设中最初的冲刺。

一旦我们有可以接受的自信水平,我喜欢用工作来确定以固定成本可以实现的很多功能和/或故事点。一旦认为这是“可行的”,我就可以像进入我的夜间俱 乐部,“1进1出”。我改变的方法就是一直说“是”,客户可以提高项目的最高限度或者删除大小相等的故事/功能。很明显当项目的最高限度得以提高,成本和 更多可能的时间也会提高。

InfoQ:您能就敏捷合同是怎么处理开发过程中的主要干扰或者延迟,举个例子吗?

Kearns:我最喜欢的方式之一是创造一个障碍的气泡图,这样我可以追查一下随着时间延迟的轨迹。一旦图上出 现气泡,它就会随着障碍存在的时间变长,开始向右移动。随着因为无所作为而引发的相关交付影响变得越来越显著,我们就会“冒泡”。一旦气泡离开容忍边界, 相关成本(气泡大小)就转变成一个变化请求。

当项目延迟的影响不再被目前的合同所忍受,那么它就必须通过合同修正处理。这可以通过减少故事点的限度,或者增加项目支出而产生。正如我们所看到的气泡每天超出项目容忍度,而我们在它们成为财务问题之前就提供最大的领先时间来解决问题。

 

InfoQ:在您的演讲里提到敏捷合约应该确保敏捷行为帮助所有那些相关的人在基于敏捷思维的基础上一起工作。您能就此详细说明一下吗?

Kearns:我喜欢在我的合约里看到的一件事是,早期失败是安全的。如果我作为一个供应商,已经证明了你的项 目假设是错误的,期望值不可能达到,因为我得到报酬以及我的客户在能够重新分配项目资金到其他地方上看到价值,是很重要的。仅此一项在最初的讨论中就产生 了一个不同的重点,早期的迭代作为结果,也更加重视起来。

另一件关于敏捷合约的事是,因为范围不能高度提前定义。传统的供应商交付也设计为逐渐形成以及独立于项目其他元素,以保护供应商的利益。不幸的是, 项目成果是相互依存相关的,需要重新设计敏捷合同条款。一种可以解决的方式,一种可以设计正确行为的方式,是各方“以原则工作”的必要手段。这一责任必须 在两个机构中共享。这对我而言已经是我在对这种合同安排负责的律师间的合作中,学会欣赏的东西。因为原则共享,它提供了一个公平的与他人交战的游戏领域。 这样原则的一个例子是将明确地显示由供应商团队在商业决策上要求的响应率,以实现目标的发布日期或者连续的对市场的交付速度。

在合同计里嵌入敏捷思维有很多好处。我想提及的最后一件事是供应商管理在这种情况下的作用。随着我们在合同评审(2-4周)上有更快的节奏,会持续 关注于结果以及迭代的交付产品如何增加价值和/或认知。通过正式的循环反馈,定期重新调整关系,透明度也以此鼓励各方关注结果,互惠繁荣,因为成功是共享 的。

InfoQ:您认为当机构想要使用敏捷软件开发合约时,律师该起到什么作用?

Kearns:律师有着同样确保项目条款反映交付的工作性质以及客户利益得以保护的责任。我觉得这个没有改变。敏捷合同的迭代是通过使用更精细的信息和定期的审核节奏来降低风险的。

InfoQ:为了能够使用敏捷合约,机构自己需要做些什么呢?

Kearns:于我而言,首先它开放于一种新的工作方式,并意识到为了成功实施,任何合同都有双向责任。在一项敏捷合同中,有更多的合作以及对双赢局面的忠实渴望。人们需要积极主动地参与其中。当难以辨认在办公室奔波的是供应商/客户时,我就知道了一切都在运转。

查看英文原文:Contracting to Enable Agile Behaviour


感谢张龙对本文的审校。

发表在 未分类 | 留下评论

用户价值覆盖率高于代码覆盖率

在用户价值多变的情况下进行软件开发,为了能更快速地向用户交付有价值的软件,开发团队应该专注于用户价值覆盖率,而不是代码覆盖率。

代码覆盖率(Code Coverage)[1]是一种用来描述程序的源代码被特定的测试套件所测试的程度的度量手段。与具有低代码测试覆盖率的程序相比,具有高代码测试覆盖率的程序会被更加全面地加以测试,并且其缺陷会更少。

代码覆盖率是Miller和Maloney两人在1963年出版的Communications of the ACM杂志上首先提出的。对于那时以用户价值变化很少的科学计算为主的软件应用开发来说,开发团队将软件开发质量的重心放到代码覆盖率上是适宜的。但随着 强调用户体验的互联网时代的到来,在当前大量的软件开发过程中,用户价值的变化速度已经大大超过50多年前的水平。如果开发团队继续“将软件开发质量的重 心放到代码覆盖率上”,那么会造成大量的工作时间被浪费在开发和测试已无用户价值的代码之上,从而导致开发有用户价值的代码时间减少,进而延期交付对用户 有价值的软件产品。

下图以一个新项目的开发过程为例来说明上述问题。

上图中红圈代表团队识别出来并要实现的用户价值,蓝圈代表系统已有的代码所实现的功能,两个圈相交的部分,表示代码实现了用户价值的部分。

在项目启动时,红圈较小,且随着识别的用户价值的增多而不断地增大,另外,它会随着用户价值的变化而不断变化,从而产生移动。此时由于编程工作刚刚起步,所以蓝圈很小。

重要通知:接下来InfoQ将会选择性地将部分优秀内容首发在微信公众号中,欢迎关注InfoQ微信公众号第一时间阅读精品内容。

随着项目的进展,代码实现也逐渐变多。但由于下面3个原因,代表代码实现的蓝圈会与代表用户价值的红圈发生偏离:1)由于诸如程序员和领域专家各讲 各自的方言所致的误解等原因,代码仅实现部分甚至没有实现原先识别的用户价值;2)当针对原先识别的用户价值的代码编写完毕后,团队识别出原先的用户价值 有部分功能需要删减(用上图中最下边那个右边缺了半圆的红圈来代表);3)团队又识别出新的尚未编写代码的用户价值(用上图中最下边那个左边多了半圆的红 圈来代表)。

而在面对上述第2)个原因中那些不再具备用户价值代码时,程序员会将其删除吗?在自动化测试覆盖不全面、手工测试反馈较慢、代码逻辑和耦合 复杂、进度很紧等等这些很“骨感”的现实情况下,程序员往往选择不去删除。“谁会保证在删代码时,不会把系统搞挂?”程序员不删那些已经不具备用户价值的 代码,又加剧了红圈与蓝圈的分离。随着过时的用户价值不断被删减,那些不会被删除的已经失去用户价值的代码就会越积越多,这使得蓝圈右侧删不掉的尾巴会越 拖越长。

在这种情况下,就出现了“代码覆盖率悖论”:如果IT企业只将注意力放到提高代码覆盖率,而忽视提高不断变化的用户价值覆盖率,那么就导致团队会把时间浪费在阅读和测试哪些已经失去用户价值的代码上,从而延误开发那些新演进出来的用户价值,无法快速满足用户需求。

相对“用户价值”这个“终”来说,代码仅仅是一个阶段的“始”。要快速地交付用户价值,我们需要“以终为始”地进行软件开发,将注意力放到 以红圈所代表的用户价值这个“终”之上,随着它的不断变化来持续追求用户价值的覆盖率,也就是用自动化测试来把红圈所代表的用户价值保护起来,而不是盲目 地追求已有代码的覆盖率。

[1] 引自:https://en.wikipedia.org/wiki/Code_coverage


感谢丁晓昀对本文的审校,张凯峰对本文的策划。

发表在 未分类 | 留下评论

企业私有云的换位再思考

引言:一个企业私有云的建设是在企业整体技术下的行为,各个方面都有影响,故而不仅仅是个技术的问题,从纯云技术以外的系统架构、管理、运维、开发等角度去讨论一下这话题,也会有更多新收获。

私有云的异和同

随着云计算的概念普及,公众对云计算的概念广泛接受,云的建设投入也越来越大。在这里我们再回头看看企业私有云这块在建设过程中的一些场景,将会发现一个很有意思的现象!每个人眼中的企业的私云,各不相同但又无比的类似。

构建一个企业私有云是一个复杂的命题,在私云开始建设的N年后,我们回头来看会发现,大部分企业私有云的建设是为了把资源动态管理起来,对访问控制和资源隔离没有做太多要求。

我们先来说说这个私云建设起初的目的,在面临基础维护的各项压力时的痛点:一、随着应用的增加,服务器的使用每天都在增加,但单机的性能往往利用不 充分,单机使用率不高,服务器增加让管理变的一团糟。二、网络的压力,随着用户数量的增多,以及使用量的变大,一个地方出问题整个网络就会出问题。外网、 内网、管理网都成了一张张无法管理的大网,管理成本高昂。三、应用的运维工作变的异常复杂,应用部署的复杂度在增加,应用部署的时间在加长,故障响应时间 变的越来越长,付出的代价也越来越大。于是很多企业都开辟了一条类似的道路:私有云。

私有云的工作对于不同的企业来说,因为需求不同所以用的方式也不同,有自己慢慢研发的,也有直接使用外部方案的,如:OpenStack等。但这里 面我们会发现这件事情更多变成了为解决服务器、网络等基础问题而专门去做的事了;或者变成了因为要私有云所以要建私有云,变为一件单为解决技术问题去做的 事了。

这时我们要是从另一个角度再来看一下私有云这件事会发现,原来很复杂的麻烦事,只是从一个麻烦变为了另一个麻烦。面对一套庞大又复杂的云系统,原来 的故障换了一个脸又来了,并且来的更难排查了,因为基础设施变的更复杂,排查的时间更慢。比如,我们的一个产品线曾经直接使用整套开源解决方案,直接部 署。在起初一切运行稳定,但是当子项目的流量进一步扩大后需要的基础支持越来越多,这时开始出现了比较大的麻烦,因无法掌控所有开源方案的技术细节,所以 系统出现了各种的问题,这些问题有些运维是可以绕过或解决的,但是毕竟运维开发能力不足,我们不得不为每天可能突发的问题配备一个比较专业的开发团队。

整体开源解决方案有很多功能,而我们只是使用了其中的一小部分,为了这一小部分的功能,我们的开发团队不得不熟悉整个项目的代码,维护系统的开发团 队的规模也比较大。我们其实给客户提供的只是产品服务,这样每天投入的人力成本非常高,而且对于问题的处理流程也是比较混乱的,最终我们只能退回到原来。 所以在建设私有云这事上,我们还是要从整体系统方面来更多的思考。

云化思维解决的困难

从整体系统架构的角度来看看我们的应用系统到底出现了哪些困难,哪些我们是可以用云化来解决的。这里用到了“云化”这个说法,不是私有云。一个系统 从应用到基础应该是一个整体,解决问题要从整体来考虑,这个整体包含很多方面:技术文化,开发人员的能力等等。那么具体困难有哪些,我们其实是可以总结一 下的,就出现系统架构这一个永恒的课题了,什么样的架构是一个好架构,答案也是一个老声音:最合适的才是最好的(这个好像等于没说)。

那么在系统架构这块往往很多企业因为历史原因存在很多不合理的情况,一时之间也很难完全解决,这才是引发故障最大的核心点之一。比如,缓存这样一件 看起来很简单的事情,在起初的系统中引入缓存,因为没有一个很好的架构设计,在一段时间后会发现这个系统中出现了一大堆的缓存服务器,每个缓存服务器中放 入的缓存数据也可以用一句话形容:“不知道是什么”。

整个系统在缓存上已经错综复杂,原本为了提高系统性能而设计的缓存变成了一个地雷,任何一个缓存服务器的故障都有可能搞死整个系统。这样一个缓存的 问题其实也是很好解决的,就看用什么样的方式来解决,只不过是要花费很多时间来重构整个系统,但是即使本次重构系统完成,可能在不久的将来因为这样凌乱的 架构,又会面临再次重构。

这样的例子应该还有很多:数据库,消息队列,各项核心服务等等,但我们回想一下缓存的故事,我们能不能应用云化的想法搞定呢,那么这里的云化,我们 就不能单单从基础技术的角度去考虑了,我们要从开发者的文化,后期的运维,架构的可扩展性,使用的便捷性等等方面去想,最后需求归为一句话“要一个缓存的 服务在开发者看来它可大可小,数据想怎么放就怎么放,永远也玩不挂,随时能说的清楚里面有什么”。

这时我们就把缓存容器到缓存的调用,整体系统的监控和系统的自动扩容都在后端解决,让开发者使用我们的缓存系统,看上去就像是一个巨大的缓存盒子。把这样的云化工作一件一件的做起来,到最后我们自然就得到了一个真正解决我们困难的私云了。

架构角度的再思考

从系统架构角度的再思考,在这个角度上我们发现一个好的系统往往是一个:大事变小、大系统小做、简单设计、可快速开发、可运维性强的微服务化系统。 不会出现一个点出问题,处处有问题的情况。并且对于业务的需求能快速的响应。这时我们私云在这块上就需要更多思考怎么更多的提供可靠的云化中间件,如,缓 存,数据代理层,服务发现治理框架等,只有这样才能给应用开发人员提供更多的技术支撑,屏蔽更多的技术细节,让他们能像开发小应用那样,开发大系统。

管理角度的再思考

从管理角度的再思考,在这个角度上,我们经常遇到的一个问题是,对我们的基础资源的整体管理不够,如这个网口上应该是一个什么样的设备;这个服务器 是用来做什么的;这个服务器应该安装什么OS,上面的基础配置应该是什么;这个服务器上部署的是什么业务;同样的应用还有多少台服务器;哪些是正在工作 的;这台服务器使用量是什么样的,还能进一步的提高吗;扩容的时候还能再快一点吗;等等。

这样的问题让我们想到了最开始的那个需求“ 把资源动态管理起来”,是的,这个正是我们最基础的那个想法,所以在这角度我们的私云就应该要为它设计一个完善的CMDB,这个CMDB可以从基础资源管 理到上层应用管理进行一个全面的掌控,并且数据还能够闭环的自动采集,CMDB虽然本事技术难度不高,但是它的管理方式的设计会直接影响整个私云的原数据 管理。

当然还有一个最重要的基础事项,选择一个合适的虚拟化的方式,当然这个还要考虑应用的现状,成熟的方案有很多,如:Docker很帅,但你当前如果还有大量的在windows上运行的应用,那么就不太合适了。所以最合适的虚拟化方案才是最好的选择。

运维角度的再思考

从运维角度的再思考,在运维这个角度可能大部分的想法是我已经选择了一个比较好的虚拟化方式这就可以了,或者说私云就是为了解决运维的问题而生的, 可能还有更激进者认为我们有云了,就不要运维了,只要找几个人把服务上架就行。但是运维真的就这样吗?这里还是先来想一下运维到底应该是个什么样的角色, 从传统情况上来说我们的运维可能每天都在忙于发布,回收等常规基础性操作,工作时间长了好像运维只会发布重启一样。

但其实在移动互联网的今天,一个应用的更新迭代的周期是非常快的,这时候会出现;一些应用,产品和开发者都不再维护它了,但是这个应用还继续在线上运行,这就一定要有运维人员在,并对各种问题进行第一时间处理,这时候运维其实更像一名全栈工程师。

所以私云的基础解决了运维的基础工作(如像Docker,运维的基础工作变的很少),这样运维需要用更多时间来思考,如何更好的在应用层面运维好一 个系统,例如:当一个故障事件发生时,这个异常事件后面是什么,关联事件又是什么,这样就让故障的解决变的更加可控。所以在私云建设中要给应用运维建设一 个强大的应用运维平台,让运维的所有数据在这个平台流通和分析,给运维人员最好的数据支撑,这样这个私云就是一个健康的云。

开发工程师角度的再思考

从开发工程师角度的再思考,这里的开发工程师并不是指私云的开发者。这个角度经常会被人忘记,因为很多情况下,大家会感觉私云主要是解决基础问题 的,开发的应用只要能在上面跑就可以了,所以和开发者的关系不大。其实这时是忽略一些事情的,私云上乘载的正是这些开发者开发的应用,让它们更好的运行才 是私云本质的目的。

但长期以来,应用发布上线,往往需要大量的运维工作,所以这个工作往往是非常忙碌的。那么这里私云需要考虑一下怎么去打通开发者到运维者之间的关系 (这也是一对长久欢喜冤家)和减少开发过程对基础环境的影响。这里举个比较low的例子:一个故障发生,运维找来了开发人员一起排查故障,几翻苦查之后, 发现应用在开发环境和生产环境的基础配置不一样。其实这里反应出来的是一个长久矛盾,开发者不擅长各种运维技能,运维者又不了解开发意途。

这里可能会说我们要‘全栈工程师’但全栈工程师毕竟数量有限,同样我们也可以用一些生硬的管理流程来解决这个问题,但是这样都不是很好的方式,因为 我们需要给开发人员更多的自由。所以私云建设在此处就可以做的很好(如:Docker在这里就给了大家更多新的想法),让开发人员通过私云慢慢融入 devops的技术文化。

同程旅游的分享

以上正是同程旅游在私云的建设上不同阶段,纯技术角度以外的思考,从这个角度来看:一开始我们对机器进行纯粹的虚拟化,然后把整套开源方案直接拿来 使用,接着使用Docker等容器加上中间件的云化走轻量之路。一切过程全是为了系统的更快,更稳,更好,让事情变的更简单,让系统变的更轻量。当然这个 私云建设是一个整体的方案,我们需要从多种角度去审视它,不应只从纯粹的云技术这一个角度来看,这也是一个需要长期迭代的过程,我们还在路上。

Q&A

1.问题: 请问同程目前的私有云建设处于何种阶段?如何满足业务的发展需求?

答: 目前同程所有的业务都是跑在我们自己的私有云上带,近一年大量的引入了docker容器,目前基本能满足业务的发展,我们还在继续带改进私有云

2.问题:vmware和citrix的桌面虚拟化您怎么看,会有使用的意愿么?用这两家的产品搭建企业私有云。

答: vmware和citrix的桌面虚拟化只是在做虚拟化,当然虚拟化在云里面是非常重要带一环,但不是全部,如果从虚拟化角度来说它们是挺不错的,但是私有云毕竟以云的方式去做的,虽然不对外公开,除了虚拟化以外,还有做很多其他的工作

3.问题:docker的网络用的ovs吗?

答: 我们的docker没有使用ovs,在网络这块做的比较保守的

4.问题:docker的安全怎么考虑的呢?

答: 我们的安全是从整体出发的,安全团队会有很多扫描器,宿主机上会有安全的agent做监控,来保障我们整体业务系统的安全,不知道问的是不是这个安全

5. 问题:您对于微服务和自适应性能水平扩展以及自动发布架构paas配置在有效数据监控下的调整有成熟的产品或者成功案例吗?

答: 这块我们仍在不断的改进,部分可以做到根据监控数据,自动弹性扩容,其他还是需要人工的半自动化参与

6. 问题:你们私有云的使用后,开发工程师对devops有什么样的参与度?

答: devops需要比较多的文化气氛,我们公司一直在积极引导工程师带devops实践,目前部分中间件研发团队,都已经进入devops

7.问题 : docker是部署在物理机上还是虚拟机上呢?

答 :docker部署在物理机上的

8.问题:在单台服务器上存在多个可选业务组件,它们需要的基础环境不尽相同。我希望使用docker封装每个组件。请问这种方案是否可行?是否存在资源占用或其他隐患?

答: 我们的每个docker容器都是单一的应用服务,docker本身的隔离是没有问题的,如果物理机紧张,可以尝试

9.问题:请问有使用openshift 之类的软件管理docker,在一台物理服务器上会出现不同docker 之间的资源竞争吗?如果有那又如何解决呢?

答 : docker 本身具备很好的资源隔离能力,所以基本不会发生资源竞争,我们在应用过程中没有发生类似问题

10.问题:目前的云平台,会使用会用到KVM,Xen等虚拟化技术吗?底层的KVM与Docker之间的关系如何?如果出现KVM的安全漏洞,是否会影响私有云的安全?

答 : kvm我们也在使用,目前有大量的windows服务是跑在kvm上的,我们的安全是整体的安全方案,所以在这一块上是从整体考虑的安全方案,安全措施比较多,基本上入侵检测,到网络监控,主机防御等基本都有一套完整的系统在跑,基本不会担心这个问题

11.问题:即使单台服务器的场景docker也值得应用对吗?

答:可以把底层的基础依赖一起打入容器运行

12.问题:请问docker集群是部署在coreos上吗?还是其他的发行版?

答: docker部署在centos7上

13.问题:有几成业务放在docker上跑了,有多少docker实例?

答 : 我们除了windows上的应用,其他都基本跑在docker下面了,大概3000个左右的container,也一直在增加

14. 问题:您公司以后会不会开源一些成熟架构或者开放一部分私有云的paas平台给其他开发者比如自动扩容数据反馈架构产品?

答:我们也很想开源出来,目前还需要做更多的工作,以让它变的更好

15.问题 :kvm通过openstack管理还是rhev?

答:我们之前也在使用openstack来管理,目前正在迁向我们自己研发的一个轻量级管理工具

16 问题 :kvm和docker的异构管理是由统一的云管理平台来负责吗

答:是的,统一归平台管理

17.问题:数据的安全性是如何整体考虑的,比如故障恢复之类的

答: 数据库在另外一套数据库的管理集群中,另外还有分布式文件存储系统,docker本身不存储数据

18.问题:容器中应用的更新一般怎么做,更新镜像并重启容器吗?

答 : 目前是这么做的

19.问题 :数据库放物理机吗?如何和虚拟机(业务层)通讯,三层吗

答 : 目前生产环境的数据库没有使用虚拟机,网络是三层通讯

20.问题:问个偏业务的问题,像业务上数据有关联的模块,在应用容器开发和部署时,有哪些要注意的?

答:这个问题没太看明白,我们这边的业务模块之间的通信和调用是通过我们的服务治理调度中间件完成的

21.问题:灰度发布吗,原则是什么?

答 : 是灰度发布的

讲师介绍

王晓波,同程旅游 首席架构师,专注于高并发互联网架构设计、分布式电子商务交易平台设计、大数据分析平台设计、高可用性系统设计。曾设计过多个并发百万以上、每分钟20万 以上订单量的电商交易平台,熟悉B2C、B2B、B2B2C、O2O等多种电商形态系统的技术设计,熟悉电子商务平台技术发展特点,拥有十多年丰富的技术 架构、技术咨询经验,深刻理解电商系统对技术选择的重要性。

ArchSummit全球架构师峰会2016(深圳站)有幸邀请王晓波出任“云服务架构探索”专题出品人。大会15大专题,3位联席主席,15位出 品人,10位大咖讲师,火币网的创始人兼CEO李林、饿了么CTO张雪峰、阿里巴巴速卖通技术部总监郭东白、Uber高级软件工程师魏凯…他们会给大 会带来什么不一样的精彩呢?让我们拭目以待!7折购票倒计时最后一周,了解更多大会详情,点击这里

本文根据ArchSummit微信大讲堂上期期邀请讲师,同程旅游首席架 构师王晓波为大家线上分享内容和提问环节整理而成,该微课堂是ArchSummit全球架构师峰会运营大会之外的一个线上交流的平台,定期组织分享活动。 在这里可以提前聆听讲师及所在团队的线上分享,了解大会最新动态。想参与的读者可以扫描二维码,回复“架构师”,获取参与方式……

发表在 未分类 | 留下评论

酒香也怕巷子深:移动App营销策略指南

常听业内人士说“只要你开发一款App就一定会有人来用”。这话听起来不错,但现在是一个即使酒香也怕巷子深的时代,不做推广,再好的App也只能 是糟糕软件。许多有抱负的开发者将App放到应用程序商店就以为美好的生活开始了,并不主动采取良好的营销措施。最终,这些iOS或Android应用程 序会被挤到不被注意的角落里。那么,如何才能保持良好的开发势头,并保证你的移动App永不休息呢?

这里提供一些方法来确保你的用户上钩,为你的App在正式上架之前和之后获得有价值的曝光度,也为后期的营销打下基础。

除了前期的设计和编码,推出一款移动App是移动应用开发过程中最重要的元素之一!目前,在Google Play Store里每一个领域都有超过100万个App整天在求关注呢。如何获得坚实的营销和分销策略,让你的App走进用户的法眼,这真的是一件比开发还要难 的事情。

通过登陆页面和社交媒体造势

在你的App呈现在用户面前之前,最好是制造出一些悬念。在一个极具创造性的登陆页面上,将你的重要想法传递出去。你觉得如何?最好是将有趣的经过剪辑和做过视觉效果的视频放出来,以此来激发目标受众的兴趣。记住,透露一点,欲擒故纵!

将社交媒体渠道和登陆页面结合起来,这就要确保即将推出的App在Facebook、Twitter和YouTube的有一定的活跃度,也可以尝试在Instagram上建立悬念。同时还可以用幸运抽奖和早期折扣券的方式获取关注。

保持一定频次的对外公布

让移动App的潜在用户尽可能早的知道你的App,他们有可能是你在开发程序早期阶段的中坚力量。因为他们会提供一些有价值的质量反馈,并最终成为App成功的因素。所以说,要确保你得到的信息都集中在你的用户身上,并专注于通过你的App来消除用户的主要问题。

App发布之前先来篇预热新闻稿

新闻稿是接触所有媒体和门户网站的最好办法!然而,商业预发行App新闻稿和官方序发布App新闻稿之间是有区别的。你的新闻稿发出去之后,估计人们问“为什么”比问“这是什么”App的问题要多得多。

这个时候你的公关焦点应该是向读者宣传你设计这款App的想法是什么,能解决什么问题,以及什么时候会出现在Google Play Store。

来部宣传片先睹为快

在正式发布App之前,大家都想先看看这款产品到底有多牛。所以这个时候丢出一部预告片吊一吊用户胃口不失为一个好方法。预告片最好包括App的设计概念,UI/UX,解决用户哪些问题,品牌代言人等等。

为了将移动App的形象包装的完美,需要考虑这几个问题:

  • 如何确保你的App在各大商店排名靠前?
  • App下载量达到多少能给你带来商业价值?
  • 怎样确定你的App是由目标用户群体下载的?

保持对话,对话,对话

据Google最近的一项研究显示,用户从手机上删除App的主要原因是缺乏对这款软件的兴趣,不符合他的使用习惯,换句话说就是缺乏可用性。但这 些因素是非常主观的,会随时间的推移而产生变化的,有可能成为用户的最爱。因此,记住,与你的用户保持积极的对话是非常重要的。

根据各种Android技术顾问团的反馈,保持对话的最好的长期策略就是建立一个App测试版本交流社区。这些技术社区能够让我们了解用户 需求是什么。除此之外,这些测试者也能在这里获得早期访问所有App功能的机会,帮助App塑造最佳形象,让这些测试人员感觉自己就像VIP会员一样,在 移动App测试行业树立自己的品牌。

准时发布,并保持更新换代

在推出App之前很有必要进行一次深入的市场调研,做竞争对手分析,核实跟媒体的合作成本,获得一个良好的公关团队也可以为App的发布带来奇迹。 App发布之后尽快联系一些熟悉的博客作者和媒体人,请他们写一些使用了这个App的心得体验,从而推动移动App的安装数量。

定期更新App程序,不仅仅是为了留住用户的兴奋感,还要确保他们不会厌倦已有的功能,更是为了避免删除这些App!

第一印象就是最后印象!

每一个应用程序都是独一无二的,它的功能,它的使用方式。一个移动App的留存比率取决于多个因素。事实上大家都知道“第一印象就是最后印象”,一 个令人愉快的使用体验是必须的。用户安装了你的App就成功了一半,接下来用户启动App的几秒钟内决定着这个用户能否成为活跃用户,还是立刻卸载掉去装 别的程序。

“速度”是用户的第一需求

没人喜欢使用速度慢的像蜗牛的App。一款App能够保证在App Store里获得一星级审查的最快方式就是提高它的运行速度。这里有一个普遍认同的简单数据:移动端用户在使用一款新App的前一分钟之内,如果感觉效果 不好就不会继续使用了。最近一项研究指出,智能设备用户希望一款成熟的App能够在2秒钟内打开。如果达不到这一数据指标,就赶紧优化吧!

App在线分析

App在线分析功能其实是一种很了不起的在线了解客户的方式,整个过程能帮你深入了解用户为什么选择这款App,以及他们所习惯的浏览模式。重要的 是可以了解你的用户基础,谁在什么时候下载了你的App?他们使用软件多久了?使用频次是怎样的?购买的时候遇到了什么问题?这些答案决定了你的App生 死存亡。所以建议开发者能够跟踪这些App。例如使用Flurry Analytics,Google Mobile App Analytics,Appsee和Mixpanel。

名人效应

这一点可能对绝大多数的移动开发者而言不太现实,但是如果能够做到的话,获得名人或大牛的支持可以显著的提升你的名声,用户会相信你的App是最棒 的。即使粉丝和竞争对手不看好你的App也没关系,因为你有专家在背后撑腰备。例如:耐克携手著名歌手和5次半程马拉松选手Ellie Goulding为他们的一款App代言。所以,你现在直到认识有名气的人对宣传产品有多么重要了吧!

关于作者

Ritesh Patil是Mobisoft Infotech公司的联合创始人,这是一家帮助创业公司和企业解决移动技术的技术型公司。作者本人是一个尤其热爱移动技术的人,在一家技术领先的Android公司从事移动App开发,产品覆盖金融、保险、医疗、娱乐、生产力、社会事业等各个领域。

参考英文原文:A Mobile Application Marketing Strategy Guide

发表在 未分类 | 留下评论

商业分析在敏捷中的角色

Erin McManus和Ryan McKergow在1st Conference(专为对敏捷不了解的人准备的的一场会议)上发表了is there a future for business analysis?(商业分析有未来吗?)的演讲,他们探讨了当机构采取敏捷时商业分析的作用。InfoQ就商业分析的需要性,敏捷是如何影响商业分析师的角色和当采用敏捷举措时发生在商业分析的变化等对他们进行了采访,以及他们有哪些具体商业分析的做法可以推荐给敏捷团队。

InfoQ:你认为当机构采用敏捷时,依然需要商业分析吗?

McKergow:是的。我认为商业分析对敏捷的软件发展来说依然很重要。商业分析意味着批判性地思考和质疑我们所提供的价值,我们在试图解决什么问题?我们为什么把开发软件当做解决方案?

它还包括理解机构的复杂性,如政府的监管变化、企业政策、行业标准、商务流程,一直进行的明细表。仅仅因为我们采用了和传统方法不同的敏捷工作方法,也不能意味着我们会忘记这些问题和考虑的领域。

McManus:当然,我觉得 Ryan和我所说的是我们考虑软件的方式随着时间的推移而进化,所以软件开发团队里的角色也需要进化。我们真的需要考虑这些角色在未来可以做什么,尤其是采用敏捷后。 所以我确实认为在机构采用敏捷后还是需要商业分析。

InfoQ:敏捷举措是如何影响商业分析师这一角色的?

McKergow:就像软件开发中的其他每个角色,敏捷挑战了这一角色带来的作用,并且质疑:“我们还需要 专门这样的一个角色吗?”这就是为什么敏捷鼓励跨职能团队。我们团队里拥有用于开发软件的所有技能,但我们不需要团队里一个专门的人,纯粹的专家(其他什 么都不是)。所以它质疑了我们需要一个纯粹的商业分析师吗?需要一个纯粹的测试人员吗?这是两个例子。还有更多。

InfoQ:你能就你所看到的当采用敏捷时发生在商业分析的变化,举些例子吗?

McManus:敏捷增加了团队内部的协作,商业分析因为敏捷而发生改变的一个例子是拥有了创造一种共享语 言的工具。我们在Behaviour Driven Development (BDD)的采用中看到了这点。商业分析师用Given, When, Then的BDD格式编写他们的验收标准。要写出这样的方案需要运用复杂的功能,同时和非技术人员用他们能理解的语言清晰地交流。
我们也看到了完成分析的时间和数量上有所改变。不仅仅有一种精益的“及时”生产方法来分析。只有在需要时做到所需要的。这就确保了在分析过程中没有浪费。

McKergow:依我来看,我认为已经有传统商业分析师向T型分析师转变。你可能有专业化的分析,但你应该扩展在敏捷方面的技能。

McManus:我同意!在开发过程中有更多的合作。我看到商业分析师扮演着测试人员的角色,所以他们可以 确定开发团队将特性所需要的全部要求考虑在内,或者作为商业代表,像一名代理产品所有者签署特性一样。在敏捷团队里有更多的余地去承担不同的责任。不再是 “这不是我的工作”,我们应该质疑,如果你能做,那为什么不做呢?我们不应该需要针对不需要专门知识的工作而配备专门人员。

McKergow:我最近一直很多次扮演测试人员的角色。主要做手工的探索性测试,但是考虑系统间的数据流 是一份很有趣的学习体验。这包括确保如果你在系统中更新数据,它会在相应的系统中更新!它也很好地刷新了我的SQL技能。我发现查询数据库的能力对分析有 很有用处。尤其是定量分析有多少用户在使用特定的功能。

McManus:这使得我了解了一些其他的T型技能。优秀的商业分析师现在更加地了解顾客以及他们的软件之旅。他们不仅对为什么企业想要这件既成产品感兴趣,更对这件产品设法解决的问题以及顾客会怎样使用它感兴趣。
商业分析师也处在一个影响团队动力的奇妙位置。他们和产品负责人紧密合作,与开发团队紧密合作,推动决策共识的达成,这是确保整个团队感受到拥有产品的很好方式。这对建立一个整个团队可以一起努力的共同目标也很有帮助。
所以你可以看到,商业分析师可以采取很多不同的方法来成为T型分析师,从而为他们的团队提供更多的价值。

InfoQ:如果一个敏捷团队想自己做分析而不是由商业分析师来完成的话,该怎么办呢?

McKergow:如果一个团队想自己做分析,那真是极好的。那就应该没有任何事阻碍他们。有一些商业分析 师做的真的很有意思的事,他们可以试试。但是他们需要记住商业分析师的缺席不是避免做更多详细分析工作的借口。比如研究一项监管或政策。了解一些复杂的业 务流程也是一个例子。还是要有人来承担这些责任。

McManus:我在一个没有专门商业分析师的夫妇创新团队中工作过。这之间一点也没有觉得不自然,而且在文档类型方案中有非常多的协作。开发人员会亲自采访顾客然后研究解决方案。在那种快速追踪——建立、测量、学习——创新的环境中,正好不需要一个专门的商业分析师。

InfoQ:你有什么具体的商业分析方法推荐给敏捷团队吗?

McKergow:有很多技术可供团队里的人使用。以下是我最喜欢的一些:

  • 3 Amigos from ATDD——不是商业分析师包括产品所有者。就你打算发展的东西和你的开发人员、测试人员和产品所有者沟通一下。甚至是深入细节,关于每个故事的验收标准 的细节。这有关于增强三者不同身份间的合作。你可以参考InfoQ对3 Amigos创始人的采访:George Dinwiddie on the three amigos
  • Story kickoffs——和前面的3 Amigos相似,但尤其是当开始发展一个Story时,让每个人一起讨论它传达的是什么,想想怎么在技术上实施它,以及所有需要注意的事情。我在我们的公司网站上写到了这一技巧:How to introduce Story Kickoffs to your team.(怎样将Story Kickoffs介绍给你的团队。)
  • Design studio(设计工作室)——这是我最近一直在用的一项使得团队合作共同设计产品的技术。团队可以从字面上理解问题的框架,然后在不同的设计中交流不同的想法,最后汇聚成一个成型的设计。Jason Furnell对这一过程有全面的认识:Facilitating Collaborative Design Workshops(促进协同设计工作室)。

如果你处于这种情况,为什么不试试这些技术呢?你也可以扩展你的技能,为你的团队带来更多的价值。

查看英文原文Role of Business Analysis in Agile


感谢张龙对本文的审校。

发表在 未分类 | 留下评论

敏捷领导力的反面模式

Andrew Koenig在1995年造了Anti-Patterns这个词,灵感来自于GoF的《设计模式》一书。而这本书则在软件领域引入了“设计模式” (Design Pattern)的概念。三年后Anti-Patterns因《AntiPatterns》这本书而获得普及,而它的使用也从软件设计领域扩展到了日常的 社会互动中。按《AntiPatterns》作者的说法,可以用至少两个关键因素来把反面模式和不良习惯、错误的实践或糟糕的想法区分开来:

  • 行动、过程和结构中的一些重复出现的乍一看是有益的,但最终得不偿失的模式。
  • 在实践中证明且可重复的清晰记录的重构方案。

很多反面模式只相当于是错误、不可解的问题、或是本该避免的糟糕实践,它们的名字通常都是一些用反话构成的词语。有些时候陷阱(Pitfalls) 或黑色模式(Dark Patterns)这些不正式的说法会被用来指代各类反复出现的不正确的解决方法。因此,一些有争议的候选的反面模式不会被正式承认。

在Agile Practitioners 2016大会上,Regina Martins也谈到了“敏捷领导的反面模式”这个话题。InfoQ随后也对她进行了采访,谈谈是什么让领导力在敏捷里如此重要,成为一个了不起的领导需 要哪些属性,领导力会不会阻碍敏捷团队的发展,有哪些领导力故事可以分享给大家!

InfoQ:在您看来是什么因素促使领导力在敏捷开发中起到重要作用的?

Martins:在我看来,一个组织里对工作有重大作用的领导力维度不仅仅只有一个,第一个可能就是最显而 易见的在固有的领导方式上重新开辟一条新的领导道路。这得从领导角色提供的团队远景以及必要时刻的紧急路线开始,接下来领导者就做一个旁观者,让团队成员 自己决定如何完成任务。因此,在这些领导所制定的环境和氛围中,团队有能力实现“自我组织”并展开工作,向用户提供有价值的服务。

当我们在讨论自我组织团队的时候,其实已经进入到了另一个维度。我也见到过一些组织的领导声称很相信自我组织团队,但实际上的作为是与之相反的。从经验角度来讲,要想对每个细节的管理进行放权是很难的,自我组织需要领导在背后的支持,让团队自己做出决定。

自我组织或团队里的领导如果自己的工作效率很高的话,应该是能理解这一点的,他们的作用就是为团队提供空间或环境。通过他们的这种管理方式,才 能在团队里产生一种互相信任和安全的文化,并创造一些使团队在一开始就能实现自我组织的关键因素。现在的一些领导人刚开始的时候告诉团队该如何做事情,紧 接着就是猜测团队成员,破坏他们自己做出的决定,这其实就是敲响了自我组织的丧钟。

最后一点也很重要,如若敏捷需要成为一个新的规范,那就得从各个类别的组织中产生出合适的领导才行。领导不是一个角色或一个头衔,也不是“负责人”的专属区域。“负责人”是什么意思?意即领导者是应运而生的,所有人都可以根据自己的能力轮流执行领导者的职责。

InfoQ:您能详细解释一下具备什么样的关键属性才能成就一位伟大的领导者呢?

Martins:我第一次参加Spiderman Leadership Workshop的时候遇到一位参会者,他说他认为的要点在于提出的问题要远比问题的答案更重要。当时听到之后就特别的激动,觉得这才是我们应该意识到的 重要点。工作中几乎所有的领导都以知道答案为准则,可实际上,只有团队需要知道答案就行了,他们需要把事情搞明白。他们唯一需要做的时候事情就是在正确的 时间回答正确的答案即可。

为了进一步阐明上述观点,就拿我之前工作过的一家公司为例,公司有专门的人员来指导并教授公司的领导层人员像“球队教练”一样和团队交流,我最喜欢这种方式的原因是给团队带来固有的管理责任感。

这里要说的另一个维度是,通常情况下领导者不仅仅只是一个团队的一部分,根据我的经验来看,决定这个领导者对团队的重要程度有多少,还是要看他 如何在矛盾出现的时候平衡各个方面。另外还有一些其它个人属性需要具备,那就是不断的进行自我反省和总结,还要向团队展示自己的脆弱性,这也是锻炼自己勇 气的最好方式,但是很少有人愿意这么做。

InfoQ:您有案例来说明领导力会阻碍敏捷团队吗?

Martins: 这里有一个典型的反面模式案例,之前有一个兼任IT经理和产品负责人的领导,为了更方便自己获得信息并向上级汇报工作,他擅自改动了团队的工作方式。导致的最直接的结果就是项目经理看到每天的进度不符合标准,无法在规定的时间交付产品,那么只能更换项目负责人了。

其实给项目制定最后期限时间同样是较为经典的阻碍行为,没有失败的过程是学不到东西的,就像时间期限到了但是产品无法交付,项目领导与其责备团队还不如让他们自我回顾一下问题出在哪,能吸取什么教训这样更有意义。训斥只会滋生恐惧,这样的案例只会在整个部门的信任度下降。

InfoQ:对于解决这样的问题有什么好的方法吗?

Martins: 说真的,去找一个Scrum教练吧,同时要记住Scrum方式重要一个价值就是要有勇气。

另一个方法就是鼓励团队发展自己强大的提问题的能力,不仅仅只有领导才能问正确的问题,可以说,每个人都是领导。通常情况下领导做了阻碍团队发 展的事情,会间接的让团队成员成为受害者模式,并以被动攻击的行为作为回报老板的阻碍。通过大胆提问,才能了解什么是真正需要解决的事情,真正的期望是什 么,虽然这听上去很难做到,但是成员之间要有这种勇气去提问,将防守化为相互理解。如果有一个Scrum教练带着做的话,见效会很快。

InfoQ:能在这里分享一些关于高效领导力的故事吗?

Martins: 作为一个有着十多年工作经验的项目经理,我一直用的是传统的Waterfall模式,后来的领导建议我在新的项目里尝试一下Scrum模式,也正是这个之前知之甚少的方式在一个具有戏剧性的情况下改变了我接下来的工作风格。

后来我的领导跟换了,是一个极其善于提问的领导,在一开始的时候我很排斥跟他接触,因为我要思考一大堆答案和决定来回复他提出的一大堆问题,这不得不迫使我绞尽脑汁把脑袋都想通了。当然,他的优点就是在对你绝对的信任的前提下给你绝对多的自主权。

InfoQ:如果组织想要挖掘领导力潜能的话,该怎么做?

Martins: 那就让领导团队的成员模仿组织希望看到的行为,没什么比模仿带来的效果更好了。我就是仆人式领导(Servant-Leadership)的忠实拥护者。

查看英文原文:Anti-Patterns of Agile Leaders

发表在 未分类 | 留下评论