Contents
  1. 1. Design for Failure
  2. 2. Responsibility for Failure

最近滴滴的事情闹的很大,也被骂地很凶。我当然也认为滴滴有错,没有尽到应有的责任。但是,我并不认为关停是好的做法。试想一下,如果是普通的出租车或者黑车出事,有可能那么快抓到人吗?科技和数据是先进的表现,滴滴拥有比出租车把事情做好的更优越的条件,只是它们的关注点没有放在安全上面,甚至是忽略了。

本文并不主要讨论滴滴,而是有感于 TK教主(网络信息安全领域大牛)发的微博:

tombkeeper weibo

Design for Failure

我不记得自己最早什么时候看到关于这个观点的文章或者书了,或许是 Martin Fowler 大叔的这篇关于微服务的文章吧。“为了失败而设计”?其实它要表达的意思是“为应对失败而设计(因为失败无可避免)”。失败指的是出错,并没有按照预期的方式运转。

如果页面打开时 JavaScript 或 CSS 文件加载不成功,或者服务端接口数据出错怎么办?后台定时运行的一个 Job,会不会因出错导致中止运行?假设一条数据处理出错,那会不会影响其它数据的处理?如果因为 Job 有 Bug 要停止运行,数据堆积了一个小时,一天,甚至一个星期,修复后如何重新运行这个 Job,要花多长时间?如果一个服务器 down 了,能马上启用一个新的吗?如果不行,按平时的流量,另一个服务器能撑多久,要不要降级,哪些次要的服务可以暂时关停?

无论是前端,还是后端开发,或者是运维等,都可能面对各种失败。不同的失败场景,有不同的处理方法。而不同的失败场景,也体现了设计者本身的关注点,和职责所在。

Responsibility for Failure

一个后端开发人员,主要考虑的是系统功能的失败,如何在发生了故障的情况下依然尽可能正常地提供服务,保障数据的正确性等。他们负责的对象以系统为主。

一个前端开发人员,主要考虑的是减少失败场景对用户产生的挫败感,尽可能让用户达成使用产品功能的目标。他们负责的对象以人为主,但主要也是针对用户体验、产品功能。

一个安全人员,主要考虑的是系统防护安全的失败,如何在不同的防护层被黑后减少对系统的影响,和保密数据的安全等。他们负责的对象以系统为主。

虽然上面举例的一些人还是以系统为主要负责对象,但是,其实系统背后也承担着使用系统的人的利益。

保障数据的安全,其实就是保护用户的资产。花功夫在这上面的企业,才是真正重视用户的资产,为他们负最大的责任。所以说,一个人,一个企业为了哪种失败而做出精心的设计和准备,其实体现了他到底是为谁而负责。

并不是每个人都能像 TK教主 那样有那么强的安全意识。但是,如果出现多次这样的事情都不能做出有效防护手段,就说不过去了。而滴滴,在接二连三的意外出现后,都没能有效地做出调整,可见用户安全这个场景对他们来说真的没有认真考虑。

一个参与创业者,最应该考虑的失败应该是项目失败或者公司面临倒闭。那 Ta 是提前怎么考虑过的?是另寻工作,变卖抵押自己和家庭的资产,还是甚至结束自己的生命?Ta 到底最终为谁负责?

对于一个普通人来说,最大的失败可能就是意外死亡,有没有为这个准备好也体现了他是否为家人负责。

每一个人都注定面临各种各样的失败,想想你都为哪些做好了准备。

Contents
  1. 1. Design for Failure
  2. 2. Responsibility for Failure