一、什么是门户网站运维
首先明确一下，全文所讲的”运维“是指：门户网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上千万（至少国内排名前20），如sina、alibaba、sohu、baidu、网易等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如本版有些同僚将公司的合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责，这是网络工程师的工作，我们就不要抢人家饭碗了，但是，非常重要一定需要明白：运维对其它关联工种必须非常了解熟悉：网络、系统、应用开发、内容；但这些非自已的本职工作，我在这里所讲的运维工程师就是指专职运维工程师。
我们再来说说一个般产品的“出生”流程：
1、首先公司BOSS层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计。
2、开发工程师将设计code实现出来、测试工程师对应用进行测试（同一产品事业部）。
3、网络/系统工程师根据产品设计的需求，如pv大小预估、服务器规模、应用架构等因素完成网络规划及设备上的调整（基本上对网络变动不大，除非大项目）、SA系统工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装。
4、好，到运维工程师出马了，首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大：应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能/安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复使：需求->开发（升级）->测试->上线（性能、安全问题等之前预估外的问题随之慢慢就全出来了）在这里提一点：网站开发模式与传统软件开发完全不一样，网站一天开发上线1~5个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像MS需要1年解决，用户早跑光了；应用上线后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化（大于50台）、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作：a 尽量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等等），提高效率 b 、解决现实中服务存在的问题，如高可靠性、可扩展性问题等，c、大规模集群管理工具的开发，如1万台机器如何在1分钟内完成密码修改、或运行指定任务？2000台服务器如何快速安装操作系统？各分布式IDC、存储集群中数BT级的数据如何快速的存储、共享、分析？等一系列挑战都需运维工程师的努力。
在此说明一下其它配合工种情况，在整个项目中，前端应用对于网络/系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的功能性开发，并对应用本身性能、安全性等应用本身负责，它不负责或关心网络/系统架构方面事宜，当然软/硬件采购人员等事业部其它同事也不会关心这些问题，各司其职，但项目的核心是运维工程师~！所有其它部门的桥梁。
上面说了很多，我想大家应该对运维有一些概念了，在此打个比方吧，如果我们是一辆高速行驶在高速公路上的汽车，那运维工程师就是司机兼维修工，这个司机不简单，有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快，汽车本身不能满足高速度时对汽车性能调优或零件升级、高速行进中解决汽车故障及性能问题、时刻关注前方安全问题，并先知先觉的采取规避手段。。。这就是运维工作~！
最后说一下运维工程师的职责：”确保线上稳定“，看似简单，但实属不容易，运维工程师必须在诸多不利因素中进行权衡：新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维工程师了。
另外在此聊点题外话，我在本版看到有很多人要sina、网易、sohu、baidu等聊自已的运维方面的经验，其实这对于它们有点免为其难：
a、各公司自已网络架构、规模、或多或少还算是公司的核心秘密，要保密，另外，对于大家所熟知的通用软件、架构，由于很多公司会根据自已实际业务需要，同时因为原版性能、安全性、已知bug、功能等原因，进行过二次开发（如apache,php,mysql...），操作系统内核也会根据不同业务类型进行定制的，如某些应用属于运算型、某些是高IO型、或大储存大内存型。。。根据这些特点进行内核优化定制，如sina就在memcache上进行过二次开发，搞出了一个memcache DB，具体做得如何我们不谈，但开源了，是值得称赞的，国内公司对于开源基本上是索取，没有贡献；另外，服务器也不是大家所熟知的型号，根据业务特点，大部份都是找DELL/HP/sun/ibm进行过定制；另外，在分布式储存方面都有自已解决方案，要不就是使用现成开源hadoop等解决方案，或自已开发。但90%都是借鉴google GFS的思想:分布式存储、计算、大表。
b、各公司业务方向不一样，会导致运维模式或方法都不一样，如alibaba和baidu运维肯定区别很大，因为他们业务模式决定了其架构、服务器量级、IDC分布、网络结构、通用技术都会不一样，主打新闻门户的sina与主打网游的盛大运维模式差异就非常大,甚至职责都不大一样；但有一点，通用技术及大致架构上都大同小异，大家不要太神化，更多的公司只是玩垒积木的游戏罢了，没什么技术含量。
c、如我上面所讲，目前门户网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，我相信大家也讲不出所以然来（我现在也中抓破脑袋挤出这点字，呵呵），可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一角，局限于具体技术细节，或某某著名网站大的框架，真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧。。
二、运维工作师需要什么样的技能及素质
作为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多IT工种技能与一身的岗位，对系统->网络->存储->协议->需求->开发->测试->安全等各环节都需要了解一些，但对于某些环节需熟悉甚至精通，如系统(基本操作系统的熟悉使用,*nix,windows..)、协议、开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理）、通用应用（如lvs、ha、web server、db、中间件、存储等。。。）、网络（至少要对应用所处网络环境非常了解）。
技能方面总结以下几点：
1、开发能力，这点非常重要，因为运维工具都需要自已开发，开发语言：c/c++（必备其中之一）、perl、python、php（其中之一）、shell（awk,sed,expect....等），需要有过实际开发经验，否则工作会非常痛苦。
2、通用应用方面需要了解：操作系统（目前国内主要是linux、bsd）、webserver相关(highttp,apahe,php,tomcat,java。。。)、数据库(mysql,oralce)、其它杂七八拉的东东。。。系统优化，高可靠性。。。这些只是加分项，不需必备，可以边工作边慢慢学，这些东西都不难。当然在运维中，有些是有分工偏重点不一样。如可能有专门的运维dba。
3、系统、网络、安全等需要有所了解，至少知道其原理。
个人素质方面：
1 沟通能力、团队协作：运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；这应该是现代企业的基本素质要求了，不多说了。。。
2 工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师是网站admin，最高线上权限者，一不小心就会遗憾终生或打入十八层地狱。。。
3 主动性、执行力、精力旺盛、抗压能力强：由于IT行业的特性，变化快；往往计划赶不上变化，运维工作就更突出了，比如国内各大公司服务器往往是全国各地，哪里便宜性价比高，就那往搬，进行大规模服务迁移（牵扯的服务器成百上千台），这是一个非常头痛的问题；往往时间非常紧迫，如限1周内完成，要命~~，这种情况下，运维工程师的主动性及执行力就有很高的要求了：计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯皮。。。7X24小紧急事故响应等。
4 其它就是一些基本素质了：头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观。
5 最后一点，做网站运维需要有探索创新精神，通过创新型思维解决现实中的问题，因为这是一个处于幼年的职业（国外也一样，但比国内起步早点），没有成熟体系或方法论可以借鉴，只能靠大家自已摸索努力。
三、怎样才算是一个合格的运维工程师
1、保证服务达到要求的线标准，如99.9%；保证线上稳定，这是运维工程师的基本责职所在。
2、不断的提升应用的可靠性与健壮性、性能优化、安全提升；这方面非常考验主动性、和创新思维。
3、网站各层面监控、统计的覆盖度，软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用的运转情况。
4、通过创新思维解决运维效率问题；目前各公司大部份运维主要工作还是依赖人工操作干预，需要尽可能的解放双手。
5、运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性犯错。
6、计划性和执行力；工作有计划，计划后想法设法达到目标，不找借口。
7、自动化运维；能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统；让大家更多的时间用于思考、创新思维、做自已喜欢的事情。
以上只是技术上的一些层面，当然个人意识也是很重要的。
四、运维职业的迷惘、现状与发展前景
运维岗位不像其它岗位，如网络工程师、系统工程师、安全工程师、研发工程师、测试工程师等，有非常明确的职责定位及职业规划，比较有职业认同感与成就感；而运维工作可能给人的感觉是哪方面都了解一些，但又都比上专职工程师更精通、感觉平时被关注度比较低（除非线上出现故障），慢慢的大家就会迷惘，对职业发展产生困惑,为什么会有这种现象呢？ 除了职业本身特点外，主要还是因为对运维了解不深入、做得不深入导致；其实这个问题其它岗位也会出现，但我发现运维更典型，更容易出现这个问题；
针对这个问题我谈一下网站运维的现状及发展前景（也在思考中，可能不太深入全面，也请大家斧正补充）
运维现状：
1、处于刚起步的初级阶段，各大公司有此专职，但重视或重要承度不高，可替代性强；小公司更多是由其它岗位来兼顾做这一块工作，没有专职，也不可能做得深入。
2、技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。
3、体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空间了。
4、优秀运维人才的极度缺乏。目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技术都局限在各大公司内部，如google 50万台机器如果科学的管理？或者国内top 10 的一些经验，这些经验是非常有价值的东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通、贯通、与借签，并最终将限制了运维发展。
5、很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量PV、硬件规模足够大，如baidu可怕的流量、海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大公司可能已有很好的解决方案或系统。
发展前景：
1、从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂；对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化。
2、从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视。
3、网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好的个人能力与技术广度的发展空间。
4、运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、全局思考能力等。
5、特长发控和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家。
6、如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做。
7、技术发展方向、网站/系统架构师。
五、运维关键技术点解剖（比较实际，现实中的案例）
1、 大规模集群管理问题：
首先我们先要明确集群的概念，集群不是泛指各功能服务器的总合，而是指为了达到某一目的或功能的服务器、硬盘资源的整合（机器数大于两台），对于应用来说它就是一个整体，目前常规集群可分为：高可用性集群（HA），负载均衡集群（如lvs），分布式储、计算存储集群（DFS，如google gfs ,yahoo hadoop），特定应用集群（某一特定功能服务器组合、如db、cache层等），目前互联网行业主要基于这四种类型；对于前两种类似，如果业务简单、应用上post操作比较少，可以简单的采用四层交换机解决（如f5、foundly），达到服务高可用/负责均衡的作用，对于资源紧张的公司也有一些开源解决办法如lvs+ha，非常灵活；对于后两种，那就考验公司技术实力及应用特点了，第三种DFS主要应用于海量数据应用上，如邮件、搜索等应用，特别是搜索要求就更高了，除了简单海量存储，还包括数据挖掘、用户行为分析；如google、yahoo就能保存分析近一年的用户记录数据，而baidu应该少于30天、soguo就更少了。。。这些对于搜索准备性、及用户体验是至关重要的。
接下来，我们再谈谈如何科学的管理集群，有以下关键几点：
I、监控
主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行，及潜在问题的及时发现与干预。
a、服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端web server，我们就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否crash、通过icmp包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，常用方法是采用面业特征码进行判断，或对重点页面进行签名，以网站被黑篡改（报警、并自动恢复被篡改数据）。。。这些只是一部份，还有N多监控方式，依应用特点而定，还有一些问题需解决，如集群过大，如何高性能的进行监控也是一个现实问题。。。。。
b、其它就是集群状态类的监控或统计，为我们合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击等问题。
II、故障管理
a、硬件故障问题；对于成百上千或上万机器的N多集群，服务器死机、硬件故障概率是非常大的，几乎每时每刻都有服务硬件问题，死机、硬盘损坏、电源、内存、交换机。。。针对这种情况，我们在设计网站架构时需要充分考虑到这些问题，并将其视为常态；更多的依靠应用的冗余机制来规避这种风险，但给系统工程师足够宽裕的处理时间。（如google不是号称同时死800台机器，服务不会受到任何影响吗）；这就是考验运维工程师及网站架构师功能的地方了，好的设计能达到google所描述自恢复能力，如gfs，糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映，直接对用户拒绝响应。
b、应用故障问题；可能是某一bug被触发、或某一性能阀值被超越、攻击。。。情况不一而定，但重要的一点，是要有对这些问题的预防性措施，不能想当然，它不会出问题，如真出问题了，如何应对? 这需要运维工程师平时做足功夫，包括应急响应速度、故障处理的科学性、备用方案的有效等。
III、自动化
自动化：简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手及枯燥的重复性劳动，例如：没有工具前，我们安装系统需要一台一台裸机安装，如2000台，可能需要10人/10天，搞烂N张光盘，人力成本更大。。。而现在通过自动化工具，只需几个简单命令就能搞定、还有如机器人类程序，自动完成以往每天人工干预的工作，使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是/非判断、优化选择等。。。这些好处非常明显不再多说。。。应该说，自动化运维是运维工程师职业化的一个追求，利私利公，虽然这是一个异常艰巨的任务：不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等。因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现。
2. 大并发网站的设计(1亿pv/天)：
网站架构设计中，非常重要的一个要素，就是确保架构的可扩展性、这是高并发网站的基石。往往，一个网站的大流量不是与生具来的，而是有一个积累的过程，最后变成巨无霸，包括google、yahoo这种全球流量大户，而在这个成长过程中所积累的经验才是最值得我们学习的，包括思考方式、问题解决、 改进过程。没有最好的架构设计方案，只有更好，因此在此不会给大家一个终极方案，在此介绍的这些经验，更多的是让大家真正掌握架构设计方法、理念、灵魂，并真正的能利用到实际中。为了让大家更易理解，我在此主题讨论中将会借用本版“jiang2798”贴的“google架构、youtube架构”等经典案例和大家分析一下，再谈谈一些通用性原则及技巧：
1) 负载均衡架构
2) 高性能中间件选择、优化
3) 架构扩展性问题
4) 应用设计、开发中的注意点
5) 数据的快速访问、要达
6) 数据库问题
7) 用户分地域优化
高并发架构需满足的一些因素、要点：
2.1负载均衡架构
首先网站前端需要采用负载均衡群集解决用户高并发的响应，目前常用方法包括：
1) squid反向代理，这也是各大网站常用的方法，包括sohu、sina ......
2) DNS轮循；
3) 采四层硬件设备，包括google、baidu 使用这种方式 ...... 对于lvs，小频道或不重要应用可以尝试使用，对于大流量、实时性要求高的网站目前还不成熟。
2.2 高性能中间件选择、优化
中间件选择、优化非常重要，当服务流量大于一定承度时，性能的稍微提升，对于整体硬件成本控制、服务的整体性能提升都是非常可观的。对于web server 目前常用的属apache，但apache 多进程(线程池)架构有一些缺点，进程频繁生成/注销系统开销大，特别当流量大时更是明显，对于应用逻辑简单的可以考虑lighttpd 采用单进程+epoll并发模式，效率高，但对多CPU支持有问题，但
可采用启多服务解决这个问题；如果由于应用架构原因必须使用apache，可考虑 apache module 性能比普通CGI成倍提升。其它原则，包括各中间件各版本测试、包括性能、安全上的考良，找到平衡点，不要太关注某一点因素，导致整体架构上出现隐 患，另外一点非常重要，那就中间件的参数优化，这些方面大家可以google、baidu上找找，比较多，但有个原则那就是需要根据服务器实际资源情况进 行优化，如httpd最大进程数设多大合适呢？有些朋友，就随手来个2048，觉得这样肯定不会再出现httpd由于进程阀值过低导致拒绝服务，但这有个 隐患，因为生成进程，是需要硬件资源的，当进程数达到一定承度，可能服务器内存会溢出，导致服务器crash，特别是内存消耗量大的应用。。。这样的案例很多，需谨记。
2.3 扩展性问题
扩展性对于高速发展期间的网站非常重要，大家可以经常在网上看到某某网站的发展励途，那简直就是一部进化史，过程曲折而痛苦。因此成熟的经验就非常重要了，扩展性可以从两个方面来看：网络系统上的扩展性及应用本身的扩展性，首先在网络上需层次分明，尽量扁平化，全网冗余不能存在故障点，尽量按业务类型进行划分网络结构(pv大小、优先级)防止互扰，重要的一点：网络设计中，简单就是美~~，在不影响扩展性的前提下，不要搞得太复杂；网络硬件资 源、机架位、IDC都需提前至少半年进行规划，这些规划的重要依据是公司业务发展的前景评估，这就体现公司的战略眼光了，包括是否需要外地IDC（依用户群体而定）；另外，选一个好点的IDC是非常必要的，否则就得疲于IDC迁移了，北京地区好IDC还是不少的：皂君庙（有点老了。）、土城、联通、 酒仙桥、
爱立信、互联世纪、奥运官方机房数字北京据说马上也能入驻了。。。当然了，有钱也能像google一样自已搞个IDC，国内谁有这个实力?
另一点就是应用本身的扩展性了，原则其实很简单，应用设计时应尽量确保应用的层次化、采用高性能的中间件、逻辑复杂及大数据量交互的功能尽量做成独立模块/后台、cache层、数据库分层（读/写操作分离），不要图前期简单直接将功能全部揉进前端CGI中，这很致命，随时都可能会遇到性能瓶颈、而且 毫无扩展性。。。当以上两点很好的解决后，现在唯一的问题就是每半年根据业务的PV增涨、新业务发展，预购服务器了。。。；当然了，对现有架构优化，性能提升才是根本解决之道，特别是现在全球经济不景气，大家都不好过，这就是运维工程师的责任了，优化再优化~~
2.4 应用设计、开发中的注意点
架构层设计好后，应用层设计就是我们重点关注对象了，这也是一个项目成功的关键，好的设计主要体现在：性能(高并发承载能力)、可扩展性、可维护、安全性（数据完整性、应用稳定性、前端应用安全如SQL注入）、模块冗余、负载均衡等等，技术点：线程池、epoll、TCP(长/短)连接的选择、功能模块的细化及后台化、模块冗余/负载均衡考虑(可扩展性)、高频数据cache缓存、数据分层、应用单故障点的解决(数据唯一性问题)等。。。
有两点要注意：
1) 应用设计时要允分考虑服务器、硬件设备甚基于IDC的不可靠性；也就是说我们在应用设计时需要考虑到应用运行过程中，随时都可能会有1~2 台服务器或更多服务器出现故障情况(网络故障, 灾难、攻击、停电((整个IDC全挂)))，如google GFS就是一个典型，我们不能将应用的稳定性寄托于硬件的稳定上，特别是门户型公司大部份采用的都是X86普通机型，服务器crash是家常便饭、随时随刻(当总量到一定量级时)，所以我们在做应用架构设计时需允分考虑这些问题发生时的对策，做到允分的冗余/负载均衡（这两点可统一），如多IDC间通过智能CDN的流控、单IDC应用模块多节点冗余/负载均衡等，即使某些应用由于特殊原因无法做到这点，也需允分考虑应急预案。。好的设计在这些突发情况下可以做到不用人工干预，当然难度也很大。。。记得前年李开复在北大演讲时说过：google一个IDC同时故障800台机器，不会影响到任何应用的正常响应（有点怀疑，可能是他挑选的某类服务器，呵呵）；
2) 大流量应用/模块中能不使用数据库就不要使用数据库, 下一节会讨论这方面问题。
3. 网站安全问题
网站安全是一个系统性工作，影响安全的因素也很多，如DDOS（最常见的）、应用漏洞、系统层面漏洞、内部安全流程漏洞等（人为失误），可以从以下几方面着手考虑:
3.1 网络层
首先在网络设计时需考虑到安全因素；在主干出口处，对非业务端口进行屏蔽（如非80端口全部屏蔽），对于非常规数据包进行限速，如icmp，udp等，但是需考虑主干设备性能，不能因为安全限制导致设备性能明显下降，需要做到平衡，否则又会出现一个新的隐患点；另一方面就是主干带宽要足够富余，做到冗余互备（vrrp、hsrp），以抵抗DDOS的所带来的带宽消耗（对于大型网站DOS随
时都存在，只是规模大小不一样），另外，现在部份4~7l硬件具有一定的syn代理功能，可以抵御一定规模的flood，但主要还得拼资源、带宽、硬件性能；另外，需做好主干数据镜像分析，对于一些有规律的攻击定位到特征、甚至是攻击源，进行针对性的防御。对于公司重点业务可以在网络层进行物理隔离，增强关键性业务的健壮性，甚至是将业务冗余分布至不同IDC，做到跨地域容灾（如地
震）。
3.2 系统层
系统层主要是操作系统安全加固、系统安全BUG解决、对非业务端口进行屏蔽、非业务软件清除、跟踪系统工具软件最新安全动态，并做到及时更新。特别是直接对外提供服务的服务器（处于外网），更需做好定期安全审查评估，由于一般公司服务器内网都是相通过，攻占一台外网机器可能会导致公司整个内网全暴露，很恐怖。
3.3 应用层面
应用方面安全就不多说了，主要是开发细节上需把好关，不留逻辑上的漏洞，并对上传接口严格控制、越界检查、SQL安全性考虑等，特别是对于用户具备上传接口的应用（如mail、bbs、blog、云计算等应用），漏洞是很多的；系统应用，如中间件也需做好相应的安全配置。。。不多说了，大家上网能馊到一大 堆。需要多关注网上关于自身网站安全漏洞方面的信息（或定期搜索），因为往往应用上的漏洞，都是用户先发现的，用户是最好的测试人员，发现后需第一时间修复，并对同类业务进行全面排查；对于特定重点页面也可以进行监控，并采用程序自动恢复主要页面（功能上如有问题，可显示业务升级提示），以免应用被攻破后 对公司形象造成影响。
3.4 内网安全管理
对于日常内网准入方面需有严格流程，统一入口，技术方面如vpn、rsa,securID（如sina就用的动态密钥）等，没有条件的也需定期更新入口密码。
3.5 安全巡查
偶尔由于人为失误会导致一些漏洞的出现，如由于工作需要临时变更了某些安全参数，但忘记开启。。。这个问题其实是最大的，往往出问题也多是人为失误，需要定期对全网关键安全点进行巡查；而且这也是404审计的一个重点，想必在sohu、sina、网易等美国上市公司里做安全的兄弟应该很有感触吧。
六. 论坛中对于本贴的精彩回复
6.1 jerryma: 运维部是网络工程师、系统工程师、安全工程师、测试工程师的集合。楼主所说的什么都会的运维工程师可能不会有很高的运维质量.
Veyron : 网络、系统、安全工程师应该是系统部的范畴，他们更多关注的是系统、网络层面，独立于上层应用，他们提供的是一个通用框架和规范；安全工程师也更多的是基于网络、系统的整体安全策略的制度与规范，如网络入口安全规划、系统层面的安全（如iptables通用规则、内核加固、通用工具的安全评估）、网络安全审计等等，基于应用层安全如逻辑上的bug/漏洞他们是鞭长莫及的，而运维是基于系统部工作的基础上，针对上层应用服务的岗位，就好像系统部提供的是一堆积木，而运维将他们组装成玩具；还有重要一点，我没有强调运维工程师什么都要会，但关联岗位工作一定要了解，否则会有困难，对某些方面需非常熟悉，并有自已的专攻，就像我正在写的运维技术讨论，全是运维工程师的核心职责及技术；另外，测试工程师更多是与开发紧密配合的岗位，与系统部更没联系了。
6.2 evil_knight : 呵呵，楼主把运维想的有些复杂了，至少网站架构你只有建议权，真正的设计者是架构师而不是你！你只是执行者！
Veyron : 这种情况在各公司还是很普遍的，主要是由于运维还不成熟（刚起步），或经验缺乏，只能做简单的执行者，而在网站设计、架构、开发中运维会没有发言权，这是正常现象。当然，我这里说的是一种比较理想的运维职业状态，也是一个奋斗方向吧.
6.3 chexyo: 感觉在混淆概念。LZ是不是可以亮下身份。你们的运维不包括NE? SA? DBA?
Veyron : 严格来说运维是包括dba的，当然有些公司的DBA比较独立，如淘宝，有专门的oralce DBA团队，而且也做得很牛。Sa是系统工程师，更多职责层面是服务器硬件的管理、资源分配，上面已有说明，另外，网络工程师也是相对独立的，很多公司这些职位是属于一个大点的部门如系统部；运维更多应该是介于系统与应用架构层之间~~~另外，NE()是什么？不好意思没弄明白。
6.4 evil_knight: 那个确实太理想化了，大多数运维都没有开发经验的，如果要达到你的这个理想状态，首先这个运维以前是一个开发者有c，web 的开发经验，非常熟悉unix类操作系统！而且基本就是一个项目的leader否则他没有这么强的架构经验的！而实际上，一个项目的leader很少懂得系统+网络+硬件的，不是没有，我们老大就是你文中所说的理想！在我看来，他的那种状态对我来说可望不可及！再一个到达你所说的这种理想，通常都是这个公司运维的头+技术顾问！
veyron : 关于你说的这几个问题：
1) 关于开发能力；c是应届生的基本能力，另外，基于c、web等中间件开发，不需要太多经验，更多是需要运维方面的经验；因为运维开发更多是基于运维工具辅助性开发，而不是线上产品，把握一些关键点就OK，如性能、易用性、可扩展性，当然如果是大的自动化管理平台还是需要开发能力更强的人来主导，但这是一个人才培养递队的问题，高低搭配，有基本运维人员、也有优秀运维人员，不能假设集体平庸化。另外，了解熟悉操作系统这是运维本职工作，必须的技能。
2) 你所说的项目leader应该是指线上产品项目；运维参与架构设计更多是运维相关、当然做得深入应用本身性能、架构优化也能给出建议（详请见正文，有说明）。
3) 对于职业的发展；大家可以发现，越向上发展，越会更加关注其一些理念及宏观层面的技能，如架构、技术、管理的全局性掌控技能，具体职业岗位区分会越来越模糊（正如没有谁关注CTO的以前的职业岗位一样，当然可能会关心行业的）。例如架构师可能出自褚多岗位的牛人，如网络、系统、开发等等，当然运维也能出架构师，只要做得足够深够广，到CTO也是有可能的。。。
4) 关于职业理想化，这应该是每个职业都有的大方向，不能自设天花板，否则会局限发展......
6.5 selinux : 看了这篇文章，忍不住想回复一下，呵呵。非常佩服veyron能够对运维的深度剖析。对运维已经达到一个比较高的认识了。个人猜测应该在几大门户网站工作，而且应该有3年以上的运维工作经验。大公司的运维和小公司的运维是有本质区别的。所以很多人对运维停留在不同的认识层面。很多大公司以前也是没有专门的应用运维职位，开始都是由开发人员同时承担运维的工作，由于没有那么大的精力，所以不可能做的深入，所以对业务的稳定性没有保障，随着工作的精细化分工，成立专门的部门 ......一个优秀的运维工程师的经验是在工作中磨练出来的 。。。不是一朝一夕的事情。一个优秀的网站运维工程师应该是一个复合型人才，对开发，操作系统，架构，安全，网络等都比较熟悉。veyron所说的门户网站运维在我们公司应该属于应用运维的范畴，门户网站运维兴起大概也就2，3年的时间，当时没有可以借鉴的东西，完全是在摸索中前进，当然，各个公司对岗位的命名有所不同，目前baidu，雅虎，腾讯，51，都设有应用运维的岗位。。。应用运维的工作和业务紧密挂钩，7×24小时服务，对业务的稳定性，健康度负责，对负责的业务而言相当于“管家”的角色，要和各个部门的人打交道。系统运维的工作则和操作系统紧密挂钩，不对应业务。网络运维则是偏向于网络规划，硬件防火墙，交换机，路由器等设备的管理，为业务部门提供支撑。IDC运维则偏向于IDC机房的运维，机器的上下架，硬件故障的处理等。安全运维则侧重于安全方面的事务，对公司的网络，服务器，产品等等的安全负责。大家可以继续讨论。希望不要看到对别人劳动成果的不尊重。。。这么好的一篇帖子，没必要打“口水战”，毕竟对运维的层面认识度不一样。
6.6 GNM : 谢谢lz的分享哈，终于明白点了，但对于运维自动化这块不是太明白啊，对于应用运维来说，如果日常工作全自动化了，还要运维做什么呢？
iamshiyu : 呵呵，自动化了，你才能抽出时间去考虑更大范围的运筹啊——构架的调整修改，业务规模的发展预测，还有最浪费精力和时间的各部门间扯皮的问题。我觉得理想的情况就是需要运维自己创造一个世界，并良好地操纵这个世界的一切，成为这个世界的上帝才行。上帝每天在考虑什么？当了上帝自然就知道了。
6.7 gehaijiang: 门户网站应用类运维工程师产生, 是架构缺陷导致的。没看明白应用运维有技术方向吗? 做什么呢? 上线, 写监控，了解各类系统等等, 应用运维必须找到方向了才行，否则越走越栽.
Veyron: 1) 同意，职业方向非常重要。其实说简单点，就是要划清岗位职责，光有职责还不够，还得有可以逐步实现但长远的职业梦想（打个不太恰当的比方，如蒙牛的理想是让全中国人每天喝上一斤牛奶，强壮一个民族）但不能太虚缈空洞~~，这样大家才会有阶段性的成就感，及长远的工作意愿，虽然对于一个新兴职业比较难，还得探索。，否则大家慢慢的会迷思在日常琐碎的工作中，看不到长远的个人发展方向，不明白自已工作的价值，进而迷失~~
2) 对于“上线，写监控，了解各类系统”这决不是运维的核心发展方向，只能说是技术要求，这些工作比较底层而且可替代性强，运维更重要的是运维经验及对应用架构的全局思维，知道如何更合理、高效、更优化的完成他职责范围内的工作，不流于型式，就好比你不会要求高级工程师和架构师具备这些技术，当然了这些基础技能对于日常具体工作执行还是非常必要的，如开发性能、安全性、可管理性方面质量高，但这不是方向，这只是满足岗位职责要求的一些具体的技能（这好比，招聘时会要求新人会c，php，新人来了后具备这些技能，再给他设计方案、步骤，几天他也能完成），包括自动化运维也是一样，它也只是运维的一个辅助工具，提高日常工作的执行效率而已。。。所以找到直正的职业方向才是根本。
3) 对于“门户网站应用类运维工程师产生, 是架构缺陷导致的” 这是由于设计、开发成熟度不够导致的问题，对于开发工程师，往往只关注功能实现及应用性能；这个问题我想首先需从开发层面找问题，由于这个缺陷直接导致运维职责的履行和绩效，可以双方共同制订规范化的流程，并由OP负责在设计、开发阶段，结合应用特点及规范给出架构设计方面的建议，如安全、性能、冗余性、及可管理性方面的问题，达不到规范要求，不能正式上线发布，并通过技术手段来强化这个规范，如定义应用-系统层接口~~~但实际操作上对运维的执行力是个挑战，这要看具体的公司文化了，有的公司研发非常强势~~
6.8 墟里烟: 鄙人目前就供职于楼主所说的门户中的其中一个做运维工程师。最初投的职位是开发，后来面试几轮后调到运维来（算法不过关，唉，非科班的致命点）。由于之前几乎没有涉足过运维（读大学时做过一段时间校园网的网管。嗯……尽管我所在的学校是教育网某核心节点，里面的网络设备和服务器我想一个职高的网管应该见都没见过吧，但我认为我所做的那还远远算不上运维），所以在入职之后一段时间一直没有找到自己的定位，最初的培训主要还是学习lamp以及研发所开发的模块功能和模块间的关联关系，也一度对这个职位的前景以及对自我技术能力的提升抱有怀疑，试想，如果你的工作仅仅是去了解研发开发出来的东西该怎样在线上run起来，那有什么意思呢？今天拜读这篇文章，觉得颇有意义，也很有深度，授人以渔总胜过授人以鱼吧，很多东西还值得去深思一下。回这个帖子一来是拜一下楼主，感谢一下楼主的无私和指导，二来是想问一点具体的问题，请不吝指教。
1) 您认为运维最核心的竞争力在哪儿？研发的核心竞争力已经很明显，能不能快速准确地完成项目要求，方向也很明确，从代码的规范、高效以及可维护方向去深入，然后到达系分。那么一个OP的核心竞争力呢？方向呢？
2) 研发的工作内容决定他们有许多的产出，总的来说，我觉得做出一个东西并且在线上run起来是一个很有成就感的事情（是的，我们的工作除了挣钱以外，满足自己的虚荣心不也是很重要的一点么？），而OP看起来更像是在维护他们的产出，那么，作为一个从小喜欢捣腾东西的人，我想知道OP怎样才能有自己的成就？怎样产出自己的想法和观点？打个比方，研发跳槽时会在简历里写到“参与开发XX产品”，那么，一个OP的呢？
PS：说我所认识的一个职高程序员的笑话，无笑话其学历的意思（我朋友中也有很强的职高程序员），仅仅是说一下某一层面的人的态度吧。
在年中曾遇到一个多年不见的朋友，问其现在做啥，答曰写程序做开发。大惊，该仁兄以前与我一同混迹于街舞圈中，按原我所在舞队的辈分来说算是我小弟的小弟（嗯，谁叫我是创始人呢…… ），多年以后我混迹于挨踢圈，没想到小弟们也跟过来了。然后与丫攀谈，问感想。丫说，就那么回事，写程序嘛，简单得很，像我这种人很快就学会了。然后再问其具体内容，答曰是做php开发，写网站。回问，我答做系统方面的东西，主要写C。伊一脸不屑的笑容，说，都啥年代了还写C。然后又聊数句，伊恍然大悟：哦，我晓得了，唉，我们的方向就完全不同，你是做低层（不是底层－－笔者注）开发的，我是做高级开发的。然后伊很牛叉状地问我：你有没有听说过phpcms？我们就拿那个来改，简单得很，套个模板，要是还差什么功能到网上一搜拷下来就行了。什么论坛啊博客啊图片啊都有。而且像我这种很熟悉的人就更快了，一个网站两三天就搞定了。然后我就问他能不能做出新浪搜狐之类的网站，他不屑地说，他们人多嘛，要是多给我点时间我也能做出来，唉，不过我比
较懒，不想做。然后我就谈起我面试，问了他一个简单问题，如何在100万个数中找出最大的100个。然后他想了一下说不晓得。
我说，肯定要排序是吧？
他说，肯定嘛，要不你咋知道哪个大？
我问，怎么排呢？
他说，简单噻，调个函数就排了。
我说，如果要你自己写呢？
他说，都有现成的了谁还自己写啊，吃饱了撑的。
我说，嗯，可能要改，不能用现成的，现成的速度达不到。那个，排序的话，嗯，冒泡你会吧？
他说：冒泡？好像听说过，不过记不太清楚了。
以下省略我费劲地从冒泡到快排到单边快排的讲解，最后给出解法。他恍然，然后一笑：哪个公司问这么无聊的问题啊？真是吃饱了撑的。这有什么用？最后我问了一下他的薪水，他答后反问我，我说，大概是你的十倍左右吧。他默然了一会儿，说，唉，公司有钱就是不一样，哥们儿你过去好好混，过两年把我也介绍到你们公司去……唉，不过太远了，我也不想跑那么远……
veyron : 1) 您认为运维最核心的竞争力在哪儿？研发的核心竞争力已经很明显，能不能快速准确地完成项目要求，方向也很明确，从代码的规范、高效以及可维护方向去深入，然后到达系分。那么一个OP的核心竞争力呢？方向呢？
2) 研发的工作内容决定他们有许多的产出，总的来说，我觉得做出一个东西并且在线上run起来是一个很有成就感的事情)是的，我们的工作除了挣钱以外，满足自己的虚荣心不也是很重要的一点么？），而OP看起来更像是在维护他们的产出，那么，作为一个从小喜欢捣腾东西的人，我想知道OP怎样才能有自己的成就？怎样产出自己的想法和观点？打个比方，研发跳槽时会在简历里写到“参与开发XX产品”，那么，一个OP的呢？
这两个问题可以结合来看，而且互为依存，重点在于，我们先要找到运维的技术发展方向：运维核心竞争力<=技术发展方向，比较理想的发展路线：科学合理的技术方向-->深入研究-->技术实际应用（个人技术、价值上会有成就感，简历上也能体现了）--> 产生收益（与公司期望相符），周而复始，不断完善。。。这个过程就是岗位价值、核心竞争力的体现了，在这个过程中个人也会得到满足；当然了运维可能没有研发成就感那么外象、明显，但即使研发，目前比较大的公司也有慢慢细化的趋势：算法研究、业务模型研究、公用组件开发。。。最后到产品实际开发时，可能就是拿着设计文档，玩垒积木、批量生产的游戏了（外包、东软。。），对于成就的定义，观念上得改变。。。说到具体，对于运维这方面的迷惑。
我总结有两方面因素：
1) 应用运维刚起步，发展大方向大家还没看明白，需要我们解决。
2) 职责定位导致了技术方向的迷失；运维在技术发展及职责分工上处于应用与系统之间，从技术发展角度来看，通常会从两边发展（软、硬），但当达到一定的深度后必然会与其它专职岗位的研究方向发生重合（开发、系统研究（内核、储存、安全。。），由于职责关系，这些方面不可能比专职岗位做得更深入~~~，在各方面都不能深入的情况下，运维工作只能靠问题/事件来驱动，做的都是技术含量低、重复性、高可替代等没有成就感的工作。。。没有技术研究方向，没有创造性，谈何竞争力？成就感？
运维发展迷图：
$光明、价值、成就感$ <-----应用 <---应用运维---> 系统-------> $成就感、价值、光明$
6.9 xuwanbest : 运维这个行业本身并不年轻，在传统企业运维已经非常成熟，技术方向也很明确：操作系统、web服务/中间件、数据库、存储、备份、安全、应用解决方案等等。这些方向在小公司也许也是一人包揽即所谓的全才，而在大公司则分工清晰各有专攻同时将运维划分为维护和项目实施两部分，维护再按级别划分，让运维不再是7×24小时的代言。既然传统行业的运维已经这么清晰，那么为什么互联网的运维还这么让人有些琢磨不透呢？
我认为原因如下：
1) 互联网年轻
2) 互联网的业务发展太迅猛
3) 互联网企业本身的闭塞性；
原因就不具体展开了，主要说说解决吧,也是自己目前的想法，欢迎讨论。
解决:
1) 分工的问题
互联网企业最初从一个小公司起家的时间并不长，最长的现在不过10年，而运维往往又滞后于业务本身，所以小公司的全才型人物还没有完全分解。但是分工是解决所有问题的唯一方法，是迈向真正大而强公司的途径。至于如何分工，则要结合每个公司各自的业务特点、相关流程会各有不同；
2) 运维的自动化
互联网运维的终极目标是完成业务实现的自动化。其实这和传统企业也是相似的：如何使得业务的运作自动化，并促进业务的发展。传统企业这方面的工作开展的较早，IT部门就是这个职责，目前针对不同的行业比如银行、制造业、电信等等，都有对应的业务自动化解决方案：ERP/MRP/BIS等等，再加上第三方（IBM/SAP...）的支持，业务自动化已经开始成熟。而作为当下互联网公司由于是个新兴的行业，目前业务的运作还停留在手工阶段，所以我们当下运维工程师的职责就是沉淀自身的经验创建并推动自动化平台的逐渐成熟。每个公司的自动化平台可能也不一样，这也和各个公司的业务特点、相关流程有关系，但框架是一样的，所以未来也许会有互联网公司咨询、解决方案一职。
如何应对当下的迷茫：
年轻人，拿好工资就要做好当下，其实很多知识是在工作的冥冥中自然掌握的。其实当你熟悉了这些别人看起来很神奇的业务架构时是多么让人羡慕啊！同时要相信运维这个行业是有前途的，起码我是有信心的那我们如何解决这个问题呢？ 今天不早了，就先聊到这里，随后有时间我们可再深入探讨，希望大家也都来谈谈自已的见解
veyron: 同意LS的观点，我归纳为三点:
1) 运维需要合理分工，细化
2) 需要通过自动化提高效率
3) 做好当下（关注细节）、并对运维的前途要有信心，积累经验....这些在正文中我也有所提及~~~，其中运维自动化属于运维的技术发展方向之一：提高运维效率/质量、减少运维中间环节及人力成本；其它两方面更多是运维组织优化、管理上需要关注的问题~~~但对于更深层的技术方向，还需结合运维职责本身来想办法：服务稳定的保障、应用/集群系统的可管理化、硬件资源合理化/性价比提升、用户体验优化。。。结合这些职责，技术方向可进一步细化，如性能、架构优化、安全、中间件/缓存技术、数据库、监控、自动化系统研究等等~~~这些方面可以做得足够深入，对于个人发展提升也是非常好的，如系统开发、数据库、中间件等技能。。。另外，对于我上面提到的那种各岗位技术方向冲突问题，主要体现在公司岗位、部门细化后职责重叠现象，随着大家对技术的研究深入，特别是对于收益明显的研究方向，会出现技术、方向上的重叠，如何协调好这个问题，就要体现公司BOSS层的智慧了。
七、 其它对运维相关参考贴子:
[1] 从IDC到站点—运维经验交流: http://bbs3.chinaunix.net/thread128488911.html
[2] YouTube 架构 : http://bbs.chinaunix.net/thread128045912.html
[3] sina,sohu等门户级网站架构设计(ZT): http://bbs.chinaunix.net/thread129114111.html
[4] Google架构: http://bbs.chinaunix.net/thread128046014.html