关于什么是 SRE，以及在业务上有哪些具体的输出，网上资料众多但都只是对基本概念做描述。那容器 SRE 究竟要怎么结合业务，得物容器 SRE 又有哪些最佳实践，本文就得物容器 SRE 的一些事情向大家做介绍。
稳定性工程师，用软件工程解决复杂的运维问题，50%的时间用于运维琐事,50%的时间用于软件工程保障业务的稳定性和可扩展性，包括开发监控，日志，告警系统，业务性能调优等
（a）清晰的问题升级路线（b）清晰定义的应急事件处理步骤（c) 监控巡检，如下:
IC(Incident Commander)：故障指挥官，这个角色是整个指挥体系的核心，最重要的职责是组织和协调，而非执行，下面所有角色都要接受他的指令并严格执行。
CL(Communication Lead)：沟通引导，负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA 或者是某个 SRE 来承担，要求沟通表达能力要比较好。
OL(Operations Lead)：运维指挥，负责指挥或指导各种故障预案的执行和业务恢复。
IR(Incident Responders)：即所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，如具体执行的 SRE、运维、业务开发、平台开发、DBA，甚至是 QA
100%稳定的系统是不存在的服务质量指标 SLI（indicator）：量化指标，包括延迟、吞吐量、错误率、可用性、持久性等
指标不宜过多，应关注用户的真实需求
常用的指标度量应该尽量标准化（如时间间隔、频率等）
服务质量目标 SLO（Objective）：对特定 SLI 的目标值
服务质量协议 SLA（Aggrement）：与用户间的明确协议，一般伴随着代价
维护服务可用性的成本不是线性增长的，到一定程度，增加一个 9 可能需要 10 倍 100 倍的成本，通过 SLO 让成本和收益取得很好的平衡，假设一个业务增加 SLO 等级，可以计算一下需要的成本和带来的收益，如果得不偿失就可以不用增加 SLO 等级
SRE 的经验大概 70% 的生产事故由某种部署的变更而触发
变更管理的最佳实践：
容量规划必需步骤：
必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。
规划中必须有准确的非自然增长的需求来源的统计。
必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来
SRE 的四个黄金指标是构建成功的监控和告警系统的一些基本原则和最佳实践
可靠性是 MTTF（平均失败时间）和 MTTR（平均恢复时间）的函数。评价一个团队将系统恢复到正常情况的最有效指标，就是 MTTR。
任何需要人工操作的事情都只会延长恢复时间。一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的系统可用性更高
Oncall 是直接体现 SRE 价值所在，能够直接影响 MTTR 时间的主要核心系数，一个好的 Oncall 甚至可以帮助公司挽回很多资损甚至是公司的形象，所以 Oncall 是每个 SRE 最重要的工作。
我们有自己的 Oncall 机制、适用范围、人员构成、复盘跟进、不同场景会邀请不同队员参与排障。有基本的故障处理原则，事故处理后的闭环。下图为整个 Oncall 流程的进行方式：
当然每次都只是处理故障，恢复后不做总结归纳是不会有任何沉淀的，容器 SRE 会记录每次有意义的故障进行文案撰写并在故障中总结现有系统存在的工具类、平台类、代码类隐患点，分等级高中低进行推进 push 帮助业务，基架不断完善系统健壮性；
某天下午 SRE 侧开始陆续接到业务研发反馈 redisRT 增长导致超时，其中某服务有多个 pod 存在 redis RT 突增导致部分请求超时（截图如下）
经过了一系列的驱逐与资源规整等止血操作后，该故障在 30 分钟后恢复。在这种场景下排查根因通常是一个很辣手的问题，因为第一现场很难在短时间内再进行模拟、恢复，第二在生产环境下不易做太多的测试工作。这种背景下就要发挥 SRE 的价值了。下面是叙述我们整个问题的排查思路与过程，希望能给大家一些借鉴。
先排查是否是网络问题引起的，当问题发现解决后后我们梳理了对应的宿主机的信息，想发现一些规律来确认故障的根因；
图上可见，这三台并不是一个网段的，唯一相同的也就是同一个区域，这个范围较大，不像是一个局部事件。所以我优先想到了云商故障；
为了进一步确认问题，我将对故障的 ecs ID 给到了阿里并进行了一个授权，随后还拉群做了语音讨论
接下来是整个根因排查分析：
1、排除链路问题
翻阅故障时的监控发现，网络耗时在故障时间点附近比较平稳、经过和阿里内部监控的核对，当时问题宿主机网络延迟在故障时间点延迟仅从 2ms 增加到 4ms 所以可以排除是由于网络问题导致的
2、发现异常现象
node 监控有大量的异常包，drop 计数异常，常规情况下应该为 0（上图），我们对这些 drop 包做了分析（下图）发现 Drop 的统计数非常高，同时 tcpofo，tcprcvq 这两个指标指向了 TCP 内存限制，需要扩充内存空间。
为了更进一步知道根因所在，我们又去观察了对应的 io 夯、调度（任务等待）、 夯住（应用进程锁）、用户态内存等待、网络 (系统 5 状态分类左图) （这里第一步已经排除了“网络”故障所以这里做了删除线处理），可以看到排查到 io 等待时间过长（下图）
3、深挖排查到 IO 平均等待时间上存在问题
IO 平均等待时间在秒级以上，远超了正常范围，故开始排查 percpu iowait 状况。经过一系列的操作最终我们使用 sls 导入 tidb 的方法数据做了一个可视化；
select * from cpus where time > now() - 4h and host = 'i-bp11f8g5h7oofu5pqgr8' and iowait > 50.0
复制代码
我们对那些 CPU iowait 比较高的筛选出来，看看能不能找到对应的业务（当时就怀疑是不是由于混部原因导致的）但是找了一圈没有发现什么问题。
绕了一圈发现线索又断了，还是回到那个 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
然后我们怎么找到是谁呢？通常情况下可以这么理解，一个 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
复制代码
为了确认又去容器中查看，确认无疑！
拉了对应引用的负责人后将结果反馈，业务得到信息后立即响应并将自己的应用做了下线处理，随后观察指标立马恢复了 - 破案~
这次故障我们深刻反省，同事建议将我们的系统参数的监控覆盖完全，所以之后我们立即就成立了一个项目，优化推进监控覆盖
继上文说到的故障后，我们意识到了容器监控上的不足故成立了专项来做内核参数上的监控。但是内核参数上千个我们怎么来做？
所以第一步就是完成内核指标罗列范围。我们对以往的故障和反馈分析来看，网络故障发生较为频繁，所以范围圈定为宿主机网络指标为主；网络指标在系统中主要由/proc/net/netstat 提供，所以我们罗列了他所提供的所有指标；（如图是 netstat 的所有指标）
有了范围我们要制定采集方案有些是 node-export 需要特殊配置才能采集到的具体方案；比如下面要增加 netstat 的监控是需要启用 node-export 对应的扩展包
第二个就是通过开源的采集组件监控不到的数据比如 tcp.socket.mem 这部分只能靠自己开发完成。如下图通常采用截取字段方式将 os 的状态指标采集到
有了采集后就是完成指标的展示与统计，我们通过/proc/net/netstat 获取到了 46 个网络指标，同时也借鉴了业内的最佳实践总共 55 个指标的罗列与代表的意义，并将各内核常见参数 含义及公式形成文档，解决了很多参数不目的不明确的问题，下图是我们展示这些指标的案例截图
完成了展示后，我们就需要对这些核心内核指标参数进行分类（这些指标存在问题可能会影响业务正常运行）
以上 55 个指标大多为辅助定位的指标，作为业务类型不同，关注的指标与内核参数的调整是有区别的
通用类型 default 资源池模型；（注重并发，多链接，多请求的场景）监控参考如下：监控统计可以看到资源使用比较平均，需要均衡的参数配置
算法类型高密度计算类型资源池；（主动睡眠，被动睡眠，看调度延时，cpu 消耗在用户态还是内核态）监控参考如下：监控统计可以看到 cpu 大多使用率较高
大数据类型 专有集群资源池；（关注网络 IO，磁盘 IO，文件系统 cache，网络开销大）监控参考如下：监控统计可以看到网络上开销较大
然后我们就对这三个类型的主机分别做了参数调整和铺平，由于文章长度关系亲，就不做详细描述了。完成了调整后我们怎么去维护和管理这些内核参数呢？这里我们对内核参数管理也做了一个方案，保障这次治理后是长久有效的。具体的流程如下：
有整理出的内核指标后还会通过日常的监控、巡检对某些需要调整的内核参数做出修改，由于是 wget 统一拉取的，所以在 update 的时候只要通过修改 oss 里面的批量类型 init.sh 就可以做到了，不需要修改每一个资源池配置
为了更安全起见，我们还做了内核初始化兜底保障功能，当然我们在以往的经历中发现，有些节点会因为网络变更等原因拉不到 oss 的初始化文件，且 Ali 没有这块初始化的提示，所以 kube-node 会有一个初始化的兜底，如果节点启动初始化失败会检测到对应的错误数据并将其修改为正常值
整套上线后，我们配置了 7 个监控告警项，在实际运行中发现 5 次以上隐患问题提前在故障发生前就预先进行了处理，保障了产线的稳定性运行。至此，整个故障算是画上了圆满的句号
上面正好说到兜底保障，其实我们在整个容器集群里部署有多个保护系统，下面我就举例一个防误删场景的方案。
首先我们来参考下某知名大厂的防控体系
从架构看来，大致分为三大块：权限、风控、流控
风险控制 Webhook 风控：
不同平台方、业务方一般在自己的前端或者后端都有对应的逻辑进行风险控制。但是也搞不好业务方在逻辑上存在 Bug 或者不够完善的地方，因此在最基础的底层上，需要有个 SRE 的 WebHook 对所有请求进行拦截校验兜底。
流量控制 K8S-Defender
阿里搞的 K8S 防火墙主要针对于 API 流量风控，早期是 Webhook 机制实现，但是 K8S-Webhook 天然存在一些缺陷，比如无法站起全局视角进行精准流控，因此后面是独立出来了。做成了 C/S 模型，但需要强制让所有接入 ASI 的基础组件在关键的位置统一使用 Defender 做 K8S 流量风制，这个目前在得物这个阶段很难推得动，所以可以降级到 Webhook 机制去实现。
他山之石，可以攻玉。我们可以参考
这里分为硬性和软性两种方式。
对于核心的 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 就主动做降级处理，不再校验拦截。这样运维就可以正常地做批量删除动作。
K8S WebHook 机制，是可以对任意带 Namespace 的 CRD|CR 进行拦截。其拦截逻辑是可以共享的，只是资源类型不一样。所以我们可以动态配置，拦截逻辑对哪些资源生效。支持 Ingress、WorkLoad、Service、ConfigMap、Secret、Pod... 类型资源，并支持标签筛选能力
对于 Ingress 规则配置比较复杂，很多初学者会犯一些低级错误。比如：rule.host 配置为 '*' ，这意味着该规则匹配所有域名，所有请求都会过这条规则进行转发，显然生产环境这种配置是不合理的。而且一旦配置上可能会覆盖掉大量的 rule，导致生产故障。所以这类低级错误配置一定要拦截，不允许配置。
这里就简单画下方案图，大致基本借助于 webhook 的能力，对一些删除动作的时候加强校验与拦截的机制。
上述几个案例都是得物容器 SRE 团队在日常工作中真实发生的事件，覆盖的也只是多项工作中的冰山一角，写这篇文章也是想让大家认知到我们团队，了解我们容器 SRE。由于篇幅有限其余细节不再展开了，大家有疑问欢迎找我讨论。同时也欢迎对容器/云原生/SRE 等领域感兴趣的同学加入我们。
我们是得物容器 SRE 团队。
我们团队的宗旨是为全司提供稳定、高效、安全的支撑和服务。
服务项目：业务稳定性保障，线上业务系统变更，业务性能 &状态监控，容量评估；核心业务场景梳理，识别关键链路和关键接口，制定服务保障预案，对关键链路实施故障演练，确保服务的连续性。得物容器化集群维护、系统网络维护以及系统基础组件维护。保障基础环境的稳定、高效，并提供丰富的工具和平台提升系统的自动化、可视化、智能化。
加入我们请发送简历 + tech_techsecurity_sa@shizhuang-inc.com
文/Gin
关注微信
