总结两句话：
1、保障业务长期稳定运行（如网站服务器、游戏服务器等）。
2、保障数据安全可靠（如用户名密码、游戏数据、博客文章、交易数据等）。
由这两句话推演运维工程师要学些什么？
稳定
出一点点差错，用户就要投诉了。
1、业务跑在什么上面？
网站服务器一般是apache,nginx,tomcat等。但是真正跑通流程还需要Mysql数据库来存储用户密码及其它。很多程序都要php的解析，所以LNMP、LAMP(即nginx、apache、mysql、php)环境部署是必须掌握的技能。
2、业务出了问题怎么及时知道？
这就需要监控软件来邮件或短信来通知你，常用的有zabbix,nagios等。报警发邮件，也得一个邮件程序呀，sendmail或postfix。
3、在家里收到报警，但服务器是内网IP，怎么也得解决问题吧？
在公司搭建openvpn或pptp或openswan，在家里通过VPN拨入内网，24小时解决问题…唉，半夜爬起来解决问题也没工资。
安全
出一点点差错，领导要找你喝茶了。
1、有时需要手动改数据库内容？
所以要会基本的Mysql数据库增删查改命令。
2、万一数据库服务器硬件坏了怎么办？
需要有个备库以备不时之需，所以需要Mysql主从复制。
3、数据库要还原怎么办？
所以需要在crond中定期全备Mysql数据，以便还原使用。如果要还原到指定时间点，还要学会Mysql增量备份与恢复。
4、如果是用户上传的图片或文件服务器坏了怎么办？
定时备份可能还不够，需要使用rsync加inotify来实时备份。以便任一时刻主服务器坏掉，也能保障所有图片有备份可以用来恢复。
5、小心黑客，要增加服务器安全性？
ssh轻易不能让外人访问，那么就设置只允许公司的IP或跳板机IP访问，这些都通过iptables来控制。
6、说一下你们公司怎么发版的（代码怎么发布的）？
笔者回答：我说什么来着，这个问题又问到了。发布：jenkins配置好代码路径（SVN或GIT），然后拉代码，打tag。需要编译就编译，编译之后推送到发布服务器（jenkins里面可以调脚本），然后从分发服务器往下分发到业务服务器上。
7、如果你们公司的网站访问很慢，你会如何排查？
其实这种问题都没有具体答案，只是看你回答的内容与面试官契合度有多高，能不能说到他想要的点上，主要是看你排查问题的思路:
1)**要url或页面:**问清楚反应的人哪个服务应用或者页面调取哪个接口慢，叫他把页面或相关的URL发给你，
2)chrome浏览器分析最直观的分析就是用浏览器按F12 (network->waterfall)，看下是哪一块的内容过慢（DNS解析、网络加载、大图片、还是某个文件内容等），如果有，就对症下药去解决（图片慢就优化图片、网络慢就查看内网情况等）。
3)观察后端服务的日志，其实大多数的问题看相关日志是最有效分析，最好用tail -f 跟踪一下日志，当然你也要点击测试来访问接口日志才会打出来。
4)排除sql，找到sql去mysql执行一下，看看时间是否很久，如果很久，就要优化SQL问题了，expain一下SQL看看索引情况啥的，针对性优化。数据量太大的能分表就分表，能分库就分库。如果SQL没啥问题，那可能就是写的逻辑代码的问题了，一行行审代码，找到耗时的地方改造，优化逻辑。
大性能
1、越来越多的用户来访问我们的网站，一台web服务器抗不住了怎么办？
那就需要多台web服务器来负担，但多台服务器之间怎么进行负载均衡呢，这就需要用到nginx反向代理或(LVS+keepalived或haproxy+heartbeat了–>高可用)。
2、用户注册发表的文章与评论太多，一台数据库抗不住了怎么办？
数据库压力分为读和写，如果写抗不住，需要进行分表分库到多个服务器上。如果是读压力不够了，可以使用mysql-proxy读写分离，
来分担读的压力。更简单方便的方法，把数据库里的内容放到内存上，这就用上memcache或redis了。
3、N多用户上传下载文件，磁盘抗不住了怎么办？
把多块磁盘做成raid，或者使用分布式存储文件系统如MFS，GlusterFS来提高磁盘的读写能力。
4、网站上好多图片，总有用户反应网站加载太慢，怎么办？
这时可以把网站上的图片通过squid或varnish缓存到网站前端，尽可能的增加访问速度，当然，最好是购买商业的CDN加速。
5、运营商是个大难题，他们之间的带宽好像很小，联通IP访问我电信网站怎么就这么慢呢？
这时可以使用bind自建一个DNS服务器，把网站的DNS记录指向自建DNS服务器上，配置好解析规则，以后联通IP解析到联通网站上，
电信IP解析到电信网站上，体验就会好很多啦。
自动化
终极目标：跑死机器，闲死人。
1、公司新买100台服务器，公司竟然就1个移动光驱，这装系统得到什么时候？
使用kickstart或cobbler来网络远程自动安装系统吧。
2、每次装完机要优化很多内容，什么文件描述符、端口、软件安装啊，手动操作不累死去？
赶紧学会shell，将解放非常多的工作量。
3、系统装完后登陆要输入密码，这么多台啊？
使用expect吧，自动读取提示来输入密码，并执行命令。
4、要批量把新代码发布到线上服务器，怎么办？
使用saltstack或puppet或ansible吧，绝对爽歪歪。
素养
安全
运维人员的权限很大，所以一定要保证帐号/私钥的安全。
最好使用加密工具存储。比如truecrypt，1password
基于本地存储。切勿用网盘，也不建议用lastpass等
ssh私钥添加密码
以上任何一点都很重要，否则弄丢了，风险会非常大。
责任心
遇到报警，第一时间处理，而不要等着他人去处理,如果无法处理，应该第一时间让同事协助帮忙，而不要禁止报警，让问题掩盖
细心
1.你的任何一个操作，都可能造成系统的损坏、业务出问题。所以敲命令时一定要细心、再三确认。你敲的再快，也就节省那么一点时间，出了问题才是大事。
2.在项目上线前,除了关注功能的测试,还要关注部署、备份、监控、安全以及配置管理,在早期发现的问题越多,越能尽少后期的问题并避免影响用户体验
3.建立各个团队的核心成员定期沟通机制(团队之间的协作纳入绩效考核过程中去)
4.如何从开发的角度去做运维工作( 1)运维去了解代码的模块结构,从运维的角度修改代码,让产品上线后更方便运维与适应生产环境的特点。2)运维参与到持续的集成测试中,用自己的自动化知识帮助实现自动的集成测试等。)
5.工作量如何体现?
周报
推进/改善
如果代码有问题，导致系统开销很大，比如负载，io等。应该第一时间和开发部门确认，要求优化代码。
进取心/不断学习
运维的知识范围很广，要不断学习。遇到问题，做好分析记录，事后还可以在部门内分享交流。
一定要整理分析, 好记性不如烂笔头!!! 没有谁能一步登天, 牛人都是从1+1开始学的, 为什么有的人会成为牛人, 定期整理分析是必不可少的. 没有整理就不能成为自己的知识.
团队沟通
在开发过程中,团队之间的冲突和抱怨是避免不了的,但是产生的影响基本一样：
1.产品上线的进度延误，整个团队很难正常交付新版本。
2.产品上线后问题很多，影响用户的访问。
3.团队的士气很差。
运维问题：
1.产品开发一点计划都没有，突然要上线机器，让我们措手不及。
2.设备使用不规范,带宽被跑满导致网络出问题.
3. 开发的代码太不靠谱,一上线就引发用户投诉,只能回滚到老版本。
开发问题：
1.开发需要了解生产环境是什么样,否则不好开发代码,那么运维是否可以直接接触线上的系统?
2.如何处理关于项目上线后出问题,运维直接回滚了.
3.代码在测试环境或我的机器跑的好好的呀，怎么一上线就出问题呢.
(测试怎么测的，那么多问题发现不了)
4.运维同事帮忙搭一个跟线上一模一样的测试环境.
测试问题：
1.开发人员不写规定写单元测试代码.
2.为了实现开发的业务功能,想着能用一个自动的集成测试环境.
3.测试环境跟生产环境不一样,很多问题不好发现.
4.bug没修复完,产品急着上线.
解决方案:
借用devops理念来处理团队协作问题:
1.推出新功能和解决老问题的周期过长
2.不同团队相互隔离,配合差.(如开发人员收到问题后，第一反应是“在我的机器上工作得好好的呀”)
DevOps更象是一种运动，每家公司都需要根椐自身的特点进行借鉴，推动团队之间的协作与合作。需要在三个方面努力：
-
人员
一方面对现有人员进行培训，鼓励他们了解别的团队的工作、面临的挑战等，让他们用自己的特长去审视和帮助别的团队，另一方面也想办法招一些全面的技术人才，在不同团队之间搭出一些适用的桥来。 -
流程
在研发的前期，让系统运维同事参与起来，一起搭建测试环境，验证想法，或者也可以在一些项目团队中直接配有系统、开发和测试以及产品人员，一起为产品的上线努力。出现问题的时候，一起想方法找到问题的真正根源，避免相互推托，将解决方案落实在以后的研发过程中。从绩效考核流程上也需要考虑协作因素。 -
工具
说实在的，大家针对DevOps在工具方面其实讨论得更多，这里面跟敏捷有些类似之处。快速的系统部署和自动化产品代码发布方面的工具显得尤为重要了。
其他
1、搭整套测试环境需要5台服务器，但公司穷的只有一台空闲服务器？
学会xen或kvm或docker吧，虚拟出多台服务器，就能解决资源问题了。特别是docker，强烈推荐，以后某个研发人员让你部署一套新环境，分分钟帮他解决。
2、研发人员的代码控制，权限控制，总要运维人员管呀？
svn或git，这个是肯定要有的。
3.权限相关问题
问题1：你们公司是如何来管理用户权限的？
答：我们是通过sudo来管理权限的，不论是运维还是开发，一般都不会给root权限，只有核心级开发或者研发总监或以上级别的我们才可能给相应服务器级别的权限；对核心运维或者运维总监才会给root权限
问题2:规划服务器的时候，在服务器上都跑几个普通用户？
答：我们的普通用户是根据项目来的，在不同公司它的项目产品线不一样。我们公司只有十几个产品线，我们为每一个项目建立一个普通用户，因此不论nginx还是tomcat都是跑在普通用户下。
问题3：那一些公用服务呢？比如memcached或者redis。
答：这些公共服务也可以跑在普通用户下，总的来说是这样的，我对运维的理解是，运维做运维的事情，开发做开发的事情。运维负责网络系统，只要系统没有故障，只要网络没有故障，只要系统资源还够用，那么我们运维的职责就到位了。而我们公司的理念是项目负责制，也就是说每个项目的责任人是开发，我们运维大概占30%-40%的责任。我们的开发占60%的责任。当进程上线的时候，这个服务是由普通用户跑的。它的每个站点目录都是普通用户的权限，也就是700的权限普通用户，这个是最安全的。无论是项目的启动，停止，以及代码上线，日志收集，日志分析都是通过我们进程跑的普通用户实现的。我们在管理这个项目的时候，我们可以把开发的用户加到这个项目组里面，这样负责相应项目的开发人员就有对应项目的所有权限。
结尾：
现在我们在回过头来思考，运维工程师平时干些啥呢？
1、 随时解决报警故障。
2、 业务程序更新。
3、 编写一些脚本，监控或完成其他可自动完成功能。
4、 运维架构完善，部署一些用起来更方便更可靠或性能更好的开源工具以及制定运维流程规范。
5、 打杂，如调交换机，装系统，部署新环境等。