笔者其实没有想到去面试，只是在智联上更新了一下简历，就陆陆续续接到很多猎头的邮件和电话，闲话少说，下面就分享给大家Linuxer的面试经历：
首先，猎头或者公司人资会把公司的介绍及岗位要求发到你邮箱（或者QQ、微信），下面这份是猎头发给我的岗位说明，为了职业道德操守，公司的介绍和面试通知信息我就不贴出来了，我就把岗位要求贴出来：
职位描述：
1、 负责应用服务器的安装、配置、优化与维护；
2、 负责应用系统的日志信息备份、管理、维护与分析；
3、 负责应用系统的日常监测于维护、故障处理、性能分析与优化；
4、 负责应用部署系统、环境配置系统、监控系统的开发、部署、升级与维护，建设高性能的运维平台。
岗位要求:
1、 熟悉Linux操作系统的基础知识，熟练使用Linux常用操作命令；
2、 熟练配置Nginx、HAproxy 等应用相关软件的部署、配置与优化维护；
3、 熟悉网络基础知识、熟悉TCP/IP的工作原理，会配交换机或路由器，能熟练的对网络情况进行分析
4、 熟悉shell/perl/python中的一种或多种进行运维程序的开发；
5、 熟悉Nagios,Ganglia等监控软件
看着上面的要求大家是不是觉得要求也不高啊，你要细看就会发现，这家公司要求的还挺多，不仅要会网络知识（熟悉TCP/IP好像是每家单位的都会写这样的要求），还要会开发技能。相信很多做运维的兄弟在网络这一块是个头疼的事情，都对交换机和路由器不怎么会配置和管理。
关键点来了，就是和面试官沟通了，有笔试的公司会让你做些面试题，没有笔试就直接和面试官聊了，下面是我和面试官沟通完之后记住的一些问题，分享给大家看一下，笔者一共记住了7个问题，好像还有两个问题实在想不起来了，如果大家有更恰当的回答一定要贴出来一起探讨和进步：
1、介绍下自己？
（几乎每家公司首先都会让你做个自我介绍，好像是必修课一样）
回答：此处省略笔者的自我介绍，笔者建议介绍自己的时间不宜过长，3-4分钟为宜，说多了面试官会觉得你太啰嗦了。说太少了也不行，那样会让人感觉你的经历太简单了、太空了。
正常情况下，一般你在做自我介绍的同时，面试官这个时候在看你的简历，他需要一边看简历、一边听你介绍自己，如果你说个几句话就把自己介绍完了，他肯定还没缓过神来，对你的映像会减分的。在介绍的同时思维要清晰，逻辑要清楚，***是根据你简历上写的经历来介绍，这样可以把面试官的思路带到你这里来，让他思路跟着你走。不要东扯一句，西扯一句。
尽量少介绍自己的性格、爱好（***能不说就不说），你可以简单罗列干过几家公司（最多罗列3家公司/也包含目前所在的公司，注意顺序不要乱），都在那几家公司负责什么工作，都用过什么技术，在着重介绍一下你目前所在的公司是负责哪些工作的，可以稍微详细一点介绍，不要让面试官听着晕头转向的感觉。
2、灰度发布如何实现？
回答：这个问题事后在知乎上看到了一位网友的建议觉得不错，大家可以参考看一下 ！
仔细考虑一下灰度发布系统要达到哪些目的，基本就能有答案了。需要注意的是，客户端应用（无论PC端还是移动端）的灰度发布要比Web应用的灰度发布更为复杂，因为应用运行在用户持有的终端上，数据采集和回滚都更为困难（但可采集的数据类型要更加丰富）。
注：本人缺乏移动客户端产品的经验，下述内容可能不适用于移动客户端产品。
我所理解的灰度发布系统，主要任务是从产品用户群中按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的显式反馈（论坛、微博）或隐式反馈（应用自身统计数据），对新版本应用的功能、性能、稳定性等指标进行评判，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。
从上述描述可以得出灰度发布系统需要具备的一些要素：
用户标识
用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。
目标用户选取策略
即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，***能够提供让用户自主回滚至旧版本的渠道。
对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。
数据反馈
用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。
服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。
新版本回滚策略
当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。
对于移动客户端，新版本发布成本较高，需要Appstore、Market审核。本人没有移动客户端产品的经验，不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App，会更有利于升级和回滚。（不过苹果对纯Web App类的App有较强的限制，好像已经不允许在Appstore上发布这类应用了？）
新版本公关运营支持
对于改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后，综合考虑应对策略。
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的原理，能说出个大概意思。万一面试官问到了你写的这一条，你都答不上来，那在他心里你又减分了，基本上这次面试希望不大。
第二，不要不懂装懂
如果面试官问到你不会的问题，你就说这个不太熟悉，没有具体研究过，千万别不懂装懂，还扯一堆没用的话题来掩饰，这样只会让面试官反感你。
第三，准备充分
竟可能多的记住原理性的知识，一般面试问的多的就是原理。很少问具体的配置文件是怎么配置的。面试前也要了解清楚“职位描述”和“岗位要求”，虽然有时候大多数不会问到岗位要求的问题，但也要了解和熟悉。
第四，面试完后一定要总结
尽量记住面试官问的每一个问题，回去记录下来，如果问到不会的问题，事后要立马查百度或者找朋友搞清楚、弄明白，这样你才能记劳，下次面试说不定又问到同样的问题。
