Skip to main content

必要条件

如果需要达到很高的稳定性,可能需要满足如下几点基本要求:

1 需要建设或接入客户的服务观测平台

包括并且不限于,日志系统、监控系统、告警系统。如果客户已经有成熟可靠的服务观测平台,需要将石墨接入到这些平台中。没有这些平台的支撑,SRE 和盲人一样,无法及时感知石墨当前潜在风险,只能被动等待用户侧反馈问题。

2 需要更多系统及平台的权限

专职的 SRE 需要更多的系统及平台的权限,包括并不限于监控系统、日志系统、生产环境集群等。只有在访问不受限的情况下,SRE 才能提供更敏捷的响应。

3 需要石墨侧提供专职 SRE,时刻应对生产环境各类潜在风险

如果没有专职 SRE,系统隐藏的问题可能得不到及时得处理,最终故障可能会放大,造成大面积的不可用。必须要有专职的 SRE 时刻响应和跟进生产环境各类告警、各类业务日志告警、中间件告警,及时的将在问题转为为故障前进行扼杀才可能提供更高级别的 SLA 保障。

4 需要 SRE 每周固定巡检

即使在各项指标都正常的情况下,也需要 SRE 对石墨整体做巡检,包括并且不限于:

  • 集群各项指标
    • 节点状态(CPU、Mem、磁盘、IO 等指标水位)
    • Workload 状态(CPU、Mem、磁盘、IO 等指标水位)
    • 服务本身指标(核心服务 P95、QPS 等指标)
  • 中间件各项指标
    • Redis(CPU、Mem、连接数、磁盘、IO 等指标水位)
    • Kafka(各 ConsumerGroup 消息堆积等指标水位)
    • MysQL(CPU、Mem、连接数、磁盘、IO 等指标水位)
    • MongoDB(CPU、Mem、连接数、磁盘、IO 等指标水位)
    • 异常日志分析
  • Shimo系统日志
    • 5xx日志
    • slow日志
    • panic日志

对这些指标进行巡检,并进行分析后,输出改进和优化建议。

5 需要有更充足的资源余量

石墨部分服务是 CPU 密集型,同时有些服务会出现 Mem 使用偏大的情况。包括:格式转换服务、函数计算服务。

部分服务需要提供独立节点池

对这些服务,需要规划独立的节点池,将这些服务调度到这些独立的节点池上独立部署,避免它们对资源的抢占导致其他服务可用率受影响。

需要支持弹性扩容

为了应对突发流量,需要对独立节点池和公共节点池配置弹性扩容机制,突发流量到来是能立刻扩充节点池,同时核心服务副本需要配置 HPA 水平扩容,及时地拉起更多的业务容器来处理突发流量。