基本概念
系统可用率，通常用可用时间来衡量和定义。我们通常所说的几个9，比如4个9，即可用时长99.99%，按照4个9的定义，全年系统的不可用时长也在52分钟左右，差不多一个小时宕机的时间，这样子来看，其实对业务的影响还是很大的，试想，一家每天有上百万交易额的公司，一个小时意味着有多少成交的损失？所以，4个9岁然看起来已经很高，但是细算到时间，对业务的影响还是很巨大。
随着9的个数增多，说明系统全年不可用时长在变少，系统在变更的更加稳定。这里的不可用时长，当然是不区分场景和时间点的。只要系统在任何时间有一分钟不可用，都会计算到这个不可用时长中。所以要提高可用率SLA，还是需要下一番功夫的。
基于概率论的角度来看，每个系统都有出问题的概率。而当系统变得更多，整体出问题的概率就会变高。这个不难得出结论。这里举例，单个系统的可用率是90%，如果两个系统关联叠加，那么他的可用率会立刻降低到A(90%)*A(90%)=81%。所以，核心系统提升自身稳定有一个很重要的点，就是降低对外部系统的依赖。
原则
简单粗暴法则
保证自身系统代码的干净、整洁。这里推荐两本书《effective java》和《代码整洁之道》。对于业务系统研发来说，越简单的代码，维护性/可读性就越高，出问题的概率就越低。
曾经阅读过一些人写的代码，各种递归，多种抽象。一些简单的业务逻辑实现，写的代码抽象一层又一层。最后自己第二遍去读的时候，都很费劲。所以，能用一种方法搞定的，就不要用两个方法来搞定。能用if判断说清楚的，就不要用超级复杂的正则。能用两个for循环搞定的，就不要用循环嵌套的递归。
相信很多人听过一句话：大道至简。对，大道理都很简单。复杂的业务逻辑，也可以用简单的方式去实现。对于系统之间，我们要做到高内聚，低耦合，系统内部，我们也要做到高内聚，低耦合。系统内部的高内聚，是功能的内聚，低耦合是模块之间，或者实现/方法之间的低耦合。因为耦合增加了复杂度，导致了可用率降低。
举个例子：
代码逻辑实现复杂度A→即单个方法的实现复杂度是A。我假设这里A是纵向实现复杂度。而横向实现复杂度，即多个方法的组合实现，达成一个纵向单体实现的目标。
我定义横向复杂度是B。A的实现需要100行代码，B复杂度实现，需要3个方法，各40行代码，3个方法功能内聚，彼此解耦。这里更推荐用B复杂度实现。
在和微信openapi进行交互的时候，需要判断获取token去操作，但是token有过期时间。一种做法是，在请求的时候去缓存取(为什么放缓存？因为很多系统都会用)，取到，判断是否过期，如果过期就调用微信刷缓存，不过期，就用。如果取不到，也要继续刷微信的token。
但是这里还有一点，集群部署的话，其他节点也会去如此操作，就需要在请求的时候一旦需要刷微信token，就要加锁。大家很容易发现：这里要做几件事：保证token有效，业务请求需要获取token。而我上面描述的做法讲几件事放在一起去做掉了。这样子就导致实现逻辑超级复杂。而且代码很容易出错。我们何不分两个方法实现：1、一个线程定时轮询，保证token有效。2、业务线程直接获取缓存token。两个线程各司其职。
所以，通过上面的案例不难看出，降低一件事情的复杂度，就是分解他的复杂度，按照步骤和职责来分工，各司其职，保证自己的结果是正确的就行。而硬要将几个步骤合成一个步骤完成，无异于又增加了本身的复杂度。
孤岛法则
孤岛的含义是隔绝，与外界没有任何关联。当然，这里所讲的是，系统尽量降低对外部系统的依赖。因为依赖方越多，你受牵连的概率就越高，不可用率就越高。
单个系统的可用率=自身系统的可用率。如果涉及到外部依赖，依赖方是B，C。B有2种情况会出问题，C有3种情况会出问题，A有一种情况会出问题，那么A整体出问题的情况就变成了123 = 6。假设概率均等为10%，这里我们判断出问题的概率必须用墨菲定律了，即10%累加。而不能相乘。
以上不难理解，关联依赖方越多，出问题的概率就越高。作为核心系统，那就更应该降低对外部的依赖。注意这里描述“依赖”，不是杜绝外部交互。我想表述的是，能自给自足，就不要靠外部实现。能用本地缓存，就不要用redis。能用mysql分布式锁，就不要用redis分布式锁和zookeeper，毕竟mysql是业务存储，系统必不可少，属于系统自身的一部分，他的可靠性远比使用外部redis和zookeeper来的要高。
B角色法则
A不可用，有B可以替代。现实生活中，叫B角色(backup角色～～，并非谈朋友的“备胎_”)。大了来讲，我们机房都会做冗灾策略，小了来说，我们系统有降级和熔断。这种B角色体现到了方方面面，俗尘留一手。思考问题，也要遵守墨菲定律，坏事情总会发生。系统上线，必须考虑到任何可能的场景，在某个时间点都会触发。程序实现，就是这种情况哪怕只有万分之一的机率发生，我们也要去处理。
系统实现，注意以下几点：
1、外部系统调用的超时机制处理。->failfast?降级？
2、外部接口不可用的处理。->降级?同步转异步？
3、db不可用的情况处理。->缓存？短暂数据不一致？
4、缓存击穿情况的处理。->短暂系统性能损耗？
5、服务器宕机情况的应急处理。->冷备？
6、专线和A机房不可用情况的应急处理。→多活？
任何情况，都要保证你的mr.right。
总结
通用法则，在提升系统可用率低时候，进行参考执行。配备必要的监控和预警策略，以及线上定位问题的工具。在事前，事中和事后三个维度来增强。我相信，系统的稳定性和可用率会大大提升。
当然，谁也不能保证问题不会发生，即使你做的再多再好，生活/工作中的小意外无处不在。
但是思路总是：预防问题->出现问题分析解决问题->复盘总结/制定规避措施->持续跟进落地预防措施->观察分析/解决问题...........。如此循环反复，形成闭环，能预知问题发生的概率会越来越少，系统会越来越稳定。