技术文章(牛)

对于网站运维，感觉大家还是比较迷惘与不解，确实，这是一个新兴岗位；近来闲而无事，在此结合自已以往的一些经历，与大家先共同探讨一下“什么是门户网站运维”？ 以下是自已的一些经验和感受请大家斧正，希望和大家一起探讨，共同进步
一、什么是门户网站运维
首先明确一下，全文所讲的”运维“是指：门户网站应用运维，与其它运维如网络、系统的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上千万（至少国内排名前20），如sina、alibaba、sohu、baidu、网易等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如本版有些同僚将公司的合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责，这是网络工程师的工作，我们就不要抢人家饭碗了，但是，非常重要一定需要明白：网站应用运维对其它关联工种必须非常了解熟悉：网络运维、系统运维、应用开发、内容；但这些非自已的本职工作，我在这里所讲的运维工程师就是指专职应用运维工程师
   我们再来说说一个般产品的“出生”流程：
1、首先公司BOSS层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计
2、开发工程师将设计code实现出来、测试工程师对应用进行测试（同一产品事业部）
3、网络\系统工程师根据产品设计的需求，如pv大小预估、服务器规模、应用架构等因素完成网络规划及设备上的调整（基本上对网络变动不大，除非大项目）、SA系统工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装

4、好，到运维工程师出马了，首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大：应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能\安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复使：需求->开发（升级）->测试->上线（性能、安全问题等之前预估外的问题随之慢慢就全出来了）在这里提一点：网站开发模式与传统软件开发完全不一样，网站一天开发上线1~5个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像M$需要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、如我上面所讲，目前门户网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，我相信大家也讲不出所以然来（我现在也中抓破脑袋挤出这点字，呵呵），可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一角，局限于具体技术细节，或某某著名网站大的框架，真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧。。


续。。。。10月6日


二、运维工作师需要什么样的技能及素质

    做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多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、自动化运维；能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统；让大家更多的时间用于思考、创新思维、做自已喜欢的事情。


更新。。。10月7日

四、运维职业的迷惘、现状与发展前景
     应用运维不像其它岗位，如网络、系统、安全运维岗位及研发工程师、测试工程师等，有非常明确的职责定位、职业规划、社会认同、比较有职业成就感；而应用运维工作可能给人的感觉是系统/应用哪方面都了解一些，但又都比上专职工程师更精通、感觉平时被关注度比较低（除非线上出现故障），慢慢的大家就会迷惘，对职业发展产生困惑,为什么会有这种现象呢？ 除了职业本身特点外，主要还是因为对运维了解不深入、做得不深入导致、新职位还没得到社会广泛认知及认同；其实这个问题其它岗位也会出现，但我发现运维更典型，更容易出现这个问题；

针对这个问题我谈一下网站运维的现状及发展前景（也在思考中，可能不太深入全面，也请大家斧正补充）

运维现状：
1、处于刚起步的初级阶段，各大公司有此专职，但重视或重要承度不高，可替代性强，工作职责也有所不同；小公司更多是由其它岗位来兼顾做这一块工作，没有专职，也不可能做得深入
2、技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。
3、体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空间了
4、优秀运维人才的极度缺乏；目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技术都局限在各大公司内部，如google 50万台机器如果科学的管理？或者国内top 10 的一些经验，这些经验是非常有价值的东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通、贯通、与借签，并最终将限制了运维发展。
5、很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量PV、硬件规模足够大，如baidu可怕的流量、海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大公司可能已有很好的解决方案或系统


发展前景：
1、从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂；对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化
2、从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视
3、网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好的个人能力与技术广度的发展空间
4、运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、全局思考能力等
5、特长发控和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家
6、如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做
7、技术发展方向、网站/系统架构师

续。。。。10.8

五、运维关键技术点解剖（比较实际，现实中的案例，今天先想出这几条，如大家有其它感觉兴趣的，可以提出，我来解答）
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变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等。。。。。。因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现

10月13日更新。。。。

2 大并发网站的设计

        网站架构设计中，非常重要的一个要素，就是确保架构的可扩展性、这是高并发网站的基石。往往，一个网站的大流量不是与生具来的，而是有一个积累过程~~最后变成巨无霸，包括google、yahoo这种全球流量大户，而在这个成长过程中所积累的经验才是最值得我们学习的，包括思考方式、问题解决、改进过程。没有最好的架构设计方案，只有更好。。。，因此在此不会给大家一个终极方案。。。，在此介绍的这些经验，更多的是让大家真正掌握架构设计方法、理念、灵魂，并真正的能利用到实际中。为了让大家更易理解，我在此主题讨论中将会借用本版”jiang2798 “贴的"google架构、youtube架构"等经典案例和大家分析一下，再谈谈一些通用性原则及技巧

高并发架构需满足的一些因素、要点：
I    负载均衡架构
    首先网站前端需要采用负载均衡群集解决用户高并发的响应，目前常用方法包括 a、squid反向代理，这也是各大网站常用的方法，包括sohu、sina...；b、DNS轮循；c、采四层硬件设备，包括google、baidu使用这种方式。。。对于lvs，小频道或不重要应用可以尝试使用，对于大流量、实时性要求高的网站目前还不成熟。

II   高性能中间件选择、优化
    中间件选择、优化非常重要，当服务流量大于一定承度时，性能的稍微提升，对于整体硬件成本控制、服务的整体性能提升都是非常可观的。对于web server 目前常用的属apache，但apache 多进程(线程池)架构有一些缺点，进程频繁生成\注销系统开销大，特别当流量大时更是明显，对于应用逻辑简单的可以考虑lighttpd 采用单进程+epoll并发模式，效率高，但对多CPU支持有问题，但可采用启多服务解决这个问题；如果由于应用架构原因必须使用apache，可考虑apache module 性能比普通CGI成倍提升。。。其它原则，包括各中间件各版本测试、包括性能、安全上的考良，找到平衡点，不要太关注某一点因素，导致整体架构上出现隐患，另外一点非常重要，那就中间件的参数优化，这些方面大家可以google、baidu上找找，比较多，但有个原则那就是需要根据服务器实际资源情况进行优化，如httpd最大进程数设多大合适呢？有些朋友，就随手来个2048，觉得这样肯定不会再出现httpd由于进程阀值过低导致拒绝服务，但这有个隐患，因为生成进程，是需要硬件资源的，当进程数达到一定承度，可能服务器内存会溢出，导致服务器crash，特别是内存消耗量大的应用。。。这样的案例很多，需谨记

10.16 续。。。

III  扩展性问题
     扩展性对于高速发展期间的网站非常重要，大家可以经常在网上看到某某网站的发展励途，那简直就是一部进化史，过程曲折而痛苦~~。因此成熟的经验就非常重要了，扩展性可以从两个方面来看：网络系统上的扩展性及应用本身的扩展性，首先在网络上需层次分明，尽量扁平化，全网冗余不能存在故障点，尽量按业务类型进行划分网络结构(pv大小、优先级)防止互扰，重要的一点：网络设计中，简单就是美~~，在不影响扩展性的前提下，不要搞得太复杂；网络硬件资源、机架位、IDC都需提前至少半年进行规划，这些规划的重要依据是公司业务发展的前景评估，这就体现公司的战略眼光了，包括是否需要外地IDC（依用户群体而定）。。。；另外，选一个好点的IDC是非常必要的，否则就得疲于IDC迁移了，北京地区好IDC还是不少的：皂君庙（有点老了。）、土城、联通、酒仙桥、爱立信、互联世纪、奥运官方机房数字北京据说马上也能入驻了。。。当然了，有钱也能像google一样自已搞个IDC，国内谁有这个实力?
     另一点就是应用本身的扩展性了，原则其实很简单，应用设计时应尽量确保应用的层次化、采用高性能的中间件、逻辑复杂及大数据量交互的功能尽量做成独立模块\后台、cache层、数据库分层（读/写操作分离），不要图前期简单直接将功能全部揉进前端CGI中，这很致命，随时都可能会遇到性能瓶颈、而且毫无扩展性。。。
      当以上两点很好的解决后，现在唯一的问题就是每半年根据业务的PV增涨、新业务发展，预购服务器了。。。；当然了，对现有架构优化，性能提升才是根本解决之道，特别是现在全球经济不景气，大家都不好过，这就是运维工程师的责任了，优化再优化~~

10.23 续。。。

IV  应用设计、开发中的注意点
    架构层设计好后，应用层设计就是我们重点关注对象了，这也是一个项目成功的关键，好的设计主要体现在：性能(高并发承载能力)、可扩展性、可维护、安全性（数据完整性、应用稳定性、前端应用安全如SQL注入。。。）、模块冗余、负载均衡等等，技术点：线程池、epoll、TCP(长/短)连接的选择、功能模块的细化及后台化、模块冗余/负载均衡考虑(可扩展性)、高频数据cache缓存、数据分层、应用单故障点的解决(数据唯一性问题)等。。。有两点要注意：1、应用设计时要允分考虑服务器、硬件设备甚基于IDC的不可靠性；也就是说我们在应用设计时需要考虑到应用运行过程中，随时都可能会有1~2台服务器或更多服务器出现故障情况(网络故障、灾难、攻击、停电((整个IDC全挂))。。。)，如google GFS就是一个典型，我们不能将应用的稳定性寄托于硬件的稳定上，特别是门户型公司大部份采用的都是X86普通机型，服务器crash是家常便饭、随时随刻(当总量到一定量级时)，所以我们在做应用架构设计时需允分考虑这些问题发生时的对策，做到允分的冗余/负载均衡（这两点可统一），如多IDC间通过智能CDN的流控、单IDC应用模块多节点冗余/负载均衡等，即使某些应用由于特殊原因无法做到这点，也需允分考虑应急预案。。好的设计在这些突发情况下可以做到不用人工干预，当然难度也很大。。。记得前年李开复在北大演讲时说过：google一个IDC同时故障800台机器，不会影响到任何应用的正常响应（有点怀疑，可能是他挑选的某类服务器，呵呵）；2、大流量应用/模块中能不使用数据库就不要使用数据库，下一节会讨论这方面问题

V   数据库问题
VI   用户分地域优化

3 高可靠性问题解决
4 网站安全问题
5 海量数据存储、统计分析方案、架构
五、运维关键技术点解剖
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变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等。。。。。。因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现
网络、系统、安全工程师应该是系统部的范畴，他们更多关注的是系统、网络层面，独立于上层应用，他们提供的是一个通用框架和规范；安全工程师也更多的是基于网络、系统的整体安全策略的制度与规范，如网络入口安全规划、系统层面的安全（如iptables通用规则、内核加固、通用工具的安全评估）、网络安全审计等等，基于应用层安全如逻辑上的bug\漏洞他们是鞭长莫及的，而运维是基于系统部工作的基础上，针对上层应用服务的岗位，就好像系统部提供的是一堆积木，而运维将他们组装成玩具；还有重要一点，我没有强调运维工程师什么都要会，但关联岗位工作一定要了解，否则会有困难，对某些方面需非常熟悉，并有自已的专攻，就像我正在写的运维技术讨论，全是运维工程师的核心职责及技术；
    另外，测试工程师更多是与开发紧密配合的岗位，与系统部更没联系了
4 网站安全问题

网站安全是一个系统性工作，影响安全的因素也很多，如DDOS（最常见的）、应用漏洞、系统层面漏洞、内部安全流程漏洞等（人为失误），可以从以下几方面着手考虑:
1、网络层，首先在网络设计时需考虑到安全因素；在主干出口处，对非业务端口进行屏蔽（如非80端口全部屏蔽），对于非常规数据包进行限速，如icmp，udp等，但是需考虑主干设备性能，不能因为安全限制导致设备性能明显下降，需要做到平衡，否则又会出现一个新的隐患点；另一方面就是主干带宽要足够富余，做到冗余互备（vrrp、hsrp），以抵抗DDOS的所带来的带宽消耗（对于大型网站DOS随时都存在，只是规模大小不一样），另外，现在部份4~7l硬件具有一定的syn 代理功能，可以抵御一定规模的flood，但主要还得拼资源、带宽、硬件性能；另外，需做好主干数据镜像分析，对于一些有规律的攻击定位到特征、甚至是攻击源，进行针对性的防御。对于公司重点业务可以在网络层进行物理隔离，增强关键性业务的健壮性，甚至是将业务冗余分布至不同IDC，做到跨地域容灾（如地震）
2、系统层
    系统层主要是操作系统安全加固、系统安全BUG解决、对非业务端口进行屏蔽、非业务软件清除、跟踪系统工具软件最新安全动态，并做到及时更新。特别是直接对外提供服务的服务器（处于外网），更需做好定期安全审查评估，由于一般公司服务器内网都是相通过，攻占一台外网机器可能会导致公司整个内网全暴露，很恐怖
3、应用层面
    应用方面安全就不多说了，主要是开发细节上需把好关，不留逻辑上的漏洞，并对上传接口严格控制、越界检查、SQL安全性考虑等，特别是对于用户具备上传接口的应用（如mail、bbs、blog、云计算等应用），漏洞是很多的；系统应用，如中间件也需做好相应的安全配置。。。不多说了，大家上网能馊到一大堆。需要多关注网上关于自身网站安全漏洞方面的信息（或定期搜索），因为往往应用上的漏洞，都是用户先发现的，用户是最好的测试人员，发现后需第一时间修复，并对同类业务进行全面排查；对于特定重点页面也可以进行监控，并采用程序自动恢复主要页面（功能上如有问题，可显示业务升级提示），以免应用被攻破后对公司形象造成影响
4、内网安全管理
    对于日常内网准入方面需有严格流程，统一入口，技术方面如vpn、rsa,securID（如sina就用的动态密钥）等，没有条件的也需定期更新入口密码
5、安全巡查
    偶尔由于人为失误会导致一些漏洞的出现，如由于工作需要临时变更了某些安全参数，但忘记开启。。。这个问题其实是最大的，往往出问题也多是人为失误，需要定期对全网关键安全点进行巡查；而且这也是404审计的一个重点，想必在sohu、sina、网易等美国上市公司里做安全的兄弟应该很有感触吧


二、运维工作师需要什么样的技能及素质
    做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多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、关于开发能力；c是应届生的基本能力，另外，基于c、web等中间件开发，不需要太多经验，更多是需要运维方面的经验；因为运维开发更多是基于运维工具辅助性开发，而不是线上产品，把握一些关键点就OK，如性能、易用性、可扩展性，当然如果是大的自动化管理平台还是需要开发能力更强的人来主导，但这是一个人才培养递队的问题，高低搭配，有基本运维人员、也有优秀运维人员，不能假设集体平庸化。另外，了解熟悉操作系统这是运维本职工作，必须的技能
2、你所说的项目leader应该是指线上产品项目；运维参与架构设计更多是运维相关、当然做得深入应用本身性能、架构优化也能给出建议（详请见正文，有说明）
3、对于职业的发展；大家可以发现，越向上发展，越会更加关注其一些理念及宏观层面的技能，如架构、技术、管理的全局性掌控技能，具体职业岗位区分会越来越模糊（正如没有谁关注CTO的以前的职业岗位一样，当然可能会关心行业的）。例如架构师可能出自褚多岗位的牛人，如网络、系统、开发等等，当然运维也能出架构师，只要做得足够深够广，到CTO也是有可能的。。。
4、关于职业理想化，这应该是每个职业都有的大方向，不能自设天花板，否则会局限发展。。。
pv 是指单位时间内网站访问量的总和，如一天之内；并发数指在1秒内网站所接收用户请求数总和
1、您认为运维最核心的竞争力在哪儿？研发的核心竞争力已经很明显，能不能快速准确地完成项目要求，方向也很明确，从代码的规范、高效以及可维护方向去深入，然后到达系分。那么一个OP的核心竞争力呢？方向呢？

2、研发的工作内容决定他们有许多的产出，总的来说，我觉得做出一个东西并且在线上run起来是一个很有成就感的事情（是的，我们的工作除了挣钱以外，满足自己的虚荣心不也是很重要的一点么？），而OP看起来更像是在维护他们的产出，那么，作为一个从小喜欢捣腾东西的人，我想知道OP怎样才能有自己的成就？怎样产出自己的想法和观点？打个比方，研发跳槽时会在简历里写到“参与开发XX产品”，那么，一个OP的呢？


这两个问题可以结合来看，而且互为依存，重点在于，我们先要找到运维的技术发展方向：运维核心竞争力<=技术发展方向，比较理想的发展路线：科学合理的技术方向-->深入研究-->技术实际应用（个人技术、价值上会有成就感，简历上也能体现了）-->产生收益（与公司期望相符），周而复始，不断完善。。。这个过程就是岗位价值、核心竞争力的体现了，在这个过程中个人也会得到满足；当然了运维可能没有研发成就感那么外象、明显，但即使研发，目前比较大的公司也有慢慢细化的趋势：算法研究、业务模型研究、公用组件开发。。。最后到产品实际开发时，可能就是拿着设计文档，玩垒积木、批量生产的游戏了（外包、东软。。），对于成就的定义，观念上得改变。。。说到具体，对于运维这方面的迷惑，我总结有两方面因素：1、应用运维刚起步，发展大方向大家还没看明白，需要我们解决；2、职责定位导致了技术方向的迷失；运维在技术发展及职责分工上处于应用与系统之间，从技术发展角度来看，通常会从两边发展（软、硬），但当达到一定的深度后必然会与其它专职岗位的研究方向发生重合（开发、系统研究（内核、储存、安全。。），由于职责关系，这些方面不可能比专职岗位做得更深入~~~，在各方面都不能深入的情况下，运维工作只能靠问题/事件来驱动，做的都是技术含量低、重复性、高可替代等没有成就感的工作。。。没有技术研究方向，没有创造性，谈何竞争力？成就感？

运维发展迷图：
$光明、价值、成就感$                   <-----应用    ？<---应用运维--->？        系统------->                      $成就感、价值、光明$            
1万台机器如何在1分钟内完成密码修改、或运行指定任务？
简单的处理办法可以使用expect等工具批量解决；如果机器数量很大，需自已写程序（多线程、高并发）进行修改即可，处理能力依机器配置及规模而定

2000台服务器如何快速安装操作系统？
这个问题做系统运维的人应该很了解，目前大部份产商都支持远程批量系统安装

各分布式IDC、存储集群中数BT级的数据如何快速的存储、共享、分析？
IT互联网行业一般采用分布式存储架构，优点在于：扩展性好、节点便宜（x86），如google dfs；有钱的可以直接选存储设备
我觉得运维的核心竞争力（个人）在于，当然这很有可能不是在说工程师

1.全局的架构能力，这其中包括技术的广度和深度，如果有影响力或直接权力的话可以领导新技术在本公司IT架构中的采用和实现，有把商业逻辑翻译为技术实现物的能力

2.必要的管理知识，例如ITIL（ISO20000）是IT治理中最适合运维的一个参照物，其他还有很多比如ISO27001，17799等

3.想往上走的人必须要能带团队

4.熟悉公司的架构和业务

5.沟通能力，有些人觉得是扯皮，其实语言只是个表面形式，实质反应的是一个人的思维逻辑和情商。例如在一个大型互联网公司，纯技术型的思维不适合与其他部门的总监去对话，没有财务思维，不懂公司政治的人也很难成为技术总监或CTO

以下是个人观点，我说的只是我自己的想法，也是我发展的目标。你可以有异议，我们是来交流的。你对的我肯定会向你学习。因为我也在摸索。运维工程师至少要能做以下的工作
1，网络工程师的工作    你至少要能配置CISCO 6509以下的设备，熟悉各种网络协议，否则网络出问题的时候你会傻掉。
2，系统工程师的工作    你至少要理解各种系统服务，在出问题的情况下要迅速解决问题，而不是等系统工程师来解决。
3，安全工程师的工作    我不要求你一定要会各种网络编程，但是在服务器收攻击的情况下，没有防火墙的情况下，做一些简单的处理工作。
4，存储工程师的工作    至少要熟悉各个厂商的设备，各种备份和还原的办法
5，测试工程师的工作    在新版本上线之前，你至少要协同测试工程师做测试工作，因为你是运维人员，不了解程序架构导致无法解决故障，你也有一份责任。
6，研发人员的工作      运维工具都需要自已开发，熟悉开发语言，需要有过实际开发经验，否则工作会非常痛苦，我深有体会。
7，英语               不想说了，我的最大痛苦就在这里
8，好的沟通者         不出问题时候你可以打游戏睡觉，出问题的时候要能和项目人员沟通，快速解决问题，而不是推；我知道有很多人能推责任，你可以做替死鬼，但是离开这个工作你还能找到更好的；把责任推到别人身上的人，下次出问题的时候，绝对没人帮你。你要能和各个兄弟部门关系非常的密切，出了问题有兄弟帮你担责任；也要能非常扯皮，没事在会议上把别人都搞定。
9，库房管理员         数万台服务器让你来管理，任何丢失或者损坏都是不负责任和失职的表现。
10，运动员            不要回家就睡觉，有空还是运动下吧；在服务器down机的时候，机房恰巧就你一个人，机柜没有空间，你需要更换一台HP 585 4U的服务器，满配约80公斤的服务器，你怎么做？
11，责任心            这个我不想说什么，这是你的职业精神。
12，组织者            给你2个啥都不会的民工，再给你2000台服务器，要求你2天把服务器装完，你咋办？
13，1－7条中，你必须有一条非常精通，是这个行业的专家。否则过了32岁，没有公司要你。

大家看了肯定觉得这个人是神仙，但是这必须是你慢慢能做到的，至少是我6年来运营经验的一点总结。
因为现在的公司都在用招聘民工的钱招聘神仙，其次我也是想让各位看看，运维工程师要担负多少责任。
我去面试过的一些公司都说，你什么都会，什么都不精。我说对，正是需要我们这些什么都会的人领导什么都精的人。
我这句话没有贬低大牛的任何意思，只是当时一个临场的发挥。虽然说完就知道这个面试白来了，但是我还是想为广大的运维工程师出口气。
不怕千招会，就怕一招精。这仍旧是我给大家的建议。

风吹云动兄http://bbs.gehoo.cn/ 说的好，不要抱怨，每个行业都有自己的苦处，没有什么值得抱怨的，所以我删除了运维中的这一小节，重新发帖。
只是想让那些身居高岗的老大们看看我们的员工都是多么的辛苦。虽说抱怨的始终是做不好的，那么我只能用风吹云动兄的话说：“做啥都行，千万别做超人”，做超人要有超人的能力。能力有多大，责任就有多大。身在这个职位就要对这个职位负责。

一句话令我茅塞顿开

不抱怨了～


以下是一些实际经验，发给大家做参考，有任何问题可以mail我，[e-mail]
有的东西是企业机密，我不能透露也不能给你相关文档。
一，架构设计
现在你要做的，就是设计你的服务器架构和网络架构。这要先看你的网站是做什么的，每日有多少的人数访问，
例如，我打算站点初期每日有20000左右的访问量，和1000人所有的并发量。我可以用我的人数并发量1000×站点中每个页面的平均大小200k×每个访问用户可能要打开4个网页＝800 000k=800M的网络流量（当然这个数字肯定是非常的过分，至于为啥，自己可以想下）
然后可以用测试环境用软件检测在你的真实环境下的服务器压力，比如在2000人在线的情况下，服务器的cpu占用多少，内存占用多少。
那么你可以得到你大致配置，其实市面上的标准服务器配置都足够你用了，比如现在的DELL 1950,HP DL360G5,IBM X？？？（忘记了）
等服务器，足够我跑一个这样简单的网站。其实说白了，双奔3都够，真的。当然你网站的流量比我要大的多，那你可以买的更好一点的服务器。或者负载均衡器。

网络架构
站点现在是一台独立服务器，未来采用的是分布式架构，比如bbs.hilinux.com是一台服务器，man.hilinux.com是一台服务器...
mysql是一台服务器。这样你要算服务器要多少台，交换机要多少口，防火墙要买什么级别的。
那些服务器可以放在一个防火墙下，哪些服务器不用防火墙保护，哪些服务器是内网服务器，
需要什么样的网络连接，最好是画出大致拓扑，方便你预算设备花费。

服务器交换机等设备选型和购买
说的简单点就是买什么机器，你可以和google一样开始，买几台pc作为你的网站服务器，也可以自己组装一台服务器
或者也可以和我一样，去挑选品牌服务器当然，现在你要看你服务器做什么的，
你可以亲自去电脑城看组装服务器，也可以打电话到IBM,HP,DELL的各地销售商让他们送服务器来测试，
当然你不要告诉他们你只买一台，那你就别指望测试了。我告诉供货商hilinux.com需要200台服务器，一个F5，10台CISCO 2960交换机，3个NETSREEN206防火墙，一个EMC CX500+满硬盘
那么不到3天，hilinux.com所需要的4台测试服务器，就送来了。。。当然，不要牛了这么多最后只买1台，那么你晚上走夜路会被人打的。
最后就是价钱问题了，这个你自己看着办吧。让你公司的财务或者采购出马砍价付钱就是了。当然，除了服务器的服务，你最好还是想想有利于自己的服务，比如人家公司可以帮你拆箱子了什么的。我做的最弱智的一件事情就是，来了400台服务器，50个交换机，8台EMC，我一个人花了一星期把箱子才全部拆完。。。

机器选型的时候你也要为自己考虑，比如HP的ILO功能，可以让你远程BIOS级操作服务器，比如浪潮的自动资产管理等等，为自己管理服务器提供便利，否则机器10来台还好，100台还一般，我这里3万来台，我不死几百遍了。丢失一台服务器，几个月工钱就没了。。。

二，IDC选择
首先要看你服务的地区是哪里，然后再去找当地的电信机房。毕竟，虽说全国已经互联了，但是各地的网速还是有差异的。
或者说有的idc机房利用率高，虽然出口带宽大，但是利用率高的结果是导致你网速慢的原因之一。
我的做法是在全国各个机房的服务器用pingplus这个软件进行一周的的流量测试。可以看到平均丢包，最大延时等等。
当然，你也可以到你目标服务的地方，找个可以上网的地方进行网络测试，比如说网吧包个机器。。。

好了，网络测试完了。那么你已经决定去哪个idc了吧。

然后你就可以电话或者自己提着礼品登门拜访一下IDC服务商的老大了
当然，你也可以找代理服务商，因为他们拿到的价钱有时候比电信或者网通给你的价钱低，但是，关键还是一个服务，因为你毕竟服务器放在那，晚上关键着急没人给你重启，机器出了问题其实按个F1就可以解决的问题，服务商的值班人员不懂。你就只能打晚上的打飞机去机房维护吧。
提着东西拜访一下服务商老大是礼节性的东西，东西不在多而在精，这样你未来谈事情人家也给你绿色通道，做事情要好做很多。当然，我也不反对你空手去，你一次租个100个机柜＋10G带宽，人家还是很优惠的。哈哈。大家都是混口饭吃，也不至于难为你什么。
最后你要知道现在的中国还是卖方市场，你给人家牛，那你买的产品只能是。。。蒙牛

然后是开始去参观机房
细心的检查一下空调数量，空调出厂和最后维护日期，网络布线类型和架构，是否可扩展，主备从电力等。
基本都是非常关键的东西，出问题了，人家可以给你更换一个新的，服务很好，但是你服务器挂一天的损失是多少，你可以自己掂量。
还有机柜电力，现在的机柜放置16台1U的服务器是正好，多了过于热，少了资源浪费；但是你发现人家只让你用10安培电力，过了要交钱买电；
或者不限制你用电，但是插线板只有10个，你还真买个托线板去转接？你要想想你一个托线板挂了，你服务器要挂几个？

最后，我的一个机房包间里140个机柜，2个空调，结果某天挂了一个空调，虽然6小时人家IDC商就给更换了一个空调机（这速度已经非常快了），
结果我机器至少被热死了100台以上，机器是HP的，机器过热，HP会自动关机，而且会不让你启动。你崩溃不？注：不是给hp做广告哈。

三，服务器上架
好了，要是你买的服务器到了，你会发现你接到电话后，楼下一个N大的“擎天柱”集装箱车给你送服务器来。。。（某次我收2000台服务器就是这样的阵势）；在这里有个重大的提示，你们财务给厂商下单的时候，收货地址一定要写对。比如 XX路XX号XX大厦XX楼XX室，你写到xx号，送快递的会给你堆到院子里，你写到xx楼，送快递的会给你送到电梯口，你写到xx室，他们才会给你搬到室内。因为送货的都是服务器厂商找的，你因为这个事情去联系厂商修改送货地址，至少要多等N小时。而且他们视你的单子的数量和楼层，判断来多少搬运人员。而且，一定要把服务器搬到你指定的地方再签字收货，否则...嘿嘿...
我最霉气的是：来了20台机器（还好不多），下着大雨人家给我往院子里一丢，让我自己搬上19楼，我没推车没啥的...
你可以说，找电信的帮忙撒，废话，这个我还不知道。那我告诉你，我在某电信大楼工作时，从CCIE到机房主管到机房工作人员，全部是美女...
虽然我在这个地方只干了5天活，我的同事们口水都有3尺长...你还叫人家给你搬机器不？
你可以说，顾民工撒，我又不是没顾过，钱得你自己支付，公司不给你报销的话，爽不？

下面是拆箱子，面对着堆积如山的2000台服务器，我是连抬手的力气都拿不出来。。。当时机房只有我们公司3个人＋电信值班2个人。。。
这时候，我的办法是。。。我打电话找来了2队收废品的：
这么多箱子，除了机器和电源线留下，里头的导轨光盘等等你全部拿走，谁拆的多谁拿的多。。。
最后按照我的要求帮忙搬到机柜上。。。于是我们5个人是监工。。。看人家拆箱子搬机器。
于是人家2队人找来了30多号人，一早上把2000台机器全部拆箱子完毕放到机柜上。
要是我们几个人拆，估计......

最后再说个行价，服务器箱子一个价值5块钱甚至更多。你服务器到了，卖卖箱子请大家吃饭吧。别让扫地的阿姨拿走，，，几个无所谓，10来个箱子，，，够大伙儿吃顿烤肉了。。。还有EMC的木箱子。。。拿去养个小鸡小鸭的。。。

42U机柜1U的服务器最好是16台。你就看着上吧。呵呵

四，安装系统和布线

好了，面对几千台服务器开始装系统，我不知道你会怎么想。。。
全部是1U服务器有什么办法安装系统？（我们公司穷，买不起刀片；而且电信不配合，要是上刀片，电路你们自己拉线，价钱还是原来的价钱；最重要的...我们公司以人为本，宁愿多养个人也不愿意买个好服务器让人失业），而且不允许GHOST，因为你这是服务器，不是网吧...GHOST出来的系统，我不知道谁用过，爽不。我自己是郁闷郁闷到了，莫名问题的时候，你就知道GHOST还是靠不住的。
其次，我们公司安全部要求：必须得一台一台安装，先安装光板的系统（比如没有SP的WIn2000），然后手工打SP4补丁，不能网络打补丁。于是我们就光盘堆成山。最扯淡的，为了快，我做了一个补丁共享的服务器，所有的补丁CP的本地来打。结果忘记拔网线，导致人家说我们是插了网线打补丁，有中毒的危险，需要重装。我直接崩溃。。。

办法1，你可以1台1台慢慢装，反正这么多机器，你可以管公司要更多的时间。但是我们公司一般是机器到了，最多2－3天就要要，一向是那种计划不如变化快的没有计划没有进度管理的“小”公司，项目组拿着鸡毛当令箭，牛x哄哄的公司。郁闷！
这个时候前期的准备就比较重要了（我公司多用windows2003），因为首先我要装一个光系统，再打驱动，再打补丁，再安装远程控制软件。一台机器装完大约要1小时多点。那么机器多了怎么办？光盘不够怎么办？等等问题就来了。
我的办法是，我一看TMD全部是DVD，IBM的机器直接佩combo，公司给我们发的全部是CD，娘的，典型的没有最慢只有更慢，除了问题闲你慢的领导班子。于是只好自己出钱买了DVD，用软件把RAID,网卡，显卡其他驱动做到光盘里，需要安装的软件也直接做成自动安装的方式，补丁也刻录到光盘里（我们要求补丁必须单打，不能安装集成补丁的ISO，shit），这样弄，你只用把光盘往光驱里一丢，分区一分，就可以下一台机器了。然后等你在去关注这个机器的时候，已经可以设置IP插网线了。灵感来自番茄花园。吼吼。
当然这时候你最好是买个KVM,16口的KVM，一次准备16张光盘就可以用一套键盘鼠标操作16台机器。当然啦，KVM是可以级联的，我最牛一次一次一套键盘安装166台机器。郁闷的是，塞光盘塞死，插KVM线插死，配置IP配死，有时候还会弄错。。。

办法2，你可以用NETKVM去远程安装，但是你插那些NETKVM的线路，2000个插下来，爽不？然后你继续扎KVM和网线的时候，看着和瀑布一样的网线和KVM线交错在一起。估计直接崩溃。远程KVM有的牛x的是可以分发ISO的，就是传说中的远程分发安装。可以自己买一个研究研究了，我们公司以人为本，从来不买这类高科技。

办法3，我犯贱时候发明的：我们的机器全部是RAID1，于是我安装一台raid1的机器，系统全部安装好，然后拔掉一个硬盘，插上一个新硬盘自动恢复镜像，基本10来分钟恢复好一个硬盘，插到机器上去。这样，还是比装系统来的快。当然啦，型号是一模一样的。。。

办法4，HP的ILO2功能，实现远程分发。前提你得一台一台配置好BIOS里的ILO2。也是蛮痛苦的。IBM和DELL现在也都有这个功能，但是你在分发以前，还是得一台一台机器插上网线，配置好BIOS的IP，痛苦。然后把操作系统和机器的驱动程序和后续的软件全部做到一张DVD里，让他自动运行。然后所有的服务器远程运营这一个ISO,最好多弄几台，否则一台机器弄的慢死。

办法5，绝对最简单的办法!!!就是买机器前，让厂家给你在硬盘里灌好系统，和你买笔记本一样，打开是个安装完成需要你输入序列号的系统。但是弱点是后续的软件需要自己装。因为服务器厂商是不会帮你安装别的软件的。

还有更多的办法，只是暂时没想到，大家也可以谈论自己的办法。互相交流嘛。
所以我喜欢linux...可以用N种办法安装系统...

windows就是个让IT人当装机男，挨踢人当民工。

好了系统装好了，电源线和网线连接完，和瀑布一样的。这时候还是尽量把他扎一下