如何拥抱“you build it ,you run it”

21世纪初期,亚马逊的应用臃肿不堪,经常导致服务不可用,贝索斯受够了这一切,强行规定应用必须通过web service接口来交互。同时推行新的准则“谁构建,谁运行”,团队的职责不仅仅是构建应用,还得让它在生产环境中跑起来,而不是像过去那样,把应用扔给其他团队。

亚马逊很快让应用扩展来支持快速的增长,在这个过程构建了AWS。 其他的公司纷纷想仿效亚马逊的成功。

亚马逊通过应用快速的规模化来支撑业务的发展,在这过程中打造出了一套web service服务(AWS)。其他公司也想复制它的成功,但这并不件容易的事。你需要面临组织架构需要大幅的调整,用户需求延迟交付,团队重组等等问题。但回报也是明显的,团队会比以前更快的实现交付。

那么,组织如何来拥抱“谁构建,谁运行”呢?

“谁动了我的奶酪?”:组织架构变更

构建云应用的第一步就是创建跨部门,多功能产品团队。没有专门的角色区分开发,测试,运维,系统管理员,dba等,但这些技能产品团队必须全部拥有。团队之间的依赖往往让人头痛,想象一下,团队完成了所有的工作,准备发布了,却发现数据库的脚本还需要数据团队来验证运行,你除了干等,别无它法。多功能团队消除了这样的瓶颈,团队成员可以自己来验证脚本,而无需依赖数据团队。

那是好事情,发布devops年度报告的团队研究表明,如果由外部团队来审查代码质量,还不如不审查。因为没有带来任何的质量改进。 一种有效的审查方式是结对审查,会带来更好的交付质量。因此,审查团队需要和产品团队更紧密的合作,变成团队的一员,这样的审查才能带来效果。

不要拖延客户的功能

Zynga是一家社交游戏公司,它的产品Farmville在facebook上发展非常迅速。但公司没有专注于快速满足用户需求,反而选择完善基础IT架构。放弃使用AWS,选择构建自己的云。最终没有成功,又重新选择了AWS。 但公司失去在手机端爆发性增长的最时机。

打造面向产品团队的组织并不意味着要从头开始构建基础云架构。 首先,用web service来构建云应用被证明是可行的,云服务更关注如何为软件提供良好的运行环境,而不是软件本身。其次,产品团队可以专注于产品本身,加快了创新的速度。 聚焦于用户需求而不是内部需求导致用户功能能快速的交付。

当你的巨无霸应用还要增加功能时,试着单独构建这部分功能,并且提供web service接口。巨无霸应用通过接口来调用功能。通过这种方式,使得你关注与你所擅长的:构建应用。应用运行的环境则交给云平台去处理。不要试图自己去搭建云平台,那样会耽搁用户功能的交付,用户会不满,从而影响你的商业目标。

改变是可怕的

让组织能持续产生有效改变的的唯一办法是让改变本身变得有吸引力。 改变是必须的,问题不是如何来改变,而是让团队想要改变。答案很简单:奖励那些投入并且驱动改变的。那些拒绝改变或者旁观的人最终会看到成效并做出选择。

为了成功,你需要一个变更催化剂。 所以,只要团队采用新的方式构建,交付应用的,立即给与奖励。当人们看到奖励了,偷懒的人会跟进。

但是,这不是可持续的方法。团队需要明白他们能做的更好,更快。 那就是自我实现,这是一个更有效的奖励系统。当团队看到自己的产品发布越来越快,并且更少的故障,他们会全身心的采用“谁构建,谁运行”原则。

亚马逊在2000年早期就采用了“谁构建,谁运行”的哲学。从那时开始,公司内部经历了组织架构的调整,面对延迟交付的无谓的害怕,让成员相信拥抱变化。 一旦你像amazon一样学会了有效处理这些问题,你会更容易的转向云应用,并且获得更多的回报。

In the early 2000s Jeff Bezos mandated that all applications at Amazon offer web services that other applications could use to access data and functionality. At the time, Amazon was struggling with a ponderous, unwieldy group of applications. Downtime was an issue, and Bezos had had enough.

Amazon not only rapidly scaled its applications to support growth, it accidentally built Amazon Web Services (AWS) along the way. It’s no surprise that other companies want to duplicate its success.

But it’s hard. You will dramatically change your org chart, run the risk of delaying functionality that customers are demanding, and say goodbye to many employees who don’t get onboard. The reward is clear, however: Your team will be able to deliver improvements faster than ever.

Here’s how to embrace “you build it, you run it” in your organization.

‘Who moved my cheese?’: Changing your org chart

The first step in building cloud applications is creating cross-functional product teams. No longer do you have dev, test, ops, system administrators, and DBAs. You have product teams that encompass those roles and skills.

One of the most frustrating aspects of application release is waiting on external teams to complete tasks that are blocking you. Cross-functional teams eliminate this bottleneck. For example, instead of waiting days or weeks for an external data services team to review an SQL script for execution, the product team can review and execute the SQL script themselves. Goodbye, waiting.

That’s a good thing. The research team behind the State of DevOps report found that companies with zero review prior to application pushes had the same IT performance as companies that had external teams reviewing change. That’s right: External reviews make no difference. The one type of review that did predict software delivery performance was peer review of changes. Thus, if you have a peer-review process, you will have better software-delivery performance.

That’s scary for the teams that perform those reviews. But if you move those reviews into the product team, your company will have better software delivery. Thus, the team members currently performing reviews must work closer with the product teams and become members of those product teams.

Don’t delay customer functionality

We have all seen companies that focus on internal infrastructure at the expense of customer functionality. Zynga was a classic example of how IT decisions can wreck a company. During the explosive growth of its Farmville app on Facebook, it decided to leave AWS and create its own cloud. Not only did it fail, eventually returning to AWS, but it missed out on the explosion in mobile gaming.

Moving to a product-team-oriented organization is not the same as building your own cloud infrastructure from scratch. First, it’s proven that using web services for cloud applications works. Contrast that to Zynga, which worked on how it hosted its software instead of on the software itself. Second, product teams accelerate the rate of innovation in a company. A focus on customer demand over internal demands results in better customer functionality that’s delivered faster.

You can test this yourself. Find a new bit of functionality you want to add to your monolithic application and build it separately, exposing data and functionality via a web service. Then have your monolithic application call the interface to use the functionality. Finally, improve it.

By measuring how each step takes, you’ll prove to others that you can deliver customer functionality faster. In the end, focus on what you are good at: building your application. There are plenty of good cloud computing options out there to house your app. Don’t make the mistake of trying to build one yourself. If you do, functionality will surely be delayed, your customers will not be happy, and your top line will suffer greatly.

Change is scary

The only way to see long-lasting, impactful change in an organization is to make change appealing. But change you must. The question is not how to change, but how to convince your team that it wants to change. The answer is simple: Reward those who engage and drive change. Those who fight change or sit on the sidelines will ultimately see the results and choose appropriately.

To succeed, you needed a change catalyst. So identify teams that are adapting to this new way of building and delivering applications and reward them immediately and loudly. As people see the rewards, the laggards will follow.

However, tha’s not sustainable over the long term. Employees need to see that they can perform their jobs better and faster. That’s self-actualization, which is a far more efficient reward system. As employees see that their own projects get released faster and with less hassle, they will whole-heartedly adopt the “You build it, you run it” mandate.

Amazon shifted to a “You build it, you run it” philosophy in the early 2,000s. Since then, it has struggled internally with changing its org chart, addressing unfounded fears of delaying customer functionality, and convincing employees to embrace the change. But as with Amazon, once you are able to manage these issues effectively, your move to cloud applications will be far easier, and much more rewarding.

Read More

you build it, you run it

“you build it, you run it”,构建代码的人,还得负责让代码在在生产环境中跑起来。相比我在之前一篇博文中提到的“eat your dog food”,职责范围又扩大了。开发人员不满了,代码是我写的没错,咱得分工啊,测试负责测试,运维负责部署,我都要参与,还能不能安静的写代码了?

这个观点不是运维或测试人员提出来的,所以不存在推卸责任的问题。这话是Werner Vogels说的,Werner何许人也,Amazon首席CTO。CTO代表着开发方,提出这样的观点,说明技术团队在整个软件价值链交付过程中的重要地位。在我看来,技术团队的职责不仅向后延伸,还得向前扩展,参与到前期需求的分析中。针对目前很多开发团队渐渐沦为设计团队的实现工具,我感到很是心痛。

这句话如果仅从字面上来理解,很容易让人误解,特别是还在采用传统接力棒模式的团队。

价值是衡量工作成果的唯一标准,代码如果没有部署到生产环境中,对用户提供价值。那就是一堆代码而已,没有任何意义。能否快速的部署,也是衡量代码质量的标准。在本地一切正常的代码,部署到正式环境,就会有出现问题,这样的场景大家都不陌生。对于上线系统的问题,开发人员是最清楚的,解决起来也最迅速,却在被排除在过程之外。势必降低价值交付的质量。

别让反馈环断了。

基础设施即代码

Read More

拆书《凤凰项目》

凤凰项目这本书几年前就看过了,当时是当小说来看的。如今虽然还记得大概的故事情节,很多的细节已经忘却。最近又拿来重新读,本想把书全部看完之后再来写总结,按照目前的进度是来不及了。只好中止阅读,先把看过的内容做个总结。按计划是上周要完成的,这几天脑袋晕晕的,无法静下心来,一直拖到了现在。

背景 正如我上一篇文章讲的,所谓的变革,一定是到了山穷水尽的地步,不得已采取的方法。这本书也不例外,作者一开始就表明了无极限公司面临的困境:CEO辞去董事职务,股票暴跌;公司期待“凤凰项目”来提高竞争力,恢复盈利能力,但几年来项目一再延期,上线遥遥无期。董事会决定再给6个月的时间,如果再无显著改善,公司将面临拆分重组。那意味着大批的人将失去工作。

见面礼 主人公比尔临危受命,虽然很不情愿,还是被CEO说服,担任IT部门的副总裁。比尔最重要的任务就是让凤凰项目尽早上线,其他项目都得为凤凰让路。

比尔新官上任,第一个见面礼是工资系统崩溃了,而且必须在晚上5点之前解决。虽然折腾到半夜才把问题解决,但错过了时间窗口,第二天公司就上了头条。这次事故暴露出的问题是变更流程缺乏。IT部门制定了变更流程,但从来没有人遵守。不但开发人员随意变更生产系统,就是自己部门内部人员,对变革流程都有很大的分歧。比尔的第一个改善就从变更流程开始。

凤凰登场 凤凰项目开发部门抱怨IT部门没能及时配置好测试环境,向高层汇报,说IT在拖整个项目的后腿。会议上开发主管声称下周就可以部署上线。在IT看来,目前连测试环境都没开始部署,下周要上线简直是天方夜谭。同时指责开发提交的产品性能连要求的一半都没有,IT不得不部署更多,性能更高的机器来弥补性能缺陷,这又导致工作量的增加。会议上,双方你来我往,互不相让。不幸的是,为了让项目尽快上线,扭转公司困境,CEO站在了开发这边,决定下周5部署上线。

火上浇油 为了应付外部审计,审计人员列出了厚达200页的问题,将近1000条。并要求下周给出整改方案。IT部门已经忙的焦头烂额,谁还能抽出空来应付审计?讨论中,比尔发现居然没人说的清楚IT到底有多少工作,很多工作都没有记录在纸面上,都在大伙的脑袋中。天哪,如果连自己部门有哪些工作都不清楚,凭什么去向领导要求援助呢?比尔要求马上整理一份工作清单出来。幸运的是,比尔的左膀右臂开始相互合作了,两人一起合计着如何来整理这份清单。这是一个好的开始。

变更流程改进 第一次的变更管理会没有一个人参加,比尔只得动用行政命令,在周五重新组织变更会议,缺席人员将受到行政处罚。周五的会议上,大家纷纷吐槽现有的变更流程,看来要按照现有流程是无法展开工作了。比尔拿出一堆卡片,让大家把变更写在卡片上,然后贴到画着日程表的白板上。一开始大伙有点蒙,这是什么玩意?有用吗?但还是有好奇的人把自己的变更贴在白板上,随后大伙也纷纷开始效仿。2个小时的会议,虽然只通过了5个变更,但重要的是,大家开始开始积极的参与讨论,讨论变更的风险,讨论变更是否必要等等。当各部门开始沟通了,我相信问题已经解决了一半。

导师降临 其貌不扬的往往都是高手,这点东西方认知还是一致的。未来的董事会成员埃里克要见比尔,比尔一开始把他当成送甜甜圈的服务员,和他聊起了自己和夫人是多么喜欢这家店的甜甜圈。等埃里克表明身份后,场面显得有点尴尬。

埃里克听了比尔关于如何改善IT效能的想法后,说你还没弄清楚什么叫工作,又怎能提高IT的效能?这让比尔很不爽,接着埃里克又拿工厂做比喻,向比尔灌输了在制品(WIP),瓶颈,三步工作法等概念,最后又让比尔回去找出四种类型的工作。比尔觉得IT工作不能和工厂类比,埃里克的话虽然记在心里,却也不以为然。

确立变更优先级 实施变更看板以来,不仅墙上贴满了卡片,会议桌上也小山似的堆了起来。要在变更会议上评审这堆卡片,估计得花几天时间。为了提高效率,团队调整了变更流程,首先按照优先级对变更进行分类。常规性的变更,因为经常在操作,基本无风险,无需讨论可以直接通过。高风险的变更通知业务部门,并告知相关的风险,由他们决定是否实施变更。中等风险的变更需要通知可能受影响的人,并得到他们的认可。由于事先准备充分,变更评审会议变得极为高效。白板的引入,让变更变得透明,透明又促进了沟通,协作。新式的变更流程让各部门都参与进来。合作,已经从IT部门内扩散到部门外。

未完待续………

优化瓶颈 变更流程跨出了良好的一步,Patti花了很多的精力整理变更卡片,却发现计划本周完成的工作实际只完成了40%,其他的不得不拖到下周。而下周有 会有更多新的变更。进多出少,Patti意识到自己将被卡片淹没了。这样的场景让Bill联想到了工厂的生产场景,大量的半成品堆积在车间。原因都是一样的,是瓶颈制约整个流程。这个瓶颈就是brent。优化瓶颈,首先得知道哪些工作会流向瓶颈。Bill让Patti把涌向布伦特的变更任务先揽下来,过滤处理,并在变更卡片上表示出来,甚至可以要求在所有新卡片上都标注这一信息。等我们知道和布伦特相关的变更是什么、有多少,就把结果反馈给你,还要确定它们的优先级。

风暴来临

计划5:30开始部署,4:30还没有通过关键节点测试,而开发已经下班回家了,只好全部叫回来修复问题。没人告知防火墙还需要开放端口,导致前端无法访问数据库。总之,快到晚上8点了,情况还是一团糟。 bill叫来了wes和patti,同时把负责测试的william也一起叫上,讨论当前的情况。 开发版本提交太快了,往往上一个版本还没测试完毕,下一个版本就来了。而且为了防止弄坏别的东西,提交的都是增量更新包。现在已经没有一个稳定的发布版本了。明天8点门店营业之前,恐怕无法让凤凰正常运转起来。 凤凰好歹上线了,但系统无法和门店pos机对接,所有的交易都得手工完成,财务部门不得不抽调大批人手来处理。系统还有泄露银行卡号的风险。性能问题严重,不得不隔几个小时重启。直到周一晚上,门口终于可以使用收银机了。虽然只是个临时解决方案,至少没有了信用卡号泄露的风险。

鉴于这次凤凰上线的失败,让董事会很是脑怒,CEO把责任都推给了开发部和IT部,计划拆分公司,并外包I T业务,这意味着很多人包括bill自己都将失业。

开发部的chris和bill一起吃了顿饭,现在火收到他们上了,他们得想想如何来应对,饭桌上,两人谈了各自的难处,开发部疲于应对各种问题,没有时间开发功能,项目部署需要的时间越来越长,技术日新月异,让人有点跟不上了。 chris说的代码完成时间,sarah认为上线时间,导致目前这样的局面。chris对此感到抱歉,应该听取william的意见,推迟上线时间。 最后,两人达成统一战线,共同对付sarah。

变更流程取得了一定的效果,有两个团队的变更都涉及同一个数据库,变更流程让他们看到了潜在的冲突病很好的解决了。因为凤凰上线导致几百个变更延迟,引出第四种工作:计划外工作。

优化瓶颈,没有围绕瓶颈做的优化都是幻觉。找出IT运维和工厂之间的对应关系。 不要让约束点迁就别的资源。 不惜一切代价消灭计划外工作 相比于向系统中投入更多的工作,,将无用的工作剔除出系统更加重要。为此,你应该知道,与实现企业目标息息相关的是什么,不论它是项目、运营、战略、法律法规合规、安全性,还是其他别的什么。” 他继续说:“记住,重要的是结果——而非过程、管理,或者你完成了哪些工作。” “别心烦意乱的。等你知道了怎样有效控制发往布伦特的工作量,就给我打电话

发票系统故障,盲目的行动可能导致更大的错误。这次重点在分析故障原因,没有许可,不允许对系统做任何的操作。晚上9点多了,问题原因还是没有找到,ceo坐不住了,让bill赶紧叫上所有人,行动起来,而不是像现在干等着分析结果。bill坚持认为他的作风是正确的,和ceo大吵一通,一怒之下,辞职不干了。

场外会议 如何建立团队信任,展现脆弱的一面。 当每个人都讲了自己的经历,bill甚至流泪了。生活中每个人都有自己的不如意,在会上分享,让大家相互间更好的了解。 ceo谈到IT的人不懂得如何去承诺,安排给IT的工作总是延误。chris认为自己总是完成了工作,wes马上反驳,如果是这样,凤凰也不会搞的一团糟了吧。chris红着脸说,代码确实按计划完成了。bill插嘴道,我们对完成的定义理解不一样。开发部总是没有吧运维工作考虑进去,或者即使考虑进去了,也耗尽了所有的时间,没有留下空间给运维。chris也承认这一点,并说我们有一大堆程序等着部署,我们的工作都被部署工作延误了。 bill谈了下目前运维的工作,除了35个业务项目,还有75个运维项目,有几千个变更需要实施,同时又有很多的计划外工作,大多是由于脆弱的应用程序故障造成的,包括凤凰。基于目前的工作量,大大超出了人力负荷。

IT运维部和开发部在两周内不再接受新项目,并且除了与凤凰相关的工作之外,停止IT运维 部的其他所有工作。

你其实是在构建一份资源清单。也就是材料清单以及所需工作中 心和工艺的清单。一旦有了这个,再加上工作订单和你的资源,你最终就能够理解你的生产能力和需求是 什么。这将让你最终明白,是否可以接受一个新工作并对其作出实际安排

改进的内容几乎是无关紧要的,关键是你要不断改进

研究表明,每天训练五分钟比每周开展一次为期三小时的训练更有效。如果你想 要营造一种真正的改进文化,就必须把那些习惯建立起来。”

通过监控项目,减少问题流向brent的可能性。 弄清楚整个工作流程,哪些工作的是安全的,哪些需要经过约束点。以此作为安排工作的依据。

“在我们离开之前,把你的注意力从工作中心转到工作中心之间的那些空间上。 与控制工作发布同等重要的是管理好工作交接。一个给定资源的等待时间,是那个资源忙碌时间的百分比除以空闲时间的百分比。因此,如果一个资源使用了50%,等待时间就是50/50,或者说1个单位。如果这个 资源使用了90%,那么等待时间就是90/10,或者说9倍时长。那么如果这个资源使用了99%呢?” 尽管还不太理解其中的关联,我还是在心里计算着:99/1。我说:“九十九。” “正确。”他说,“当一个资源使用了99%,那么等待时间就是该资源使用50%时的99倍。”

‘第二工作法’的一个关键部分是让等待时间可视化

Read More

吃饭问题

2年多了,一直在客户现场上班,回到公司,感觉还是有点陌生,搞得像个新员工一样。相比客户现场,公司的办公环境是好了很多,唯一不足的地方就是吃饭。客户是机关单位,有食堂,15元钱,两荤两素+水果。很实惠了,更关键一点是相比外面饭店,卫生安全多了。晚上5块钱一碗水饺,真的是物美价廉。所以不管加不加班,都会吃了晚饭再回家。

回到公司,只能去外面吃,或者点外卖。公司附近吃饭的地方倒也不少,但就是提不起胃口,早些年天天在外面吃,真吃厌了。心里有了自己带饭的念头。最近加班也少,晚上回家把炒点菜,第二天带到公司用微波炉一热,吃饭问题就解决了。当年去美国出差的时候,大伙都是这么干的,一到中午,大家就在微波炉前面排队热饭。我记得有次一同事直接拿了一筒干面来,我真不知道他后来是怎么解决的。

上周就在网上淘了一个饭盒,前两天又把厨房重新整理下,把没用的东西都扔掉,重新清洗一遍。经常在做饭的,也不觉得厨房有多脏。一段时间不用,就觉得到处都脏。一切整理完毕,就等开工了。

下班路上刚好有个菜场,买点蔬菜,家里还有鸡蛋,就不准备荤菜了。2个素菜加炒鸡蛋,就是明天的菜了。回家后,先煮个面条把晚饭解决了,然后把菜炒好。因为一个人不能煮太多饭,电饭煲不太合适。就直接把米放到碗里,洗净后放置一会,再加点热水,放到蒸锅上蒸30分钟就可。饭菜准备完毕,装入饭盒,放入冰箱。明天的中饭算是有着落了。

Read More

垃圾分类

之前上海搞垃圾分类,网上各种关于垃圾分类的只是,算是给我扫了盲。虽然对干垃圾湿垃圾还是有点糊涂,至少知道了塑料原来是可回收垃圾。如今杭州也开始实施垃圾分类了,先从写字楼开始试行。不知道其他地方怎样,反正我公司所在的大楼也试行范围内。一大早,就有人员在电梯口发放垃圾分类说明传单。我也拿了一张放在桌上,以便随时参考。

公司里每个桌子旁边的小垃圾桶被收走了,在指定的地方放了两个大垃圾桶,一个蓝色,一个灰色。还有一个绿色的因为是食物垃圾,易腐烂,所以放在了外面的楼梯口。放垃圾的地方还有监控,如果乱放垃圾被拍到,可能还会罚款。

一时间,不知道如何仍垃圾了,手册看了好几遍,还是没记住。每次扔之前,都要对照一下,明确是哪个颜色的桶。还好办公场所,垃圾不多,倒也没造成太多不便。

之所以要实行这么严格的垃圾分类,因为垃圾问题已经是相当严重了。我们扔到的垃圾,在自然界转了一圈后,又回到了我们的体内,影响我们的健康。关于垃圾问题,我认为宣传的力度还不够大。很多人,包括我自己,这方面的意识还很薄弱。

几十年后,地球会不会变成一个垃圾场?这显然有点杞人忧天,随着科学的进步,一定会找到相关处理垃圾的方法。

Read More