工作快10年了，干过程序员，技术支持，最后干的运维，公司是BAT之一，具体哪家就不说了，一直很少写文章，但最近确实比较闲，打算写一点面向新人的文章，当然对于中高级的我觉得也可能有参考意义。先写三篇吧，看对大家有没有用，如果有用，后面再写些高级的。文章主要面向方法论，不讨论具体的技术细节。
第一天：选择运维
运维值不值得干
对于没进入和刚进入IT行业的新同学来说，如果你在思考这个问题，说明你出身平凡，上流社会是不需要考虑这种问题的。当然，如果你考虑了，说明你还是屌丝中的进步青年。在过来人看来，这个就跟上大学一样，专业不是很重要，大学很重要。所以，选对行业和公司对以后还是很有帮助的，对于运维来说，目前互联网行业机器比较多，发展也比较好，我认为进入这个行业是不错的选择。选择完了，我们来看下运维职业发展的问题。
运维职业规划
说实话，我不太喜欢搞职业规划，扯淡居多，当然你可以不信，但确实有位大师也是这么说的，对于我这种只观大略的来说，大师的名字就别指望我记得了。在我看来，搞职业规划不如多去了解自己的兴趣！如果你对技术有兴趣，也选择了运维这个职业，我们再来看看运维怎么发展。
其实没太多说的，技术类的职业发展大同小异，基本会有管理线和专家线两条路，看自己兴趣了。所谓管理，就是leader，总监，VP，所谓专家，就是…,统称大牛，领导得给你面子，但活还得干。
运维的缺点
到目前为止，恭喜你已经成功成为运维攻城狮的一员了，我说下运维工作的缺点吧，这里妹子稀少，成天对着电脑，还尼玛只有文字的屏幕，有点逼格的可以搞黑底绿子，也就这样了。不要抱怨，要知道，你旁边的码畜也好不到哪去。没事去产品那逛逛，也许会有好看点的妹纸或者散发着雌激素的基友。当然，会找女朋友的一定不在这里找，得去女人堆找，质量高，选择面广，至于哪里是女人堆，请私信我。
第二天：开始运维
看来你已经接受运维的缺点了，让我们开始工作。
鸟瞰运维
古语有云：不谋全局者，不足谋一域。要想做好运维工作，了解下运维的全貌也是有必要的。让我们围绕一项业务的生命周期来了解运维工作的大概内容。
假设一个网站做完了，需要给用户使用，怎么办呢，我们需要上线，首先需要服务器，服务器放在哪？机架，机架放在哪？机房。服务器要对外服务，还需要网络，服务器上要运行我们的网站程序，需要操作系统，程序还需要保存数据到数据库，需要对外服务的web服务器，这样用户就可以访问网站了。在这之后，网站运营期这些软硬件都随时可能出问题，所以要进行监控，告警。网站也可能还有黑客攻击，还需要考虑安全。业务发展过程中需要变更，网站下线后资源需要回收，这大概算是一个运维工作的最小原型了，实际情况也远比这个复杂，在一家大型的互联网公司，这些环节都是需要分工合作完成的，让我们看看一个大型互联网公司的运维部门基本组成。
先让我们记住一些关键词：上线，运营期，下线
服务器 机架 机房 网络 操作系统 数据库 web服务器 监控 告警 安全 变更 资源回收
上图只是标出了运维人员的组成，在实际的组织架构中，往往还包括产品，研发，质量，项目管理，大数据部门，因为大数据往往也属于基础设施，他们与运维共同组成更大的部门。
云计算与运维
从上面的图我们基本可以看出，运维工作需要的知识面非常广，小公司不可能招聘这么多的人来进行基础设施建设，但他们又需要这些产品和技术，于是就有厂商专门提供这种服务，成立了云计算公司，当然云计算的形式不只是图上的这些，但目前最激烈的战场就在基础设施这里，国外知名的像亚马逊，国内的有腾讯云，阿里云等等，他们的业务规模天然适合做基础设施云计算。所以运维要是能去云计算部门，算是去对了地方。
业务运维是个神马角色
业务运维也是运维，但为什么要单独来提，主要是因为我原来就是干这个的，另外，业务运维人员较多，与其他运维的工作也有不同之处。首先我们看看业务运维在工作中的定位。
业务运维往往和项目组组成一个虚拟的组，所以需要了解业务，同时又需要和基础设施部门对接，相当于业务和基础设施之间的纽带，也就是说，业务运维不仅需要了解大量的基础设施技术，还需要与人沟通的能力，是一个需要综合能力的工作。
业务运维的工作内容
上面对运维的介绍相对笼统，还是不容易理解，运维到底干的都是哪些事。我们还是围绕一个项目来介绍。
一． 开发阶段运维宣导
做过软件开发的都知道，以前应用都基于操作系统，但互联网应用则是基于云，也就是图中提到的基础设施，由于专业分工的关系，开发人员对这些基础设施并不一定全部了解，基础设施有什么好处，有什么限制，使用上有什么规范，所以需要培训，可以起个好听的名字，运营规范宣导。项目开发阶段运维也需要介入，跟踪项目进展，最好是能对项目的物理架构提供一些建议，很多问题越早发现越好，互联网公司虽然大牛众多，但也不是每个项目组都有大牛把控，如果不加限制，后期维护将非常困难，对产品，对运维都没什么好处。（有的部门在产品开发阶段会有委员会进行评审，委员会成员既有研发也有运维）
二． 项目接入前检查
在项目开发快完成的时候，运维需要及时介入对项目进行可运维性评审，比如了解项目的物理架构，配置文件管理，部署，变更复杂度，可用性，容量，容错处理，可监控性等等，尽量排除一些问题。
另外还需要根据项目的发展规划，重要级别等，申请相应的基础设施资源，在申请阶段还需要考虑物理部署的问题，这个阶段如果做的好，会给后期的运维带来很大的方便。验收完成后运维也需要根据项目情况提供相应的SLA。
我曾在一线互联网公司的多个部门呆过，发现即使在这么大规模的公司，发展也极不平衡，有的部门在产品上线前期就做了大量的工作，而很多部门的运维只是被动的上线，什么再难也要顶上，人肉战术，疲于奔命。我想这应该是管理上权利与责任不对应的问题，在互联网的世界里，线上的产品就是公司的生命线，运维对线上负责，也应该有相应的权利，这样才能更好的保证线上业务的稳定。
很早以前运维过一个项目，半路接手的，数据库IP地址分散在几十个文件中，有配置文件，脚本，代码，而具体修改点竟有上百处，这还是我自己调查的，其他地方有没有开发都记不清，大家可以想象项目乱到什么程度了，我也终于理解前面的哥们为什么不干了，也感慨如此规模的公司竟然也有这样的项目。所以这就是前期控制的重要性，我想我遇到的问题在许多公司仍然存在，不少兄弟应该有同感吧。
三． 项目接入
如果前期工作都做的很好的话，这个阶段的工作不难，自动化强的很轻松，自动化弱的无非耗点体力，总之难度不大，这里不多说。
四． 运营阶段
项目上线后，随着业务的发展，可能需要扩容，上新版本，也可能会遇到各种问题，这个阶段都是常规打法，记住变更需要慢慢来，一般称为灰度发布，这个做法其实很容易理解，比如我国要改革开放，改革开放到底行不行，不是谁说了算，先拿深圳搞个试点，行了再逐步开放其他城市，这么做无非就是避免大规模失败。
如果遇到故障，不仅需要排查，还需要记录，一般称为事故管理。
如果遇到奇怪的问题不能解决，也需要记录，一般称为问题管理。
如果需要变更线上环境，也需要记录，一般称为事件管理。
五． 业务下线
不多说，过程是愉快的。
六． 总结：
在我看来，如果把运维工作按照项目上线分成三个阶段的话(上线前，上线，上线后)，那么上线前是最重要的阶段，正对应了那句话，好的开始是成功的一半。
这里给出一张运维工作和ITIL的对应图，完整的ITIL比这个要复杂，实际的运维工作也比这个要复杂，但这张图也基本涵盖了运维工作的核心内容。
第三天:运维的技能
运维是门手艺活，怎么掌握这门手艺，我这里列出一些书籍和开源软件，希望能给大家提供一些参考和学习方向。
书：
大学计算机系科目
鸟哥的私房菜
linux fromscratch
RHCE RHCA书籍
深入理解linux内核
Linux内核设计与实现
Linuxprogramming interface
Tcpip详解
高性能mysql
MySQL内核:InnoDB存储引擎
构建高性能web站点
软件构件与中间件技术
大话存储
正则表达式
一些开源工具
Cobbler 系统安装
Ansible，puppet，fabric，saltstack 配置管理，批量操作
Zabbix，cacti，nagios 监控告警
kvm，xen，docker，coreos 虚拟化
nginx resin php memcache redis lvs 常用软件
top sar iostat vmstatiotop strace perf tcpdump dstat tcpflow tcprstat tsar nmon 性能监控
本文转载自 http://bbs.linuxtone.org/thread-26624-1-1.html