影响SLA的主要问题

就说说从技术角度来考虑线上SLA的主要问题。

几个大部分就是: 发布, 手动操作, 流量, 安全

首先还是要统计下这4个在SLA事故里的占比。

发布

发布和更新在一般意义上是影响线上sla最大部分。

回归测试

这里涉及到新功能,新接口的稳定性。
是否有影响到旧有的接口。
以上两个一般测试做一个回归测试就应该可以完成。这个一般测试都会做。

压力测试

所有涉及到的接口或者功能都需要进行一轮压力测试。至少需要满足产品的预期设定。而运维就应该以此为上限。
这个一般测试也有都有现成的工具去做成。

破坏性测试

这个netflix有一个叫混沌工程。
随机终止在生产环境中运行的虚拟机实例和容器。
磁盘满,网络满,进程假死,通讯延迟,时钟不同步等等。
具体可以参考:
https://github.com/dastergon/awesome-chaos-engineering

灰度发版

对于有用户id的系统,那就直接用用户id进行灰度发布。对于没有用户id的,那就根据用户ip,地域来进行灰度。

研发评审

研发在写代码前,需要让运维和测试进行技术评审,不光是架构,还有各种api的交互,这样让运维和测试都有底。同时规避掉很多上线后可能导致的灾难。
作为测试和运维不能等着研发自己去想到一些问题。因此什么基础资源使用规范这些就很有必要了。

手动操作

最好是没有直接ssh到线上操作的内容。

整理下现在线上操作都有哪些?

看日志,看配置,看状态。

日志

大家都说用ELK处理,但是这个日志量少的话还行,要是每分钟就好几个GB的日志,那也挺麻烦的,可能要求的es配置还不低。
后期可能得更多会用druid来进行处理。爱奇艺在日志实时数据监控的探索与实践
但是就算是es很多研发同学也不一定会lucent的语法。这个教几次或者自己看下很快就会了。然后一般情况下elk不行了就加kafka。
不过一直这样就不是办法了,要么扩es,要么优化下写入。

还有一种就是查数据库的,比如es,mysql,redis。这些貌似没有很好的开源方案。我司就直接用python撸了套系统来干这个,只读查询,限制各种命令的使用。
为了防止单查询就把线上系统搞挂,要么限制的恨死,要么权限很少人有,再不行的就专门整个slave去查。

配置

应用服务配置,这个现在都走config server了,所以这个也好看。
机器配置呢直接看cmdb.
但是一些比如tcp缓存,tcp拥塞参数呢?
这个就统一配置,统一版本,统一软件,一套应用服务相同配置就行了。一些基础应用服务也一样。

状态

这个基础服务都从监控系统里看,所有服务自己上线前确定好自己的health接口返回信息。
Prometheus定期去收集并存放。
其他就通过JMX来获取对应信息了。

流量

这里的流量不光只网络层面的流量,还包含qps等。
那首先所有的服务都要有限流,超过XXX就直接返回,或者不返回。其次要有开关降级,只保证核心功能?
这些都是产品设计阶段需要考虑好的。
其次我们要迅速知道这些流量从哪里来? 从哪个客户来? 影响的服务主要是哪个?还是属于恶意攻击?
这些信息从哪里? 日志,监控系统,要没有就赶紧补上吧。

快速扩容

在云上就比较方便了,快速扩容一般都是分钟级别的。主要时间应该就是购买机器和初始化了。
但是有些含有数据的服务你加入集群并不是能很快工作,可能还有数据迁移什么的。所以这种含有数据的服务必须要保证XX%的冗余。

限流

如果确认不是ddos攻击,那就只有快速限流一条路了。
这种要是平时没有准备,那基本干不了。哪些接口可以封,限流策略是怎么样的?怎么保证核心功能可用。
这些都是需要产品,研发以及管理层确认好的。然后限制措施是否有效等等。

安全

这个已经有微盟的教训了。
https://www.zhihu.com/question/374518368

备份,备份,备份。这几个说多少遍都不为过。但是你们有定期验证这些备份的可用性吗?

要是在云上就帮你省很多事情了。

但是说的各种权限分离什么的,这个就看公司类型吧。有些真的SLA故障的时候,可能一个授权的时间就把一个月的SLA就用去了。