跳到主要内容

必要条件

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

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 水平扩容，及时地拉起更多的业务容器来处理突发流量。