运维工程师面试题 ----- 系统网络类_运维工程师 面试题 网络篇(1)

为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！

这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。

本份面试集锦涵盖了

• 174 道运维工程师面试题
• 128道k8s面试题
• 108道shell脚本面试题
• 200道Linux面试题
• 51道docker面试题
• 35道Jenkis面试题
• 78道MongoDB面试题
• 17道ansible面试题
• 60道dubbo面试题
• 53道kafka面试
• 18道mysql面试题
• 40道nginx面试题
• 77道redis面试题
• 28道zookeeper

总计 1000+ 道面试题， 内容 又全含金量又高

• 174道运维工程师面试题

1、什么是运维?

2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?

3、现在给你三百台服务器，你怎么对他们进行管理?

4、简述raid0 raid1raid5二种工作模式的工作原理及特点

5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?

6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?

7、Tomcat和Resin有什么区别，工作中你怎么选择?

8、什么是中间件?什么是jdk?

9、讲述一下Tomcat8005、8009、8080三个端口的含义？

10、什么叫CDN?

11、什么叫网站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

22、判断一个文件是否为字符设备，如果是将其拷贝至/etc

23、在A目录下创建50个文件file1-file50，然后将其移至/path/B

24、LINUX系统软件安装和卸载的常见方法

25、Windows和LINUX常用的远程连接工具有那些

26、如何修改LINUX的IP地址、网关和主机名

27、编写脚本实现以下功能；
每天早上5点开始做备份
要备份的是/var/mylog里所有文件和目录可以压缩进行备份
备份可以保存到别一台器上192、168、1、2 FTP帐号 aaa 密码 bbb
要示每天的备份文件要带有当天的日期标记

28、1000台服务器需要放一个2G的单个文件，请设计几种放置方法，并且描述各种方法利弊 （涉及到一个对单播多播组播概念的描述，如果明白，为较好的一种方法）

29、双网卡服务器，对网络做高可用，画一个简图

30、如何将本地80端口的请求转发到8080端口，当前主机IP为192.168.2.1 ？

31、Shell循环语句有哪些？

32、通过Apache访问日志access.log 统计IP和每个地址访问的次数，按从大到小前10名？

33、编写shell脚本，获取本机的网络地址。比如IP地址是192.168.100.2/255.255.255.0，那么它的网络地址是192.168.100.1/255.255.255.0

34、写一个脚本查找最后创建时间是3天前，后缀是*.log的文件并删除。

35、写一个脚本将数据库备份并打包至远程服务器192.168.1.1 /backup目录下

36、如何重置mysqlroot密码?

37、如何让history命令显示具体时间？

38、如何查看占用端口8080 的进程

39、LVS四层负载均衡与Nginx七层负载均衡原理

40、keepalived高可用原理

Git 和 Svn 的区别

Git 是分布式的，而 Svn 不是分布的;

Git 把内容按元数据方式存储，而 SVN 是按文件;

Git 没有一个全局版本号，而 SVN 有：目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征;

Git 的内容的完整性要优于 SVN: GIT 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏;

Git 下载下来后，在 OffLine 状态下可以看到所有的 Log,SVN 不可以; SVN 必须先 Update 才能 Commit,忘记了合并时就会出现一些错误，git 还是比较少的出现这种情况。

克隆一份全新的目录以同样拥有五个分支来说，SVN 是同时复製 5 个版本的文件,也就是说重复五次同样的动作。而 Git 只是获取文件的每个版本的 元素，然后只载入主要的分支(master)在我的经验,克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约 1500 个文件的 SVN,耗了将近一个小时！而 Git 只用了区区的 1 分钟！

版本库（repository):SVN 只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git 可以有无限个版本库。或者，更正确的说法，每一个 Git 都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於 GitHub 的版本库）发生了什麼事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

分支（Branch）在 SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。

Git 的分支名是可以使用不同名字的。例如：我的本地分支名为 OK，而在主要版本库的名字其实是 master。

提交（Commit）在 SVN，当你提交你的完成品时，它将直接记录到中央版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而 Git 的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git 的“推”其实是在执行“同步”（Sync）。

总结：SVN 的特点是简单，只是需要一个放代码的地方时用是 OK 的。

Git 的特点版本控制可以不依赖网络做任何事情，对分支和合并有更好的支持(当然这是开发者最关心的地方)，不过想各位能更好使用它，需要花点时间尝试一下。

mysql 主从原理？主从不同步怎么办？主从慢，差的多咋办？

master 将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）slave 将 master 的 binary log events 拷贝到它的中继日志 (relay log) slave 重做中继日志中的事件，将改变反映它自己的数据。或从库生成两个线程，一个 I/O 线程，一个 SQL 线程；

i/o 线程去请求主库 的 binlog，并将得到的 binlog 日志写到 relay log（中继日志） 文件中；

主库会生成一个 log dump 线程，用来给从库 i/o 线程传 binlog；

SQL 线程，会读取 relay log 文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

先上 Master 库：

mysql>show processlist;查看下进程是否 Sleep 太多。发现很正常。

show master status;也正常。

mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +-------------------+----------+--------------+-------------------------------+ | mysqld-bin.000001 | 3260 | | mysql,test,information_schema | +-------------------+----------+--------------+-------------------------------+ 1 row in set (0.00 sec) 再到 Slave 上查看

mysql> show slave status\G
Slave_IO_Running: Yes Slave_SQL_Running: No 可见是 Slave 不同步

下面介绍两种解决方法：

方法一：忽略错误后，继续同步 该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况 解决：

stop slave; #表示跳过一步错误，后面的数字可变 set global sql_slave_skip_counter =1; start slave; 之后再用mysql> show slave status\G查看：

Slave_IO_Running: Yes Slave_SQL_Running: Yes ok，现在主从同步状态正常了。。。

方式二：重新做主从，完全同步 该方法适用于主从库数据相差较大，或者要求数据完全统一的情况 解决步骤如下：

先进入主库，进行锁表，防止数据写入 使用命令：mysql> flush tables with read lock; 注意：该处是锁定为只读状态，语句不区分大小写

进行数据备份 #把数据备份到 mysql.bak.sql 文件 [root@server01 mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql 这里注意一点：数据库备份一定要定期进行，可以用 shell 脚本或者 python 脚本，都比较方便，确保数据万无一失

查看 master 状态 mysql> show master status; ±------------------±---------±-------------±------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | ±------------------±---------±-------------±------------------------------+ | mysqld-bin.000001 | 3260 | | mysql,test,information_schema | ±------------------±---------±-------------±------------------------------+ 1 row in set (0.00 sec) 把 mysql 备份文件传到从库机器，进行数据恢复 #使用 scp 命令 [root@server01 mysql]# scp mysql.bak.sql root@192.168.128.101:/tmp/ 停止从库的状态 mysql> stop slave; 然后到从库执行 mysql 命令，导入数据备份 mysql> source /tmp/mysql.bak.sql 设置从库同步，注意该处的同步点，就是主库 show master status 信息里的 | File | Position 两项 change master to master_host = ‘192.168.128.100’, master_user = ‘rsync’, master_port=3306, master_password=’’, master_log_file = ‘mysqld-bin.000001’, master_log_pos=3260; 重新开启从同步 mysql> start slave; 查看同步状态 mysql> show slave status\G查看：

Slave_IO_Running: Yes Slave_SQL_Running: Yes 好了，同步完成啦。

如果延迟比较大，就先确认以下几个因素：

从库硬件比主库差，导致复制延迟; 主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟。更高版本的 mysql 可以支持多线程复制 慢 SQL 语句过多 网络延迟 master 负载：主库读写压力大，导致复制延迟，架构的前端要加 buffer 及缓存层 slave 负载 一般的做法是，使用多台 slave 来分摊读请求，再从这些 slave 中取一台专用的服务器，只作为备份用，不进行其他任何操作。另外，2 个可以减少延迟的参数:

–slave-net-timeout=seconds 单位为秒，默认设置为 3600 秒

#参数含义：当 slave 从主数据库读取 log 数据失败后，等待多久重新建立连接并获取数据

– master-connect-retry=seconds?单位为秒?默认设置为 60 秒 #参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。通常配置以上 2 个参数可以减少网络问题导致的主从数据同步延迟 MySQL 数据库主从同步延迟解决方案;

最简单的减少 slave 同步延时的方案就是在架构上做优化，尽量让主库的 DDL 快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1之类的设置，而 slave 则不需要这么高的数据安全，完全可以讲sync_binlog设置为 0 或者关闭 binlog，innodb_flushlog也可以设置为 0 来提高 sql 的执行效率。另外就是使用比主库更好的硬件设备作为 slave。

kafka 和 mq 的区别

作为消息队列来说，企业中选择 mq 的还是多数，因为像 Rabbit，Rocket 等 mq 中间件都属于很成熟的产品，性能一般但可靠性较强，而 kafka 原本设计的初衷是日志统计分析，现在基于大数据的背景下也可以做运营数据的分析统计，而 redis 的主要场景是内存数据库，作为消息队列来说可靠性太差，而且速度太依赖网络 IO，在服务器本机上的速度较快，且容易出现数据堆积的问题，在比较轻量的场合下能够适用。

RabbitMQ,遵循 AMQP 协议，由内在高并发的 erlanng 语言开发，用在实时的对可靠性要求比较高的消息传递上。

kafka 是 Linkedin 于 2010 年 12 月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

k8s service 类型？

ClusterIP 集群内部容器访问地址，会生成一个虚拟 IP 与 pod 不在一个网段。

NodePort 会在宿主机上映射一个端口，供外部应用访问模式。

Headless CluserIP 无头模式，无 serviceip，即把 spec.clusterip 设置为 None 。

LoadBalancer 使用外部负载均衡。

k8s 健康检查方式

存活性探针（liveness probes）和就绪性探针（readiness probes） 用户通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。语法是一样的。

k8s pod 状态

Pod --Pending 状态

Pending 说明 Pod 还没有调度到某个 Node 上面。可以通过 kubectl describe pod命令查看到当前 Pod 的事件，进而判断为什么没有调度。可能的原因包括

资源不足，集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、GPU 等资源。

HostPort 已被占用，通常推荐使用 Service 对外开放服务端口

Pod --Waiting 或 ContainerCreating 状态

首先还是通过 kubectl describe pod 命令查看到当前 Pod 的事件。可能的原因包括

镜像拉取失败，比如配置了镜像错误、Kubelet 无法访问镜像、私有镜像的密钥配置错误、镜像太大，拉取超时等。

CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如无法配置 Pod 、无法分配 IP 地址

最后的话

最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！

资料预览

给大家整理的视频资料：

给大家整理的电子书资料：

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

…(img-VjWGcVAw-1715537133102)]

如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！