在梳理好有哪些系统将参与到大促后，我们的目标就是对它们的现状进行健康检查，为后续制订优化方案提供数据支持。

同样，检查纬度还是依照上面罗列的，从自身、依赖方、服务方、基础服务和后台服务五个纬度来检查。

自身

1、硬件
主要是检查服务器的各项指标，包括CPU、IO、内存、连接数以及磁盘剩余空间。

2、软件
此次我们只是着重于检查JVM的一些参数，如GC策略和启动参数。

3、接口服务

• 接口性能。检查tps、成功率、耗时、流控阀值以及超时时间(调外部服务)。
• 定时任务。要明确其作用，用来决定是否执行关闭、流控降级等策略。同时要了解并发数，单线程和多并发对资源的消耗和性能的影响是不一样的。关注耗时主要目的在于，如果其耗时过长，对大促的影响可能比较大，则需要考虑是否可错峰关闭。最后的执行时间肯定是必须的，如果和大促重叠执行，则面临的风险自然是很大的。
• 降级。 降级是我们系统服务治理的一个重要环节，现简单介绍一下我们在设计流控系统时的一些策略。
  降级的目的主要是为了保护系统自身，当请求量超过系统自身承载量时，及时的执行降级策略，保证核心服务不受影响，牺牲部分非核心业务是必须的。
  降级的策略通常有三种：
  1、超时降级。此情况通常发生在依赖服务频繁长时间的不可用或者因为压力过大响应特别慢，导致调用几乎都达到最大耗时。如果任由其发展下去，系统平均耗时将极具增加。同时，由于顾客并不清楚具体原因，及可能刷新页面，频繁请求，将导致请求量成倍扩大。结果是，一边是请求耗时过长，一边是请求突然猛增，结果可想而知。
  在有一次活动期间，我们依赖的一个系统因为压力过大处理能力极具下降，响应时间陡增，这导致我们的处理时间迅速被拉长，系统被拉向崩溃边缘。于是我们及时采取降级策略，执行了多级流控才保住系统。试想，如果我们没有这个降级保护，将引起连锁反映，整个支付路径的系统都可能被拖垮。有经历过类似情况的朋友肯定清楚，依赖服务宕机不可怕，就怕它一直超时。宕机大不了不用，但是超时，没准会拖垮整个系统。
  2、统计失败次数降级。对于一个服务，如果它不能满足一定成功率，保证一定的服务质量，采取降级的措施是必要的。毕竟，如果支付都是失败，就不应该让用户支付。
  3、故障降级。也就是依赖服务出故障了执行降级。
  降级的类型主要分为人工降级和自动降级。由于当时人力和能力的不足，所以降级我们采用的是人工去调整流控阀值，但缺点就是响应时间慢，有可能洪峰就在这一瞬间压垮了系统。
  从降级的程度可分为流控和开关。我们在设计时，针对核心系统的核心接口采用的是多级流控，核心系统非核心接口采取的是单极流控或者是开关。
  回到梳理降级方面。当时我们梳理了接口的流控令牌名称和最新流控阀值。
  时间有点晚了，改日完成系统容量评估和压测