Linux 运维和网站开发，你更愿意让哪个作为您的职业？为什么？我一定要认真回答这个问题，多写一些。感触太多啊！
我毕业之后的第一份工作就是在百度做运维，之后在人人做开发，五年了，现在又在做运维的事。
运维和开发都是必不可少的
开发的价值大家有普遍的认识，但是运维也是从网站存在的第一天就存在的，只是没有专人而已。规模扩大之后，专人并不是最大的改变，而是有越来越严格的运维规范，兼职执行不过来了。
举个例子来说考虑问题的区别：
运维初期是：WebServer和DB各占多少内存可以性能最好。
运维后期是：如何让开发、测试、生产环境流畅的循环。
开发初期是：如何完成功能，如何更快的完成功能。
开发后期是：如何复用、如何减少耦合、如何提高性能。
开发不给力，运维背黑锅
归根结底，开发是第一步，运维是第二步。开发的一个小问题，在运维可能会被放大。没有运维思路的开发，会给运维找很多麻烦：程序本身的性能不优、内存泄漏、结构耦合、日志不规范，都让运维无从下手。
我在百度维护一个有索引的业务，这个服务有一个文件记录A/B库的切换状态，一次回滚操作需要修改很多服务器上的这个文件，系统结构造成这个文件是服务器相关的，只好逐台修改。后来在人人开发类似的系统，宁愿付出一些同步的成本，也会让运行状态与部署无关，简化运维的操作。
运维不给力，全公司倒霉
运维无法让开发流程进入良性循环，开发的效率低，版本模糊无法测试，线上BUG无法快速修复，安全漏洞频出。最终导致故障频发，用户流失。
人人曾经有个教训，我们采用了多种语言做后台开发，后来新功能非常的难推进，要协调很多开发工程师才能串起一个功能。然后这个系统就死了。
对职业选择的建议
要有决心两个都做，优秀的开发一定是对运维有思考的，优秀的运维一定是和开发有共鸣的。但是很可惜，现实并不美好。我见过运维做到位的，很少。面试遇到的几乎都是因为不会写代码，才选择做运维。只能算是操作员，职业发展瓶颈严重。
我见过优秀的工程师，很多。有转架构师的，有的转管理的，转运维……貌似没有公司愿意付同样的薪酬。还是行业里操作员太多了。
我认识很多运维，工作了2~3年后普遍觉得自己就是个操作员，天天半夜起来“抗洪救灾”不说，还偶尔背黑锅。到了年终大头都让研发、产品、测试分了……
但请不要抱怨，想一想，如果自己是老板会不会这么做呢？
研发、产品就像Dota里的DPS和Gank，是左右战局发展的；测试、运维一个是奶妈，一个是肉不被重视是很自然的。
运维和开发是互联网大生产时代分工的必然结果，但如果你画地为牢，就不要抱怨别人为什么过得更好
我想说的是：
- 不要把运维当作一种职业去发展，一般运维做2~3年就会遭遇瓶颈期
- 工程开发人员想要有深入的发展，必须懂一定的系统运维
- 如果你是运维，请明白一个程序能稳定运行在线上，不是什么魔法，是研发的付出
- 由于PaaS的迅猛发展，传统运维的工作（配网络设备，服务器物理操作）将会越来越少，建议运维人员向运维开发或者系统开发转型
- 如果你是开发，请尊重团队的成员，不要给别人凭添麻烦，如下
大学的时候有幸接触了Linux网站运维的工作，勤工俭学负责了学校网站的运维工作，现在回头看来这份工作的技术含量不是很高。当时觉得最牛的事情就是做做内核裁剪，后来由于好奇心的驱使，初生牛犊不怕虎，斗胆修改了proftpd的代码。从此走上了系统开发的不归路，由于深知系统运维的工作的枯燥，我给自己开发的程序定下了几个原则：
- 不能崩溃，要有自己的崩溃恢复机制，tj/mon · GitHub
- 内存泄漏，句柄泄露这种事情决不允许发生，Valgrind
- 尽量静态依赖所有的库，除了常见的libc、libm等什么都不要依赖，做到丢到服务器上就能运行，像这样miniPy for CentOS 5/6和 异步多线程C/S框架gko_pool
- 做好start、stop、restart脚本
- 能通过参数传递实现的功能，绝不要求写配置文件，auxten/gingko · GitHub
- 默认参数就是最佳配置，同样参见上面的项目
- 能自己处理日志，自带rotate功能，同样参见上面的项目
1、大公司重流程和协调。运维一般分为一线二线三线，三线往往是研发接口人了。很多时候，不需要你技术能力很强，一个问题，你独立解决还是求助高手解决了，公司无所谓，能解决就行。这样子导致很多人干了几年下来，技术能力其实很弱，bash都写不好。顶着一个500强“高级系统工程师”的title，其实自己知道自己斤两，不是说这个工程师不行，而是大公司分工太细了，他只会他负责的那个小领域。
2、小公司重独立快速解决问题的能力。从大公司去小公司干运维，会感觉从正规军去了游击队，很多小公司做事真是令人发指的不规范。升级不打申请，没有文档，没有审批，事后没有总结，糊里糊涂一个事情就做完了。处理了故障，也不写案例，谁都不知道他怎么处理的。小公司的这种作风，看上去效率很高，实际上难以培养出高水平的专业性工程师，而且小公司对技术的需求很弱，对运维的要求更弱，往往只要求你不出故障就了
1）、坐等故障发生，然后处理故障
2）、主动深入观察系统，优化系统，实施自动化运维
3）、优化运维架构，跟进新技术，参与研发前期架构选型
小公司大多处在第一个层次。
我觉得只要公司处在不是所有应用都跑在一台服务器上，只要公司是想好好发展的，就一定需要一个好的运维。因为运维是基础建设，是所有的程序的基础。基础不好，还谈什么其它。
开发和运维相对来说侧重点不一样，但我觉得真的好运维在技术层面和知识面的沉淀上远远的要超过开发。因为开发可能只要掌握一种开发语言，积累一种开发语言的技巧代码，就能很牛了。可是运维呢？网络，系统，数据库，程序开发，系统架构等等这些都需要知道了解熟悉。胜至于几乎随便一个SA都要熟悉掌握bash,python等几种脚本语言命令，光会搭建的服务就不下十种。或许有人说搭建服务很简单的，只需要下一步默认安装就好。但我想说，哪个服务不是配置项十几二十条的，理解各自的意思，明白各自的意义，这也是运维专业的地方。
撇开那些技术不到位的运维操作员，求一个好运维比求一个好开发难得多得多。因为知识面太广，而深度又太深，运维技术的变更革新又快得厉害，这些要求其实远远的超过对开发的要求。看着开发好像很厉害实现了某些功能，让公司赚钱了。可是如果没有运维的支持，没有运维的协助，没有运维的环境保障。那么这些很可能其实都看不到，或是只能越做越差，最后做死系统。
运维的功劳是很大的，但非常的含蓄，不像开发那么明显。这一点太吃亏了，而且就大家回复看，很多人都觉得运维其实就是打打杂，把运维当成一种开发的附带产品。
我想说真的要做好运维，其实很难。而且一个好的运难，也会让公司的开发流程运转更顺畅，架构更合理。效率更高。不过说了那么多，仍然无法改变现状。开发比运维好混得多，而且运维易学难精。
要么不做，要做就做到最好。所以到了深处开发和运维其实还是一样的，但走的路运维比开发要难走得多。付出的时间要多得多，所以如果能重选。我觉得还是从开发走起，会好很多！
不错的好文章