运维工程师常见面试题

文章转载自:

2、灰度发布如何实现？

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

3、mongodb熟悉吗，一般部署几台？

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

 

4、如何发布和回滚，用jenkins又是怎么实现？

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

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

5、tomcat工作模式？

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

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

tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是apache, iis, nginx等；

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

6、监控用什么实现的？

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

7、你是怎么备份数据的，包括数据库备份？

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

总结一下面试注意几点事项，可能笔者也说得不太对，为了我们运维工作的兄弟们都能拿到高薪，大家一定要指证出来一起进步、一起探讨：

    第一，你要对自己的简历很熟悉，简历上的写的技能自己一定要能说出个一二，因为面试官的很多问题都会挑你简历上写的问。比如你简历上写了这么一条技能“熟悉mysql数据库的部署安装及原理”。你即然写了这么一条技能，你在怎么不熟悉你也要了解mysql的原理，能说出个大概意思。万一面试官问到了你写的这一条，你都答不上来，那在他心里你又减分了，基本上这次面试希望不大。

    第二，如果面试官问到你不会的问题，你就说这个不太熟悉，没有具体研究过，千万别不懂装懂，还扯一堆没用的话题来掩饰，这样只会让面试官反感你。

    第三，准备充分，竟可能多的记住原理性的知识，一般面试问的多的就是原理。很少问具体的配置文件是怎么配置的。面试前也要了解清楚“职位描述”和“岗位要求”，虽然有时候大多数不会问到岗位要求的问题，但也要了解和熟悉。

    第四，面试完后一定要总结，尽量记住面试官问的每一个问题，回去记录下来，如果问到不会的问题，事后要立马查百度或者找朋友搞清楚、弄明白，这样你才能记劳，下次面试说不定又问到同样的问题。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

下面是这家公司中的岗位要求说明：

岗位职责：
1、负责公司产品的版本控制、构建和发布管理；
2、负责公司统一配置库管理工作，权限管理与分配准确及时，定期完成配置备份；
3、负责公司内部开发/测试服务器的运行管理工作；
4、负责linux操作系统的安装、配置、监控和维护、问题处理、软件升级、 数据备份、应急响应、故障排除等、保证线上环境的稳定运行；
5、负责支撑平台24×7稳定运行，并进行前瞻性容量规划；
6、负责公司机房服务器日常维护及网络系统安装、部署、维护工作。

岗位要求：
1、计算机相关专业本科及以上学历，2年以上运维或配置管理工作经验；
2、至少熟悉一种监控系统搭建，如nagios/zabbix/等；
3、至少熟悉一种集群管理工具，如ansible/saltstack等；
4、有使用集成发布工具发布构建经验优先。比如：bamboo或者jenkins；
5、熟悉unix/linux操作系统，熟悉weblogic/tomcat等中间件，能够编写shell脚本，熟悉软件开发过程及过程产品，有一定的网络基础；
6、熟悉rsyslog, flume等日志收集和处理系统；
7、具有强烈的安全意识及较强的沟通协调和学习能力，良好的团队合作精神，工作积极主动。

 问我应该有不下10个以上的问题，我记住了下面有10个问题：

1、lvs负载的原理，和nginx负载有啥区别？

笔者回答：这个问题我觉得面试官司没问好，正常都会这么问“lvs有哪些负载均衡技术和调度算法?"。我回答就是按我说的这种问法回答的，反正他也频繁点头，当然，笔者回答的可能没有下面我整理出来的那么详细，大概意思我都说明白了。

    lvs是liunx虚拟服务器的简称，利用lvs提供的负载均衡技术和linux操作系统可实现高性能、高可用的服务器集群，一般lvs都是位于整个集群系统的最前端，由一台或者多台负载调度器（director server）组成，分发给应用服务器（real server）。它是工作在4层（也就是tcp/ip中的传输层），lvs是基于ip负载均衡技术的ipvs模块来实现的，ipvs实现负载均衡机制有三种，分别是nat、tun和dr，详述如下：

 vs/nat： 即（virtual server via network address translation）

也就是网络地址翻译技术实现虚拟服务器，当用户请求到达调度器时，调度器将请求报文的目标地址（即虚拟ip地址）改写成选定的real server地址，同时报文的目标端口也改成选定的real server的相应端口，最后将报文请求发送到选定的real server。在服务器端得到数据后，real server返回数据给用户时，需要再次经过负载调度器将报文的源地址和源端口改成虚拟ip地址和相应端口，然后把数据发送给用户，完成整个负载调度过程。

可以看出，在nat方式下，用户请求和响应报文都必须经过director server地址重写，当用户请求越来越多时，调度器的处理能力将称为瓶颈。

 vs/tun ：即（virtual server via ip tunneling）

也就是ip隧道技术实现虚拟服务器。它的连接调度和管理与vs/nat方式一样，只是它的报文转发方法不同，vs/tun方式中，调度器采用ip隧道技术将用户请求转发到某个real server，而这个real server将直接响应用户的请求，不再经过前端调度器，此外，对real server的地域位置没有要求，可以和director server位于同一个网段，也可以是独立的一个网络。因此，在tun方式中，调度器将只处理用户的报文请求，集群系统的吞吐量大大提高。

 vs/dr： 即（virtual server via direct routing）

也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与vs/nat和vs/tun中的一样，但它的报文转发方法又有不同，vs/dr通过改写请求报文的mac地址，将请求发送到real server，而real server将响应直接返回给客户，免去了vs/tun中的ip隧道开销。这种方式是三种负载调度机制中性能最高最好的，但是必须要求director server与real server都有一块网卡连在同一物理网段上。

回答负载调度算法，ipvs实现在八种负载调度算法，我们常用的有四种调度算法（轮叫调度、加权轮叫调度、最少链接调度、加权最少链接调度）。一般说了这四种就够了，也不会需要你详细解释这四种算法的。你只要把上面3种负载均衡技术讲明白面试官就对这道问题很满意了。接下来你在简单说下与nginx的区别：

lvs的优点：

• 抗负载能力强、工作在第4层仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；无流量，同时保证了均衡器io的性能不会受到大流量的影响；

• 工作稳定，自身有完整的双机热备方案，如lvs+keepalived和lvs+heartbeat；

• 应用范围比较广，可以对所有应用做负载均衡；

• 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。

lvs的缺点：

• 软件本身不支持正则处理，不能做动静分离，这就凸显了nginx/haproxy+keepalived的优势。

• 如果网站应用比较庞大，lvs/dr+keepalived就比较复杂了，特别是后面有windows server应用的机器，实施及配置还有维护过程就比较麻烦，相对而言，nginx/haproxy+keepalived就简单一点

nginx的优点：

• 工作在osi第7层，可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则比haproxy更为强大和灵活；

• nginx对网络的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势所在；

• nginx安装和配置比较简单，测试起来比较方便；

• 可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；

• nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点；

• nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的web应用服务器。lnmp现在也是非常流行的web环境，大有和lamp环境分庭抗礼之势，nginx在处理静态页面、特别是抗高并发方面相对apache有优势；

• nginx现在作为web反向加速缓存越来越成熟了，速度比传统的squid服务器更快，有需求的朋友可以考虑用其作为反向代理加速器；

nginx的缺点：

• nginx不支持url来检测。

• nginx仅能支持http和email，这个它的弱势。

• nginx的session的保持，cookie的引导能力相对欠缺。

2、redis集群的原理，redis分片是怎么实现的，你们公司redis用在了哪些环境？

笔者回答：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，主要缓存有登录用户信息数据、设备详情数据、会员签到数据等

3、你会怎么统计当前访问的ip，并排序？

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

4、你会使用哪些虚拟化技术？

笔者回答：vmware vsphere及kvm，我用得比较多的是vmware vsphere虚拟化，几本上生产环境都用的vmware vsphere，kvm我是用在测试环境中使用。vmware 是属于原生架构虚拟化技术，也就是可直接在硬件上运行。kvm属于寄居架构的虚拟化技术，它是依托在系统之上运行。vmware vcenter管理上比较方便，图形管理界面功能很强大，稳定性强，一般比较适合企业使用。kvm管理界面稍差点，需要管理人员花费点时间学习它的维护管理技术。

5、假如有人反应，调取后端接口时特别慢，你会如何排查？

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

6、mysql数据库用的是主从读写分离，主库写，从库读，假如从库无法读取了、或者从库读取特别慢，你会如何解决？

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

7、cpu单核和多核有啥区别？

双核cpu就是能处理多份任务，顺序排成队列来处理。单核cpu一次处理一份任务，轮流处理每个程序任务。双核的优势不是频率，而是对付同时处理多件事情。单核同时只能干一件事，比如你同时在后台bt下载，前台一边看电影一边拷贝文件一边qq。

8、机械磁盘和固态硬盘有啥区别？

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

9、说一下用过哪些监控系统？

笔者回答：这个监控的问题又问到了，笔者在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如果写好自动化脚本后，也很简单，问题在于写自动化脚本很费神。

 10、给你一套环境，你会如何设计高可用、高并发的架构？

笔者回答：

如果这套环境是部署在云端(比如阿里云)，你就不用去考虑硬件设计的问题。可直接上阿里云的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”。这样一套环境下来是绝对满足高可用、高并发的架构。

本文转载自：http://blog.51cto.com/ganbing/2057482

文章转载自: