门户网站运维

门户网站运维 载至: chinaunix.net 论坛 http://bbs.chinaunix.net/thread-1281178-1-1.html 作者: veyron 整理: fire-phoenix 门户网站运维 pdf 版是截至当前 2008-12-18 当进的贴子页数为 20 页, 如有更新请以论坛为主. 期待 veyron 的进一步更新. 这个 pdf 版 本 共分为 9 章节, 其中 1-7 章节正文部分为 veyron 所写. 第 8 章节为在论坛上的精采回复, 因我时间有限不能将这些回贴一一列出. 还请大家多多谅 解. 第 9 章节为 veyron 提到的: ”jiang2798 “贴的"google 架构、youtube 架构"等经典案例的帖子的 url 连接. 最后非常感谢 veyron, 同时 也期待 veyron 对运维行业进一步深入的讲解. 正文 对于网站运维，感觉大家还是比较迷惘与不解，确实，这是一个新兴岗位；近来闲而无事，在此结合自已以往的一些经历，与大家先共同探讨一 下“什么是门户网站运维”？ 以下是自已的一些经验和感受请大家斧正，希望和大家一起探讨，共同进步 1. 什么是门户网站运维? 首先明确一下，所讲的”运维“是指：门户网站应用运维，与其它运维如网络、系统的区别还是蛮大的；然后我们再对大型网站与小 型网站进行范围定 义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv 量等考虑，其它因素不是重点；因此，我们 先定义服务器规模大于 1000 台，pv 每天至少上千万（至少国内排名前 20），如 sina、alibaba、sohu、baidu、网易等等；其它小型网站可 能没有真正意义上的运维工 程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如本 版有些同僚将公司的采购都纳入了运维职责范 围，还有如 IDC 网络规划也纳入运维职责，这是网络工程师的工作，我们就不要抢人家饭碗 了，但是，非常重要一定需要明白：网站应用运维对其它关联工种必须非常了解熟悉：网络运维、系统运维、应用开发、内容；但这些非自已的 本职工作，我在这里所讲的运维工程师就是指专职应用运维工程师 我们再来说说一个般产品的“出生”流程： 1.1 首先公司 BOSS层给出指导思想，PM 定位市场需求（或 copy 成熟应用）进行调研、分析、最终给出详细设计 1.2 开发工程师将设计 code 实现出来、测试工程师对应用进行测试（同一产品事业部） 1.3 网络\系统工程师根据产品设计的需求，如 pv 大小预估、服务器规模、应用架构等因素完成网络规划及设备上的调整（基本上对网络 变动不大，除非大项目）、SA 系统工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装 1.4 好，到运维工程师出马了，首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大： 1.1.1 应用的前期架构设计、软/硬件资源评估申请 采购 1.1.2 应用设计性能隐患及评估 1.1.3 IDC、服务性能\安全调优 1.1.4 服务器系统级优化（与特定应用有关） 等都需运维全程参与，并主导整个应用上线项目；运维工程 师需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因 素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一 起，最终完成产品上线提供用户使用，并周而复使：需求- >开发（升级）->测试->上线（性能、安全问等之前预估外的问题随之慢慢就 全出来了）在这里提一点：网站开发模式与传统软件开发完全 不一样，网站一天开发上线 1~5 个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像 M$需要 1年解决，用户早跑光了；应用上线 后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发 故障处理、服务日常变 更调整、集群管理、服务性能评估优化、数据库管理优化（大于 50 台）、随着应用 PV增减进行应用架构的伸缩、安全、运维开发工作：a 尽 量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等等），提高效率 b 、解决现实中服务存在的问题，如高可靠 性、可扩展性问题等，c、大规模集群管理工具的开发，如 1 万台机器如何在 1 分钟内完成密码修改、或运行指定任 务？2000 台服务器如何快 速安装操作系统？各分布式 IDC、存储集群中数 BT 级的数据如何快速的存储、共享、分析？等一系列挑战都需运维工程师的努力。 在此说明一下其它配合工种情况，在整个项目中，前端应用对于网络/系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的 功能性开发，并对应用本 身性能、安全性等应用本身负责，它不负责或关心网络/系统架构方面事宜，当然软/硬件采购人员等事业部其它同事 也不会关心这些问题，各司其职，但项目的核 心是运维工程师~！所有其它部门的桥梁 上面说了很多，我想大家应该对运维有一些概念了，在此打个比方吧，如果我们是一辆高速行驶在高速公路上的汽车，那运维工程师就是 司机兼维修工，这个司机不 简单，有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快，汽车本身不能满足高速 度时对汽车性能调优或零件升级、高速行进中解决 汽车故障及性能问题、时刻关注前方安全问题，并先知先觉的采取规避手段。。。这就是运 维工作~！ 最后说一下运维工程师的职责：”确保线上稳定“，看似简单，但实属不容易，运维工程师必须在诸多不利因素中进行权衡：新产品模式 对现有架构及技术的冲击、 产品高频度的升级带来的线上 BUG隐患、运维自动化管理承度不高导致的人为失误、IT 行业追求的高效率导致流程 执行上的缺失、用户增涨带来的性能及架构上 的压力、IT 行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的 大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、 原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维 工程师了 1.2 另外在此聊点题外话，我在本版看到有很多人要 sina、网易、sohu、baidu 等聊自已的运维方面的经验，其实这对于它们有点免为 其难: 1.2.1 各公司自已网络架构、规模、或多或少还算是公司的核心秘密，要保密，另外，对于大家所熟知的通用软件、架构，由于很多公司 会根据自已实际业务需要，同 时因为原版性能、安全性、已知 bug、功能等原因，进行过二次开发（如 apache,php,mysql...），操作系统内 核也会根据不同业务类型进行 定制的，如某些应用属于运算型、某些是高 IO 型、或大储存大内存型。。。根据这些特点进行内核优化定制，如 sina 就在 memcache 上进行过二次开 发，搞出了一个 memcache DB，具体做得如何我们不谈，但开源了，是值得称赞的，国内公司对于开 源基本上是索取，没有贡献；另外，服务器也不是大家所熟知的型号，根据业务特点，大 部份都是找DELL/HP/sun/ibm 进行过定制；另外， 在分布式储存方面都有自已解决，要不就是使用现成开源 hadoop 等解决方案，或自已开 发。但 90%都是借鉴 google GFS 的思想:分布 式存储、计算、大表 1.2.2 各公司业务方向不一样，会导致运维模式或方法都不一样，如 alibaba 和 baidu 运维肯定区别很大，因为他们业务模式决定了其架 构、服务器量级、 IDC 分布、网络结构、通用技术都会不一样，主打新闻门户的 sina 与主打网游的盛大运维模式差异就非常大,甚至职责都不大 一样；但有一点，通用技术及大 致架构上都大同小异，大家不要太神化，更多的公司只是玩垒积木的游戏罢了，没什么技术含量。 1.2.3 如我上面所讲，目前门户网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，我相信大家也讲不出所以然来 （我现在也中抓破脑袋挤出这点 字，呵呵），可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一 角，局限于具体技术细节，或某某著名网站大的框架， 真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧. 2. 运维工作师需要什么样的技能及素质 做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多 IT 工种技能与一身的岗位，对系 统->网络 ->存储->协议->需求->开发->测试->安全等各环节都需要了解一些，但对于某些环节需熟悉甚至精通，如系统 (基本操作系统的熟 悉使用,*nix,windows..)、协议、开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理）、通用应用 （如 lvs、ha、web server、db、中间件、存储等。。。）、网络（至少要对应用所处网络环境非常了解） 2.1 技能方面总结以下几点： 2.1.1 开发能力，这点非常重要，因为运维工具都需要自已开发，开发语言：c/c++（必备其中之一）、perl、python、php（其中 之一）、shell（awk,sed,expect....等），需要有过实际开发经验，否则工作会非常痛苦 2.1.2 通用应用方面需要了解：操作系统（目前国内主要是 linux、bsd）、webserver相关 (highttp,apahe,php,tomcat,java。。。)、数据库(mysql,oralce)、其它杂七八拉的东东。。。系统优化，高可 靠性。。。 这些只是加分项，不需必备，可以边工作边慢慢学，这些东西都不难。当然在运维中，有些是有分工偏重点不一样。如可能有 专门的运维 dba 2.1.3 系统、网络、安全等需要有所了解，至少知道其原理 2.2 个人素质方面： 2.2.1 沟通能力、团队协作：运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；这应该是现代企业的基本 素质要求了，不多说了。。。 2.2.2 工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师 是网站 admin,最高线上权限者，一不小心就会遗憾终生或打入十八层地狱。。。 2.2.3 主动性、执行力、精力旺盛、抗压能力强：由于 IT 行业的特性，变化快；往往计划赶不上变化，运维工作就更突出了，比如 国内各大公司服务器往往是全国各地， 哪里便宜性价比高，就那往搬，进行大规模服务迁移（牵扯的服务器成百上千台）， 这是一个非常头痛的问题；往往时间非常紧迫，如限 1周内完成，要命~~~， 这种情况下，运维工程师的主动性及执行力 就有很高的要求了：计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯 皮。。。。。7X24 小紧急事故响应等。 2.2.4 其它就是一些基本素质了：头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观 2.2.5 最后一点，做网站运维需要有探索创新精神，通过创新型思维解决现实中的问题，因为这是一个处于幼年的职业（国外也一 样，但比国内起步早点），没有成熟体系或方法论可以借鉴，只能靠大家自已摸索努力 3. 运维工程师的职责 3. 1 保证服务达到要求的线，如 99.9%；保证线上稳定，如，网络/系统运维工程师对网络、系统稳定负责，那应用运维就需对线上 应用的稳定负责。 3.2 不断的提升应用的可靠性与健壮性、性能优化、安全提升；这方面非常考验主动性、和创新思维 3.3 网站各层面实时状态的监控、统计的覆盖度；软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用 的运转情况。 3.4 通过创新思维解决运维效率问题；目前各公司大部份运维主要工作还是依赖人工操作干预，需要尽可能的解放双手 3.5 运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性范错。 3.6 成本控制；通过技术手段提升硬件承载、架构优化，如虚拟化技术，节省硬件开支。 3.7 自动化运维；能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统；让大家更多的时间用于 思考、创新思维、做自已喜欢的事情。 4. 运维职业的迷惘、现状与发展前景 应用运维不像其它岗位，如网络、系统、安全运维岗位及研发工程师、测试工程师等，有非常明确的职责定位、职业规划、社会认同、比 较有职业成就感；而 应用运维工作可能给人的感觉是系统/应用哪方面都了解一些，但又都比上专职工程师更精通、感觉平时被关注度比较低 （除非线上出现故障），慢慢的大家就会迷 惘，对职业发展产生困惑,为什么会有这种现象呢？ 除了职业本身特点外，主要还是因为对运维了解 不深入、做得不深入导致、新职位还没得到社会广泛认知及认同；其实这个问题其它岗位也会出现，但我发现运维更 典型，更容易出现这个问 题；针对这个问题我谈一下网站运维的现状及发展前景（也在思考中，可能不太深入全面，也请大家斧正补充） 4.1 运维现状 4.1.1 处于刚起步的初级阶段，各大公司有此专职，但重视或重要承度不高，可替代性强，工作职责也有所不同；小公司更多是由 其它岗位来兼顾做这一块工作，没有专职，也不可能做得深入 4.1.2 技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。 4.1.3 体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟 的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空 间了 4.1.4 优秀运维人才的极度缺乏；目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技 术都局限在各大公司内部，如 google 50 万台机器如果科学的管理？或者国内 top 10 的一些经验，这些经验是非常有价值的 东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通,贯通,与借签,并最终将限制了运维发展 4.1.5 很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量 PV、硬件规模足够大， 如 baidu 可怕的流量、海量 数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大 公司可能已有很好的解决方案或系统 4.2 发展前景 4.2.1 从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂； 对专职网站运维工程师、网站架构 师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目 前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没 有经验人才加入会导致公司技术更新缓慢、影响公 司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化 4.2.2 从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视 4.2.3 网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好 的个人能力与技术广度的发展空间 4.2.4 运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、 全局思考能力等 4.2.5 特长发控和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、 网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家 4.2.6 如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做 4.2.7 技术发展方向、网站/系统架构师 5. 运维关键技术点解剖（比较实际，现实中的案例，今天先想出这几条，如大家有其它感觉兴趣的，可以提出，我来解答） 5.1 大规模集群管理问题 首先我们先要明确集群的概念，集群不是泛指各功能服务器的总合，而是指为了达到某一目的或功能的服务器、硬盘资源的整合（机 器数大于两台），对于应用来说 它就是一个整体，目前常规集群可分为：高可用性集群（HA），负载均衡集群（如 lvs），分布式 储、计算存储集群（DFS，如 google gfs ,yahoo hadoop），特定应用集群（某一特定功能服务器组合、如 db、cache层等）， 目前互联网行业主要基于这四种类型；对于前两种类似，如果业务简单、 应用上 post操作比较少，可以简单的采用四层交换机解决 （如 f5、foundly），达到服务高可用/负责均衡的作用，对于资源紧张的公司也有一些开源 解决办法如 lvs+ha,非常灵活；对于后 两种，那就考验公司技术实力及应用特点了，第三种DFS 主要应用于海量数据应用上，如邮件、搜索等应用，特别是 搜索要求就更 高了，除了简单海量存储，还包括数据挖掘、用户行为分析；如 google、yahoo 就能保存分析近一年的用户记录数据，而 baidu 应 该少 于 30 天、soguo 就更少了。。。这些对于搜索准备性、及用户体验是至关重要的。 接下来，我们再谈谈如何科学的管理集群，有以下关键几点： 5.1.1 监控 1) 主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行，及潜在问题的及时发现与干预； 服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端web server，我们就可 以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否 crash、通过 icmp包探测服务器 健康状态， 更上层可能还包括应用各频道业务的监控，常用方法是采用面业特征码进行判断，或对重点页面进行签名，以 网站被黑篡改（报警、并自动恢复被篡改数据）...... 这些只是一部份，还有 N 多监控方式，依应用特点而定，还有一 些问题需解决，如集群过大，如何高性能的进行监控也是一个现实问题 ...... 2) 其它就是集群状态类的监控或统计，为我们合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击 等问题 5.1.2 故障管理 1) 硬件故障问题；对于成百上千或上万机器的 N 多集群，服务器死机、硬件故障概率是非常大的，几乎每时每刻都有服务硬 件问题，死机、硬盘损坏、电 源、内存、交换机。。。针对这种情况，我们在设计网站架构时需要充分考虑到这些问题， 并将其视为常态；更多的依靠应用的冗余机制来规避这种风险，但给系统 工程师足够宽裕的处理时间。（如 google 不是 号称同时死 800 台机器，服务不会受到任何影响吗）；这就是考验运维工程师及网站架构师功能的地方了，好 的设计能达 到 google 所描述自恢复能力，如 gfs，糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映，直接 对用户拒绝响应。 2) 应用故障问题；可能是某一 bug被触发、或某一性能阀值被超越、攻击。。。情况不一而定，但重要的一点，是要有对这 些问题的预防性措施，不能想 当然，它不会出问题，如真出问题了，如何应对? 这需要运维工程师平时做足功夫，包括应急 响应速度、故障处理的科学性、备用方案的有效等 5.1.3 自动化 自动化：简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手及枯燥的重复性劳动， 例如：没有工具前，我们安装系 统需要一台一台裸机安装，如 2000 台，可能需要 10 人/10 天，搞烂N张光盘，人力成本 更大。。。而现在通过自动化工具，只需几个简单命令就能搞定、还 有如机器人类程序，自动完成以往每天人工干预的工作， 使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是/非判断、优化选择等。。。这 些好处非常明显 不再多说。。。应该说，自动化运维是运维工程师职业化的一个追求，利私利公，虽然这是一个异常艰巨的任务：不断变更 的业务、不规范化的应用 设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影 响，所以需要模块化、接口化、变因参数化等。。。。。。因 此，自动化相关工作，是运维工程师的核心重点工作之一，也 是价值的体现 6. 大并发网站的设计(1 亿 pv/天) 网站架构设计中，非常重要的一个要素，就是确保架构的可扩展性、这是高并发网站的基石。往往，一个网站的大流量不是与生具来的， 而是有一个积累过 程~~最后变成巨无霸，包括 google、yahoo 这种全球流量大户，而在这个成长过程中所积累的经验才是最值得我们学习的， 包括思考方式、问题解决、 改进过程。没有最好的架构设计方案，只有更好。。。，因此在此不会给大家一个终极方案。。。，在此介绍的这 些经验，更多的是让大家真正掌握架构设计方法、 理念、灵魂，并真正的能利用到实际中。为了让大家更易理解，我在此主题讨论中将会借用 本版”jiang2798 “贴的"google 架构、youtube 架构"等经典案例和大家分析一下，再谈谈一些通用性原则及技巧 1) 负载均衡架构 2) 高性能中间件选择、优化 3) 架构扩展性问题 4) 应用设计、开发中的注意点 5) 数据的快速访问、要达 6) 数据库问题 7) 用户分地域优化 6.1 高并发架构需满足的一些因素、要点： 6.1.1 负载均衡架构 首先网站前端需要采用负载均衡群集解决用户高并发的响应，目前常用方法包括 1) squid反向代理，这也是各大网站常用的方法，包括 sohu、sina ...... 2) DNS轮循； 3) 采四层硬件设备，包括 google、baidu 使用这种方式 ...... 对于 lvs，小频道或不重要应用可以尝试使用，对于大流量、实 时性要求高的网站目前还不成熟 6.2 高性能中间件选择、优化 中间件选择、优化非常重要，当服务流量大于一定承度时，性能的稍微提升，对于整体硬件成本控制、服务的整体性能提升都是非常 可观的。对于 web server 目前常用的属 apache，但 apache 多进程(线程池)架构有一些缺点，进程频繁生成\注销系统开销大，特 别当流量大时更是明显，对于应用逻辑简单的可以考虑 lighttpd 采用单进程+epoll并发模式，效率高，但对多 CPU支持有问题，但 可采用启多服务解决这个问题；如果由于应用架构原因必须使用 apache，可考虑 apache module 性能比普通CGI 成倍提升。。。 其它原则，包括各中间件各版本测试、包括性能、安全上的考良，找到平衡点，不要太关注某一点因素，导致整体架构上出现隐 患， 另外一点非常重要，那就中间件的参数优化，这些方面大家可以 google、baidu 上找找，比较多，但有个原则那就是需要根据服务器 实际资源情况进 行优化，如 httpd 最大进程数设多大合适呢？有些朋友，就随手来个 2048，觉得这样肯定不会再出现 httpd由于进 程阀值过低导致拒绝服务，但这有个 隐患，因为生成进程，是需要硬件资源的，当进程数达到一定承度，可能服务器内存会溢出，导 致服务器 crash，特别是内存消耗量大的应用。。。这样的案例 很多，需谨记 6.3 扩展性问题 扩展性对于高速发展期间的网站非常重要，大家可以经常在网上看到某某网站的发展励途，那简直就是一部进化史，过程曲折而痛苦~ 因此成熟的经验就 非常重要了，扩展性可以从两个方面来看：网络系统上的扩展性及应用本身的扩展性，首先在网络上需层次分明， 尽量扁平化，全网冗余不能存在故障点，尽量按业 务类型进行划分网络结构(pv 大小、优先级)防止互扰，重要的一点：网络设计中， 简单就是美~~，在不影响扩展性的前提下，不要搞得太复杂；网络硬件资 源、机架位、IDC 都需提前至少半年进行规划，这些规划的 重要依据是公司业务发展的前景评估，这就体现公司的战略眼光了，包括是否需要外地 IDC（依用户 群体而定）。。。；另外，选一 个好点的 IDC 是非常必要的，否则就得疲于 IDC迁移了，北京地区好 IDC 还是不少的：皂君庙（有点老了。）、土城、联通、 酒仙桥、 爱立信、互联世纪、奥运官方机房数字北京据说马上也能入驻了。。。当然了，有钱也能像 google 一样自已搞个 IDC，国内谁有这 个实力? 另一点就是应用本身的扩展性了，原则其实很简单，应用设计时应尽量确保应用的层次化、采用高性能的中间件、逻辑复杂及大数据 量交互的功能尽量做成独 立模块\后台、cache层、数据库分层（读/写操作分离），不要图前期简单直接将功能全部揉进前端CGI 中， 这很致命，随时都可能会遇到性能瓶颈、而且 毫无扩展性。。。 当以上两点很好的解决后，现在唯一的问题就是每半年根据业务的 PV增涨、新业务发展，预购服务器了。。。；当然了，对现有架 构优化，性能提升才是根本解决之道，特别是现在全球经济不景气，大家都不好过，这就是运维工程师的责任了，优化再优化~~ 6.4 应用设计、开发中的注意点 架构层设计好后，应用层设计就是我们重点关注对象了，这也是一个项目成功的关键，好的设计主要体现在：性能(高并发承载能力)、 可扩展性、可维护、安全性 （数据完整性、应用稳定性、前端应用安全如 SQL注入。。。）、模块冗余、负载均衡等等，技术点：线 程池、epoll、TCP(长/短)连接的选择、功能 模块的细化及后台化、模块冗余/负载均衡考虑(可扩展性)、高频数据 cache缓存、数据 分层、应用单故障点的解决(数据唯一性问题)等。。。 有两点要注 意： 1) 应用设计时要允分考虑服务器、硬件设备甚基于 IDC 的不可靠性；也就是说我们在应用设计时需要考虑到应用运行过程中，随时都 可能会有 1~2 台服务 器或更多服务器出现故障情况(网络故障, 灾难、攻击、停电((整个 IDC 全挂))。。。)，如 google GFS 就是 一个典型，我们不能将应用的稳定性寄托于硬件的稳定上，特别是门户型公司大部份采用的都是 X86普通机型，服务器 crash 是家 常便饭、随时随 刻(当总量到一定量级时)，所以我们在做应用架构设计时需允分考虑这些问题发生时的对策，做到允分的冗余/负载 均衡（这两点可统一），如多 IDC 间通过智 能 CDN 的流控、单 IDC 应用模块多节点冗余/负载均衡等，即使某些应用由于特殊原 因无法做到这点，也需允分考虑应急预案。。好的设计在这些突发情况下可以做到不用人工干预，当然难度也很大。。。记得前年 李开复在北大演讲时说过：google 一个 IDC 同时故障 800 台机器，不会影响到任何应用的正常响应 （有点怀疑，可能是他挑选的 某类服务器，呵呵）； 2) 大流量应用/模块中能不使用数据库就不要使用数据库, 下一节会讨论这方面问题 * 数据库问题 * 用户分地域优化 * 高可靠性问题解决 * 网站安全问题 * 海量数据存储、统计分析方案、架构 7. 网站安全问题 网站安全是一个系统性工作，影响安全的因素也很多，如DDOS（最常见的）、应用漏洞、系统层面漏洞、内部安全流程漏洞等（人为失 误），可以从以下几方面着手考虑: 7.1 网络层 首先在网络设计时需考虑到安全因素；在主干出口处，对非业务端口进行屏蔽（如非 80端口全部屏蔽），对于非常规数据包进行限速， 如 icmp，udp 等，但是需考虑主干设备性能，不能因为安全限制导致设备性能明显下降，需要做到平衡，否则又会出现一个新的隐患 点；另一方面就是主干带宽 要足够富余，做到冗余互备（vrrp、hsrp），以抵抗DDOS的所带来的带宽消耗（对于大型网站DOS随 时都存在，只是规模大小不一样），另外，现在 部份 4~7l硬件具有一定的 syn 代理功能，可以抵御一定规模的 flood，但主要还得拼 资源、带宽、硬件性能；另外，需做好主干数据镜像分析，对于一些有规律的攻击定位到特征、甚至是攻 击源，进行针对性的防御。 对于公司重点业务可以在网络层进行物理隔离，增强关键性业务的健壮性，甚至是将业务冗余分布至不同 IDC，做到跨地域容灾（如地 震） 7.2 系统层 系统层主要是操作系统安全加固、系统安全 BUG解决、对非业务端口进行屏蔽、非业务软件清除、跟踪系统工具软件最新安全动态， 并做到及时更新。特别是直接 对外提供服务的服务器（处于外网），更需做好定期安全审查评估，由于一般公司服务器内网都是相通 过，攻占一台外网机器可能会导致公司整个内网全暴露，很恐怖 7.3 应用层面 应用方面安全就不多说了，主要是开发细节上需把好关，不留逻辑上的漏洞，并对上传接口严格控制、越界检查、SQL安全性考虑等， 特别是对于用户具备上传接 口的应用（如 mail、bbs、blog、云计算等应用），漏洞是很多的；系统应用，如中间件也需做好相应的安 全配置。。。不多说了，大家上网能馊到一大 堆。需要多关注网上关于自身网站安全漏洞方面的信息（或定期搜索），因为往往应用上 的漏洞，都是用户先发现的，用户是最好的测试人员，发现后需第一时间修 复，并对同类业务进行全面排查；对于特定重点页面也可以 进行监控，并采用程序自动恢复主要页面（功能上如有问题，可显示业务升级提示），以免应用被攻破后 对公司形象造成影响 7.4 内网安全管理 对于日常内网准入方面需有严格流程，统一入口，技术方面如 vpn、rsa,securID（如 sina 就用的动态密钥）等，没有条件的也需定期更 新入口密码 7.5 安全巡查 偶尔由于人为失误会导致一些漏洞的出现，如由于工作需要临时变更了某些安全参数，但忘记开启。。。这个问题其实是最大的，往 往出问题也多是人为失误，需要 定期对全网关键安全点进行巡查；而且这也是 404审计的一个重点，想必在 sohu、sina、网易等美国 上市公司里做安全的兄弟应该很有感触吧 ******************************************************************************************************************************* 8. 论坛中对于本贴的精彩回复 * 前面的 id 为回贴作者在论坛中的 ID 8.1 jerryma: 运维部是网络工程师、系统工程师、安全工程师、测试工程师的集合。楼主所说的什么都会的运维工程师可能不会有很高的 运维质量. Veyron : 网络、系统、安全工程师应该是系统部的范畴，他们更多关注的是系统、网络层面，独立于上层应用，他们提供的是一个通用 框架和规范；安全工程师也更多的是基于网络、系统的整体安全策略的制度与规范，如网络入口安全规划、系统层面的安全 （如 iptables通用规则、内核加固、通用工具的安全评估）、网络安全审计等等，基于应用层安全如逻辑上的 bug\漏洞他们 是鞭长莫及的，而运维是基于系统部工作的基础上，针对上层应用服务的岗位，就好像系统部提供的是一堆积木，而运维将他 们组装成玩具；还有重要一点，我没有强调运维工程师什么都要会，但关联岗位工作一定要了解，否则会有困难，对某些方面 需非常熟悉，并有自已的专攻，就像我正在写的运维技术讨论，全是运维工程师的核心职责及技术；另外，测试工程师更多是 与开发紧密配合的岗位，与系统部更没联系了. 8.2 evil_knight : 呵呵，楼主把运维想的有些复杂了，至少网站架构你只有建议权，真正的设计者是架构师而不是你！你只是执行者！ Veyron : 这种情况在各公司还是很普遍的，主要是由于运维还不成熟（刚起步），或经验缺乏，只能做简单的执行者，而在网站设计、 架构、开发中运维会没有发言权，这是正常现象。当然，我这里说的是一种比较理想的运维职业状态，也是一个奋斗方向吧. 8.3 chexyo: 感觉在混淆概念。LZ是不是可以亮下身份。你们的运维不包括NE? SA? DBA? Veyron : 严格来说运维是包括 dba 的，当然有些公司的DBA比较独立，如淘宝，有专门的 oralce DBA团队，而且也做得很牛。Sa 是 系统工程师，更多职责层面是服务器硬件的管理、资源分配，上面已有说明，另外，网络工程师也是相对独立的，很多公司这 些职位是属于一个大点的部门如系统部；运维更多应该是介于系统与应用架构层之间~~~ 另外，NE()是什么？不好意思没弄明白 8.4 evil_knight: 那个确实太理想化了，大多数运维都没有开发经验的，如果要达到你的这个理想状态，首先这个运维以前是一个开发者有 c，web 的开发经验，非常熟悉 unix类操作系统！而且基本就是一个项目的 leader否则他没有这么强的架构经验的！ 而实际上，一个项目的 leader很少懂得系统+网络+硬件的，不是没有，我们老大就是你文中所说的理想！在我看来，他的那 种状态对我来说可望不可及！ 再一个到达你所说的这种理想，通常都是这个公司运维的头+技术顾问！ veyron : 关于你说的这几个问题： 1) 关于开发能力；c 是应届生的基本能力，另外，基于 c、web 等中间件开发，不需要太多经验，更多是需要运维方面的经验； 因为运维开发更多是基于运维工具辅助性开发，而不是线上产品，把握一些关键点就OK，如性能、易用性、可扩展性，当 然如果是大的自动化管理平台还是需要开发能力更强的人来主导，但这是一个人才培养递队的问题，高低搭配，有基本运维 人员、也有优秀运维人员，不能假设集体平庸化。另外，了解熟悉操作系统这是运维本职工作，必须的技能 2) 你所说的项目 leader 应该是指线上产品项目；运维参与架构设计更多是运维相关、当然做得深入应用本身性能、架构优化也 能给出建议（详请见正文，有说明） 3) 对于职业的发展；大家可以发现，越向上发展，越会更加关注其一些理念及宏观层面的技能，如架构、技术、管理的全局性 掌控技能，具体职业岗位区分会越来越模糊（正如没有谁关注CTO的以前的职业岗位一样，当然可能会关心行业的）。例如 架构师可能出自褚多岗位的牛人，如网络、系统、开发等等，当然运维也能出架构师，只要做得足够深够广，到CTO也是有 可能的。。。 4) 关于职业理想化，这应该是每个职业都有的大方向，不能自设天花板，否则会局限发展...... 8.5 selinux : 看了这篇文章，忍不住想回复一下，呵呵。 非常佩服 veyron 能够对运维的深度剖析。对运维已经达到一个比较高的认识了 。个人猜测应该在几大门户网站工作，而且 应该有 3年以上的运维工作经验. 大公司的运维和小公司的运维是有本质区别的。所以很多人对运维停留在不同的认识层面。很多大公司以前也是没有专门的 应用运维职位，开始都是由开发人员同时承担运维的工作，由于没有那么大的精力，所以不可能做的深入，所以对业务的稳 定性没有保障，随着工作的精细化分工，成立专门的部门 ...... 一个优秀的运维工程师的经验是在工作中磨练出来的 。。。不是一朝一夕的事情。一个优秀的网站运维工程师应该是一个复 合型人才，对开发，操作系统，架构，安全，网络等都比较熟悉. veyron 所说的门户网站运维在我们公司应该属于应用运维的范畴，门户网站运维兴起大概也就 2，3年的时间，当时没有可 以借鉴的东西，完全是在摸索中前进，当然，各个公司对岗位的命名有所不同，目前 baidu，雅虎，腾讯，51，都设有应用 运维的岗位。。。应用运维的工作和业务紧密挂钩，7×24小时服务，对业务的稳定性，健康度负责，对负责的业务而言相 当于“管家”的角色，要和各个部门的人打交道。系统运维的工作 则和操作系统紧密挂钩，不对应业务。网络运维 则是偏 向于网络规划，硬件防火墙，交换机，路由器等设备的管理，为业务部门提供支撑。IDC运维则偏向于 IDC机房的运维，机 器的上下架，硬