一次棘手的容器故障，我终于知道SRE有多重要了……-51CTO.COM

前言：

关于什么是SRE，以及在业务上有哪些具体的输出，网上资料众多但都只是对基本概念做描述。那容器SRE究竟要怎么结合业务，得物容器SRE又有哪些最佳实践，本文就得物容器SRE的一些事情向大家做介绍。

一、SRE定义

稳定性工程师，用软件工程解决复杂的运维问题，50%的时间用于运维琐事，50%的时间用于软件工程保障业务的稳定性和可扩展性，包括开发监控，日志，告警系统，业务性能调优等

二、对于SRE的理解

1、SRE的监控和Oncall应急响应

（1）一个团队 Oncall 至多需要两个人（另外一个是新手 shadow），oncall人员需要具备以下能力：

①清晰的问题升级路线

②清晰定义的应急事件处理步骤

③监控巡检，如下：

查看监控，分析服务可用性下降或者耗时增加等影响服务质量的问题的根部原因。
整理以上事件的数据
分析根本原因，优化并且解决（运维手段，代码，或者脚本 / 代码自动化运维手段）

（2）遇到重大故障时的各种重要角色

IC(Incident Commander)：故障指挥官，这个角色是整个指挥体系的核心，最重要的职责是组织和协调，而非执行，下面所有角色都要接受他的指令并严格执行。

CL(Communication Lead)：沟通引导，负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA或者是某个SRE来承担，要求沟通表达能力要比较好。

OL(Operations Lead)：运维指挥，负责指挥或指导各种故障预案的执行和业务恢复。

IR(Incident Responders)：即所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，如具体执行的SRE、运维、业务开发、平台开发、DBA，甚至是QA

2、SLO和SLA制定和保障

100%稳定的系统是不存在的

服务质量指标 SLI（indicator）：量化指标，包括延迟、吞吐量、错误率、可用性、持久性等

指标不宜过多，应关注用户的真实需求

常用的指标度量应该尽量标准化（如时间间隔、频率等）

服务质量目标 SLO（Objective）：对特定 SLI 的目标值

服务质量协议 SLA（Aggrement）：与用户间的明确协议，一般伴随着代价

维护服务可用性的成本不是线性增长的，到一定程度，增加一个9可能需要10倍100倍的成本，通过SLO让成本和收益取得很好的平衡，假设一个业务增加SLO等级，可以计算一下需要的成本和带来的收益，如果得不偿失就可以不用增加SLO等级

3、变更管理

SRE的经验大概 70% 的生产事故由某种部署的变更而触发

变更管理的最佳实践：

（1）采用渐进式发布机制

（2）迅速而准确地检测到问题的发生

（3）当出现问题时，安全迅速地回退改动

4、容量规划

容量规划必需步骤：

必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。

规划中必须有准确的非自然增长的需求来源的统计。

必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。

5、监控系统

SRE的四个黄金指标是构建成功的监控和告警系统的一些基本原则和最佳实践

延迟：延迟是信息发送方和接收方之间的时间延迟，以毫秒（ms）为单位。而原因往往是由于数据包丢失网络拥塞和网络抖动造成的，称为“数据包延迟差异”延迟对客户体验有直接影响，转化为成功请求的延迟和失败请求的延迟。

流量：流量是系统工作量带来的压力。它通过每秒查询数（QPS）或每秒事务数（TPS）来衡量。企业通过数量来衡量这一点：关键绩效指标（KPI）是在给定时间来到站点的人数。这与商业价值有直接关系。

错误：错误是根据整个系统中发生的错误来衡量的。被认为是服务错误率的重要指标！有两类错误：显式错误，如失败的HTTP请求（500个错误代码，例如）；隐含错误是成功的响应，但内容错误或响应时间长。

饱和度：饱和度定义了服务的过载程度。它衡量系统利用率，强调服务的资源和整体容量。这通常适用于CPU利用率、内存使用、磁盘容量和每秒操作数等资源。仪表板和监控警报是帮助你密切关注这些资源并帮助你在容量饱和之前主动调整容量的理想工具

6、可靠性衡量

可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）的函数。评价一个团队将系统恢复到正常情况的最有效指标，就是MTTR。

任何需要人工操作的事情都只会延长恢复时间。一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的系统可用性更高

三、得物容器SRE的实践

1、Oncall应急响应的总结

Oncall是直接体现SRE价值所在，能够直接影响MTTR时间的主要核心系数，一个好的Oncall甚至可以帮助公司挽回很多资损甚至是公司的形象，所以Oncall是每个SRE最重要的工作。

我们有自己的Oncall机制、适用范围、人员构成、复盘跟进、不同场景会邀请不同队员参与排障。有基本的故障处理原则，事故处理后的闭环。下图为整个Oncall流程的进行方式：

当然每次都只是处理故障，恢复后不做总结归纳是不会有任何沉淀的，容器SRE会记录每次有意义的故障进行文案撰写并在故障中总结现有系统存在的工具类、平台类、代码类隐患点，分等级高中低进行推进push帮助业务，基架不断完善系统健壮性；

2、一次容器故障的分享

（1）延迟问题背景：

某天下午SRE侧开始陆续接到业务研发反馈redisRT 增长导致超时，其中某服务有多个pod存在redis RT突增导致部分请求超时（截图如下）

经过了一系列的驱逐与资源规整等止血操作后，该故障在30分钟后恢复。在这种场景下排查根因通常是一个很棘手的问题，因为第一现场很难在短时间内再进行模拟、恢复，第二在生产环境下不易做太多的测试工作。这种背景下就要发挥SRE的价值了。下面是叙述我们整个问题的排查思路与过程，希望能给大家一些借鉴。

（2）问题排查思路：

排障过程描述只是说了一个思路，部分时间点可能和故障产生的时间重合

先排查是否是网络问题引起的，当问题发现解决后后我们梳理了对应的宿主机的信息，想发现一些规律来确认故障的根因；

图上可见，这三台并不是一个网段的，唯一相同的也就是同一个区域，这个范围较大，不像是一个局部事件。所以我优先想到了云商故障；

为了进一步确认问题，我将对故障的 ecs ID 给到了阿里并进行了一个授权，随后还拉群做了语音讨论

接下来是整个根因排查分析：

①排除链路问题

翻阅故障时的监控发现，网络耗时在故障时间点附近比较平稳、经过和阿里内部监控的核对，当时问题宿主机网络延迟在故障时间点延迟仅从 2ms 增加到 4ms 所以可以排除是由于网络问题导致的

②发现异常现象

node监控有大量的异常包，drop 计数异常，常规情况下应该为0（上图），我们对这些drop 包做了分析（下图）发现Drop 的统计数非常高，同时tcpofo，tcprcvq这两个指标指向了TCP内存限制，需要扩充内存空间。

为了更进一步知道根因所在，我们又去观察了对应的 io夯、调度（任务等待）、夯住（应用进程锁）、用户态内存等待、网络 (系统 5状态分类左图) （这里第一步已经排除了“网络”故障所以这里做了删除线处理），可以看到排查到io等待时间过长（下图）

③深挖排查到IO平均等待时间上存在问题

IO平均等待时间在秒级以上，远超了正常范围，故开始排查percpu iowait 状况。经过一系列的操作最终我们使用sls 导入tidb 的方法数据做了一个可视化；

select * from cpus where time > now() - 4h and host = 'i-bp11f8g5h7oofu5pqgr8' and iowait > 50.0

我们对那些 CPU iowait 比较高的筛选出来，看看能不能找到对应的业务（当时就怀疑是不是由于混部原因导致的）但是找了一圈没有发现什么问题。

（3）最终根因定位：

绕了一圈发现线索又断了，还是回到那个TCP 内存限制的问题，为什么会判断tcpofodrop 指标会与tcp_mem 有关呢？可以直接看代码逻辑

（一个展示源代码存储库的软件工具集）

上面的逻辑简单叙述：TCP的核心预分配缓存额度函数为tcp_try_rmem_schedule，如果无法分配缓存额度，将首先调用tcp_prune_queue函数尝试合并sk_receive_queue中的数据包skb以减少空间占用，如果空间仍然不足，最后调用tcp_prune_ofo_queue函数清理乱序数据包队列（out_of_order_queue）。简单说：如果内存分配失败，对应drop计数就会递增

另外当时我们也发现了dmesg日志里tcp oom的日志，如下图所示

于是就搜了一些实践准备将线上连接数比较高的那几台机器做一个替换处理试试

#命令查看方法
sysctl -a|grep -i tcp_mem|tcp_rmem|tcp_wmem

当时想准备替换的配置（当时这个调整低于线上目前的值）

# 扩大TCP 总内存大小
# 扩大到 32G  最小值不动  中间数为max 的 70%  
echo  "net.ipv4.tcp_mem = 1104864 5872026 8388608">> /etc/sysctl.conf  
#单个 socket 读分配最大内存 
#原先16MB 扩大到 32MB （中间数为最佳实践推荐）
echo "net.ipv4.tcp_rmem = 4096 25165824 33554432">> /etc/sysctl.conf
#单个 socket 写分配最大内存 
#原先16MB 扩大到 32MB （中间数为最佳实践推荐）
echo "net.ipv4.tcp_wmem = 4096 25165824 33554（）432">> /etc/sysctl.conf

当时线上内存

cat /proc/sys/net/ipv4/tcp_mem
6169920        8226561        12339840，这里是最小值24G 压力值32G 最大值48G

在check这些参数的过程中突然就发现了一个问题，我们线上的参数换算成内存值是48G左右，已经算大了，可以想象一下 tcp 链接总的内存已经用了48G！这部分还不光是网络开销只是一个 TCP 链接，我们就有 ss 看了下当时的链接情况：

通常出现这种情况的原因有以下两种：1、应用没有正确close他的socket进程 2、没有处理异常情况下的socket🔗

感兴趣的同学可以看下这个文档（推荐）

https://stackoverflow.com/questions/38837724/linux-too-many-closed-connections

然后我们怎么找到是谁呢？通常情况下可以这么理解，一个 soket 就是一个 fd （句柄），对应soket 大必然fd 也大！（因为linux 一切皆文件）随后我们用了 for 循环查找对应的/proc 下的文件数量，结果如下：

附上命令参考：

#看进程对应哪个容器
for i in `docker ps |grep Up|awk '{print $1}'`;do echo \ &&docker top $i &&echo ID=$i; done |grep -A 15 4078683
#看FD谁占用的多
for pid in `ls -1 /proc/|grep -Eo '[0-9]{1,}'`; do pnum=$(ls -1 /proc/${pid}/fd/|wc -l); if [ $pnum -gt 1000 ];then echo "${pid} ${pnum}"; fi; done

为了确认又去容器中查看，确认无疑！

拉了对应引用的负责人后将结果反馈，业务得到信息后立即响应并将自己的应用做了下线处理，随后观察指标立马恢复了 - 破案~

这次故障我们深刻反省，同事建议将我们的系统参数的监控覆盖完全，所以之后我们立即就成立了一个项目，优化推进监控覆盖

3、容器底层对于内核参数监控与优化

继上文说到的故障后，我们意识到了容器监控上的不足故成立了专项来做内核参数上的监控。但是内核参数上千个我们怎么来做？

（1）圈定监控指标范围

所以第一步就是完成内核指标罗列范围。我们对以往的故障和反馈分析来看，网络故障发生较为频繁，所以范围圈定为宿主机网络指标为主；网络指标在系统中主要由/proc/net/netstat提供，所以我们罗列了他所提供的所有指标；（如图是netstat的所有指标）

（2）内核指标的采集实现

有了范围我们要制定采集方案有些是node-export需要特殊配置才能采集到的具体方案；比如下面要增加netstat的监控是需要启用node-export对应的扩展包

第二个就是通过开源的采集组件监控不到的数据比如tcp.socket.mem这部分只能靠自己开发完成。如下图通常采用截取字段方式将os的状态指标采集到

（3）指标的展示可视化

有了采集后就是完成指标的展示与统计，我们通过/proc/net/netstat获取到了46个网络指标，同时也借鉴了业内的最佳实践总共55个指标的罗列与代表的意义，并将各内核常见参数含义及公式形成文档，解决了很多参数不目的不明确的问题，下图是我们展示这些指标的案例截图

（4）场景分类逐个优化

完成了展示后，我们就需要对这些核心内核指标参数进行分类（这些指标存在问题可能会影响业务正常运行）

以上55个指标大多为辅助定位的指标，作为业务类型不同，关注的指标与内核参数的调整是有区别的

通用类型default资源池模型；（注重并发，多链接，多请求的场景）监控参考如下：监控统计可以看到资源使用比较平均，需要均衡的参数配置

参数	作用	是否合理	备注
vm.min_free_kbytes	用于保留空闲内存最小值	redhat官方建议小于5%，但没有给出最小值，参考网上建议一般设置为总内存的2%	如果过大，会导致空闲内存过多，浪费内存，并且可能会频繁触发oom；过小可能会导致触发程序direct claim,从而导致应用hang住
fs.file-max	系统级的进程可打开句柄数	合理	通过/proc/sys/fs/file-nr可以看当前打开句柄占用比
net.netfilter.nf_conntrack_max	连接跟踪表上限	偏大但无副作用	连接跟踪自身占用内存空间不大，但实际要考虑的资源负载，一台机器并发上百万时
net.ipv4.tcp_max_syn_backlog	影响系统半连接全连接队列大小	合理	从当前收集的tcp各种指标看，没有出现过队列满的情况
net.ipv4.tcp_rmem/wmem	每个tcp socket的读写缓冲区大小	待观察-目前合理	涉及到net.ipv4.tcp_rmem irate(node_netstat_TcpExt_PruneCalled{instance=~"$instance",job=~"$job"}[5m]) 历史上有大量上报的数据
net.ipv4.tcp_max_tw_buckets	当前系统允许最大的time_wait状态的tcp连接数	偏大 (考虑到内存不紧张暂时不做修改)	当一个客户端有20w以上的tw时，可用端口，句柄资源存在较多浪费

算法类型高密度计算类型资源池；（主动睡眠，被动睡眠，看调度延时，cpu消耗在用户态还是内核态）监控参考如下：监控统计可以看到 cpu大多使用率较高

参数	作用	是否合理	备注
各cpu核心中断是否均衡	用于确定是否存在网卡存在硬件问题，从而导致cpu热点	均衡
cpu整体负载是否超过cpu核心	负载过高时任务调度可能存在延迟	中等	-
是否有跨numa	跨numa会导致内存访问延迟增加	单node节点	-
cs上下文切换(nvcswch)	非自愿进程切换	合理	如果频繁出现，说明分配的cpu资源不够，存存资源争抢

大数据类型专有集群资源池；（关注网络IO，磁盘IO，文件系统cache，网络开销大）监控参考如下：监控统计可以看到网络上开销较大

参数	作用	是否合理	备注
net.netfilter.nf_conntrack_max	连接跟踪表上限	偏大但无副作用	连接跟踪自身占用内存空间不大，但实际要考虑的资源负载，一台机器并发上百万时
net.ipv4.tcp_max_syn_backlog	影响系统半连接全连接队列大小	合理	从当前收集的tcp各种指标看，没有出现过队列满的情况
net.ipv4.tcp_rmem/wmem	每个tcp socket的读写缓冲区大小	待观察-目前合理	涉及到net.ipv4.tcp_rmem irate(node_netstat_TcpExt_PruneCalled{instance=~"$instance",job=~"$job"}[5m]) 历史上有大量上报的数据
/proc/sys/vm/dirty_ratio	控制内存脏页百分比	建议适当提高并观察	（目前io写入写出量比较大）vmstat
net.ipv4.tcp_max_tw_buckets	当前系统允许最大的time_wait状态的tcp连接数	偏大 (考虑到内存不紧张暂时不做修改)	当一个客户端有20w以上的tw时，可用端口，句柄资源存在较多浪费

（5）参数优化管理与兜底保障

然后我们就对这三个类型的主机分别做了参数调整和铺平，由于文章长度关系亲，就不做详细描述了。完成了调整后我们怎么去维护和管理这些内核参数呢？这里我们对内核参数管理也做了一个方案，保障这次治理后是长久有效的。具体的流程如下：

有整理出的内核指标后还会通过日常的监控、巡检对某些需要调整的内核参数做出修改，由于是wget统一拉取的，所以在update的时候只要通过修改oss里面的批量类型init.sh就可以做到了，不需要修改每一个资源池配置

为了更安全起见，我们还做了内核初始化兜底保障功能，当然我们在以往的经历中发现，有些节点会因为网络变更等原因拉不到oss的初始化文件，且Ali没有这块初始化的提示，所以kube-node会有一个初始化的兜底，如果节点启动初始化失败会检测到对应的错误数据并将其修改为正常值

整套上线后，我们配置了7个监控告警项，在实际运行中发现5次以上隐患问题提前在故障发生前就预先进行了处理，保障了产线的稳定性运行。至此，整个故障算是画上了圆满的句号

4、容器安全的一些保障

上面正好说到兜底保障，其实我们在整个容器集群里部署有多个保护系统，下面我就举例一个防误删场景的方案。

（1）简介业内防控体系

首先我们来参考下某知名大厂的防控体系

从架构看来，大致分为三大块：权限、风控、流控

权限管控：

2018年某大厂整体架构开始往社区K8S方向迁移。迁移是个非常漫长的过程，需要考虑很多的细节。最开始自然是K8S权限体系管控问题，不同BU、不同平台、基础组件，都要跟新的ASI对接，第一件事情就是 申请项目专用账号 。当时SRE开了个Git仓库，专门用于各个 基础业务方 提交 账号申请信息，格式是按照 K8S标准权限资源进行提交。

除了 RBAC，SRE还管控 CRD、WebHook 、Kubeconfig 等核心资源

风险控制Webhook风控：

不同平台方、业务方一般在自己的前端或者后端都有对应的逻辑进行风险控制。但是也搞不好业务方在逻辑上存在Bug或者不够完善的地方，因此在最基础的底层上，需要有个SRE的WebHook对所有请求进行拦截校验兜底。

流量控制K8S-Defender

阿里搞的 K8S防火墙主要针对于API流量风控，早期是Webhook机制实现，但是K8S-Webhook天然存在一些缺陷，比如无法站起全局视角进行精准流控，因此后面是独立出来了。做成了C/S模型，但需要强制让所有接入ASI的基础组件在关键的位置统一使用 Defender 做K8S流量风制，这个目前在得物这个阶段很难推得动，所以可以降级到Webhook机制去实现。

他山之石，可以攻玉。我们可以参考

（2）得物现在防护具备的功能

① Namespace 防误删：

这里分为硬性和软性两种方式。

对于核心的Namespace，例如 kube-system、monitoring。不应该以任何理由删除，这类Namespace可以普通账号直接锁死，即便你RBAC里面拥有删除NS的权限，就不允许删除。

对于 Addons 或者纯业务类型的Namespace，因为可能出现调试场景，比如：调试或者测试某个复杂的Addons组件，因为牵涉到太多的配置和资源，过程中已经混乱不堪，想彻底干净地重装一遍，回到初始状态。这种情况下是需要利用K8S级联删除特性，把该Namespace包括下面所有资源清理一次。如果锁死该Namespace，业务方遇到这种情况，就会很麻烦，所以这个场景走 硬性防删 就不是明智之举。

相对于硬性防删，我们引入了软性防删策略。也就是对于非核心的Namespace，在一定的时间内，我们对删除的请求做计数统计，在没达到阀值之前，会一直拒绝删除。并在返回的结果上给予风险提示，如果N秒内再提交X次，则真的执行删除动作。这种方式对业务方明显会更加友好一些，一方面起到了一定防误删效果，另一方面也不至于在你真正想删除的时候删不掉。

另外我们还开发了一种策略，专门针对批量删除Namespace的场景。对于我们目前Namespace的使用方式是不合理的，说不定哪天可能会对Namespace做治理，以域的方式来确定Namespace。这个时候就会涉及到大量Namespace的清理工作。这种合法的删除，如果不断地被Webhook拦截中断，这不是个合理的设计。所以我们支持以管控标降级策略，也就是给对应的Namespace打一个管控标，则Webhook对这类Namespace就主动做降级处理，不再校验拦截。这样运维就可以正常地做批量删除动作。

②NS-CRD|CR 防误删：

K8S WebHook 机制，是可以对任意带Namespace的CRD|CR进行拦截。其拦截逻辑是可以共享的，只是资源类型不一样。所以我们可以动态配置，拦截逻辑对哪些资源生效。

支持 Ingress、WorkLoad、Service、ConfigMap、Secret、Pod ... 类型资源，并支持标签筛选能力

高危配置校验：

对于 Ingress 规则配置比较复杂，很多初学者会犯一些低级错误。比如：rule.host 配置为 '*' ，这意味着该规则匹配所有域名，所有请求都会过这条规则进行转发，显然生产环境这种配置是不合理的。而且一旦配置上可能会覆盖掉大量的rule，导致生产故障。所以这类低级错误配置一定要拦截，不允许配置。

这里就简单画下方案图，大致基本借助于webhook的能力，对一些删除动作的时候加强校验与拦截的机制。

四、总结

上述几个案例都是得物容器SRE团队在日常工作中真实发生的事件，覆盖的也只是多项工作中的冰山一角，写这篇文章也是想让大家认知到我们团队，了解我们容器SRE。由于篇幅有限其余细节不再展开了，大家有疑问欢迎找我们讨论。