11月份运维面试题

1.信XX大公司

1.你们平时用zabbix都监控什么指标？

1. 系统资源： CPU利用率、内存使用率、磁盘空间/IO、网络带宽/流量/延迟；
2. 系统状态： 服务器在线状态、进程数、负载平均值（load average）、登录用户数；
3. 应用服务： Nginx/MySQL/Tomcat等进程是否存活、端口是否监听、服务响应时间；
**4. 日志与告警：**系统错误日志、应用异常日志，支持自定义阈值告警（如CPU超80%告警）。

2.数据量很大，但是网络带宽是有限的。咱们现在如果要备份的话，怎么执行这种策略？

数据量大+带宽有限时，备份核心策略是 "减少传输量+错峰+分阶段备份" ，具体方案如下：

一、核心备份策略（3个关键动作）

选对备份类型，减少重复传输

全量备份：每周1次（如周日），备份所有数据（基础备份）；
增量备份：每日1次，仅备份全量后变更的数据（传输量极小）；
差异备份：每3天1次，备份上次全量后变更的数据（兼顾速度与恢复效率）。
工具：MySQL用 mysqldump （加 --single-transaction 锁表），文件用 rsync （增量同步）。

错峰+压缩，降低带宽占用

错峰：在凌晨0-4点（业务低峰）执行备份，避开带宽高峰；
压缩：备份时启用压缩（如 mysqldump -u root -p --compress ），或用 gzip 压缩备份文件，传输量减少60%-80%。

本地备份+异地同步，拆分带宽压力

第一步：先在本地服务器完成备份（无网络消耗）；
第二步：用 rsync （支持断点续传）或 scp （加 -C 压缩），仅同步新增/变更的备份文件到异地，避免全量传输。

二、进阶优化（带宽极紧张时）

启用备份分片：大文件拆分后分批传输（如用 split 命令），避免单次占用过多带宽；
限制传输速率： rsync 加 --bwlimit=1000 （限制1000KB/s），避免备份拖垮业务网络；
用存储专线：异地备份走内网专线，不占用公网带宽。

3.如果是部署一个 MySQL 集群，主从啊，或者是双主啊，就说它如果是主节点挂了之后，它如何让业务感觉不到那个波动，能平滑的切到另外一个节点上。

核心是 "自动故障检测+自动切换+业务无感知接入"，分主从、双主架构给极简方案：

一、主从架构（一主多从）

核心组件： Keepalived （虚拟IP+故障检测）+ 从库（备用主库）
切换逻辑：

主库挂了，Keepalived检测到（ping不通/端口无响应），自动将虚拟IP漂移到备用从库；
从库提升为主库（ stop slave; reset master; ），业务通过虚拟IP连接，无感知。

关键配置：Keepalived绑定虚拟IP，主从库配置相同服务端口。

二、双主架构（互为主从）

核心组件： Keepalived （双机热备）+ 互为主从配置
切换逻辑：

两台主库互相同步数据，共享一个虚拟IP；
一台挂了，Keepalived秒级将虚拟IP切到另一台，业务无感知，且数据已同步。

三、进阶方案（高可用）

用 MGR（MySQL Group Replication）或 ProxySQL ：

MGR：自动选举新主，内置故障转移，无需额外组件；
ProxySQL：作为中间代理，业务连ProxySQL，主库挂了自动路由到从库，透明切换。

4.我现在要进入容器去改一些文件，比如怎么进容器啊？

进入Docker容器改文件最常用的是 docker exec 命令，若容器无编辑器或无法启动，还有备用方案，具体操作如下：
1. 直接进入运行中的容器（临时修改首选）

先查目标容器的ID或名称，执行命令： docker ps 。
执行进入命令： docker exec -it 容器ID/名称 /bin/bash ；若容器是Alpine系统，把 /bin/bash 换成 /bin/sh 。
若容器无vim编辑器，Debian/Ubuntu系统可装： apt-get update && apt-get install vim ；Alpine系统用： apk add vim 。
用 vi 容器内文件路径修改文件，改完按 Esc + :wq 保存，输入 exit 退出容器，必要时用 docker restart 容器ID/名称重启生效。
2. 容器无法启动？拷贝文件到宿主机修改

若容器启动失败没法进入，用 docker cp 拷贝文件操作：

把容器内文件复制到宿主机： docker cp 容器ID/名称:容器内文件路径宿主机本地路径。
本地改完后，再复制回容器： docker cp 宿主机本地路径容器ID/名称:容器内文件路径。
最后启动容器： docker start 容器ID/名称。
提前挂载目录（长期频繁修改首选）

启动容器时用 -v 挂载宿主机目录到容器，后续直接改宿主机文件就能实时同步，无需进入容器。启动命令示例： docker run -d -v 宿主机目录路径:容器内对应目录路径 --name 容器名镜像名。

5.做过安全加固吗？比如说有安全部门的扫出来什么服务器漏洞啊，或者是怎么着，需要去去修啊什么的。

6.就咱们平常一般巡检的话，比如说咱们有几台机器要巡检，要防止未来出故障，主要巡检哪些内容？

巡检核心围绕 "硬件健康+系统稳定+应用可用+安全合规"，覆盖4大维度，简单好执行：

一、硬件层巡检（物理机/云主机基础）

CPU/内存/磁盘：CPU利用率（峰值≤80%）、内存使用率（≤85%）、磁盘空间（剩余≥20%）、磁盘IO（无持续100%占用）；
网络状态：网卡流量（无异常峰值）、端口连通性（核心端口如3306/80/443正常监听）、无丢包（ ping 测试丢包率=0）；
硬件告警：云主机看厂商监控（如AWS CloudWatch/阿里云ECS监控），物理机查电源、风扇、硬盘指示灯（无红灯告警）。

二、系统层巡检（操作系统稳定性）

进程状态：无僵尸进程（ ps -ef | grep defunct 无输出）、核心服务（sshd/rsyslog/crond）正常运行；
日志检查：/var/log/messages（系统错误）、/var/log/secure（登录异常）无报错，无暴力破解日志；
资源监控：负载平均值（load average，单CPU≤1，多CPU≤核心数）、swap使用率（≤20%，过高说明内存不足）；
定时任务： crontab -l 检查备份/清理任务是否正常，无失效任务。

三、应用层巡检（业务服务可用性）

中间件状态：
MySQL：进程存活、端口3306监听、主从同步正常（ show slave status 无报错）、慢查询无激增；
Redis/Nginx：进程存活、端口监听、连接数正常（无超上限）；
容器： docker ps 无异常退出容器， kubectl get pods （K8s）无CrashLoopBackOff；
业务可用性：Web服务可访问（ curl 地址返回200）、接口响应时间（≤500ms）、无5xx错误。

四、安全层巡检（防攻击/漏洞）

端口暴露： netstat -tuln 检查无用端口是否开放，核心端口（3306/6379）仅内网可访问；
权限检查：关键文件（/etc/passwd、/etc/sudoers）无异常权限变更，无新增不明用户；
漏洞修复： yum check-update 查看是否有高危系统漏洞，定期更新补丁（生产需测试后更新）。

7.你说的这些都是用工具还是直接进行脚本？

日常巡检推荐 "脚本自动化+工具可视化" 结合，小集群用脚本高效，中大型用工具省心，具体方案如下：

一、脚本执行（适合≤10台机器，轻量高效）

核心脚本功能：一键检查CPU/内存/磁盘/服务状态，输出异常信息，示例片段：

bash 复制代码

# 检查CPU利用率（超80%告警）
cpu_usage=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}')
if [ $(echo "$cpu_usage > 80" | bc) -eq 1 ]; then
  echo "⚠️ CPU利用率过高：$cpu_usage%"
fi
# 检查MySQL存活
if ! ps -ef | grep -q [m]ysqld; then
  echo "❌ MySQL服务未运行"
fi

使用方式：保存为 server_check.sh ，定时任务（ crontab ）每日凌晨执行，结果发邮件/企业微信。

二、工具巡检（适合≥10台机器，可视化强）

开源工具：

Zabbix：监控硬件/系统/应用，支持自定义告警（如CPU超阈值发短信）；
Prometheus+Grafana：时序数据监控，图表化展示趋势（如磁盘空间递减）；
Ansible：批量执行巡检脚本，输出统一报告。

云厂商工具：阿里云ARMS、AWS CloudWatch，直接对接云主机，无需额外部署。

三、组合方案

脚本做日常快速巡检（5分钟出结果），工具做长期监控+预警（24小时值守），既高效又全面。

8.那你平时是怎么部署 K8S 的？你能给我简单说一下吗？

部署K8S核心是"准备环境→安装组件→初始化控制平面→加入节点→部署网络插件"，简单步骤如下：
1. 环境准备： 所有节点（至少1主N从）配置静态IP、关闭防火墙/SELinux、禁用swap，安装Docker等容器运行时。
2. 安装组件： 各节点安装kubeadm（部署工具）、kubelet（节点代理）、kubectl（命令行工具）。
3. 初始化主节点： 主节点执行 kubeadm init ，生成加入集群的令牌和命令。
4. 加入从节点： 从节点用主节点生成的命令，加入集群（如 kubeadm join 主节点IP:6443 --token ... ）。
**5. 部署网络插件：**主节点安装Calico/Flannel等网络插件，确保Pod间通信。

9.你这个CI/CD 这块是怎么做的呀？

CI/CD核心是**"代码提交→自动构建→测试→部署"** 的自动化流水线，主流做法结合工具链实现，简单步骤如下：

1. 工具选型（常用组合）

代码仓库：Git（GitHub/GitLab/Gitee）
CI/CD工具：GitLab CI、Jenkins、GitHub Actions、Jenkins
构建工具：Maven（Java）、npm（前端）、Docker（容器打包）
镜像仓库：Docker Hub、Harbor
部署目标：K8s、云服务器、虚拟机

2. 核心流程（以"GitLab CI + Docker + K8s"为例）
1. 代码提交触发CI： 开发者推代码到GitLab，触发 .gitlab-ci.yml 配置的流水线。
2. 自动构建与打包： CI服务器拉取代码，用Maven/npm构建项目，再通过Dockerfile打包成镜像，推送到镜像仓库。
3. 自动测试： 构建后执行单元测试、集成测试（如JUnit、Selenium），测试失败则终止流水线并告警。
4. 自动部署到目标环境： 测试通过后，CD工具（GitLab CI内置/ArgoCD）拉取镜像，通过K8s的Deployment资源更新应用，实现滚动更新。

10.那个咱们，你刚刚不是说你从 Jenkins 到那个 K8S 去实现了自动部署吗？对吧？咱们这个流水线阶段是怎么去做的？

Jenkins + K8s 实现自动部署的核心是用Jenkins串联**"代码拉取→构建→打包镜像→推镜像→调用K8s部署"** ，流水线分5个关键阶段，步骤如下：

1. 前置准备（环境铺垫）

Jenkins安装 Docker Plugin （操作镜像）、 Kubernetes Plugin （连接K8s集群）。
Jenkins服务器配置Docker环境（能构建镜像），并添加K8s集群凭证（kubeconfig）。
准备好Dockerfile（项目打包镜像用）、K8s部署yaml文件（Deployment+Service）。

2. 流水线5个核心阶段（Jenkinsfile定义）

复制代码

groovy   
pipeline {
    agent any
    stages {
        // 阶段1：拉取代码
        stage('Pull Code') {
            steps {
                git url: 'https://xxx.git', branch: 'develop' // 拉取develop分支代码
            }
        }

        // 阶段2：Build构建（以Spring Boot为例）
        stage('Build Project') {
            steps {
                sh 'mvn clean package -Dmaven.test.skip=true' // 编译打包，跳过测试
            }
        }

        // 阶段3：构建Docker镜像并Push到仓库
        stage('Build & Push Image') {
            steps {
                sh '''
                    # 构建镜像（镜像名含版本号，用commit号做标签，避免重复）
                    docker build -t harbor.xxx.com/myapp:${GIT_COMMIT} .
                    # 登录镜像仓库并推送
                    docker login -u admin -p 123456 harbor.xxx.com
                    docker push harbor.xxx.com/myapp:${GIT_COMMIT}
                '''
            }
        }

        // 阶段4：部署到K8s集群
        stage('Deploy to K8s') {
            steps {
                sh '''
                    # 替换K8s yaml中的镜像版本，执行部署
                    sed -i "s#IMAGE_TAG#${GIT_COMMIT}#g" k8s-deploy.yaml
                    kubectl apply -f k8s-deploy.yaml --namespace=myapp
                '''
            }
        }

        // 阶段5：验证部署结果
        stage('Verify Deployment') {
            steps {
                sh 'kubectl rollout status deployment/myapp -n myapp' // 检查滚动状态
                sh 'kubectl get pods -n myapp' // 查看Pod是否正常运行
            }
        }
    }
    // 失败回滚
    post {
        failure {
            sh 'kubectl rollout undo deployment/myapp -n myapp' // 失败则回滚上一版本
        }
    }
}

关键说明

触发方式：可配置"代码提交（Git WebHook）"或"定时触发"启动流水线。
版本控制：用Git commit号作为镜像标签，确保每个版本可追溯，避免镜像覆盖。
回滚机制：部署失败时，通过 kubectl rollout undo 回滚到上一个正常版本。

11.容器化改造过程中， Dockerfile 怎么设计的？

容器化改造中，Dockerfile设计核心是"精简、高效、稳定"，同时需提前规避易导致部署失败的坑，以下是实操设计方案：

一、Dockerfile核心设计原则（避坑+优化）

1. 基础镜像选型：轻量优先

优先用Alpine（如 openjdk:8-jre-alpine ，仅50MB）或Slim镜像，避免臃肿的Full镜像（如 centos ，超200MB），减少构建失败和漏洞风险。
2. 分层构建：分离依赖与代码

依赖（如Maven包、npm依赖）单独分层，利用Docker缓存，避免代码修改后重复下载依赖，加速构建。

示例（Spring Boot）：

复制代码

# 构建层：编译打包
FROM maven:3.8.5-openjdk-8 AS builder
WORKDIR /app
COPY pom.xml .
# 先下载依赖（缓存层）
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -Dmaven.test.skip=true# 运行层：仅保留运行时所需
FROM openjdk:8-jre-alpine
WORKDIR /app
# 从构建层复制jar包
COPY --from=builder /app/target/*.jar app.jar
# 非root用户运行（安全）
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
# 健康检查（避免启动失败未察觉）
HEALTHCHECK --interval=30s --timeout=3s CMD wget -q -O /dev/null http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java","-jar","/app/app.jar"]

3. 规避常见失败点

不要用 latest 标签：固定版本（如 openjdk:8-jre-alpine 而非 openjdk:latest ），避免镜像更新导致兼容性问题。
清理构建残留：如 RUN mvn package && rm -rf ~/.m2 ，减少镜像体积，避免冗余文件引发冲突。
明确工作目录：用 WORKDIR 替代 cd ，避免目录混乱导致文件找不到。

二、不同项目的Dockerfile示例（直接复用）

1. 前端Vue项目

复制代码

# 构建层
FROM node:16-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# 运行层（Nginx）
FROM nginx:1.21-alpine
# 替换Nginx配置（解决跨域、路由问题）
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
HEALTHCHECK --interval=30s --timeout=3s CMD wget -q -O /dev/null http://localhost || exit 1

2. 后端Node.js项目

复制代码

FROM node:16-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --production # 只装生产依赖
COPY . .
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s CMD curl -fs http://localhost:3000/health || exit 1
USER node
ENTRYPOINT ["node","app.js"]

三、失败后的快速排查技巧

构建失败：用 docker build --progress=plain . 查看详细构建日志，定位哪一步报错（如依赖下载失败、命令不存在）。
运行失败：用 docker logs 容器ID 查看日志，结合 HEALTHCHECK 结果，判断是端口占用、配置错误还是依赖缺失。

12.比方说在 A 服务器上构建了一个那个镜像，就 A 服务器上是可以运行的，但 B 服务器上不能运行的话，这个问题要你去排查的话，一般是怎么去排查？从哪些角度去排查？

A服务器镜像可运行、B服务器不可运行，核心排查思路是 "从'镜像本身→运行环境→容器配置→底层依赖'逐层对比差异" ，具体角度和步骤如下：

1. 先排查镜像一致性（最易忽略）

确认B服务器拉取的镜像版本/标签完全一致 （避免拉到旧镜像或 latest 标签匹配错误），执行 docker images | grep 镜像名对比A、B的镜像ID。
若镜像ID不一致，重新从A服务器推送镜像（ docker save 镜像名 > 镜像.tar 拷贝到B，再 docker load -i 镜像.tar ），排除镜像传输/拉取损坏。

2. 检查B服务器Docker环境差异
- Docker版本兼容： A、B的Docker版本是否差距过大（如A是24.x，B是18.x），部分镜像特性（如多阶段构建产物）低版本不支持，执行 docker -v 对比。
- Docker配置限制： B服务器是否开启了SELinux/AppArmor（会限制容器权限），或 daemon.json 配置了镜像加速器、存储驱动（如A用 overlay2 ，B用 devicemapper ）不兼容，执行 docker info 查看存储驱动。
- 资源不足： B服务器内存/CPU不足导致容器启动失败，执行 free -m 、 top 检查资源，用 docker run -m 1G 镜像名限制资源测试。

3. 对比容器运行命令与配置

确认A、B的 docker run 命令完全一致 ：端口映射（ -p ）、挂载目录（ -v ）、环境变量（ -e ）、网络模式（ --net ）是否相同，避免B漏挂配置文件或端口冲突。
检查挂载目录权限：若B服务器挂载的宿主机目录不存在或权限不足（如A是 /data ，B是 /tmp/data 且无读写权限），执行 ls -ld 挂载目录对比权限，用 chmod 755 目录调整。

4. 查看容器日志与底层依赖

直接看容器启动日志：B服务器执行 docker run --rm 镜像名（不加 -d ）前台运行，或 docker logs 容器ID （失败容器），定位报错（如"文件不存在""端口被占用""依赖库缺失"）。
底层库依赖：若镜像基于Alpine，B服务器可能缺少系统库（如 libc6-compat ），可进入容器（ docker exec -it 容器ID sh ）执行 ldd 应用程序，对比A容器的依赖库是否存在。
内核差异：A、B服务器内核版本差距过大（如A是5.x，B是3.x），可能导致容器网络或系统调用失败，执行 uname -r 对比。

5. 快速验证：最小化测试

在B服务器用 docker run --rm 镜像名基础命令（如 java -version 、 node -v ），验证基础运行环境是否正常，排除应用本身的配置问题。

13.那比方说一个那个 docker 里面，比如说我在那个 X86 构建的一个镜像，我在那个 ARM 上能用吗？

不能直接使用，核心原因是 CPU架构不兼容 （X86是复杂指令集，ARM是精简指令集，二者二进制程序无法互通）。

关键说明
1. 直接运行的结果： 在ARM服务器上启动X86镜像，会报"exec format error"错误，容器启动失败。
2. 解决方案：

方案1：分架构构建镜像，为X86和ARM分别构建对应镜像（如用 docker build --platform linux/amd64 构建X86镜像， --platform linux/arm64 构建ARM镜像）。
方案2：构建多架构镜像，用Docker Buildx或GitHub Actions生成同时支持X86和ARM的镜像，推送到仓库后，不同架构服务器会自动拉取适配版本。

14.在一台机器上要去构建一个那个通用版本的镜像，应该怎么构建呢？

在一台机器上构建通用（多架构，如X86+ARM）镜像，核心是用 Docker Buildx（Docker内置的多架构构建工具），通过"模拟不同架构环境"生成适配多平台的镜像，步骤如下：

一、前置准备（开启Buildx功能）

确保Docker版本≥19.03（支持Buildx），执行 docker -v 验证。
启用Buildx并创建构建器（支持跨架构模拟）：

bash 复制代码

# 启用Buildx（临时，重启Docker失效）
export DOCKER_CLI_EXPERIMENTAL=enabled
# 创建并使用多架构构建器
docker buildx create --use --name multi-arch-builder
# 启动构建器（依赖qemu模拟不同架构）
docker buildx inspect --bootstrap

二、构建多架构镜像（以Spring Boot为例）

编写Dockerfile（和单架构一致，无需修改）

FROM openjdk:8-jre-alpine
WORKDIR /app
COPY target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/app.jar"]
执行多架构构建并推送到镜像仓库

格式：docker buildx build --platform 架构列表 -t 镜像仓库/镜像名:标签 --push .

docker buildx build
--platform linux/amd64,linux/arm64 \ # 适配X86（amd64）和ARM（arm64）
-t harbor.xxx.com/myapp:v1.0 \ # 镜像名（需推送到仓库，本地无法存储多架构镜像）
--push . # 直接推送到仓库（本地不保留，需拉取使用）

三、关键说明

本地无法直接运行多架构镜像：多架构镜像推送至仓库后，X86/ARM服务器拉取时，会自动匹配对应架构的镜像层，无需手动选择。
模拟依赖qemu：Buildx通过qemu模拟非本机架构，构建时会自动下载依赖，无需额外配置。
支持更多架构：可添加 linux/arm/v7 （32位ARM）、 linux/ppc64le 等，按需扩展。

15.这没有公网的那个机房中要构建一个镜像的话，应该怎么操作？

无公网机房构建镜像，核心是先在联网机器备好基础镜像、依赖包等资源，传输到内网后再构建，小团队可单台离线构建，大团队建议搭内网镜像仓库统一管理，具体操作如下：

1. 单台/小规模内网机器（快速落地）
1. 联网机预准备资源： 先拉取所需基础镜像（如 docker pull openjdk:8-jre-alpine ），用 docker save -o base-image.tar 镜像名:版本导出为tar包；若有软件依赖（如Python包、deb包），也提前下载，比如用 pip download -r requirements.txt -d pip-packages 下载Python依赖并打包。
2. 传输资源到内网机房： 通过U盘、内网传输工具，将基础镜像tar包、依赖包压缩包、项目代码和Dockerfile，拷贝到无公网的B服务器。
3. 内网加载资源并构建： 执行 docker load -i base-image.tar 加载基础镜像，解压依赖包；修改Dockerfile，用本地基础镜像并指定离线依赖安装（如 pip install --no-index --find-links /tmp/pip-packages -r requirements.txt ），最后运行 docker build -t 目标镜像名:版本 . 完成构建。
**2. 多台内网机器（搭建内网镜像仓库，高效复用）

内网搭私有镜像仓库：** 选一台内网服务器，执行 docker run -d -p 5000:5000 --restart=always --name registry registry:2 ，启动简单的Docker私有仓库，暴露5000端口。
2. 同步基础镜像到内网仓库： 按第一步的方法，把联网机准备好的基础镜像、预制依赖的镜像传到这台仓库服务器，加载后用 docker tag 镜像名:版本仓库服务器IP:5000/镜像名:版本打标签，再 docker push 仓库服务器IP:5000/镜像名:版本推到内网仓库。
**3. 内网机器统一拉取构建：**机房其他机器的Dockerfile，直接用内网仓库的镜像（如 FROM 仓库服务器IP:5000/openjdk:8-jre-alpine ），执行 docker build 即可，无需重复拷贝镜像，后续镜像更新也只需推到内网仓库。

16.我 init 的那个损坏了，服务器起不来了。然后现在要去处理它，应该怎么处理它？

若 .run/init 文件缺失导致容器/服务起不来，核心是 "补全缺失文件"或"重建环境"，具体处理分两种场景：
场景1：Docker容器内的 init 文件缺失（容器启动失败）
1. 尝试从镜像重新复制文件： 若镜像本身完整（A服务器可运行），在B服务器重新加载镜像后，用 docker run --rm 镜像名 cp /path/to/.run/init /tmp/ 从镜像复制 init 文件到宿主机，再通过 docker run -v /tmp/init:/目标路径/.run/init 镜像名挂载进去启动。
2. 重建容器： 若复制失败，直接删除损坏容器（ docker rm 容器ID ），用原Dockerfile重新构建镜像（确保构建时 init 文件被正确复制），再启动新容器。
场景2：服务器系统的 init 文件缺失（服务器无法启动）
1. 紧急修复模式补文件：

用服务器安装介质（如CentOS镜像）启动，进入"救援模式"（Rescue Mode）。
挂载系统分区（如 mount /dev/sda1 /mnt ），从同版本正常服务器拷贝 /sbin/init （或对应路径的 init 文件）到 /mnt/sbin/ 。
修复权限（ chmod 755 /mnt/sbin/init ），重启服务器。
**2. 重装系统：**若文件无法补全或系统损坏严重，备份数据后重装系统，再重新部署Docker和应用。

17.就是系统的这个 run init 卡住了，黑屏了，然后怎么解决？

系统级 .run/init 缺失导致黑屏卡住，核心是进入救援模式补回 init 文件，步骤清晰可落地：
一、准备工作

找与服务器系统同版本的安装介质（如CentOS、Ubuntu镜像U盘/光盘）。
把故障服务器设为从安装介质启动（BIOS中调整启动顺序）。

**二、救援模式补文件步骤

进入救援模式**

启动后选 "Rescue a CentOS system"（CentOS示例，Ubuntu类似选"Rescue Mode"）。
按提示选语言、键盘，网络可跳过，最后选 "Continue" 进入救援环境（系统分区会挂载到 /mnt/sysimage ）。
执行 chroot /mnt/sysimage 切换到故障系统的根目录。
**2. 补回缺失的 init 文件
方案1：从同版本正常服务器拷贝**

用U盘把正常服务器的 /path/to/.run/init 文件拷到故障机，挂载U盘后执行：

cp /mnt/usb/.run/init /path/to/.run/ （替换实际路径）。
- 方案2：从安装介质提取

若没有正常服务器，挂载安装介质的系统镜像，从镜像中提取 init 文件并复制到对应路径。
3. 修复权限+验证

执行 chmod 755 /path/to/.run/init （确保执行权限）。
退出救援模式： exit → reboot ，拔掉安装介质，重启服务器。

三、兜底方案

若补文件失败（如系统分区损坏），先通过救援模式挂载磁盘，备份 /home 、 /data 等数据，然后重装系统，再恢复数据、部署应用。

18.这台机器，然后我想限制那个在单位时间内的那个最大带宽。比如说我带宽是 70 兆，比如说在早上 8 点到晚上 10 点之间，然后我下载上传最多只允许用 50 兆。要实现这个东西的话应该怎么实现？

若服务器是Linux系统，推荐用 wondershaper 简化带宽限制配置，搭配 crontab 实现早8点到晚10点的定时限速，非时段自动解除限制，操作简单易落地，具体步骤如下：

1. 安装wondershaper： 它是Linux原生 tc 工具的封装，能快速设置网卡上下行带宽。Ubuntu/Debian系统执行 sudo apt install wondershaper -y ，CentOS系统执行 sudo dnf install wondershaper -y 。
2. 确认网卡名称： 执行 ip link show 查看需限速的网卡（如 eth0 、 ens33 等，记为目标网卡名）。
3. 写限速和解除限速脚本

新建限速脚本，执行 sudo nano /usr/local/bin/start_limit.sh ，写入内容（把 eth0 换成目标网卡，50M带宽对应50mbit）：

bash 复制代码

#!/bin/bash
sudo wondershaper 目标网卡名 50mbit 50mbit

新建解除脚本，执行 sudo nano /usr/local/bin/stop_limit.sh ，写入内容：

bash 复制代码

#!/bin/bash
sudo wondershaper clear 目标网卡名

- 赋予脚本执行权限： sudo chmod +x /usr/local/bin/start_limit.sh /usr/local/bin/stop_limit.sh 。
4. 用crontab设置定时任务

执行 sudo crontab -e 打开定时任务编辑，添加两行配置实现定时触发，配置如下：

bash 复制代码

0 8 * * * /usr/local/bin/start_limit.sh  # 每天早8点执行限速
0 22 * * * /usr/local/bin/stop_limit.sh # 每天晚10点解除限速

**5. 验证效果：**执行 sudo wondershaper 目标网卡名可查看当前限速配置；也能用 iftop 或 nload 工具实时监控带宽，确认时段内速率是否被限制在50兆左右。

19.现在异地备份。我一个在北京，一个在杭州。然后北京这边有自建机房，杭州那边也有自建机房。然后我现在需要把北京这边的机房里面的一些数据，然后拷到杭州那边去。用 VPN 去访问嘛，然后 VPN 这边他们的 VPN 是不通的。要解决这个问题的话，怎么高效的去进行打通呢？

VPN不通时，要高效打通北京和杭州自建机房的异地数据备份通道，可按"优先修复VPN（低成本）→ 备选替代方案（快速落地）→ 专业专线（长期稳定） "的思路选择，具体方案如下：

1. 修复现有VPN（优先尝试，成本最低）： 先排查VPN不通的核心问题，多数情况是配置或链路问题。第一步核对两端防火墙/路由器的IKE和IPsec策略，确保加密算法、预共享密钥一致，比如一端用AES - 128加密，另一端不能用其他算法；第二步检查ACL规则，要允许北京、杭州机房的内网网段互通；第三步用 ping 或 mtr 命令测试两端公网IP连通性，若丢包严重可联系运营商优化链路，同时确认证书是否过期、连接数是否超限，这些都是VPN不通的常见诱因。
2. 部署开源VPN替代（快速落地，适配自建机房）： 若原有VPN修复麻烦，可换OpenVPN或WireGuard这类开源方案快速组网。WireGuard配置更简单、性能更好，适合数据传输，两端机房各部署一台服务器当网关，配置好两端内网网段和公网IP，建立加密隧道后，数据传输就和原VPN效果一致，而且可自主运维，适配自建机房的灵活需求。
3. SD - WAN智能组网（适配高频备份，兼顾稳定与灵活）： 适合需要长期稳定传输备份数据的场景。它能整合两地机房的多条宽带链路，智能选择低延迟、低丢包的路径，还内置加密隧道。中小型机房可选蒲公英SD - WAN这类轻量化产品，大型机房可用华为、深信服的企业级设备，部署后不仅能满足数据备份，后续扩展分支也很方便，运维起来比传统VPN更省心。
4. MPLS专线（高稳定高安全，适合核心数据备份）： 若备份的数据是核心业务数据，对稳定性和安全性要求极高，可找电信、联通等运营商办理MPLS专线。它通过运营商骨干网构建逻辑隔离的专网，不走公网，延迟和丢包率都有保障，不过缺点是开通周期长（通常几周）、成本较高，适合预算充足的长期核心数据备份需求。
**5. 云中转临时过渡（应急传输，避免业务中断）：**若需紧急传输备份数据，可先用云服务器中转。在北京和杭州机房分别与同一云平台（如阿里云、腾讯云）建立VPN连接，把北京机房数据先传到云服务器，再由杭州机房从云服务器拉取。这种方式部署快，还能通过云防火墙控制访问权限，适合临时解决数据备份问题，等专线或VPN修复后再切换回来。

20.我加的前提条件，如果说这两家公司不是一家公司，但是需要做到数据同步，那他们的 VPN 天然肯定就就不是一样嘛。

两家不同公司VPN不同且需数据同步，核心思路是统一接入标准或绕开原有异构VPN，优先选低成本易落地的方案，兼顾安全与合规，具体可按以下方式实现：

1. 共建统一VPN隧道（适配长期高频同步）

这是直接打通的核心方案，不用改动双方原有内网，仅需对接网关层。一是选通用协议组网，双方各部署一台独立VPN网关，统一用OpenVPN或WireGuard这类开源且兼容性强的协议，避免因企业原有VPN协议差异导致的不兼容，配置好两端公网IP和需同步的内网网段，建立加密隧道；二是解决路由与地址冲突，若双方内网IP重叠，在网关配置NAT，把各自内网地址映射为不同的公网段；若用MPLS架构的企业VPN，可通过共享VPN Target（RT）配置，让双方路由相互导入，实现互通。
2. 借助第三方中转同步（适配合规要求高的场景）

不用搭建跨公司VPN，通过中间载体中转数据，减少双方网络直接暴露的风险。一方面可选跨网文件交换系统，比如FileLink、DataLink Secure这类工具，支持端到端加密、传输审批和全程审计，适合金融、医疗等对合规性要求高的行业，双方仅需通过系统上传/下载待同步数据，无需调整自身VPN；另一方面可用云存储中转，双方将需同步的数据上传到约定的云存储桶（如阿里云OSS、腾讯云COS），设置桶的访问权限（仅双方指定账号可访问），开启版本控制和同步规则，实现自动化数据同步，云平台的安全机制还能保障数据传输安全。
3. SD-WAN轻量化对接（适配多分支/复杂网络）

适合两家公司均有多个分支机构、原有VPN架构复杂的情况。双方各部署一台SD-WAN网关，接入SD-WAN平台，网关会自动适配双方原有VPN协议和网络环境，通过运营商骨干网构建智能加密通道。它能自主选择低延迟路径，还支持流量监控和权限管控，既不用重构双方原有网络，又能稳定实现数据同步，后续扩展其他合作分支也很方便。

21.k8s有哪些常用常用命令

K8s 常规命令核心围绕「集群、命名空间、Pod、Deployment、服务」展开，整理了高频实用命令，清晰好记：

一、集群与命名空间操作

kubectl cluster-info ：查看集群状态（是否正常运行）
kubectl get namespaces / kubectl get ns ：列出所有命名空间
kubectl create namespace 命名空间名：创建命名空间
kubectl config set-context --current --namespace=命名空间名：切换默认命名空间

二、Pod 核心操作（最常用）

kubectl get pods / kubectl get po ：列出当前命名空间的 Pod
kubectl get pods -n 命名空间名：查看指定命名空间的 Pod
kubectl get pods -o wide ：查看 Pod 详细信息（含节点、IP）
kubectl describe pod Pod名称：查看 Pod 详细日志（排障用）
kubectl logs Pod名称：查看 Pod 日志
kubectl logs -f Pod名称：实时跟踪 Pod 日志（类似 tail -f）
kubectl exec -it Pod名称 -- /bin/bash ：进入 Pod 容器（交互式终端）
kubectl delete pod Pod名称：删除 Pod

三、Deployment 操作（部署应用）

kubectl get deployments / kubectl get deploy ：列出 Deployment
kubectl create deployment 应用名 --image=镜像名：快速创建 Deployment（如 kubectl create deployment nginx --image=nginx ）
kubectl describe deploy 应用名：查看 Deployment 详情
kubectl scale deploy 应用名 --replicas=副本数：扩缩容（如 --replicas=3 启动3个副本）
kubectl set image deploy 应用名容器名=新镜像名：更新应用镜像
kubectl delete deploy 应用名：删除 Deployment

四、Service 操作（暴露应用访问）

kubectl get services / kubectl get svc ：列出所有服务
kubectl expose deploy 应用名 --port=端口 --type=服务类型：暴露 Deployment 为服务（如 --type=NodePort 对外暴露端口）
kubectl describe svc 服务名：查看服务详情
kubectl delete svc 服务名：删除服务

五、常用辅助命令

kubectl apply -f yaml文件名.yaml ：通过 YAML 文件创建/更新资源（生产常用）
kubectl delete -f yaml文件名.yaml ：通过 YAML 文件删除资源
kubectl get all ：列出当前命名空间所有资源（Pod、Deploy、Svc 等）
kubectl rollout undo deploy 应用名：回滚 Deployment 到上一版本

22.咱们比方说我们要收集到一个机器上所有用户的那个命令，一般怎么收集啊？

收集机器上所有用户的操作命令，核心是监控用户的Shell输入，推荐3种实用方案，覆盖临时排查、长期监控和审计合规场景：

一、临时收集：利用Shell历史记录（快速查看，无需额外部署）

查看单用户历史命令：每个用户的命令默认存在 ~/.bash_history （bash Shell），执行 cat /home/用户名/.bash_history 查看指定用户，或切换到该用户后直接输 history 。
查看所有用户历史：遍历所有用户目录，执行 for user in $(cut -d: -f1 /etc/passwd); do echo "=== 用户$ user 的命令 ==="; cat /home/$user/.bash_history 2>/dev/null; done 。
注意：默认仅记录退出Shell后的命令，实时输入未记录，且用户可手动删除该文件，适合临时排查。

二、长期监控：配置Shell全局日志（实时记录，不可篡改）

通过修改Shell配置，让所有用户的命令实时写入系统日志文件，步骤如下：
**1. 编辑全局Shell配置：**执行 sudo nano /etc/profile ，添加以下内容：

bash 复制代码

# 记录命令到 /var/log/all_commands.log，包含用户、时间、终端、命令
export HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S "
export PROMPT_COMMAND='{ echo -e "$(whoami) | $(hostname) | $(date +"%Y-%m-%d %H:%M:%S") | $(pwd) | $(history 1 | sed "s/^[ ]*[0-9]*[ ]*//g")"; } >> /var/log/all_commands.log'

2. 创建日志文件并授权：

bash 复制代码

sudo touch /var/log/all_commands.log
sudo chmod 600 /var/log/all_commands.log  # 仅root可读写，防止篡改

3. 生效配置： 执行 source /etc/profile ，或让用户重新登录Shell，之后所有用户的命令会实时写入日志。

三、审计合规：用auditd系统审计（权威可追溯，适合生产）

Linux自带的auditd服务可审计系统调用，包括命令执行，适合需要合规留痕的场景：

1. 安装并启动auditd： Ubuntu执行 sudo apt install auditd -y ，CentOS执行 sudo dnf install auditd -y ，启动： sudo systemctl start auditd && sudo systemctl enable auditd 。
**2. 添加审计规则：**监控所有用户执行命令的行为（记录bash/zsh调用）：

bash 复制代码

# 监控bash命令执行
sudo auditctl -a exit,always -F arch=b64 -F euid!=0 -F exe=/bin/bash -k user_commands
# 监控zsh命令执行（若用户用zsh）
sudo auditctl -a exit,always -F arch=b64 -F euid!=0 -F exe=/usr/bin/zsh -k user_commands

3. 查询审计日志： 执行 sudo ausearch -k user_commands 查看所有用户的命令记录，包含用户ID、时间、命令内容。

11月份运维面试题

1.信XX大公司

1.你们平时用zabbix都监控什么指标？

2.数据量很大，但是网络带宽是有限的。咱们现在如果要备份的话，怎么执行这种策略？

3.如果是部署一个 MySQL 集群，主从啊，或者是双主啊，就说它如果是主节点挂了之后，它如何让业务感觉不到那个波动，能平滑的切到另外一个节点上。

4.我现在要进入容器去改一些文件，比如怎么进容器啊？

5.做过安全加固吗？比如说有安全部门的扫出来什么服务器漏洞啊，或者是怎么着，需要去去修啊什么的。

6.就咱们平常一般巡检的话，比如说咱们有几台机器要巡检，要防止未来出故障，主要巡检哪些内容？

7.你说的这些都是用工具还是直接进行脚本？

8.那你平时是怎么部署 K8S 的？你能给我简单说一下吗？

9.你这个CI/CD 这块是怎么做的呀？

10.那个咱们，你刚刚不是说你从 Jenkins 到那个 K8S 去实现了自动部署吗？对吧？咱们这个流水线阶段是怎么去做的？

11.容器化改造过程中， Dockerfile 怎么设计的？

12.比方说在 A 服务器上构建了一个那个镜像，就 A 服务器上是可以运行的，但 B 服务器上不能运行的话，这个问题要你去排查的话，一般是怎么去排查？从哪些角度去排查？

13.那比方说一个那个 docker 里面，比如说我在那个 X86 构建的一个镜像，我在那个 ARM 上能用吗？

14.在一台机器上要去构建一个那个通用版本的镜像，应该怎么构建呢？

格式：docker buildx build --platform 架构列表 -t 镜像仓库/镜像名:标签 --push .

15.这没有公网的那个机房中要构建一个镜像的话，应该怎么操作？

16.我 init 的那个损坏了，服务器起不来了。然后现在要去处理它，应该怎么处理它？

17.就是系统的这个 run init 卡住了，黑屏了，然后怎么解决？

18.这台机器，然后我想限制那个在单位时间内的那个最大带宽。比如说我带宽是 70 兆，比如说在早上 8 点到晚上 10 点之间，然后我下载上传最多只允许用 50 兆。要实现这个东西的话应该怎么实现？

20.我加的前提条件，如果说这两家公司不是一家公司，但是需要做到数据同步，那他们的 VPN 天然肯定就就不是一样嘛。

21.k8s有哪些常用常用命令

22.咱们比方说我们要收集到一个机器上所有用户的那个命令，一般怎么收集啊？