你好呀，我是歪歪。
之前给大家分享了《关于编码高可用的一点思考》这篇文章，里面提到了一个观点：有的时候我们都是在基于运气编程。
今天再给大家分享一篇文章，里面提到的是另外一个观点：面向失败编程。
在这个行业干了这几年，我越来越意识到，面向失败进行设计、进行编码，才是真正的保命之道。
你想想，你编程的时候，是不是最好写的永远都是正向流程，最难对付的永远是各种各样的异常情况。
正向流程写起来行云流水，但是处理异常情况的时候就焦头烂额，害怕有什么考虑不周的地方，导致线上出现问题。
不论是面向运气还是面向失败，其他它们都殊途同归，为的都是系统的运行的稳定性。
在开发设计阶段，充分考虑失败场景，才能减少失败的概率，向死而生，不是乱说的。
面向失败编程，或者说防御性编程，是编程中最难的事情。
话说程序员小林的某一天：起床-吃饭-坐地铁-到公司-敲代码-回家-玩游戏-睡觉。
这一天的另一个版本：起床-吃饭-坐地铁-到公司-突然要24小时健康码-进不了公司-坐地铁回去-地铁停运了-上厕所-踩到屎滑倒-摔成脑震荡。
第二个版本充满意外，貌似有些极端，但你我天天在新闻上看到类似的事情，说明它其实每天都在发生。
程序也是如此。
程序员小林给公司开发的某个系统，用户量暴涨；三年后公司上市了，小林喜迎白富美。
另一个版本：上线后第二天被SQL注入删库了，造成大量投诉；小林被老板痛骂一顿后，卷铺盖走人了。
论概率，卷铺盖的概率一定比娶白富美的概率高。
程序的世界充满意外，你我的每一行代码几乎都是bug。
写出可用的系统很容易，但写出健壮的系统很难。
一个“简单”的例子我们通过储值卡消费这个例子来看看如此”简单“的案例到底存在多少让人眼花缭乱的失败场景。
假设我们给某个加油站开发个储值卡系统，用户可以往里面充钱，可以用储值卡加油消费，类似你在理发店、洗脚店开的那种充值卡。
我们看看车主加油消费的场景——而且只看这个场景中的”储值卡扣款“这一个结点。
正常流程（简化版）大致是这样的：
流程很简单，加油员加完油后，用户掏出手机扫码进入付款页面，输入油枪、金额，选储值卡支付，输完密码后点提交。
后端创建订单后调卡服务的扣款接口执行扣款（传入卡号、订单号、金额）。
卡服务扣款成功后返回告知用户付款成功。
”这个需求大概要几天开发？“产品经理问小林。
”五天。“小林觉得五天绰绰有余。
”三天吧，这周我们就要上线。“
”那就三天。“小林觉得其实三天足够——不就一两个接口调用嘛，卡服务是现成的。
于是小林撸起袖子开始敲代码。进展比预想得要顺利，两天就敲完了（多少加了点班），一天测试完成，第四天就上线了！
某天夜里，小林正在撸猫时，运营同学打来某车主的卡被莫名其妙扣款了！
事情是这样的：车主鲁某加了元的油，选择用储值卡支付，结果系统提示扣款失败，于是鲁某换