跳到正文
首页
Linux
运维避坑
Linux运维避坑案例整理
Linux运维避坑案例整理
整理自用户提供的《新炬运维避坑指南合集》41
篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 46
个案例 。期数按专辑标题编号；来源链接取自离线文章元数据。
查看或下载 Markdown 原稿
案例目录
第
40 期｜CCSE K8S集群中etcd, apiserver,scheduler controller
频繁切换问题分析
专辑文件：02.html，第 6 个案例
查看原文 现象： K8S集群中etcd, apiserver,scheduler
controller
频繁切换。；查看etcd/apiserver/scheduler/controller日志，确认频繁Leader
Election切换，而非组件崩溃。；定位etcd延迟运维建议：
配置标准化；生产环境存储必须开启WriteBack缓存。；新机器上线前应检查存储配置。
第 39
期｜静态ARP绑定活跃内存超限问题分析
专辑文件：03.html，第 7 个案例
查看原文 现象：
网管网办公终端防火墙割接替换后，出现终端业务正常，下挂二层交换机脱管、无法远程管理的。处置过程：
排查防火墙策略是否限制，检查策略无限制。；排查二层交换机管理ip有无静态arp绑定，ip与mac是否相对应，检查无异常。；查看二层交换机本地arp表，发现学不到网关mac，查看防火墙网关mac为全零。运维建议： 防火墙割接后必做校验；核对网关 MAC
地址，确保为非零有效地址，同时检查下挂二层交换机 ARP
表，确认能正常学习到网关 MAC。；建立交换机脱管快速排查流程
第 38 期｜K8S
群节点notReady故障问题分析
专辑文件：04.html，第 6 个案例
查看原文 现象：
某中心集群节点notReady故障，业务侧反馈业务登录界面有异常。处置过程：
出现故障后，查看节点状态；发现异常，并且尝试恢复节点上的服务出现卡死，无法恢复。；通过执行kubectl
get pod -A |grep -vi Running
查看所有的pod是否都正常，并且实例pod副本数都达到期望值运维建议： 新增 containerd、kubelet、docker
服务监控，设置服务无响应、异常重启、日志报错告警；确保核心容器服务异常可及时发现。；建立孤儿
Pod 定期清理机制，定期执行清理命令
第 38
期｜集团sap推送数据到账务系统失败，网络问题分析
专辑文件：04.html，第 7 个案例
查看原文 现象：
集团sap推送数据到账务系统失败，需要多次推送才能成功。处置过程：
因为账务系统刚做了数据中心双活，新增了域名解析，联系集团sap人员确认sap是单点部署，不存在忘记修改配置问题，能正常访问到账务系统。；通过网关日志查看，正常请求都转发到80端口，异常请求都报400，无法负载到后端，分析了异常请求日志发现是将http请求转发到https上了，集团配置账务系统的请求是http://域名。；考虑到网关是不是有http和https之间的转换，直接将服务绑定到节点上进行抓包，发现到服务也是有https请求。运维建议：
双活、域名新增等改造后，必须进行全链路测试；模拟
数据推送场景，校验请求协议、网关转发、网络策略的适配性，确认无异常后再正式上线。；优化网关负载均衡策略，明确
HTTP/HTTPS 端口转发规则
第 33 期｜GPU驱动报错
专辑文件：09.html，第 3 个案例
查看原文 现象：
AI大模型主机需要扩容资源，在添加磁盘后显示不出，然后大数据同事对主机进行了重启。；但重启后gpu驱动报错，识别不到GPU驱动。处置过程：
检查GPU驱动执行nvidia-smi命令，报错；NvIDIA-SMI has；failed because it
couldn运维建议：
部署服务时要考虑到兼容性问题；官网查询资料确认。；对于大模型这类新兴技术要对底层的测试
第
33 期｜prometheus在grafana展示中无法将选择的主机中的显卡筛选出来
专辑文件：09.html，第 4 个案例
查看原文 现象：
部署prometheus对AI大模型主机进行监控，实时监控GPU的资源使用率以及温度等情况，但在grafana中展示无法将选择的主机中的显卡筛选出来。处置过程：
在部署过程中是按照客户的规范进行部署，初步怀疑是grafana中的变量导致；但在排查中发现显卡暴露是以UUID进行区分。所以在展示中不存在变量问题导致区分不开显卡。；排除变量的问题后，怀疑是grafana版本问题导致运维建议：
部署时尽量在客户允许的情况下选择较新的软件版本。减少异常的同时也能提升对新技术的掌握。
第 33 期｜firewall问题
专辑文件：09.html，第 6 个案例
查看原文 现象：
因为系统内核太过陈旧，限制了安装bind9的版本，导致扫描漏洞不能修复，通过开启服务器firewall限制扫描机扫描。处置过程： 首先开启防火墙；systemctl start
firewalld；添加规则使所有ip都能接入运维建议：
此种操作方式类似于添加黑名单，首先得使所有ip都能接入，添加源ip 0.0.0.0/0
为accept至关重要。
第 32
期｜容器应用应用报连接kafka失败
专辑文件：10.html，第 9 个案例
查看原文 现象：
某业务系统反馈无法采集和发出最新告警，应用报连接kafka失败。处置过程：
查kafka日志，提示“设备上没有空间”，立即检查文件系统，发现/app目录达100%。立即分析并清理/app目录中的历史数据，清掉约5%的空间后，再次启动kafka进程，访问kafka集群恢复。；针对此次kafka集群的5台主机，监控告警触发项被禁用，因此两个节点/app被撑满未发出告警，在故障中，也没有第一时间检查空间，导致kafka集群处理恢复速度慢。运维建议：
Kafka集群5个节点，其中2个节点因/app文件系统撑满，kafka进程挂掉，导致集群mgr节点及两个数据节点停止服务。从而无法正常管理集群、新建的连接也无法连接上kafka集群；
第 31 期｜Linux主机重启问题
专辑文件：11.html，第 10 个案例
查看原文 现象：
当主机重启后，系统未能正常进入操作系统，而是直接进入了救援模式；（Rescue
Mode）处置过程：
查看/dev目录，查看磁盘是分区还是逻辑卷，并且找到对应路径；ls
/dev；确认其路径后创建临时目录进行挂载运维建议：
异常因素，出现几率很小。；建立严格的系统配置变更管理制度，对
/etc/fstab、GRUB
引导程序等关键配置文件的修改进行严格审批和记录；配置变更前后，需进行全面的测试和备份，确保配置的准确性和可靠性。
第 28
期｜云服务器域名访问报错504问题
专辑文件：14.html，第 5 个案例
查看原文 现象： 访问云服务器域名报504网关错误。处置过程：
检查网络策略确认无误，云服务器WAF没问题。；发现服务器配置了负载均衡CLB，再次检查WAF，勾选服务器前有四七层代理选项。运维建议：
全面了解业务架构；在排查问题之前，必须先了解系统的整体架构，包括负载均衡、WAF等组件的配置。只有深入理解架构，才能有效识别和排查问题的根源。；检查所有中间层组件配置
第 28
期｜网络通信多VPC通信无法访问
专辑文件：14.html，第 10 个案例
查看原文 现象：
多个VPC通过一个VPN网关无法与线下数据中心通信。处置过程：
原来阿里云学院VPC已经通过IPSEC和线下数据中心实现通信，理论上在此基础只要其他VPC和学院VPC建立对等连接即可。；建立对等连接后仍然无法通信，继续排查发现IPSEC的两端；（阿里云和线下数据中心）运维建议：
多VPC与数据中心通信配置要细致；在多VPC通过一个VPN网关连接到线下数据中心时，确保所有VPC之间的对等连接和路由配置正确。这不仅仅是设置IPSEC连接，还需要确保VPC之间、VPC与线下数据中心的路由规则和流量转发是同步配置的。；对等连接的路由配置
第 27
期｜Kubernetes微服务支付服务异常
专辑文件：15.html，第 3 个案例
查看原文 现象： 在生产环境中运行了一个基于 Kubernetes
的微服务应用，其中某个系统关键服务是 payment-service。；某天开发团队发现
payment-service 的 Pod 状态始终为
CrashLoopBackOff，导致无法处理支付请求。处置过程： 检查配置文件；通过 kubectl describe pod
查看 Pod 的描述信息，发现环境变量 DB_HOST 被配置为
localhost。；检查数据库服务运维建议：
加强配置管理与规范化；严格遵循配置管理规范，利用 Kubernetes 提供的
ConfigMap 和 Secret
等工具集中管理应用配置，避免因手动配置错误导致服务不可用。；全面的环境与依赖验证
第 24
期｜Kubernetes微服务容器间通信丢包问题分析
专辑文件：18.html，第 7 个案例
查看原文 现象：
某中心地市反馈缴费、商品订购失败，重启后容器间ping丢包，业务切换至另一个中心后恢复正常。减少pod数量后，ping丢包消失，微服务容器重启后业务回切至开发区恢复正常。；通过从集群所有主机分别ping
k8s集群自有coredns、monitor-node-exporter服务podip以及业务容器podip，发现部分主机存在ping丢包；经过多次测试，发现这些存在ping
pod丢包的主机均为业务微服务部署主机；30台微服务部署主机中约8台存在丢包；；将一台问题主机上calico容器进行重启验证是否calico网络影响，重启后pod间超时未消失；处置过程：
检查宿主机通信正常，非全部pod之间通信异常，部分业务pod间通信有明显丢包，跨主机ping
pod
ip，有明显丢包；；排查主机之间网络，ping包无丢包；查看监控页面，主机负载均在正常范围内；；查看calico配置文件，主机网卡配置正常；运维建议：
1）单节点资源限制需合理规划；单台主机上运行的Pod数量应限制在合理范围内（如20个以内），特别是在业务高峰期，以避免因资源争用导致的容器间通信问题。；2）加强网络性能监控和预警
第 23
期｜操作系统国产化启动实例时存在节点未启动
专辑文件：19.html，第 9 个案例
查看原文 现象：
操作系统国产化，重启bes中间件集群，域主机控制台、节点、实例正常启动，启动其他节点正常，但域主机日志未输出子节点启动信息，启动实例时报错节点未启动无法启动实例。处置过程：
经排查是由于操作系统国产化后，国产系统不支持主机名带下划线，下划线与bes应用授权相关，所以导致license不可用，在使用临时license替换后，bes集群正常启动。运维建议：
国产化操作系统兼容性检查的重要性；本次故障揭示了在国产化过程中，操作系统与现有软件和中间件的兼容性问题。特别是在涉及到系统配置；（如主机名）
第 21
期｜K8S用户使用平台时会出现504错误问题分析
专辑文件：21.html，第 1 个案例
查看原文 现象：
某业务使用一套华为云paas服务CCE；（基于Kubernetes集群，Kubernetes版本为1.19）；用户使用平台时会出现504错误，在主机中curl后端服务部分后端服务接口正常，部分后端服务无响应。排查与原因：
在故障中，坚持基于证据和自身分析的判断，不被外部厂商或甲方的初步反馈误导。；有效的运维工作需要综合考虑各种因素，并通过不断学习和实践来提升自身的技术水平和问题解决能力。这不仅能提高故障处理效率，也能增强对复杂系统的掌控能力。运维建议：
全面检查系统组件；在遇到问题时，不应只关注一个方面，而应全面检查所有相关的系统组件。从服务运行状态、磁盘使用情况到ELB的健康状态，都需要进行详细检查。通过系统化的检查，能够更全面地了解问题背景和潜在的故障点。；对比分析，找出性能瓶颈
第 21
期｜K8s控制面etcd服务异常，导致大量业务容器服务异常问题分析
专辑文件：21.html，第 2 个案例
查看原文 现象：
某日晚处理故障过程中，需要登陆能力运营管理平台开启能开CIP接口应急，突然发现平台无法登陆，报错404。；检查应急程序服务正常，尝试多次重启也未恢复。检查能开容器pod状态均正常。；后续发现应用deployment
ready副本数与应有副本数不一致，经过滚动重启全量docker服务后应用副本数恢复正常且能力运营管理平台能正常登录。处置过程： 次日发现部分deployment
ready副本数与应有副本数不一致问题重现并有陆续的能开CIP接口调用超时的情况，从kubelet、api等日志发现有大量调用apiserver超时情况，怀疑存在网络问题，协调网络工程师、东软云平台侧等核查，反馈无异常；；偶然检查三台k8s
master节点，发现其中一台etcd服务日志有大量写入超时报错，随后发现该主机IO存在异常情况，io
wait高达70%左右；但检查该虚拟机节点无高耗IO进程，怀疑宿主机存储异常；；将该k8s节点虚拟机迁移至其他宿主机后观察etcd服务恢复正常；运维建议：
应急方案设计要避免对业务自身的依赖；本次故障处理中，因K8s控制面etcd服务异常，导致能力运营管理平台无法登录，进而影响了应急操作的执行。；通过此次经验可以得出，应急方案应尽量避免依赖该业务自身的服务或平台。若业务服务因故障而无法使用，应急方案的实施也将受阻。
第 18
期｜ANTD wal被自动删除，导致集群节点不能加入集群
专辑文件：24.html，第 8 个案例
查看原文 现象：
在etcd和patroni的高可用的环境中，当发生主备切换，当重新加入集群的时候会使用pg_rewind命令来进行数据验证，pg_rewind验证的会去读取wal日志，pg_wal目录的wal日志会自动进行复用或者被删除；，本次就是wal被自动删除了；，导致pg_rewind验证数据的时候查找不到所需要的wal日志，数据验证不通过，导致集群节点不能加入集群。处置过程： stderr=pg_rewind: servers diverged at
WAL location；2 / 80000000 on timeline 2；pg_rewind: error: could
not运维建议：
深入理解wal_keep_size参数的重要性；在本次故障中，由于wal_keep_size设置不当，导致在需要历史WAL日志进行数据一致性验证时，关键的WAL文件已被自动删除，从而引发了集群节点无法成功加入的问题。这突显了深入理解wal_keep_size参数对于维护数据库高可用性和数据一致性的重要性。；明确其作用
第 18
期｜k8s集群pod实例内存使用率增长过快触发的实例重启
专辑文件：24.html，第 9 个案例
查看原文 现象：
某系统业务负载的内存使用率大于90%频繁告警，收到告警后，经过查看部分pod实例发生重启，暂时未影响到业务。；经过与开发人员沟通，先在夜间重启该负载释放内存，观察内存增长情况，；该负载在重启1天后，又出现pod内存使用率90%告警，同时也有部分实例重启处置过程：
通过华为apm监控分析该负载的JVM堆内存使用率较低峰值在3g左右，发现堆内存垃圾回收正常，确认jvm堆内存使用量正常，且堆内存设置值过大，首先降低jvm内存配置值-Xms和-Xmx为5g。；询问开发人员该负载的功能，确认为查询es数据，查询可能会涉及大量内存使用，因此调高pod的内存申请量和限制量为12g，；同时对pod的实例个数由5个扩容到8个，增强负载承载能力。运维建议：
针对业务功能合理配置资源；不同的业务负载对资源的需求不同，因此需要根据具体功能调整资源配置。在本次案例中，针对查询ES数据的负载，合理调高了pod的内存申请量和限制量，确保负载在高内存需求下依然能够稳定运行。；定期评估并优化JVM配置
第
18 期｜对apollo主机缩容后，导致容灾环境的k8s容器实例不断重启
专辑文件：24.html，第 10 个案例
查看原文 现象： 经过查看容器日志发现无法Could not load
config for namespace appication from
Apollo，确认apollo服务的问题，该服务主机进行配置缩容16g缩容为8g。；经过查看apollo是有amdin，conifig，portal三个服务进程部署一台主机上，初步判断是主机缩容后，服务启动异常，于是进行服务重启，使用一键启动脚本启动后，发现缺少config服务进程，于是查看服务日志，未发现明显的服务报错。；由于想到该主机刚进行过缩容，查看已启动的服务进程发现进程设置的jvm堆内存为3g处置过程：
对每个服务的jvm堆内存降低配置3g；（-Xms和-Xmx；重启容器服务，业务正常。运维建议：
结合系统变动快速定位问题；在排查故障时，尤其是在系统刚刚经历了变动的情况下，首先考虑变动对系统的潜在影响能够迅速定位问题根因。本次故障的快速定位归功于对Apollo主机缩容后的问题联想，迅速确定了内存不足导致服务启动失败。；合理配置服务内存
第 17
期｜K8S单个pod在某个时间点内存突增
专辑文件：25.html，第 2 个案例
查看原文 排查与原因：
容器服务中的单个pod在某个时间点内存突增，导致服务访问故障。需要在保证服务正常运行的前提下排查。处置过程：
业务反应部署的一个服务中的三个pod，其中一个pod内存突增，而此时访问服务已出现故障。；在后台定位定位故障pod，使用kubectl
edit pod xxxxx -n xxxx
修改故障pod当前标签的值，使其与deployment的标签不匹配，此时故障pod不再受控制器托管，请求也不会落到故障pod上，那么RS会由于当前控制器实际管理pod比期望pod数量少而新增一个pod。；提醒业务方检查服务是否可用，在业务反馈服务正常之后，在故障pod中导出dump.hprof内存快照，运维建议：
业务系统的开发人员，将大对象分割成指定大小的数个小对象进行处理，更有利于GC收集器对其进行回收，避免内存泄漏，；最后将从控制器孤立出来的pod手动删除。；强化监控系统，
第 17
期｜K8Setcd的master节点不断选举
专辑文件：25.html，第 3 个案例
查看原文 现象：
etcd的master节点不断选举，由于apiserver通常会使用etcd作为存储后端，存储集群状态信息，所以会导致apiserver的leader也不断选举。；因为应用节点要与apiserver进行交互，来管理和调度应用程序，上述故障会导致应用节点与apiserver及时的或者正确的通信，影响业务应用的使用。处置过程：
检查相关的master节点上的etcd服务运行的状态以及相关events；发现etcd集群不断的在选举，从而导致apiserver也不断在选举，因为apiserver配置的环路地址，并且etcd又在不同的主机上面，那么etcd无法通过apiserver的环路地址进行通信。；检查3个节点的服务器的系统状态及日志运维建议：
增加网络监控；使用网络监控工具；（如Nagios、Zabbix等）
第 15
期｜OB集群网络抖动导致事务偶发失败
专辑文件：27.html，第 3 个案例
查看原文 现象： 数据库中执行；insert into xxx select * from
xxx；时有时候插入正常，有时候报错transaction needs
rollback，用oms迁移oracle数据到该ob库时基本上每次迁一会速度就会降到0kb/s，在ocp
sql诊断查看oms的insert语句报的也是-6244 transaction needs
rollback。处置过程：
ocp上观察到该集群主机频繁有网络收发包出错告警，业务网卡bond
error计数一直在增加。主机侧排查网卡有翻滚，主机侧协助禁用故障网卡后恢复正常。运维建议：
综合网络监控；使用高级网络监控工具监控网络流量、错误率和延迟。；工具如Nagios、Zabbix或新兴的云监控工具，可以实时检测并报告网络状态。
第 13 期｜K8S
集群主机节点端口不通
专辑文件：29.html，第 5 个案例
查看原文 现象：
k8s主机集群主机节点到端口8082不通（网络策略已经申请，并且网络策略已经实施完毕），网络策略配置没有问题，端口却依然不通。处置过程： 检查134.84.xx.xxx到目标主机134.84.xx.xxx
8082 端口不通同时不能ping通；通过在目标主机上tcpdump抓包，没有抓到源主机
134.84.xx.xxx的请求数据包；tcpdump i any nn host 134 .84.xx .xxx运维建议：
在修改网络配置后，应有一套验证流程来确保所有更改均已正确生效。这包括验证配置文件和运行时配置是否一致，以及确保所有相关服务（如keepalived）使用的是更新后的配置。；自动化检测和修复；考虑实施自动化工具来监测集群的网络状态和配置一致性。例如，可以开发一个简单的脚本定期检查VIP配置，并与预期状态对比，自动报告或修正偏差。
第 13
期｜k8s集群执行kubectl exec 报错
专辑文件：29.html，第 6 个案例
查看原文 现象： k8s集群执行kubectl exec 报错。处置过程： 通过kubectl exec
命令进入pod，等待一会，报错，无法进入pod；报错显示kubelet
端口10250端口超时。；从执行命令的节点，ping
pod所在的宿主机节点IP通。telnet
那个无法进入pod所在的宿主机的10250端口不通运维建议：
实施实时监控，特别是针对关键服务和端口的可达性，以便及时发现并解决问题；审查
kubelet、kube-proxy 和 Docker
服务之间的依赖关系和启动顺序。错误的启动顺序可能导致网络或服务初始化不正确；制定一套标准化的网络故障恢复流程，包括服务重启、网络连接测试和验证步骤
第 13
期｜db2恢复数据库过程以及恢复中出现的问题解决
专辑文件：29.html，第 7 个案例
查看原文 现象：
需要查询历年数据进行核对，db2数据保留的时间无法满足于当前需求，所以进行数据恢复供查证。处置过程：
恢复数据中，执行恢复脚本会出现的问题，出现过bad
container…错误；原因1：因为可能是指定的路径正在被自动存储使用。要确定是否是这种情况，可以列出表空间的容器路径，并确定是否正在使用自动存储。；处理1：Db2pd
-d databasename
-tab查看最后一项中的path是否存在，存在的且被使用的话，可以在他原来路径的子目录下新建一个目录。运维建议：
在进行任何恢复操作前，确保有完整的备份，并验证备份数据的完整性；尽可能在隔离环境中进行数据恢复操作，避免对生产环境造成干扰；包括在测试服务器上进行恢复尝试，以确保所有步骤都不会对生产数据造成影响。
第 12
期｜硬件更换导致K8S服务异常处理
专辑文件：30.html，第 6 个案例
查看原文 现象：
etcd的master节点不断选举，由于apiserver通常会使用etcd作为存储后端，存储集群状态信息，所以会导致apiserver的leader也不断选举。；因为应用节点要与apiserver进行交互，来管理和调度应用程序，上述故障会导致应用节点与apiserver及时的或者正确的通信，影响业务应用的使用。处置过程：
检查相关的master节点上的etcd服务运行的状态以及相关events；发现etcd集群不断的在选举，从而导致apiserver也不断在选举，因为apiserver配置的环路地址，并且etcd又在不同的主机上面，那么etcd无法通过apiserver的环路地址进行通信。；检查3个节点的服务器的系统状态及日志运维建议：
对于k8s集群核心组件的故障，切忌盲目进行配置修改，首先应观察节点日志、集群事件。发现并非应用发引起的故障后才应驱逐该节点上的应用并将节点设置为不可调度，继续排查问题所在。
第 11
期｜业务系统告警拨测异常，且出现大规模恶化情况
专辑文件：31.html，第 5 个案例
查看原文 现象：
业务系统告警拨测异常，一开始只有个别机器，后来是大规模恶化，排查出问题的主机不在一台宿主机上，且不是一个系统，出问题主机无法ssh登录，vnc登录报错主机huang住，偶尔可以登录主机，top查看所有iowait使用率比平时高很多。；查看Ceph集群服务，pg状态异常；log_log_channel（cluster）处置过程：
存储使用的Ceph集群；重启mon服务后等待数据均衡后恢复。运维建议：
优化管理流程，在遇到故障时所有团队一块处理问题，避免因流程浪费故障处理时间。
第 11 期｜主机系统load
average负载过高
专辑文件：31.html，第 9 个案例
查看原文 现象： 系统load
average负载刚开始就很高，查看原因是有大量D进程；[ScqDelayTask]；因为D进程都是同样的，查看dmesg日志，有HBA卡跟驱动相关Call
Trace打印处置过程：
原因为HBA卡驱动版本与系统不匹配，升级对应版本驱动。运维建议：
及时升级版本驱动，升级前务必做好充分的测试。
第 11 期｜业务系统
专辑文件：31.html，第 10 个案例
查看原文 现象：
某日用户反馈其业务系统丢包情况较为频繁。；应用云为三域独立部署，该故障用户系统部署在公共服务域，应用云由外向内大致拓扑走向为：出口路由器——某安全厂商防火墙——业务核心交换机——云内。；1）故障点定位排查与原因：
当前场景下开启ha会话同步配置，导致主设备大量会话通过ha会话同步给备机，引起备机会话数过高，导致备机会话池占用率超出95%，且未及时清理，引发丢包。；对备防火墙进行了重启操作，释放出的空间达到95%以上，后经用户两天的反馈，未再发生心跳中断情况，此故障问题恢复。运维建议：
1）自身缺乏监控手段；应用云骨干链路缺乏自动化监控及告警手段，导致故障发现不及时。；部署rpa监控软件，自动ping测三域云内、云外网络通信情况，实现分钟级告警提醒。
第 8
期｜F5会话分布保持方式配置导致负载分配不均
专辑文件：34.html，第 5 个案例
查看原文 现象：
F5会话分布保持方式配置导致负载分配不均导致的业务影响。处置过程：
业务属性为redis中间件，微服务组件自搭建组件化服务，共6个服务节点；；排查出现问题负载现配置策略情况；负载策略为轮询，会话保持方式主用cookie，候选为源地址；；故障发生时只有单个业务员受到影响，其他用到组件间的都无此异常；运维建议：
此负载策略建立、使用2年，出现故障业务系统使用组件化1年左右，随着业务增长导致原存在隐患造成业务故障；；在新创建负载时需了解负载的业务使用场景，选择最优的负载配置方式；；后期注意负载使用的监控，及时发现隐患，及时解决。
第 8 期｜Kubernetes无响应处置
专辑文件：34.html，第 9 个案例
查看原文 现象：
某业务有一套Kubeadm部署的Kubernetes集群，Kubernetes版本为1.15，CNI网络插件为Calico，使用的IPIP模式。：用户使用平台时会出现无响应、响应超时，在集群中部分主机curl接口正常，部分主机无响应。；curl服务接口，在node节点上和容器内抓包，抓包发现有大量重传，遂怀疑主机网络有问题。联系甲方核实是否有网络变更，甲方回复没有任何网络变更，突然之间就是不能用了。部署业务的主机由甲方提供，且主机、网络等由甲方维护。；查看甲方反馈出问题时间点的kubernetes组件日志、系统日志、业务日志，逐个重启服务，重新抓包分析。怀疑是mtu值设置不合理导致重传和丢包较多，检查主机网卡和calico
mtu值配置均未发现改动。联系我方网络侧同事帮助分析，也怀疑是mtu值设置不合理导致，遂将初…处置过程：
首先检查服务是否运行正常，磁盘使用率是否正常（磁盘使用率较高会导致kubernetes主动驱逐pod），业务日志有无明显报错。；检查calico、coredns是否正常运行。；网络是任何系统或平台离不开的技术，在故障中需要充分考虑。
第 7 期｜BC Linux lvm
缩容引发的“血案”
专辑文件：35.html，第 7 个案例
查看原文 现象： BC Linux lvm
缩容后重新挂载后数据盘丢失。处置过程：
GDDB单机环境安装可用空间为3.6T，但实际发现数据盘总可用大小为1.9T。；检查环境可知，系统采用gpt分区管理。同时发现数据库采用lvm管理。；于是决定对数据盘进行lvm扩容。RAID磁盘一块盘可以创建最多4个primary分区。所以当时在划分pv时，只划分了500G。并且成功扩容VG容量到2.4T。运维建议：
又因为GDDB厂商扩容到3T。因此又进行了pv的创建。在创建过程中发现无法创建第五个主分区。；因此尝试采用扩展分区进行LVM扩容。分区创建成功后，需用toggle
/dev/sdn lvm
进行标识。结果发现扩展分区打标成功，但是还是无法识别成lvm的pv。且尝试添加pv到VG当中失败。；思考之后，决定进行lv的缩容，然后划分更大的PV。于是执行了lvreduce
命令，随后进行vg的缩容。缩容后重新创建了更大的pv，并成功标识为lvm磁盘，添加进了VG。
第 6
期｜某业务系统新框架服务自助查询缓慢
专辑文件：36.html，第 3 个案例
查看原文 现象： 某业务系统查询出现缓慢。处置过程：
检查容器应用服务资源使用情况正常，业务反馈缓慢时，pod已全部重建，但查询仍然缓慢。；数据库资源使用情况核查、数据库连接请求情况核查，均无异常。；redis服务器资源使用情况核查，无异常。运维建议：
对于业务繁忙的且开启redis开启了rdb持久化的系统,调大redis
save参数。；上线前充分作业性能压力测试。
第 6
期｜某应用POD出现连接数据库偶断
专辑文件：36.html，第 4 个案例
查看原文 现象：
网络配置导致某应用POD出现连接数据库偶断问题。处置过程： 查看数据库会话，
发现会话数正常，也没有繁忙的会话，数据库主机负载正常；；查看K8S的宿主机，发现宿主机负载正常；；在宿主机上连接数据库测试，
测试正常，没有连不上的情况；运维建议：
在高版本的操作系统，或者开源操作系统中，可能开启了多个管理插件，如防火墙的filter
有iptables.service，firewalld，网络管理的NetWorkManager,
network等，最好不要同时启用；；正式上线前最好能做全面的压力测试，确保数据库及其相关服务器无问题。
第 6
期｜Openssh后(9.1或9.3)导致sshd等服务失败
专辑文件：36.html，第 6 个案例
查看原文 现象：
升级完成OPENSSH后，出现相关问题，表现如下；ssh免密失效；；sftp无法连接登录；处置过程：
升级openssh后ssh免密失效，跳转出错，在/etc/ssh/sshd_config添加一些旧版的算法，并重启sshd服务，免密跳转恢复正常；HostkeyAlgorithms
+ssh-rsa；PubkeyAcceptedAlgorithms +ssh-rsa运维建议：
升级前，一定要对方案进行仔细测试并进行评审，做好回退方案；；升级中，认真按照方案操作，不能疏忽导致漏掉步骤；；升级后，仔细检查服务状态，确认升级后服务没影响。
第 5
期｜主机密码过期导致crontab失效
专辑文件：37.html，第 1 个案例
查看原文 现象：
接收到ADG中断告警，经核查为密码过期导致crontab无法正常运行，影响自动清理任务以及告警发出，进而导致备库无法接收归档。处置过程：
发现主机用户密码设置的90天生命周期，密码过期后会影响该用户下crontab任务的调用，导致依据crontab调用的一些重要脚本失效，如归档清理脚本无法自动清理而耗尽归档目录导致备库无法接收归档；crontab调用的告警脚本无法读取数据，告警信息无法正常发出等。；若故障期间相关信息无法第一时间推送出来，会加剧该故障的影响。运维建议：
各场地加强对主机用户密码状态的管控，增加主机账号密码过期监控告警。或者建设专门的密码管控平台，将所有主机账号的密码生命周期纳入管理。
第 5 期｜磁盘挂载后主机hang死
专辑文件：37.html，第 2 个案例
查看原文 现象：
出现问题的设备为Proxy主机，安装了zabbix-proxy和snc-proxy，由于分配的磁盘较大，也在上面运行了一个kafka节点，一个zookeeper节点，所有服务都运行在挂载的磁盘空间内，在主机的内存使用率和线程占用飙升后，；主机卡死，无法登陆，重启主机失败处置过程：
由于出现问题的主机在稍早前出现过硬盘资源不够的问题，通过向资源池管理工程师提交资源扩容工单，多分配500g的磁盘。；在得到分配后的硬盘时，通过使用lvextend
-l +100%FREE /dev/vg/root命令和xfs_growfs /dev/mapper/vg-root
命令将未使用空间在线扩展并同步文件系统。；挂载点选则为ampdcp目录下运维建议：
在/etc/fstab配置问文件挂载磁盘时，一定要检查好格式是否有问题，否则在重启主机后有可能会失败。；在配置磁盘挂载的时候，与以前正确的配置文件做一下对比保证磁盘挂载成功。
第 5
期｜光纤链路报错导致数据库IO响应缓慢
专辑文件：37.html，第 3 个案例
查看原文 现象： 光纤链路报错导致数据库IO响应缓慢。处置过程：
CRM库业务反馈缓慢，经核查发现大量TX锁，锁源和被堵会话均为insert语句，先通过查杀会话后恢复，十几分钟后TX锁又再次出现，刚开始怀疑业务逻辑有问题导致TX积压，继续kill会话，但业务反馈近期未做更新，抓取故障时间段的awr发现日志写入延迟非常高，查看主机日志发现；存在链路报错信息；，在更换故障链路后，业务恢复正常。运维建议：
分析故障问题需要结合多方面情况查看，很多表现出来的问题都是被影响的。；完善监控体系，增加对syslog的监控
第 5
期｜云应用CPU资源使用率持续达到90%以上
专辑文件：37.html，第 9 个案例
查看原文 现象：
上云应用所有pod的CPU资源使用率持续达到90%以上。处置过程：
top分析pod的线程占cpu情况。；分析线程目前运行代码段，使用jstack命令获取当前正在Running的代码段。；代码段提交业务侧分析代码，业务侧对代码段中的代码进行分析，是由于while循环，一直返回false引起。运维建议：
建立代码开发规范，严格要求按照规范进行业务代码开发。；加强上线代码审核，避免代码带病上线。
第 5 期｜容器pod无业务请求
专辑文件：37.html，第 10 个案例
查看原文 现象：
上云应用模块存在2个pod无业务请求，业务侧反馈是服务未注册至zookeeper导致。处置过程：
查看应用模块四个pod运行情况,cpu、内存及jvm配置，属正常情况。；查看Tomcat日志运行情况。；该应用4个pod后台日志都正常启动，没有明显报错的日志，连接数据库初始化正常。运维建议：
加强应急演练，引入混沌工程体系，通过混沌提前发现问题。；梳理相关业务资产配置信息，确保问题不再发生。；引入流量监控体系，当某个pod流量长时间低于某个值时进行告警或者预警。
第 4
期｜中间件tomcat连接数告警处理
专辑文件：38.html，第 1 个案例
查看原文 现象：
某主机中间件tomcat连接数告警处理，检查分析tomcat访问日志等，后续重启XX掌柜nginx及主机tomcat逐步恢复。处置过程：
收到23主机tomcat后端连接数高告警；；重启23主机tomcat后过一段时间连接数涨起来；；切换array负载至22主机，后过一段时间22主机tomcat连接数涨起来；运维建议：
系统页面未设置防止重复点击功能，积压后重启后端服务，用户不断进行大量点击都会产生大量连接进而导致重启后积压不断重复此操作无法恢复业务，经验总结前后端同时重启后恢复。
第 4
期｜磁盘挂载后主机重启失败
专辑文件：38.html，第 10 个案例
查看原文 现象： 磁盘挂载后主机重启失败。处置过程：
由于出现问题的主机在稍早前出现过硬盘资源不够的问题，通过向资源池管理工程师提交资源扩容工单，多分配500g的磁盘。；在得到分配后的硬盘时，通过使用lvextend
-l +100%FREE /dev/vg/root命令和xfs_growfs /dev/mapper/vg-root
命令将未使用空间在线扩展并同步文件系统。挂载点选则为ampdcp目录下。挂载后使用df
-h查看主机磁盘挂载成功，但是通过上述命令挂载的磁盘，在/etc/fstab的配置文件中并没有对文件格式xfs配置，所以导致当主机重启后失败。；最后通过修改错误的配置后重启成功运维建议：
在配置磁盘挂载的时候，与以前正确的配置文件做一下对比保证磁盘挂载成功。；新炬运维避坑指南连载（一）；新炬运维避坑指南连载（二）
第 3
期｜K8S集群某业务模块偶尔访问缓慢
专辑文件：39.html，第 9 个案例
查看原文 现象： K8S集群某业务模块，偶尔访问缓慢问题。处置过程：
业务前台反馈，有时访问缓慢。；厂商查询未发现异常。；我侧介入分析，发现某pod的cpu比其它15个pod
cpu高，然后做线程快照，未发现阻塞进程。运维建议：
与业务侧沟通整个访问逻辑，发现业务注册zk时，并非用的是k8s自带的，用的是Dubbo的负载均衡，并且用的是默认均衡策略(加权随机策略),这种默认策略存在雪崩风险，修改为加权轮询；临时方案，由于重保期间，删除有问题的pod,再水平伸缩pod至20个。；使用dubbo负载均衡，采用加权轮询模式。
第 2 期｜IP V6双栈后网络不通
专辑文件：40.html，第 9 个案例
查看原文 现象： ipv6
前缀地址(类似ipv4的子网掩码)是128，ipv6双栈改造报错，不同网段的主机不通。处置过程： 观察到ipv6
的前缀地址之后，反馈给主机和网络检查，ping IPV6
测试主机网络是通的。；ORACLE集群添加ipv6 的子网直接报错如下；./ srvctl
modify network subnet 2049 8020:5cc0:bbf2:c701 / 112 PRCN-2070运维建议：
对于IPV6改造，要提前进行子网规划，提前进行相关测试。避免因为双栈改造导致业务故障。
第 2
期｜ZABBIX延迟增大导致业务缓慢
专辑文件：40.html，第 10 个案例
查看原文 现象：
zabbix_server采集延迟越来越大，查看zabbix_server服务进程时发现预处理进程（preprocessing）积压数据越来越大，最终缓存数据会撑爆主机内存导致内存溢出，操作系统自动kill调zabbix_server进程。处置过程：
观察zabbix_server预处理进程（preprocessing)数据积压是否越来越大，历史数据同步进程（history
syncer）是否存在耗时较大的情况；；zabbix_server运行日志error报错处理，；写入/更新报错日志并跟进处理，其次可能会存在因为脚本下发不成功或者脚本未能正常更新导致的采集指标报错的日志，需要重新下发/更新采集脚本/禁用监控项方式解决掉报错问题；运维建议：
增加对ZABBIX积压告警，大多数情况下ZABBIX主要用于各类运维系统，需要；增加自监控；，防止监控系统在自身出现问题时灯下黑，进而让运维人变成睁眼瞎。
第 1 期｜k8s
Coredns配置参数配置优化
专辑文件：41.html，第 7 个案例
查看原文 现象：
业务迁移到容器云平台上线后，用户反映服务访问缓慢，经过查看大量日志，发现某中心coredns
域名解析存在告警级别报错，怀疑与coredns解析域名迟缓有关。；由于
conntrack 的创建和插入是不加锁的，最终后面插入的 conntrack
表项就会被丢弃，导致dns 的 pod
副本只有一个实例的情况就很容易发生，造成就是 DNS 5
秒延时，从而请求超时。排查与原因：
k8s在大规模并发情况下存在一个coredns5秒超时的问题，；是镜像底层库 DNS
解析行为默认使用 UDP 在同一个 socket 并发 请求 A (ipv4地址) 和 AAAA
(ipv6地址)记录。；由于 UDP 无状态，两个请求可能会并发创建
conntrack连接跟踪 表，连接跟踪表存放于系统内存中，可以用cat
/proc/net/nf_conntrack查看，最终会被 DNAT目标地址转换 成同一个集群 DNS
的 Pod IP ，最终它们的五元组就相同了，就会导致 conntrack 冲突。处置过程：
排查Coredns服务日志报错问题，Coredns配置参数，Coredns配置资源，域名解析地址查询及k8s内域名解析测试等。；具体操作如下；查看coredns
资源使用情况，docker stats xxxx；运维建议：
上线之前，增加大并发请求测试，针对coredns解析进行性能测试2、部署dns缓存代理，当大并发请求时出现，避免出现coredns超时5秒的情况。