0.前言关于什么是SRE，在业务中具体产出是什么，网上资料很多，但都只是介绍了基本的概念。那么容器SRE如何与业务结合，得物容器SRE有哪些最佳实践呢？本篇介绍得物容器SRE的一些事情。1、SRE定义了稳定性工程师，用软件工程来解决复杂的运维问题。50%的时间花在琐碎的运维上，50%的时间花在软件工程上，保证业务的稳定性和可扩展性，包括开发监控。日志、告警系统、业务性能调优等2.SRE的理解2.1SRE监控和oncall应急响应2.1.1一个团队oncall最多需要两个人（另一个是菜鸟影子），oncall人员需要具备以下条件能力：（a）清晰的问题升级路径（b）明确的应急事件处理步骤（c）监控检查，具体如下：检查监控，分析服务可用性下降或时间等影响服务质量问题的根本原因-消费增加。2.整理以上事件的数据3.分析根因，优化解决（运维手段，代码，或者脚本/代码自动化运维手段）2.1.2IC（事件指挥官）的各种重要角色遇到重大失误时：FaultyCommander，这个角色是整个指挥系统的核心，最重要的职责是组织协调，而不是执行，下面的所有角色都必须接受他的指令并严格执行。CL（CommunicationLead）：沟通负责人，负责内外部信息收集和报告，这个角色一般比较固定，由技术支持、QA或SRE承担，需要更好的沟通能力。OL（OperationsLead）：运维指挥，负责指挥或指导各种故障预案和业务恢复的执行。IR（IncidentResponders）：指需要参与故障处理的各类人员。真正的故障定位和业务恢复都是由他们完成的，比如SRE的具体实施、运维、业务开发、平台开发、DBA，甚至QA2.2SLO和SLA的制定和保证100%稳定的系统是不存在的.服务质量指标SLI（indicator）：量化指标，包括时延、吞吐量、错误率、可用性、持久性等指标不宜过多，要关注用户的真实需求，常用的指标尽可能标准化可能的（如时间间隔、频率等）服务质量目标SLO（Objective）：针对特定SLI的目标值成本不会线性增加。在一定程度上，加一个9可能需要10倍甚至100倍的成本。SLO可以在成本和收益之间取得很好的平衡。假设一个业务提高了SLO级别，它可以计算出所需的成本和收益。如果收益大于损失，则不需要提高SLO级别2.3改变管理SRE的经验。大约70%的生产事故是由某种部署变更引发的。变更管理的最佳实践：1.采用渐进式变更2.快速准确地检测问题的发生3.当问题发生时，安全快速地回滚变更2.4容量规划容量规划的必要步骤：必须有一个准确的自然增长需求预测模型，需求预测时间应超过资源获取时间。计划中必须包括关于非自然增加的需求来源的准确统计数据。必须定期进行压力测试，才能将系统的原始资源信息准确映射到业务能力上。2.5监控系统SRE的四大黄金指标，是构建成功的监控告警系统的一些基本原则和最佳实践。Latency：延迟是信息发送者和接收者之间的时间延迟，以毫秒（ms）为单位。原因往往是由于数据包丢失、网络拥塞和网络抖动，称为“数据包延迟方差”。延迟对客户体验有直接影响，转化为成功请求的延迟和失败请求的延迟。流量：流量是系统工作负载带来的压力。它以每秒查询数(QPS)或每秒事务数(TPS)来衡量。企业通过数字来衡量这一点：关键绩效指标(KPI)是在给定时间访问网站的人数。这直接关系到商业价值。错误：错误是根据整个系统中发生的错误来衡量的。被认为是服务错误率的重要指标！有两类错误：显式错误，例如失败的HTTP请求（例如500错误代码）；隐式错误，即成功响应但内容错误或响应时间长。饱和度：饱和度定义了服务的超载程度。它衡量系统利用率，强调服务的资源和整体能力。这通常适用于CPU利用率、内存使用率、磁盘容量和每秒操作数等资源。仪表板和监控警报是帮助您密切关注这些资源并帮助您在容量饱和之前主动调整容量的理想工具2.6可靠性措施可靠性是MTTF（平均无故障时间）和MTTR（平均恢复时间）的函数。评价一个团队恢复正常状态最有效的指标就是MTTR。任何需要人工干预的事情只会延长恢复时间。一个即使故障再多也能自动恢复的系统，会比什么都需要人工干预的系统有更高的可用性直接影响MTTR时间的主要核心因素，一个好的oncall甚至可以帮助公司恢复很多资金损失甚至公司形象，所以oncall是每个SRE最重要的工作。我们有自己的oncall机制、适用范围、人员构成、回放跟进，不同的场景会邀请不同的团队成员参与排查。有基本的故障处理原则和事故处理后的闭环。下图展示了整个oncall流程的执行方式：当然每次只是处理故障，恢复后没有总结就没有沉淀。容器SRE会记录每一个有意义的故障编写并总结在故障中现有系统存在的工具、平台、代码隐患，推送帮助业务分高、中、低档次推进，框架不断提高系统的健壮性；3.2共享一个容器故障SRE端开始收到业务研发反馈redisRT增长导致超时。其中，某服务存在多个pod，redisRT激增导致部分请求超时（见下图）。30分钟后恢复。这种场景下的根因排查通常是一个非常棘手的问题，因为一是很难在短时间内模拟和还原场景，二是在生产环境做太多的测试工作也不容易。在这种背景下，SRE的价值必须发挥出来。以下是我们对整个问题的排查思路和过程的描述，希望能给大家一些参考。3.2.2故障处理思路：故障处理过程的描述只是一种思路。有些时间点可能与故障发生的时间重合。首先检查是否是网络问题引起的。找到并解决问题后，我们整理出对应的主机。信息，想找一些规律来确认故障的根源；从图中可以看出，三个站不在同一个网段，唯一的共同点就是同一个区域。这个范围比较大，看样子不是局部事件。所以我首先想到了云提供商的失败；为了进一步确认问题，我把故障的ecsID给了阿里并授权了，然后我也拉群语音讨论，接着是整个根因分析：故障排查链接监控发现的故障网络耗时在故障时间点附近相对稳定。经与阿里内部监控核对，问题主机在故障时间点的网络延迟仅从2ms增加到4ms，因此可以排除是由于网络问题导致的异常现象节点监控有较大异常包数，dropcount异常，正常情况下应该为0（上图）。我们分析了这些drop包（下图），发现Drop的统计量非常高。同时tcpofo和tcprcvq这两个指标指向TCP内存限制，需要扩展内存空间。为了进一步了解根源，我们去观察对应的ioramming，scheduling（任务等待），ramming（应用进程锁），user-modememorywaiting，network（左边系统5状态分类）（这里是首先第一步排除了“网络”故障，所以这里删掉了那一行），可以看到io等待时间过长（下）深挖发现是平均IO有问题等待的时间。IO的平均等待时间在秒级以上，远远超出正常范围，所以开始排查percpuiowait状态。经过一系列的操作，我们最终使用从sls导入tidb数据的方式做了一个可视化；select*fromcpuswheretime>now()-4handhost='i-bp11f8g5h7oofu5pqgr8'andiowait>50.0我们把那些cpu的iowait比较高的筛选出来看看能不能找到对应的业务（当时我怀疑说是混合部门造成的），但是找了一圈也没有发现什么问题。3.2.3最终rootcause定位：兜兜转转了一段时间，发现线索又断了，又回到了TCPmemorylimit的问题上。为什么我判断tcpofodrop指标与tcp_mem有关？可以直接看代码逻辑内核源码网站推荐https://lxr.missinglinkelectronics.com/linux+v4.19/net/ipv4/tcp_input.c#L4459（显示源代码仓库的软件工具集）以上逻辑很简单说明：TCP的核心预分配缓存配额函数是tcp_try_rmem_schedule。如果不能分配缓存配额，会先调用tcp_prune_queue函数尝试合并sk_receive_queue中的数据包skb，减少空间占用。如果空间仍然不足，会调用tcp_prune_ofo_queue函数清理乱序数据包队列（out_of_order_queue）。简单来说就是：如果内存分配失败，相应的dropcount会增加。另外我们在dmesg日志中也发现了tcpoom日志，如下图，于是搜索了一些提高在线连接数的实践方案。尝试在机器上做一个替换#命令查看方法sysctl-a|grep-itcp_mem|tcp_rmem|tcp_wmem那个时候我想准备替换的配置（这个调整比网上的当前值低）#展开TCPtotalmemorysize#Expandto最小值32G不变，中间数为max的70%。echo"net.ipv4.tcp_mem=110486458720268388608">>/etc/sysctl.conf#Singlesocketreadallocationmaximummemory#原来的16MB扩充到32MB（中间数是最Bestpractice推荐）echo"net.ipv4.tcp_rmem=40962516582433554432">>/etc/sysctl.conf#Singlesocketwriteallocationmaximummemory#原来的16MB扩展到32MB（中间的数字是最佳实践推荐）echo"net.ipv4.tcp_wmem=40962516582433554()432">>/etc/sysctl.conf然后在线内存cat/proc/sys/net/ipv4/tcp_mem6169920822656112339840,这里是最小值24G压力值32G最大48G在检查过程中这些参数，突然发现一个问题。我们的在线参数换算成内存值大概是48G，已经太大了。你可以想象一下，tcp链接的总内存已经使用了48G！这部分不仅仅是网络开销而是一个TCP连接，我们有ss来看一下当时的连接情况：通常出现这种情况有两种原因：1.应用没有正确关闭它的socket进程2.确实异常情况下不处理Socket
