高可用

每个公司对不可用时长的标准似乎不同，像我们搞sass的，标准是某个功能达到一定量的租户反馈有问题，则可算进SLA的不可用时长内。说句大实话，随着服务的增多（目前已经有上千个微服务了），几十个产品，业务的增多，人员的变动，人员能力的参差不齐，线上事故肯定还是会有的，但是我们有完善的复盘机制，也有奖罚机制，每次出问题QA都要拉人复盘，给出各种后续措施，还要全公司通报，因此管理层对服务的稳定性是十分看重，我们目前的目标也是3个9，其实只要有一个组拖后腿，这个目标就很难达成。我们目前用的很多东西都是阿里云的，没有自己搞机房，所以运维基本也都是靠阿里云的工程师来协助处理。2、其他高可用方案：多环境验证（开发、测试、予发布、生产），灰度环境验证（G0、G1、G2），代码灰度上线（根据租户力度），配置项或者数据库的执行需要管理层审核，测试来执行，服务支持跨云部署（阿里云、华为云），南北流量分发，开发流程规范，代码CR，发布回滚机制，数据库监控告警，网关流量告警，服务自动扩容，业务error日志监控告警，数据库按服务拆库隔离，按租户分库，SQL慢日志监控等等。