BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

架构师(2015年5月)

| 作者 InfoQ中文站 关注 53 他的粉丝 发布于 2015年5月11日 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

卷首语

Tim Yang老师前两天在他的微信公众号timyang_net上更新了一篇名叫《软件的体验障碍与解决之道》的文章。标题有点讳莫如深,所以我一开始没敢进去看;结果Tim Yang老师把这篇文章发了朋友圈,号召小伙伴们都去看看捐个茶叶蛋否则过两周才写下一篇(让你们不点赞,等死你们!),于是乖乖的进去仔细拜读了好几遍。

以我浅薄的理解,该文章的前半部分问了一个问题:用户使用某些云同步服务,该服务因为某些莫(tian)名(chao)其(zhuan)妙(you)的网络问题而造成频繁的同步失败。尝试解决此类问题,将对工程师极不友好,因为将不得不引入非标准技术方案。而放任此类问题,将对这些被影响的“一小撮”用户极不友好。那么,到底这个问题值不值得解决?

文章的后半部分没有直接提供答案,只是说从架构师的角度,自己反对引入非标准技术方案。

这个问题值不值得解决,我是想不出来。不过文中对“工程师体验”和“用户体验”的论述,是个很有意思的话题,因为从某种层面而言(以前的我一直没有意识到),“工程师体验”和“用户体验”是会出现冲突的!而且是经常!

不禁想起上个月QCon北京的时候听阿里云的献涛同学分享他们做Xen上的内核hotfix方案,该方案可以说是用户体验优先的一个典型代表。Xen在3月份爆了一个高危漏洞XSA-123,大意是你的云服务如果是跑在Xen上,那么你的客户机们说不定能够读取到其他客户机们的数据,所以必须修复。目前,内核本身的hotfix技术虽然已经相对成熟,但是要想在hypervisor上操作却还没有标准的做法,所以从“技术标准化”的角度,只能乖乖的给所有服务器打冷补丁再重启。这无疑会伤害用户体验。

对于用户至上的阿里同学们来说,这能忍吗?不能忍!于是“非标准技术方案”就势在必行了。该方案基于一个内存覆写的原理,一个非常规的实现方式——人工截获DMA请求,修改之,以在原本没权限访问的hypervisor内存空间实现写入操作。修复思路像极了打电脑游戏用动态修改器作弊的思路,但是细节操作的难度更大,如果没有吃透Xen的代码是不敢随便玩的。

这是一次成功的hack,达成了在没有影响用户体验的前提下给全部集群完成修复的目的。

单独看这次修复,一切都很好。但对于一个庞大的线上系统而言,如果每天都冒出n多这种需要用“非标准技术方案”解决的问题,可就大大的不好玩。但凡是有点技术洁癖的工程师,如果他在公司的每一天都在处理这样的需求,恐怕会发疯。

不管用户体验一定是不对的。但,不计代价的“用户体验至上”,大概也是一个误区。“用户体验至上”当作宣传口号还行,如果在具体面对每一个工单需求时把它当作权衡原则,注定会造成大量投入产出比低下的疲于奔命。不过对于这个问题,也有众多业界前辈们提出一些量化的权衡方法,比如有个叫做T-shirt size estimation的方法,就是给研发经理用来跟产品经理“拉扯”用的利器。

从工程的角度,有一些事情虽然不利于用户体验,但也要坚持,就好像建筑工地一定要坚持工地安全准则一样重要。其实这也算是“现在”与“未来”之间的权衡吧。

——杨赛

目录

热点 | Hot

Apple Watch两个月开发的一些收获总结

开发者必须关注的微软技术热点——Build2015大会综述

Docker发布新的网络项目,并开始招聘中国区主管

专题 | Topic

Netty系列之Netty编解码框架分析

深入浅出Mesos(一):为软件定义数据中心而生的操作系统

深入浅出Mesos(二):Mesos的体系结构和工作流

微博“异地多活”部署经验谈

推荐文章 | Article

Java字节码忍者禁术

专访ThoughtWorks王磊:从单块架构到微服务架构

高效运维最佳实践(03): Redis集群技术及Codis实践

观点 | Opinion

赵海平:开源是个兴趣活儿

性能优化:一个全栈问题

手动测试是否可以退出测试舞台?

封面植物

 

亚马逊中国可下载本书的Kindle版本

百度阅读在线阅读

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT