工程师思维随笔

工程师思维随笔

不能将碰运气当成战略 --《SRE Google运维解密》

double check

互联网的敏捷开发，导致开发、测试、验收时间都很短。有时候业务过于紧急也导致很容易出线上问题，一个很简单避免低级故障的办法，就是double check。double check一般来说，最好是不同的同学，极端情况下，没有其他辅助的同学，也可以一个人完成。当然这个是最不建议的。
double check一来可以通过不同的视角来纠正和确认低级问题。

监控

业务上线后，测试都是OK的，但是如何保障整体稳定性、持续稳定性？这是对一个系统非常难的考核。如何保障一个系统的高可用，监控则是非常重要的一环。对于系统来说，有几个非常直观的指标：接口RT、QPS、成功率、吞吐量等。

屏幕快照 2020-07-23 下午5.29.09

通过监控接口RT、成功率可以清楚了解当前接口的耗时风险、依赖外部接口的风险，同时可以快速定位到整体系统抖动的时间点和大致原因。

稽核

在监控都正常，但是发生了数据不一致的情况下，往往会出很大的资损漏洞。很多时候，开发辛苦加班加点编码，测试辛苦加班加点测试验收，最后发布上线，当以为皆大欢喜时，最后发现出现了一个较为严重的漏洞，没有验证到，导致出现极大的故障。
比如秒杀系统发现没有验证到最后一个库存的场景，导致严重超卖。比如优惠券使用存在BUG，导致无门槛购买任意商品。对于复杂系统来说，没有办法完全走查到所有的代码，也无法100%覆盖验证到所有场景，特别是对于高并发的情况下。那么端到端的监控、稽核则变得尤为重要。

稽核一般采用点对点的策略，即稽核两个数据源是否符合预期。比如稽核场景为：升级订单不得为0元；退款后微应用解除授权；支付后权益开通成功等；

灰度

相比用一个最简单的方式来降低系统上线的业务风险，灰度策略是最轻量级的，最容易实施的，几乎所有的场景都可以用灰度的方式来控制风险。灰度可以按照用户比例，可以按照地域，可以按照生效时间点，可以按照机型，可以配置随机策略等等。如果说全量100%的风险是100，不发布的风险为0，而灰度则可以灵活在0-100中自由控制。
其中AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

开关

灰度是一种调节式策略，而开关则是一种紧急情况下的快速恢复预案，开关一般只有两种状态，即开、关，可以用来在极端场景下的快速切换。在较大的系统里，可能有几千台机器，发布一次可能需要几个小时，如果发布中或者发布后出现了业务问题，使用回滚的方式往往可能耗时太久，进一步放大故障，而具备开关的情况下，只需要调节开关，就可以无缝快速切换业务。

兼容式编码

对于具体编码来说，也有很多方式可以降低编码代码的风险。其中第一点就是兼容性，代码具有对动态和存量数据、接口的兼容性。比如系统对外提供了一个api，function(a,b)，需要优化成function(a,b,c)，就不能直接修改原来的function，而是需要提供一个新的function2(a,b,c)，保留原来的function(a,b)。就算业务方也修改了调用api，在开发环境中也改成了function2(a,b,c)，也要考虑到发布期间的调用情况，不能直接修改function(a,b)。对于同样的数据，也必须做兼容，需要兼容存量的数据。

总结

稳定压到一起，稳定性始终是一个系统最重要的基础指标，没有稳定性的系统，不管业务如何丰富和复杂，给用户的感知始终是不好的。而且，一个有故障的系统，不管开始多小，都有变大的可能。
大家信任windows，windows除了强大之外，就是稳定。因此不管业务跑多快，稳定性始终是不能丢弃的一个指标。
在业务发展越来越快的今天，已经无法像传统软件公司一样投入大量的人力物力到测试中，因此对如何快速实现系统稳定性有了一个更高的要求，即最小成本的稳定性管控。