最近参加运维工程师岗位的面试，笔者把自己遇到的和网友分享的一些常见的面试问答收集整理出来了，希望能对自己和对正在准备面试的同学提供一些参考。

笔者回答：此处省略笔者的自我介绍，笔者建议介绍自己的时间不宜过长，3-4分钟为宜，说多了面试官会觉得你太啰嗦了。说太少了也不行，那样会让人感觉你的经历太简单了、太空了。正常情况下，一般你在做自我介绍的同时，面试官这个时候在看你的简历，他需要一边看简历、一边听你介绍自己，如果你说个几句话就把自己介绍完了，他肯定还没缓过神来，对你的映像会减分的。在介绍的同时思维要清晰，逻辑要清楚，最好是根据你简历上写的经历来介绍，这样可以把面试官的思路带到你这里来，让他思路跟着你走。不要东扯一句，西扯一句。竟量少介绍自己的性格、爱好（最好能不说就不说），你可以简单罗列干过几家公司（最多罗列3家公司/也包含目前所在的公司，注意顺序不要乱），都在那几家公司负责什么工作，都用过什么技术，在着重介绍一下你目前所在的公司是负责哪些工作的，可以稍微详细一点介绍，不要让面试官听着晕头转向的感觉。

笔者回答：其实对这个问题笔者也答的不好，就不写出来误导大家了。大家有好的方法可以共享出来。不过笔事后在知呼上看到了一位网友的建议觉得不错，大家可以参考看一下 ：https://www.zhihu.com/question/20584476

笔者回答：部署过，没有深入研究过，一般mongodb部署主从、或者mongodb分片集群；建议3台或5台服务器来部署。MongoDB分片的基本思想就是将集合切分成小块。这些块分散到若干片里面，每个片只负责总数据的一部分。  对于客户端来说，无需知道数据被拆分了，也无需知道服务端哪个分片对应哪些数据。数据在分片之前需要运行一个路由进程，进程名为mongos。这个路由器知道所有数据的存放位置，知道数据和片的对应关系。对客户端来说，它仅知道连接了一个普通的mongod，在请求数据的过程中，通过路由器上的数据和片的对应关系，路由到目标数据所在的片上，如果请求有了回应，路由器将其收集起来回送给客户端。

笔者回答：发布：jenkins配置好代码路径（SVN或GIT），然后拉代码，打tag。需要编译就编译，编译之后推送到发布服务器（jenkins里面可以调脚本），然后从分发服务器往下分发到业务服务器上。

回滚：按照版本号到发布服务器找到对应的版本推送

笔者回答：Tomcat是一个JSP/Servlet容器。其作为Servlet容器，有三种工作模式：独立的Servlet容器、进程内的Servlet容器和进程外的Servlet容器。

进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类：

Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是Apache, IIS, Nginx等；

Tomcat作为独立服务器：请求来自于web浏览器；

笔者回答：现在公司的业务都跑在阿里云上，我们首选的监控就是用阿里云监控，阿里云监控自带了ECS、RDS等服务的监控模板，可结合自定义报警规则来触发监控项。上家公司的业务是托管在IDC，用的是zabbix监控方案，zabbix图形界面丰富，也自带很多监控模板，特别是多个分区、多个网卡等自动发现并进行监控做得非常不错，不过需要在每台客户机（被监控端）安装zabbix agent。

笔者回答：在生产环境下，不管是应用数据、还是数据库数据首先在部署的时候就会有主从架构、或者集群，这本身就是属于数据的热备份；其实考虑冷备份，用专门一台服务器做为备份服务器，比如可以用rsync+inotify配合计划任务来实现数据的冷备份，如果是发版的包备份，正常情况下有台发布服务器，每次发版都会保存好发版的包。

笔者回答：reids集群原理：

其实它的原理不是三两句话能说明白的，redis 3.0版本之前是不支持集群的，官方推荐最大的节点数量为1000，至少需要3(Master)+3(Slave)才能建立集群，是无中心的分布式存储架构，可以在多个节点之间进行数据共享，解决了Redis高可用、可扩展等问题。集群可以将数据自动切分(split)到多个节点，当集群中的某一个节点故障时，redis还可以继续处理客户端的请求。

redis分片：

分片(partitioning)就是将你的数据拆分到多个 Redis 实例的过程，这样每个实例将只包含所有键的子集。当数据量大的时候,把数据分散存入多个数据库中,减少单节点的连接压力,实现海量数据存储。分片部署方式一般分为以下三种：

（1）在客户端做分片；这种方式在客户端确定要连接的redis实例，然后直接访问相应的redis实例；

（2）在代理中做分片；这种方式中，客户端并不直接访问redis实例，它也不知道自己要访问的具体是哪个redis实例，而是由代理转发请求和结果；其工作过程为：客户端先将请求发送给代理，代理通过分片算法确定要访问的是哪个redis实例，然后将请求发送给相应的redis实例，redis实例将结果返回给代理，代理最后将结果返回给客户端。

（3）在redis服务器端做分片；这种方式被称为“查询路由”，在这种方式中客户端随机选择一个redis实例发送请求，如果所请求的内容不再当前redis实例中它会负责将请求转交给正确的redis实例，也有的实现中，redis实例不会转发请求，而是将正确redis的信息发给客户端，由客户端再去向正确的redis实例发送请求。

redis用在了哪些环境：

java、php环境用到了redis，主要缓存有登录用户信息数据、设备详情数据、会员签到数据等

笔者回答：统计用户的访问IP，用awk结合uniq、sort过滤access.log日志就能统计并排序好。一般这么回答就够了，当然你还可以说出其它方式来统计，这都是你的加分项。

笔者回答：vmware vsphere及kvm，我用得比较多的是vmware vsphere虚拟化，几本上生产环境都用的vmware vsphere，kvm我是用在测试环境中使用。vmware 是属于原生架构虚拟化技术，也就是可直接在硬件上运行。kvm属于寄居架构的虚拟化技术，它是依托在系统之上运行。vmware vcenter

管理上比较方便，图形管理界面功能很强大，稳定性强，一般比较适合企业使用。KVM管理界面稍差点，需要管理人员花费点时间学习它的维护管理技术。

笔者回答：其实这种问题都没有具体答案，只是看你回答的内容与面试官契合度有多高，能不能说到他想要的点上，主要是看你排查问题的思路。我是这么说的：问清楚反应的人哪个服务应用或者页面调取哪个接口慢，叫他把页面或相关的URL发给你，首先，最直观的分析就是用浏览器按F12，看下是哪一块的内容过慢（DNS解析、网络加载、大图片、还是某个文件内容等），如果有，就对症下药去解决（图片慢就优化图片、网络慢就查看内网情况等）。其次，看后端服务的日志，其实大多数的问题看相关日志是最有效分析，最好用tail -f 跟踪一下日志，当然你也要点击测试来访问接口日志才会打出来。最后，排除sql，，找到sql去mysql执行一下，看看时间是否很久，如果很久，就要优化SQL问题了，expain一下SQL看看索引情况啥的，针对性优化。数据量太大的能分表就分表，能分库就分库。如果SQL没啥问题，那可能就是写的逻辑代码的问题了，一行行审代码，找到耗时的地方改造，优化逻辑。

笔者回答：这个问题笔者觉得回答的不太好，对mysql比较在行的朋友希望能给点建议。以解决问题为前提条件，先添加从库数量，临时把问题给解决，然后抓取slow log ，分析sql语句，该优化就优化处理。慢要不就是硬件跟不上，需要升级；要不就是软件需要调试优化，等问题解决在细化。

笔者回答：很少有面试官会问这样的问题，即然问到了，也要老实回答。还好笔者之前了解过CPU，我是这么说的：双核CPU就是能处理多份任务，顺序排成队列来处理。单核CPU一次处理一份任务，轮流处理每个程序任务。双核的优势不是频率，而是对付同时处理多件事情。单核同时只能干一件事，比如你同时在后台BT下载，前台一边看电影一边拷贝文件一边QQ。

笔者回答：我擦，啥年代了，还问磁盘的问题，这面试官有点逗啊。那也要回答啊：

HDD代表机械硬盘，SSD代表固态硬盘。首先，从性能方面来说，固态硬盘几乎完胜机械硬盘，固态硬盘的读写速度肯定要快机械硬盘，因为固态硬盘和机械硬盘的构造是完全不同的（具体的构造就没必要解释了）。其次，固态盘几乎没有噪音、而机械盘噪音比较大。还有就是，以目前的市场情况来看，一般机械盘容量大，价格低；固态盘容量小，价格偏高。但是企业还是首选固态盘。

笔者回答：这个监控的问题又问到了，笔者在2018年1月4号也被问到类似这样的问题，笔者曾经用过zabbix、nagios、 cacit等。但是在这次面试中只说用过zabbix和nagios。说完了之后，面试官就让我说一下这两个监控有啥区别：

从web功能及画图来讲：

Nagios简单直观，报警与数据都在同一页面， 红色即为问题项。Nagios web端不要做任何配置。  Nagios需要额外安装插件，且插件画图不够美观。

 Zabbix监控数据与报警是分开的，查看问题项需要看触发器，查看数据在最新数据查看。而且zabbix有很多其它配置项，  zabbix携带画图功能，且能手动把多个监控项集在一个图中展示。

从监控服务来讲：

Nagios自带的监控项很少。对一些变动的如多个分区、多个网卡进行监控时需要手动配置。

Zabbix自带了很多监控内容，感觉zabbix一开始就为你做了很多事，特别是对多个分区、多个网卡等自动发现并进行监控时，那一瞬间很惊喜，很省心的感觉。

从批量配置和报警来讲：

Nagios对于批量监控主机，需要用脚本在server端新增host，并拷贝service文件。   Nagios用脚本来修改所有主机的services文件，加入新增服务。

Zabbix在server端配置自动注册规则，配置好规则后，后续新增client端不需要对server端进行操作。  Zabbix只需手动在模板中新增一监控项即可。

总体来讲：

Nagios要花很多时间写插件，Zabbix要花很多时间探索功能。

Nagios更易上手，Nagios两天弄会，Zabbix两周弄会。

Zabbix画图功能比Nagios更强大

Zabbix对于批量监控与服务更改，操作更简洁；Nagios如果写好自动化脚本后，也很简单，问题在于写自动化脚本很费神。

笔者回答：如果这套环境是部署在云端(比如阿里云)，你就不用去考虑硬件设计的问题。可直接上阿里云的SLB+ECS+RDS这套标准的高可用、高并发的架构。对外服务直接上SLB负载均衡技术，由阿里的SLB分发到后端的ECS主机；ECS主机部署多台，应用拆分在不同的ECS主机上，尽量细分服务。数据库用RDS高可用版本（一主一备的经典高可用架构）、或者用RDS金融版（一主两备的三节点架构）。在结合阿里其它的服务就完全OK，业务量上来了，主机不够用了，直横向扩容ECS主机搞定。

如果这套环境托管在IDC，那么你就要从硬件、软件（应用服务）双面去考虑了。硬件要达到高可用、高并发公司必须买多套网络硬件设备（比如负载设备F5、防火墙、核心层交换、接入层交换）都必须要冗余，由其是在网络设计上，设备之间都必须有双线连接。设备如果都是跑的单机，其中一个设备挂了，你整个网络都瘫痪了，就谈不上高可用、高并发了。其次在是考虑应用服务了，对外服务我会采用成熟的开源方案LVS+Keepalived或者Nginx+Keepalived，缓存层可以考虑redis集群及Mongodb集群，中间件等其它服务可以用kafka、zookeeper，图片存储可以用fastDFS或MFS，如果数据量大、又非常多，那么可采用hadoop这一套方案。后端数据库可采用 “主从+MHA”。这样一套环境下来是绝对满足高可用、高并发的架构。

笔者回答：首先呢，安装nginx，然后进入nginx的配置文件，加入upstream 自定义名字{ server：www.abc.com/refuse}这样得一个节点，然后在server{}节点上加上http://自定义的名字，最后呢配置nginx限制过滤特定的接口访问，像这个样location ~/solr/.*/update{return 403;} ，这样就能返回403了。

笔者回答：iptables允许192.168.16.1ip端口为80转发到ip为8080的端口，操作如下： iptables -t nat -A PREROUTING -d 192.168.16.1 -p tcp --dport 80 -j DNAT --to 192.168.16.1:8080

笔者回答：使用top命令，查看linux的状态，top里边有一个cpu值，这个就是cpu的内存使用的情况 使用uptime中load average的查看平均负载

笔者回答：默认情况下，有两个请求头会被重新定义： proxy_set_header Host $proxy_host; //默认会将后端服务器的HOST填写进去 proxy_set_header Connection close; 然后将nginx map配置根据请求头不同分配流量到不同后端服务

笔者回答： #!/bin/bash name = ls -l | awk ‘$5 > 10240 {print $9}’ mv $name > /tmp ls -la /tmp

笔者回答：我了解的大部分的大型网站是采用docker+redi集群来实现缓存，然后通过使用nginx反向代理来确保安全性，再采用lvs+MySQL主主+keepalived来实现单点高可用和负载均衡。

笔者回答： sed -n ‘/10:00/,/12:00/p’ /var/log/nginx/access.log | awk ‘{a[$1]++} END {for(b in a) print b"\t"a[b]}’ | sort -k 2 -r | head -n 10

笔者回答： 0 6-12/2 * 11 * /usr/bin/httpd.sh

笔者回答：DFS 通过DFS，可以使分布在多个服务器上的文件在用户面前显示时，就如同位于网络上的一个位置。用户在访问文件时不再需要知道和指定它们的实际物理位置。

笔者回答： netstat -n | awk ‘/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}’ LAST_ACK 1 SYN_RECV 14 ESTABLISHED 79 FIN_WAIT1 28 FIN_WAIT2 3 CLOSING 5 TIME_WAIT 1669 状态：描述 CLOSED：无连接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另一边已同意释放 ITMED_WAIT：等待所有分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另一边已初始化一个释放 LAST_ACK：等待所有分组死掉

笔者回答：

#! /bin/bash base_path=’/usr/local/nginx/logs’ log_path=( d a t e − d y e s t e r d a y + " m i n u t e = (date -d yesterday +"%Y%m") minute=(date−dyesterday+"minute=(date -d “1 minute ago” +"%Y%m%d-%H:%M") mkdir -p b a s e p a t h / base_path/base  p ​      ath/log_path echo $base_path/access.log mv $base_path/access.log b a s e p a t h / base_path/base  p ​      ath/log_path/access_$minute.log echo b a s e p a t h / base_path/base  p ​      ath/log_path/access_$minite.log kill -USR1 cat /usr/local/nginx/logs/nginx.pid

#crontab -l

1 * * eck_nginx_log.sh

笔者回答：

Raid 0:   读写传输数据的速度最快 Raid 1：所存储的数据安全性高，但硬盘容量损失大 Raid 3：安全性能好，但是写入慢 Raid 5：磁盘利用率高，数据安全性高，成本低 Raid 10 ：拥有RAID 0的高速，又拥有RAID 1的安全。

笔者回答： #!/bin/bash find ./ -name “*.png” -mtime +15 -print -exec rm -fr {} ; -print： find命令将匹配的文件输出到标准输出。 -exec： find命令对匹配的文件执行该参数所给出的shell命令。相应命令的形式为’command’ { } ;

笔者回答：Zabbix:数据采集比较强，支持agent、teknet等多种采集方式；支持多种报警管理，报警的设置比较全面，图形化展示比较直观，历史数据查询可配置，具有安装的用户审计日志 普罗米修斯：具有多维数据模型，拥有一种灵活的查询语言，课完成复杂的查询，不依赖分布式存储，通过服务发现或静态配置发现目标。 Nagios：具备定义网络分层结构的能力，可以支持并实现对主机的冗余监控，自动的日志回滚，并行服务检查机制

笔者回答： 运维就是对网络软硬件的维护，是要保证业务的上线与运作的正常，在业务运转的过程中，对业务进行维护，运维集合了网络、系统、数据库、开发、安全、 监控于一身的技术。运维要做的一个事情除了协调工作以外，还需要与各平台沟通，做好开服的时间、开 服数、用户导量、活动等计划。

笔者回答：

当我们在shell中执行命令的时候，每个进程都和三个打开的文件相联系，并使用文件描述符来引用这些文件。由于文件描述符不容易记忆，shell同时也给出了相应的文件名。

下面就是这些文件描述符及它们通常所对应的文件名：

文件文件描述符 系统中实际上有12个文件描述符，但是正如我们在上表中所看到的， 0、1、2是标准输入、输出和错误。可以任意使用文件描述符3到9。

标准输入是文件描述符0。它是命令的输入，缺省是键盘，也可以是文件或其他命令的输出。标准输出是文件描述符1。它是命令的输出，缺省是屏幕，也可以是文件。标准错误是文件描述符2。这是命令错误的输出，缺省是屏幕，同样也可以是文件。 你可能会问，为什么会有一个专门针对错误的特殊文件？这是由于很多人喜欢把错误单独保存到一个文件中，特别是在处理大的数据文件时，可能会产生很多错误。 如果没有特别指定文件说明符，命令将使用缺省的文件说明符（你的屏幕，更确切地说是你的终端）。

文件重定向

在执行命令时，可以指定命令的标准输入、输出和错误，要实现这一点就需要使用文件重定向。下表列出了最常用的重定向组合，并给出了相应的文件描述符。 在对标准错误进行重定向时，必须要使用文件描述符，但是对于标准输入和输出来说，这不是必需的。

其语法如下： command < filename                         把标准输入重定向到filename文件中 command 0< filename                       同上 command > filename                         把标准输出重定向到filename文件中(覆盖) command 1> fielname                       同上 command >> filename                       把标准输出重定向到filename文件中(追加) command 1>> filename                     同上  command 2> filename                       把标准错误重定向到filename文件中(覆盖) command 2>> filename                     同上 command > filename 2>&1               把标准输出和标准错误一起重定向到filename文件中(覆盖) command >> filename 2>&1             把标准输出和标准错误一起重定向到filename文件中(追加) command < filename >filename2        把文件filename中的内容作为command的输入，把标准输出重定向到filename2文件中

command 0< filename 1> filename2   同上

重定向的使用有如下规律： 1）标准输入0、输出1、错误2需要分别重定向，一个重定向只能改变它们中的一个。 2）标准输入0和标准输出1可以省略。（当其出现重定向符号左侧时） 3）文件描述符在重定向符号左侧时直接写即可，在右侧时前面加& 【类似于指针前要加*号，来区分这、两种情况】。 4）文件描述符与重定向符号之间不能有空格！

https://www.cnblogs.com/softidea/p/3965093.html

详细区别对比：