影响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就用去了。