再谈大型数据中心的运维工作（本站推荐）

第一篇：再谈大型数据中心的运维工作（本站推荐）

再谈大型数据中心的运维工作

随着数据中心的建设规模不断扩大，新技术层出不穷，数据中心变得越来越复杂。数据中心往往是由很多规模庞大的集群系统组成的，运维工作需要具备方方面面的知识，包括硬件上，业务上的东西，需要上下打通地去做运维工作。因为很多数据中心的规模非常大，面临的挑战和问题非常超前，很多不是问题的问题在这样的规模下也就凸显出来了，所以要做好大型数据中心的运维工作，对整个数据中心技术的系统的学习就要花费比较长的时间，只有对这个数据中心整体非常了解，才能有针对性地制定一些运维方案，甚至可以二次开发一些监控软件，对整个数据中心进行管理与监控，提升整个数据中心的运行效率，减少故障的发生，从而将运维工作推向新的高度。一个大型的数据中心内部包含了很多小系统，运维工作都是围绕着这些具体的应用系统展开的，具体的可以分为五大部分，三十多个小项，覆盖了数据中心的所有组成部分，本文就来说一说一般大型的数据中心应该具备的哪些运维方法。

从数据中心安全方面来考虑，运维工作就是十几个小项：攻击保护、固件管理、备份、抓BUG/找BUG、脚本工具、自动化维修、数据安全、性能优化、服务巡检等项目，其中每一项拿出来其实都包含很多的内容。比如说到攻击与保护，这个主要指的是防止外来的异常入侵者对数据中心发起的恶意和无意攻击，恶意攻击就是有人故意的使用各种攻击方法，进入到数据中心内部，将重要的数据窃取或者破坏，达到其不可告人的目的。也有的是无意的攻击，因为整个数据中心是要与外界保持互联互通的，运行是动态的，变化的，不可避免会有一些异常流量攻击数据中心，有时甚至来自于数据中心内部，比如某些服务器中毒，或者硬件故障，构造出了环路，异常流量等网络故障，这些都会影响到数据中心的运行，所以如何做好数据中心的攻击与保护是一个很大的题目，这并不是在数据中心里部署几台安全设备就能解决的，需要对整个数据中心进行全面的统一规划，并有针对性地部署一些安全防护措施，而且随着各种黑客技术的提升，安全防护措施也要不断提升，这是一个不断学习与完善的过程，只要数据中心还在运行，这个完善就不会停止。为了方便运维，也要做好一些执行脚本，以便在出现突发事件时，能够快速部署。比如如果一个数据中心的业务出现异常，为了快速恢复业务，需要将路由进行调整，将流量全部引到其它的数据中心，这就需要在核心路由器上进行调整，这时有个现成的脚本就可以自动执行，达到快速切换的目的。数据中心还应该准备很多其它工作的脚本，以便紧急的时候快速使用。从数据中心的基础运维管理方面考虑，则主要有网络抓包/过滤、可维护性优化、配置管理、监控、报警处理、自动化运维、断网，断电、机房容灾等运维工作。其中自动化运维能提升运维的工作效率，尽量减少人为的参与，让数据中心自己管理自己，释放人力。同时针对数据中心可能发生的故障还做好监控与报警处理，以便能够在故障发生的第一时间知晓问题，往往一次大的故障都是从开始的一点小故障逐渐扩展最终引发整个大系统的崩溃的，所以在出现一些小的异常时一定要及时消除，而这些异常就要靠完善的监控和报警系统来检测。

从数据中心的日常业务运维方面考虑，则主要有资源、机器分配、Coredump、服务、内存使用、网络吞吐、故障恢复、应用，集群搭建、流量，压力，扩容，升级、上下级业务关联情况、资源利用率、异常处理、降级预案等等。这些日常运维工作实际上要花费大量的人力和时间，是运维工作的主体，也最烦琐，但却最不能体现业绩的部分。一个数据中心能够长久安全稳定运行，就是靠这些日常的工作积累的，只有平时注意这些细微的变化，才能不断优化。压力测试、软件升级、业务部署、异常处理等几乎成为了运维工作的日常必修课，只有将这些工作做好，才能避免出现大的故障，并能够快速部署新的业务，新的扩容设备。从数据中心网络方面考虑，则主要有网络硬件设备、ACL、VIP、流量、负载均衡、二三四七层情况、网络监控、万兆板卡、SAS/SATA/SSD等。网络是数据中心的重要组成部分，是一切工作运行的基本，没有网络数据中心就无法运转起来，所以保证网络稳定是数据中心运维工作中的重中之重。这里主要关注的就是网络的硬件问题，ACL部署还有流量情况。网络可以说是包罗万象，涉及太多的设备和协议技术，所以也需要不断地学习，加深对网络技术的理解，这样才能做好网络运维工作。

从数据中心服务器方面考虑，则主要有文件系统、内核参数调优、各种硬盘驱动、内核版本、Kernel panic等。Linux系统不仅在服务器，在网络操作系统也占据着主流地位，掌握Linux系统的使用才能更好地处理服务器和网络设备的运维工作，Linux是运维工作的一项基本技能。除了熟悉Linux系统的操作，还要对服务器的运行状态和内核运行状态进行监控与管理，减少服务器故障的发生。一般大型的数据中心都包含有成千上万台的服务器，几乎每天都会有服务器出现各种各样的问题，只有对服务器有深入理解才能很好地消除问题。为了防止服务器故障引发业务中断，所以一般在服务器上都要部署虚拟化技术或者集群技术，当一台服务器物理硬件故障时，业务可以平滑切换到其它服务器上，业务不会受到任何影响。这些虚拟化技术增加了运维的难度，也需要对虚拟化技术进行不断学习。通过上面的罗列您一定很惊讶，原来数据中心运维包含这么多内容，大大小小数十项，而且每一项包含的内容说起来都不那么简单，也涉及很多的技术知识。一个数据中心能否稳定运行，能够高效运行，运维是关键。只有将这些运维工作很好地部署和执行下去，数据中心才能长期稳定。【编辑推荐】

浅析建设绿色数据中心供电系统的意义

数据中心发展吹响“绿色”集结号

利用废弃建筑建设数据中心

解密公有云数据中心扩张背后的驱动力量

“互联网+”时代 数据中心如何做“减法”？

第二篇：数据中心运维题目

运维部第二季度考试试卷

部门：__________________ 姓名:__________________ 分数:_____________

一、填空题（每空 1分，共 10分）

1、IDC 机房温湿度应严格符合设备运行要求。温度正常工作范围 18-26 度；相对湿度正常工作范围 40%-70% ；当发现温湿度异常时，应及时（）

2、严格机房进出制度，外来人员应（）

3、UPS 电源三相电压 Vab、Vbc、Vca 正常时显示应为（），用蓝，黑颜色和字母（）来标识零线，用 黄 绿 颜色和字母（）标识保护地线。

4、空调非标柜分闸灯亮表示该路电源（），合闸灯亮表示该路电源闭 合。当机房外供电出现中断以后，空调非标准柜上市电灯亮起时，需要 按非标柜上的（）按钮，手动合闸。

5、启动机房气体消防系统灭火的方法有三种，按照启动级别依次为 按监控 室控制端的（）、击碎机房大门侧面的（），到气瓶间拔出对应楼层的（）。

二、选择题（每题 4 分 共 20 分）

1、MAC地址表示方法正确的是（）A、0778 B、202.201.32.100 C、011111110.01001000.11110101.00101010 D、00-60-58-70-C8-9A

2、以下那一项不含在PUE计算的电子信息设备能耗之中（）A．通讯机房的传输设备 B．模块机房中客户的交换机

C．模块机房中我司自有的云平台设备 D．值班室的办公电脑

3、下面不是 IDC 机房的服务器操作系统的是（）A、Windows Server 2003、Windows 2008 Server B、Andorid、Symbian、BlackBerryOS、windows mobile C、LINXU、Centos、SUSlinux D、UNIX、freebsd

4、某公司申请到了一个C类IP地址，需要分配给8个子公司，最好的子网掩码应设为（）A、255.255.255.0 B、255.255.255.128 C、255.255.255.240 D、255.255.255.224

5、Cisco 交换机端口指示灯为（）的情况下，为正常工作。A．熄灭

B．橘色固定时间间隔缓慢闪动 C．绿色快速闪动

D．绿色固定时间间隔缓慢闪动

三、判断题（每题 1分，共 10分）

1、值班人员不得随意屏蔽设备报警。（）

2、机房技术档案可以在论坛中与其他人分享。（）

3、各种灭火器材应定位放置，随时保持有效，人人会使用。（）

4、在机房服务器故障巡检中漏检，错检，在下次注意即可，不同通知相关负责人。（）

5、设备测试远距离取电，多个插排串接不会对设备用电产生安全隐患。（）

6、客户入室维护时发现未收到入室工单，应安抚客户并立刻与客响中心确认。（）

7、当发现隐患尚未解决，上一班次已经传报，接班人无须二次传报。（）

8、气体消防气体采用无毒惰性气体，因此在气体释放时人员可以站在机房内或者机房大门旁。（）

9、电源线和网线在条件允许下，可以在同一个走线架上走在一起。（）

10、发现服务器电源模块与电源线插接处电缆外皮剥落，可能发生漏电情况，应先保障设备安全，操作设备进行关机操作。（）

四、简答题（每题10分，共60 分）

1、请简要划出你所在 IDC 机房的弱电路由图（包括光纤odf分布，布线弱电桥架分布）。

2、请简要说明你所在 IDC 机房的设备设施的供电方式和断电处理方式。

3、简述下常用网络命令操作；

（1）检测机房到“百度网”的网络连通性；

（2）查看机房到“百度网“的网络路由，并说出最大延迟和丢包所在 的 IP 地址；

（3）连续 ping 百度网 50 个包，查看丢包率；

4、简述配置linux环境下，windows环境下，开启远程桌面的命令或者步骤；

5、请简要描述你所在 IDC 机房的机柜单路空开跳闸的处理过程和注意事项。

6、请简要说明下你所在的IDC机房汛期的重要关注事项及位置。

第三篇：数据中心运维操作标准及流程

数据中心运维操作标准及流程

郑州向心力通信技术股份有限公司

二零一八年 1 机房运维管理前期准备 1.1 管理目标

机房基础设施运维团队应与业主管理层、IT部门、相关业务部门共同讨论确定运维管理目标。制定目标时，应综合考虑机房所支持的应用的可用性要求、机房基础设施设施的等级、容量等因素。目标宜包括可用性目标、能效目标、可以用服务等级协议（SLA）的形式呈现。不同应用的可用性目标的机房，可设定不同等级的机房基础设施的运维管理目标。1.2 参与数据中心建设过程

机房运维团队应充分了解自己将要管理的场地基础设施。对于新建机房，应尽早参与机房基础设施的建设过程，以便将运维阶段的需求在规划、设计、建造、安装和调试等过程中得到充分的考虑；同时为后期做好运维工作打下基础。1.2.1 应参与规划设计

机房的规划设计是一个谨慎和严谨的过程，需要所有参与机房建设的相关方共同完成，才能确保规划和设计的有效性、实用性等要求。其中，基础设施运维团队应提出运维要求，从运维经验、实际运维难度、提高运维可易性等方面对规划和设计过程进行配合。1.2.2 应参与相关供应商遴选

机房基础设施运维团队应参与机房基础设施设备供应商选择的全过程，及时地了解各种产品及服务的品牌、型号、规格等关键参数，使之更能满足运维的要求。并就在安装、调试过程中的注意事项等提出建议，还需要对后续的设备保修等服务提出要求。1.2.3 应参与建造管理

机房的基础设施运维团队应积极参与机房基础设施的建造工作，并协助做好建设项目的项目管理工作，着重关注工程建造中如材料的使用、工序、建造过程等工作，重点关注隐蔽工程的安装工艺和质量。机房基础设施运维团队应充分了解施工过程中的工艺。对于新建数据中心，从施工质量和日后运维方便性出发，尽早发现施工过程的问题，及时纠正，方便日后运维和节省日后整改成本。1.3 测试验证

机房基础设施投产前的测试验证是确保机房基础设施满足设计要求和运行要求的关键环节。1.3.1 时间和预算

机房的业主应设立测试验证专项预算，预算应包括外部测试验证服务提供商的相关费用，以及在测试验证阶段产生的电费、水费、油费等相关费用。应制定测试验证的工期规划，以更准确地预测机房基础设施交付投产的日期。1.3.2 测试验证参与方

项目建设管理部门可作为测试验证工作的主体责任单位；运维管理部门可作为测试验证工作的主体审核单位；第三方测试服务商可作为测试验证的实施单位及整体组织工作的协调单位。但运维管理部门应要求测试服务商预先提供测试方案，在运维管理部门审核后方可进行。机房基础设施运维团队可参与测试验证工作，在此过程中熟悉设施和设备，可建立相关运维技术文档库，为后期的运维工作做好准备。

机房关键设备提供商及工程总包商，应积极配合测试验证工作，应在供应商合同中对此项有明确要求。1.3.3 测试验证内容

验证应覆盖所有关键子系统和设备应具备的功能和关键的操作程序，确保满足设计要求，必要时可做故障情景模拟来检验。

测试验证中发现设计或者建设阶段的问题，应该在报告中充分体现；可以改造的部分，应要求建设单位进行改造；不能改造或暂时不需改造部分，应作为风险点在运维过程中予以特别的重视，并制定相关预案。

1.3.4 设施健康评估

当接手已在运行的机房基础设施的运维工作前，运维团队应对设施的情况进行健康评估，了解潜在风险点，其中能够改造的部分，应该申请予以优化改造。不能改造的部分，应该作为风险点在运维中予以特别的重视，并制定相关预案。1.4 技术文档

完整并准确的技术文档是后期运行、维护、维修、故障诊断、优化改造的基础。运维团队在开展运维工作前，应从施工单位得到场地基础设施的全套相关文档，包括但不限于：机房的规划设计资料及竣工图纸、全套设备的清单及相关操作文档和保修保养资料、机房自动操作系统的逻辑图及说明文档、监控系统的点表、验收测试文档、机房所在建筑的建筑设计资料、竣工图纸。整体文档应在限定时限内进入运维管理知识库,并按照质量管理的原理和要求设定文档的起草、变更、审核、批准、保存、分发等职责权限。1.5 管理边界

为了明确管理责任，机房基础设施运维团队应将可能影响机房基础设施运维目标达成的外界因素整合成管理边界报告，提交业主管理层并组织研讨，形成明确的决策，制定完整的协调沟通机制及权责界限。这些因素包括但不限于：不归本部门负责，但可能对于本部门有重大影响的供电、供水、供暖、制冷、消防、安防、监控、运营商线路接入等系统。安全管理和质量管理建议 2.1 人员安全

机房基础设施运维团队要编制正式的机房生产环境（工作场所）的安全方针，设定严格的安全生产规范；并根据安全方针制定有效的、明确的安全计划，来教授和培训安全原则、危险识别、纠正缺陷和控制风险。并加强对于该部分规范的合规度的培训、考试和审核检查，以确保机房运维人员的人身安全。相关安全生产规范主要包括：

●机房生产环境安全管理规范； ●机房基础设施各系统安全管理手册； ●机房基础设施涉及安全的应急预案； ●机房基础设施管理过程涉及的技术方案中的安全管理策略。机房基础设施中与电气相关的工作存在着固有危险。设施运维团队应当创建一份正式电气安全计划，以最小化所有工作人员受到电气伤害的风险，确保现场电气系统达到相关法规标准。电气安全计划中的条款应规定电气工作人员在有资质和具备合理安全工作流程的前提下才能进行操作，并应利用防护设备和其他控制手段，如上锁挂牌设备。此计划的创建旨在防止员工受到电击、烧伤、电弧和其他潜在电气安全隐患，同时要求其遵守法规标准。

相关国家、行业规程包括但不限于：

●GB 26860电力安全工作规程 发电厂和变电站电气部分； ●DL 408 电业安全工作规程。2.2 物理环境安全

应了解周边社会环境信息，评估潜在的安全风险并制定预案。这些信息宜包含但不限于：周边交通路况、医院、供油站、消防站、变电站、供水、供电、供气、网络通信线路等。可建立周边社会环境管理资料库。

应了解机房所在地的历史自然灾害情况。包含但不限于GB50174 及TIA-942中提到的所有评估机房选址的外部因素，并制定相应的管理预案。

应建立并执行严格的机房设备、人员、车辆进出管理制度。应设立不同安全区等级(参考ISO27001信息安全管理中的物理安全控制)并制定访客管理制度,用以有效管理访客。2.3 质量管理

在机房基础设施运维过程中建立完善的质量管理体系，是保障以上机房基础设施运维趋于卓越的重要因素和手段。机房基础设施运维团队的所有关键工作应包括以下的质量管理要素： 2.3.1 质量保证

●过程制定； ●程序制定； ●过程审核和批准； ●过程和程序培训。2.3.2 质量控制

●事件回顾； ●质量检查和检验； ●定期质量审核。2.3.3 质量改进

●故障分析； ●经验教训； ●优化及创新计划。人员管理建议 3.1 组织及人员 3.1.1 组织架构

机房运维团队应有清晰的组织架构，同时对各岗位有明确的岗位职责说明并在计算机化维护管理系统（CMMS）中实现权责匹配，同步更新。中大型数据中心场地基础设施运维团队中除现场负责人外，可按照工作内容分设以下几个主要职能岗位：

●运维巡检团队

主要职责：对基础设备设施进行巡检，担任值班工作，第一时间发现故障或问题，并作为管理程序的执行者。

●技术管理团队

主要职责：对机房基础设施提供运维技术支持，解决技术问题，承担机房基础设施一般性的优化改造工程的项目管理工作，宜包括电气、空调、弱电等系统的技术人员。

● 物理环境安全管理团队

主要职责：对物理环境安全进行管理，进行安全巡检等工作。3.1.2 人员配制

机房基础设施运维人员的配备应根据运维管理目标或SLA来确定。中高等级的机房，可按照7X24的运行要求配置运维人员。上岗人员应具备国家要求的相应资格证书。应在运维管理程序中明确规定资质等级与操作权限的一致性。

高等级以及具有一定规模的机房，每个班组应配备具有电力、暖通、弱电专业能力的运维人员，以达到“即时应急响应”的工作状态。等级相对低的机房，每个班需要至少配备一人，达到“即时报警”的工作状态。

运维团队的关键岗位应有人员备份和储备。机房基础设施运维管理团队的关键管理人员或关键岗位人员在正常运维工作开展中应采用A、B 角色配置，日常工作中应注意角色的分配和工作的配合。其它岗位人员宜建立良好的循环机制，人员可进行岗位轮换和交叉培训，使所有人员掌握全面的基础知识。3.1.3 绩效管理

为了提高机房运维人员的技术技能、职业素养和提倡团队合作精神，专业地、高效率地运行和维护机房基础设施，有必要建立人员的关键绩效指标，定期对所有人员的短期和长期绩效进行评估，奖优罚劣，推动整个运维团队技术和素质的发展和改进。3.1.4 人员管理制度

为了保障机房基础设施运维团队的创新性、稳定性、持续性，应通过建立合理的人员管理制度，约束人员的工作态度、行为规范，提高人员的工作热情、工作效率和执行力，激发人员正面影响，使团队一直保有活力来共同努力达成服务等级协议的要求，运维团队应该建立运维人员的各项管理制度。这些管理制度应该主要包含（但不限于）：

●《日常活动管理制度》； ●《人员安全操作制度》；

●《运维人员基本素质养成管理制度》； ●《安全运行奖惩制度》； ●《节能运行奖惩制度》； ●《技术创新奖励制度》； ●《人员晋升制度》； ●《人才储备制度》； 3.2 培训及认证

3.2.1 员工培训及资格认证计划

对于机房基础设施运维团队新员工应进行完整及严格的培训，以确保其尽快具备岗位需要之知识及能力。培训内容应包括机房基础设施的所有系统的工作原理、操作流程、应急预案、以及管理制度等。

对于所有运维人员宜设定以知识更新、技能提高为目标的培训及认证计划。宜要求运维人员不断提升理论知识，以便于在缺乏操作程序的应急状态下进行正确的处置。

可借助行业第三方专业培训及职业技能鉴定平台，积极开展运维人员任职资格的评定工作。3.2.2 历史事件分析学习

运维团队应将机房基础设施历史事件的总结分析作为培训的重要素材，进行全员培训；对于新员工应在上岗前予以培训，以避免相同的事件再次发生。3.2.3 组织学习

运维团队管理者应积极参与行业交流，了解行业最佳的运维管理实践，并从行业故障案例中总结经验，做好自身整改。3.3 运维外包服务商

3.3.1 基础设施运维外包服务商的选择

机房基础设施属于关键性设施，选择外包运维团队时应考察其机房基础设施的运维服务的资质、能力和经验。如机房作为商业物业的一部分整体外包运维，应要求外包运维机构针对机房基础设施设施部分设立专门的有机房基础设施运维经验的团队，并严格按机房基础设施的运维规程规范执行。3.3.2 运维外包服务商的管理

对于外包服务商的员工的管理原则应该参照运维团队内部员工同等要求，相关人员只有在进行培训并得到相关的认证后才能从事相关的工作。

外包服务商需要严格遵循数机房基础设施既定的操作流程和安全守则。

机房基础设施运维管理的最终责任承担者是机房管理者，责任无法外包。因此，机房应保留运维核心管理人员，对于外包团队的工作进行审核、监督和绩效评估管理。设施管理建议 4.1 资产数据库

数据中心应建立完整及实时更新的资产数据库。数据库应包括所有关键基础设施设备的清单，还应记录设备设施的运行情况、事件情况、变更情况、维护保养频次等信息。

资产数据库应最少包括以下信息： 资产ID：每个资产的唯一标识号

种 类：一级分类（如电气、制冷、消防系统）子 类：二级分类（如 UPS、电池、PDU等）描 述：资产的文字说明 制 造：资产的制造厂家 型 号：制造厂家的产品型号 规 格：资产的规格或者标称值 位 置：位置 ID（房间或区域）购 买 人：资产维护的负责人 序 列 号：制造厂家的序列号 安装日期：资产的投产日期 保修期限：保修到期的日期 更 换：预计的资产更换日期 维护频次：年检、季检、月检等 4.2 预防性维护 4.2.1 预防性维护计划

预防性维护是为了延长设备的使用寿命和减少设备故障的概率而进行的有计划的维护。其目的是通过定期检查和保养，使设备的某些缺陷或隐患在变得更严重之前被发现。

运维团队应根据系统设备情况与供应商进行沟通，按照供应商的建议提前制定、季度、月度预防性维护计划。各专业运维人员需按照各设备系统特性、维护流程及规范，及时、完整地落实维护工作，并形成客观实际的记录和报告予以存档。运维团队还应定期对设备的运行状态数据进行统计和趋势量化分析，对于异常的趋势，做出报警及相关预案。预防性维护包括并不限于以下系统设备或内容： ●冷水机组、精密空调； ●UPS，开关、和发电机组； ●消防系统和监控系统检验； ●蓄电池放电测试；

●配电装置（高低压配电装置）的绝缘性定期试验； ●二次保护定值实验；

●每年雨季之前进行的数据中心防雷接地装置测试等。4.2.2 工单管理

运维团队应建立预防性维护及保养的工单管理系统，工单应列出工作内容、完成相应工作需要的工具及备件、工作预计完成的时间、工作负责人等信息。

计算机化维护管理系统应该对每份工单从产生到完成进行全程的跟踪。4.3 操作流程

机房基础设施的所有操作，均应事先制定详细的操作流程，经过审核后存档并在后期运行阶段严格执行。4.3.1 维护作业程序MOP 对机房关键基础设施设备的每次维护、维修、安装操作，都应事先制定一份MOP。可要求设备供应商提供MOP的建议，但对于MOP最终确认审核的责任在于运维团队，批准责任在于运维管理团队。4.3.2 标准操作流程SOP 所有关键基础设施设备在各种情况下都能执行的常用操作都应制定标准操作流程SOP。例如手动启动发电机组的操作流程，或将UPS转换到旁路的操作流程等。4.3.3 应急操作流程EOP 应急操作流程适用于有可能发生的严重故障情况。以下为部分严重故障的例子：

●一路市电供电时中断； ●双路市电供电时同时中断； ●单个精密空调时故障停机； ●全部精密空调都故障停机； ●单台UPS时故障停机。4.4 工具及备件管理

运维团队应根据资产分类清单及其分类制定最低备件库存清单并及时补充备件。

测试分析仪器仪表方面可配备进行电气性能参数测试、电池测试、接地电阻测试、绝缘性能测试、设备运行温度测试、风速测试、环境温度测试、噪音测试等的仪器仪表。仪器仪表应该定期校准。

应制定相关规定对操作工具、仪器仪表实行人员负责制或者交接班负责制等管理制度。备件和工具应定期进行盘点。4.5 供应商管理

应该按照机房基础设施运维的资质、以往的经验、业界的口碑等因素，以注重预防性和预测性维护和提高可用性的相同标准来选择合格的供应商。

所有供应商到达机房执行维护程序之前，应通过机房相关规程的培训，获得机房运维团队和运维管理层的批准。在执行维护活动的过程中要严格遵循操作流程。操作时需由运维团队的人员陪同并监督记录流程的执行情况。

供应商的每次机房维护活动都应该提交现场服务报告并存档。运维团队应该建立供应商的绩效评估方案，并定期对供应商进行绩效评估。应设立供应商管理文档，记录所有供应商的联系方式、服务承诺（SLA）、工作范围、针对设施的培训和认证情况等信息。4.6 生命周期管理

应基于设施设备的合理生命周期，结合风险评估，制定设备维护、升级或更换的计划及预算，及时报告给运维管理部门。

风险评估主要评估内容包括： ●资产重要性识别； ●资产威胁识别； ●资产脆弱性识别； ●风险值的计算；

●在评估更换设备的方案时，可综合考虑原有设备的维护费用以及新设备在能效方面的改进，做好综合投资回报分析；

●对于冗余设备宜设立轮换运行机制，以延长整体设备的生命周期。

4.7 运维管理系统 机房可建立自动化维护管理系统（MMS），集中实现资产管理、维护调度、信息安全、文档管理、工单管理的职能并记录所有的运维工作任务及完成情况。运行管理建议 5.1 运行管理制度

机房基础设施运维团队应建立并严格执行运行管理制度，包括：5.1.1 巡检相关管理制度

●日常巡视巡检管理制度； ●值班管理制度； ●交接班管理制度； ●通知矩阵。

5.1.2 工作流程相关管理制度

●工单处理流程； ●例会制度；

●工作总结报告制度（日、周、月、季、年总结报告）；●交付管理规范；

●运维质量管理办法文档管理制度； ●工具备件管理制度。5.1.3 安全相关管理制度

●机房出入管理制度； ●机房现场管理制度；

●机房卫生管理制度； ●信息安全相关管理制度。5.1.4 故障处理管理制度

●设备操作管理制度； ●设备故障处理流程； ●应急准备和应急响应流程； ●维护作业计划管理制度； ●故障隐患跟踪反馈管理制度； ●紧急事件汇报流程。5.1.5 经营相关管理制度

●员工行为规范； ●考勤管理制度； ●人员管理考核制度。

5.2 设施监控、巡检、及交接班管理

应配备环境、动力、安防等监控系统以便于运维人员及时了解设施各系统及设备的运行状态和及时发现异常情况。

应规定相应的运行人员对设施运行状态的巡视频次、巡视工作内容及规范。

运行人员交接班时应对当班执行的操作、变更及观察到的任何异常数据或现象进行交接和签收。5.3 机房清洁管理

应划定保洁区域，定期做好机房保洁工作，保证地板及地板下的无尘状态。重要区域进行保洁工作时应有运维人员现场监督和指导。5.4 标签标识管理

应建立针对数据中心场地基础设施设备和物理环境完整的、清晰的标签标识管理系统。应至少包括：

●设备标识：包括设备名称、型号、编号、资产编号等； ●线缆标识：包括起始端信息、终止端信息、设备名称等； ●警示标识：如“设备已带电/危险”、“禁止合闸”、“禁止分闸”等；

●物理环境标识：如位置标识、区域标识等；

●系统图展板标识：如电气、暖通、消防、弱电系统图展板。这类标识便于运维人员清晰、快捷地掌握区域及整个数据中心系统的配电、制冷、消防、弱电的原理及关键点位。5.5 变更管理

任何对于设施运行状态的变更应进行预先的风险分析，并基于风险等级，设定相应级别的事前审核流程。在变更方案及变更时间窗口确认后，应进行相应范围的告知。变更结束后，应向相应范围部门通报变更结果。5.6 事件管理

应制定事件管理流程，明确不同等级事件下相应的处理流程。5.6.1 事件等级定义

一般事件：任何没有达到机房设计和运行标准的异常事件； 严重事件：任何没有达到机房设计、运行标准的事件，且对提供的服务造成中断的事件；

重大事件：任何没有达到机房设计、运行标准的事件，且对提供的服务造成中断，且影响范围大的事件。5.6.2 事件升级

当事件暂时无法排除，需要逐级报告，进入事件升级流程。如遇特殊情况，与直接主管联系不上时，可越级向上一级主管报告。

5.7 应急响应

5.7.1 设施应急预案演练

运维团队应针对应急操作流程EOP进行定期的演练工作，主要包括：

●沙盘演练：参与演练的运维人员集合，并分别口述在发生紧急情况下自身所应承担的职责及将会执行的方案及步骤；

●跑位演练：参与演练的人员跑位到模拟故障现场，模拟处理故障，参与人员应清晰地说出故障的处理方案及步骤。

应急演练的演练原则是：尽量接近真实情况，在条件允许的情况下尽量真实地处理故障。在运行中的一些特定场景下也可以进行应急演练，如发电机带载实验等。5.7.2 人员安全应急流程

机房基础设施运维团队应针对影响运维人员健康的人身事故制定应急流程并定期演练。应急流程可包括设置现场急救包以及联系当地医疗急救机构的方式等。5.8 容量管理

容量管理可包括但不限于以下方面： 5.8.1 空间容量

●IT设备摆放空间； ●基础设备设施摆放空间； ●综合布线线路空间，配线架管理。5.8.2 能力容量

●电力供应容量； ●空调供应容量； ●综合布线信息点容量； ●互联网接入容量。

设施运维团队应与IT 部门定期沟通，动态了解IT需求的预测，并通报设施容量的使用情况。可制定3个月至36个月周期的IT需求及设施可用容量两者的对比分析表。

当机房基础设施不能满足IT增长的需求时，应提前制定并上报扩容或者新建机房的计划。5.9 能效管理 5.9.1 能效监测

机房基础设施运维团队应了解并记录机房在不同工况及不同外界气候条件下的电力使用效率 PUE 的变化情况，从中发现趋势，以不断优化运行方案。5.9.2 了解IT设备运行特征 机房基础设施运维人员应具备一定的IT设备相关知识，了解服务器、网络、存储等设备的运行特点和功耗情况。还应了解客户或用户的业务基本情况，了解IT 设备的运行峰谷期。

应与客户或用户相关部门做好沟通，针对高密度IT负载的部署做出预测，并制定相关应对方案。5.9.3 管理气流组织

应封堵设施建筑所有可能的漏风口，维持设施的正压。应疏导设施内气流的流向、封堵所有可能的漏风口、对机柜内所有空闲U位安装盲板、关闭不必要的出风口、保证冷空气的最佳使用效率。

5.9.4 运行阈值设定

应基于安全性及运行效率的综合考虑，建立运行阈值设定指南，设置监控报警阈值、空调回风温度等。5.10 预算管理

运维团队应做好运维财务预算，上报主管领导及财务部门，并做好预算必要性的沟通解释工作。

预算应包括但不限于以下内容： ●基于SLA的人力预算； ●备件及工具、仪器采购费用； ●应急维护材料费用；

●专业外包维保和应急服务费用； ●政策性等强制检测服务费用； ●整改或节能改造预算； ●突发问题备用金。

第四篇：云数据中心运维问题解析

1、云计算时代的到来，数据中心的运行管理工作必然会产生新的问题，提出新的要求，您认为，数据中心运维工作发生了哪些改变？

云计算是当下的技术热点，云数据中心是提供云计算服务的核心，是传统数据中心的升级。

无论是传统的数据中心，还是云数据中心，从他们的生命周期来看，运维管理都是整个生命周期中历时最长的一个阶段。

云数据中心的运维工作需要我们仔细分析，认真对待。从开源云计算社区openstack发布的模块来看，截止2014年11月，社区共有项目模块450个左右，模块数量前三的类型是“运维”、“易用性”、“上层服务”，其中运维模块数量第一，占到了153个。可见云计算的技术动向基本上围绕“如何运维”和“如何使用”。

我们今天的话题就先来说一说云数据中心运维的变化。说到云数据中心运维工作的变化，就要分析云的特点。云时代数据中心最明显的特点就是虚拟化技术的大量应用，这使得运维管理的对象发生了变化：

一、云数据中心运维对象数量激增。虚拟化技术将1台物理服务器虚拟为多台虚拟服务器，如果数据中心支撑业务需求规模不变的话，所需要的物理服务器数量将会减少，这与很多人认为的运维服务器数量激增是不符的，那么这个“激增”认识是如何产生的呢。可以这样分析，由于虚拟化技术进一步提高了数据中心各种资源的使用效率，同时大幅提高了业务需求响应能力，所以多个传统数据中心合并为一个云数据中心在技术上成为了可能。很多跨国企业采用云计算技术，实现数据中心10：1到20：1的合并效果，也就是说如果原来在全球建设1000个数据中心，那么现在可以由50到100个云数据中心实现对业务的支撑，在一个合并后的云数据中心内，所要运维的服务器数量绝对可以称得上“激增”，这里所说的服务器既包括物理服务器也包括虚拟服务器。与此同时，运维岗位也就是运维人员虽然也进行了调整，但是人员增加的幅度远低于设备的增涨幅度，也就是人均运维设备数量增加了很多，在这种情况下，如果不借助工具、系统，很难完成运维工作。

二、在传统数据中心中，设备都是物理的、真实的，位置也是相对固定，对业务系统来讲，交换网络、服务器、存储设备对象之间关联也是比较固定的，管理起来相对直观。在云数据中心，虚拟化带来了资源的池化，使得一切管理对象变成虚拟的、可灵活迁移的逻辑存在。虚拟资源可以随时创建、删除，再加上高可用需求、性能优化需求带来的虚拟资源迁移，虚拟资源所在的位置变得不固定了，虚拟资源与物理资源的关系也被解耦了，原来很多能说得清、找得到的资源现在不借助工具就再也无法说得清、找得到了。

三、在传统数据中心中，设备监控主要是采集故障、性能数据，容量一般来讲还不是运维层面的问题，而是规划的问题，当然这也带来了业务系统竖井、数据中心竖井的问题，以及业务资源申请周期长的问题。在云数据中心中，容量不仅是规划问题，同时也是一个运维问题。也就是说，在日常工作中，需要随时采集资源池容量数据，不仅要看资源池的总容量，还要看容量在各个物理宿主机上分布情况，以便满足高可用和迁移的需要。

四、云数据中心在管理虚拟设备时，接口的标准化问题。在传统数据中心内，物理设备已经形成了接口标准，提供运维数据，如snmp、netflow等。而对虚拟化设备，还没有形成国标或行标，对虚拟设备的运维还需要采用厂家标准。如果在一个云数据中心中采用了多个厂家的虚拟化系统，运维人员就需要熟悉多个厂家的界面。这个问题的解决，短期来看，需要一个融合的系统，为运维人员屏蔽多厂家虚拟化系统的差异，长期来看，希望能够形成各厂家虚拟化系统的统一接口标准。

云计算带来了IT服务成本的降低，提高了应对业务需求的敏捷性，同时，我们也要看到，如果云数据中心运维管理调整不及时，不但运维工作量不减反增，而且运维水平还会降低。

2、当数据中心发展到一定的规模，人们在数据中心管控要求的基础上，强调了流程化、自动化运维的模式，以便数据中心的运维工作能够更加快捷高效的开展起来，数据中心步入云时代，对于运维工作的流程化、自动化要求，云管理系统能给用户带来哪些价值？ 虚拟化技术是云数据中心的特点，但是云数据中心不仅仅是虚拟化。云数据中心响应业务需求的敏捷性，基于虚拟化，这是云数据中心的技术基础。

云数据中心以租用的方式向资源用户提供云服务，包括IaaS、PaaS、SaaS。从运维的角度讲，云服务的提供者要如何保障用户获得需要的服务呢。

云管理系统保障分配资源给用户的动作是自动化的，也就是说所有操作完全在线上完成，并且支持批量处理。

在云管理系统中，可创建并保存三个层面的资源模板，分别对应IaaS、PaaS、SaaS三个服务层面。用户申请某个或某些服务时，云管理系统就会按照相应的模版去创建资源。这是最基本的虚拟资源分配动作。

复杂一些的操作是可配置参数的资源模板，用户在申请服务时或运维人员在点击资源创建按钮前，可以传递一些参数给创建程序，如操作系统的用户名、密码，那么云管理系统在基于相应模板创建虚拟服务器时，会按照参数设置服务器操作系统管理员的账号信息。

再复杂一些的自动化动作，是基于模板组合进行的、有顺序的、有条件的动作序列，一般用作响应需要多个资源进行部署的业务系统的服务申请，通过一系列操作，为该业务系统分配网络地址、服务器、存储空间，并进行相关的配置，可定义动作执行的顺序以及后续动作执行的前提条件。对于特别复杂的动作组，允许进一步分割，也就是定义子动作组。

上述三种操作都是线上的、自动化完成的，这样的好处就是提高效率。云计算的好处之一就是敏捷分配，如果用户申请后，还要线下做很多配置，就会明显延长服务交付时间。同时基于模板的自动化操作也减少了人工线下操作的不确定性。

上面说完了运维的自动化，下面再说一下流程化。在云管理系统中，服务流程既包含了ITIL流程，如事件管理、问题管理、变更管理、发布管理等，同时也包含了云服务申请和审批的流程，如服务开通、服务变更、服务终止等。云管理系统还提供流程设计器和表单设计器，方便运维人员修改系统提供的服务流程，或者根据需要新建流程。

3、云时代数据中心最明显的特点就是虚拟化技术的大量应用，这使得管理的对象也在变化。以前的设备都是真实的，位置也是相对固定，管理起来相对直观。而应用虚拟化技术的结果是将这些资源进行“池化”，使得一切管理对象变成虚拟的、可迁移的存在，如何帮助用户面对这种挑战？

我们在谈云数据中心运维变化时，曾经提到过这个问题。在云数据中心，虚拟化带来了资源的池化，使得管理对象变成虚拟的、可灵活迁移的逻辑存在。运维人员很难再说清楚虚拟资源与物理资源的对应关系。

云管理系统会采集虚拟资源的运行数据，即时掌握资源之间的关系。首先是虚拟资源与物理资源的关联信息，比如虚拟机运行在哪台物理机上。其次，虚拟资源与虚拟资源的关系，如某台虚拟机与哪个虚拟网络设备的端口连接，某个虚拟磁盘挂载到了哪个虚拟服务器上。第三，物理资源与空间资源的关联，可以定位资源的实际部署位置。第四，物理资源与物理资源的关联关系。第三点与第四点与传统数据中处理方式并无不同。第五，云管理系统，还能够管理资源与业务系统的关系，以及资源与用户的关系。

通过云管理系统，运维人员可以即时掌握云数据中心中有哪些资源，资源的运行情况，以及资源之间的链接，资源分配给了哪个用户、哪个业务系统，资源在哪，这个在哪既包括了虚拟资源的分布也包括了物理资源的位置。

可以这么说，云管理系统以服务租用的方式向最终用户屏蔽了云数据中心内的资源情况，但是运维人员通过云管理系统能够清清楚楚、明明白白的掌握资源情况，包括虚拟的资源，也包括传统的资源。

4、目前，云数据中心管理的最大挑战除了上面提到的流程化、自动化和虚拟化，同时还要实现异构资源的融合管理，在这方面云管理系统是如何满足的？ 我们在谈云数据中心变化时，曾经提到过，如果云数据中心同时存在多个虚拟化系统，由于提供商执行各自的厂家标准，要如何去运维。当时我们提到了“融合”，也就是通过一个统一的管理系统，去融合、去屏蔽多个虚拟化系统的差异。

需要融合的虚拟化系统有很多，有商业产品，也有开源系统，在这我们不一一说明。但这只是虚拟资源范畴的融合，在我们实际的云数据中心运维工程中，我们发现，现阶段国内的很多云数据中心并没有全盘的虚拟化，这种现象在企业云数据中心中尤其普遍。企业中一部分业务系统部署在虚拟环境中，另外一部分业务系统部署在物理环境中，还有一些业务系统，部署环境同时存在物理资源及虚拟资源。

基于这种情况，云管理系统进一步扩大了“融合”的范畴，管理的资源范围不仅包括虚拟资源，还包括数据中心的物理资源、空间资源、动环资源，这样就把云数据中心全面地管理起来，既有传统的，也有虚拟的，而且传统资源和虚拟资源结合起来管理，使得云数据中心的运维更加的智能。比如，我要分配一个虚拟服务器，如果有动环资源的信息，我不仅可以基于宿主机也就是物理服务器的使用情况做策略，还可以考虑服务器所在区域的电能、冷能信息。

云数据中心是传统数据中心的升级，那么云数据中心的运维也应该是传统数据中心的运维升级，不应该缺少原有的运维能力。

5、云数据中心解决了业务系统部署的烟囱问题，通过资源池化及资源自动调度实现了灵活统一的业务部署，但不同的业务系统有其固有的专业性，对网络、计算、存储的规格要求各不相同，各个业务系统的服务要求、监控要求、故障处理要求等也存在差异，要做到业务系统的统一部署，又要满足特定需要，对于云数据中心“求同存异”的挑战，云管理系统是如何克服的？

云管理系统以服务租用的方式对云服务用户屏蔽了云数据中心的资源细节。以计算资源举例，一般情况下，云服务用户所看到的、分配给自己的服务器CPU配置都是虚拟的，也就是vCPU，他和物理CPU之间并没有一个统一的对应关系，甲用户和乙用户同样的虚拟服务器配置，可能由于宿主机品牌、型号、虚拟化方式、超配策略等，在计算能力上会有较大差异，当然，云服务提供的成本也会存在差异。这个差异再加上监控、维护等增值服务要求的差异，构成了不同等级的服务水平要求。

云管理系统在资源池划分方式上支持这种服务水平的差异性管理。云管理系统支持几种划分资源池的方式，其中一种就是按资源池等级进行划分并进行管理。可以定义不同等级的资源池，如金牌、银牌、铜牌，把物理资源及虚拟资源调度到不同等级的资源池中，用户、业务系统具有相应等级资源池的配额，在配额内可以申请、使用资源。其实，关于资源划分等级的做法在传统数据中心就有，在云数据中心中只是加入了虚拟资源而已。

6、对于数据中心而言，能效的问题为大家所关注，绿色数据中心的话题也一直再提，云管理系统是否能有效帮助云数据中心降低能耗？

虚拟化技术带来的一个好处就是降低能耗，这是基于虚拟机迁移技术实现的。前提是业务量在某一时间段内下降，物理机资源在这段时间内存在一定比例的空闲。最好是空闲的比例和时间是能够预见的，一般来讲，这个时间是夜晚。在这个相对空闲的周期内，通过迁移虚拟机到值班物理服务器的方式，实现部分物理服务器关机休息，达到省电的目的。

云管理系统同样采用这种方式，通过一段时间的监控，分析物理机资源空闲情况，包括每台物理机资源的空闲比例和空闲时间，每台物理机上运行虚拟机的配置情况，分析最优的虚拟机迁移目的地，最优的值班物理机“人选”，做到既省电，又不会因为部分服务器“休息”影响业务的性能。

第五篇：大型网站运维探讨和心得分享

大型网站运维探讨和心得分享

看到一篇不错的心得体会；相信我们做技术的都会有或多或少的担忧自己的未来职业发展，下面和大家一起来探讨一下。

一、什么是大型网站运维?

首先明确一下，全文所讲的”运维“是指：大型网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上亿（至少国内排名前10），如sina、baidu、QQ，51.com等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统、开发工作于一身的“复合性人才”，就如有些公司把一些合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责。所以，非常重要一定需要明白：运维对其它关联工种必须非常了解熟悉：网络、系统、系统开发、存储，安全,DB等；我在这里所讲的运维工程师就是指专职运维工程师。我们再来说说一般产品的“出生”流程：

1、首先公司管理层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计。

2、架构师根据产品设计的需求，如pv大小预估、服务器规模、应用架构等因素完成网络规划,架构设计等（基本上对网络变动不大，除非大项目）

3、开发工程师将设计code实现出来、测试工程师对应用进行测试。

4、好，到运维工程师出马了，首先明确一点不是说前三步就与运维工作无关了，恰恰相反，前三步与运维关系很大：应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能安全调优、服务器系统级优化（与特定应用有关）等都需运维全程参与，并主导整个应用上线项目；运维工程师负责产品服务器上架准备工作，服务器系统安装、网络、IP、通用工具集安装。运维工程师还需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责，并负责最后将产品（程序）、网络、系统三者进行拼接并最优化的组合在一起，最终完成产品上线提供用户使用，并周而复使：需求->开发（升级）->测试->上线（性能、安全问题等之前预估外的问题随之慢慢就全出来了）在这里提一点：网站开发模式与传统软件开发完全不一样，网站一天开发上线1~5个升级版本是家常便饭，用户体验为王嘛，如果某个线上问题像M$需要1年解决，用户早跑光了；应用上线后，运维工作才刚开始，具体工作可能包括：升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作： a、尽量将日常机械性手工工作通过工具实现（如服务监控、应用状态统计、服务上线等等），提高效率。

b、解决现实中服务存在的问题，如高可靠性、可扩展性问题等。

c、大规模集群管理工具的开发，如1万台机器如何在1分钟内完成密码修改、或运行指定任务？2000台服务器如何快速安装操作系统？各分布式IDC、存储集群中数PT级的数据如何快速的存储、共享、分析？等一系列挑战都需运维工程师的努力。在此说明一下其它配合工种情况，在整个项目中，前端应用对于网络/系统工程师来说是黑匣子，同时开发工程师职责只是负责完成应用的功能性开发，并对应用本身性能、安全性等应用本身负责，它不负责或关心网络/系统架构方面事宜，当然软/硬件采购人员等事业部其它同事也不会关心这些问题，各司其职，但项目的核心是运维工程师~！所有其它部门的桥梁。

上面说了很多，我想大家应该对运维有一些概念了，在此打个比方吧，如果我们是一辆高速行驶在高速公路上的汽车，那运维工程师就是司机兼维修工，这个司机不简单，有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快，汽车本身不能满足高速度时对汽车性能调优或零件升级、高速行进中解决汽车故障及性能问题、时刻关注前方安全问题，并先知先觉的采取规避手段。这就是运维工作~！

最后说一下运维工程师的职责：”确保线上稳定“，看似简单，但实属不容易，运维工程师必须在诸多不利因素中进行权衡：新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素，都会是网站稳定的大敌，运维工程师必须把控好这最后一关，需具体高度的责任感、原则性及协调能力，如果能做到各因素的最佳平衡，那就是一名优秀的运维工程师了。

另外在此聊点题外话，我在这里看到有很多人要sina、QQ、baidu,51.com等聊自已的运维方面的经验，其实这对于它们有点免为其难：

a、各公司自已网络架构、规模、或多或少还算是公司的核心秘密，要保密，另外，对于大家所熟知的通用软件、架构，由于很多公司会根据自已实际业务需要，同时因为原版性能、安全性、已知bug、功能等原因，进行过二次开发（如apache,php,mysql），操作系统内核也会根据不同业务类型进行定制的，如某些应用属于运算型、某些是高IO型、或大存储大内存型。根据这些特点进行内核优化定制，如sina就在memcache上进行过二次开发，搞出了一个MemcacheDB，具体做得如何我们不谈，但开源了，是值得称赞的，国内公司对于开源基本上是索取，没有贡献；另外，服务器也不是大家所熟知的型号，根据业务特点，大部份都是找DELL/HP/ibm进行过定制；另外，在分布式储存方面都有自已解决方案，要不就是使用现成开源hadoop等解决方案，或自已开发。但90%都是借鉴googleGFS的思想:分布式存储、计算、大表。

b、各公司业务方向不一样，会导致运维模式或方法都不一样，如51.com和baidu运维肯定区别很大，因为他们业务模式决定了其架构、服务器量级、IDC分布、网络结构、通用技术都会不一样，主打新闻门户的sina与主打sns的51.com运维模式差异就非常大,甚至职责都不大一样；但有一点，通用技术及大致架构上都大同小异，大家不要太神化，更多的公司只是玩垒积木的游戏罢了，没什么技术含量。

c、如上面所讲，目前大型网站运维还处于幼年时期理念和经验都比较零散，没有成熟的知识体系，可能具体什么是运维，大家都要先思索一番，或压根没想过，真正讨论也只是运维工作的冰山一角，局限于具体技术细节，或某某著名网站大的框架，真正运维体系化东西没有，这也许是目前网上运维相关资料比较少的原故吧。或者也是国内运维人员比较难招，比较牛的运维工程师比较少见的原因之一吧。

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

做为一名运维工程师需要什么样的技能及素质呢，首先说说技能吧，如大家上面所看到，运维是一个集多IT工种技能与一身的岗位，对系统->网络->存储->协议->需求->开发->测试->安全等各环节都需要了解一些，但对于某些环节需熟悉甚至精通，如系统(基本操作系统的熟悉使用,*nix,windows..)、协议、系统开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理）、通用应用（如lvs、ha、webserver、db、中间件、存储等）、网络,IDC拓朴架构； 技能方面总结以下几点：

1、开发能力，这点非常重要，因为运维工具都需要自已开发，开发语言：c/c++（必备其中之一）、perl、python、php（其中之一）、shell（awk,sed,expect….等），需要有过实际开发经验，否则工作会非常痛苦。

2、通用应用方面需要了解：操作系统（目前国内主要是linux、bsd）、webserver相关(nginx,apahe,php,lighttpd,java。。)、数据库(mysql,oralce)、其它杂七八拉的东东。。系统优化，高可靠性。。这些只是加分项，不需必备，可以边工作边慢慢学，这些东西都不难。当然在运维中，有些是有分工偏重点不一样。

3、系统、网络、安全，存储，CDN，DB等需要相当了解，知道其相关原理。个人素质方面：

1、沟通能力、团队协作：运维工作跨部门、跨工种工作很多，需善于沟通、并且团队协作能力要强；这应该是现代企业的基本素质要求了，不多说。

2、工作中需胆大心细：胆大才能创新、不走寻常路，特别对于运维这种新的工种，更需创新才能促进发展；心细，运维工程师是网站admin,最高线上权限者，一不小心就会遗憾终生或打入十八层地狱。

3、主动性、执行力、精力旺盛、抗压能力强：由于IT行业的特性，变化快；往往计划赶不上变化，运维工作就更突出了，比如国内各大公司服务器往往是全国各地，哪里便宜性价比高，就那往搬，进行大规模服务迁移（牵扯的服务器成百上千台），这是一个非常头痛的问题；往往时间非常紧迫，如限1周内完成，这种情况下，运维工程师的主动性及执行力就有很高的要求了：计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯皮,7X24小紧急事故响应等。

4、其它就是一些基本素质了：头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观。

5、最后一点，做网站运维需要有探索创新精神，通过创新型思维解决现实中的问题，因为这是一个处于幼年的职业（国外也一样，但比国内起步早点），没有成熟体系或方法论可以借鉴，只能靠大家自已摸索努力。

三、怎样才算是一个合格的运维工程师

1、保证服务达到要求的线上标准，如99.9%；保证线上稳定，这是运维工程师的基本责职所在。

2、不断的提升应用的可靠性与健壮性、性能优化、安全提升；这方面非常考验主动性、和创新思维。

3、网站各层面监控、统计的覆盖度，软件、硬件、运行状态，能监控的都需要监控统计，避免监控死角、并能实时了解应用的运转情况。

4、通过创新思维解决运维效率问题；目前各公司大部份运维主要工作还是依赖人工操作干预，需要尽可能的解放双手。

5、运维知识的积累与沉淀、文档的完备性，运维是一个经验性非常强的岗位，好的经验与陷阱都需积累下来，避免重复性范错。

6、计划性和执行力；工作有计划，计划后想法设法达到目标，不找借口。

7、自动化运维；能对日常机械化工作进行提炼、设计并开发成工具、系统，能让系统自动完成的尽量依靠系统；让大家更多的时间用于思考、创新思维、做自已喜欢的事情。以上只是技术上的一些层面，当然个人意识也是很重要的。

四、运维职业的迷惘、现状与发展前景

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

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

1、处于刚起步的初级阶段，各大公司有此专职，但重视或重要承度不高，可替代性强；小公司更多是由其它岗位来兼顾做这一块工作，没有专职，也不可能做得深入

2、技术层次比较低；主要处于技术探索、积累阶段，没有型成体系化的理念、技术。

3、体力劳动偏大；这个问题主要与第二点有关系，很多事情还是依靠人力进行，没有完成好的提练，对于大规模集群没有成熟的自动化管理方法，在此说明一下，大规模集群与运维工作是息息相关的如果只是百十来台机器，那就没有运维太大的生存空间了。

4、优秀运维人才的极度缺乏；目前各大公司基本上都靠自已培养，这个现状导致行业内运维人才的流动性非常低，非常多好的技术都局限在各大公司内部，如google50万台机器科学的管理,或者国内互联公司top10的一些运维经验，这些经验是非常有价值的东西并决定了一个公司的核心竞争力；这些问题进而导致业内先进运维技术的流通、贯通、与借签，并最终将限制了运维发展。

5、很多优秀的运维经验都掌握在大公司手中；这不在于公司的技术实力，而在于大公司的技术规模、海量PV、硬件规模足够大，如baidu可怕的流量、51.com海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的，或即将遇到。但大公司可能已有很好的解决方案或系统。发展前景：

1、从行业角度来看，随着中国互联网的高速发展（目前中国网民已跃升为全球第一）、网站规模越来越来大、架构越来越复杂；对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大，而且是越老越值钱；目前国内基本上都是选择毕业生培养（限于大公司），培养成本高，而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展；当然，毕业生也有好处：白纸一张，可塑性强，比较认同并容易融入企业文化。

2、从个人角度，运维工程师技术含量及要求会越来越高，同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视。

3、网站运维将成为一个融合多学科（网络、系统、开发、安全、应用架构、存储等）的综合性技术岗位，给大家提供一个很好的个人能力与技术广度的发展空间。

4、运维工作的相关经验将会变得非常重要，而且也将成为个人的核心竞争力，具备很好的各层面问题的解决能力及方案提供、全局思考能力等。

5、特长发控和兴趣的培养；由于运维岗位所接触的知识面非常广阔，更容易培养或发挥出个人某些方面的特长或爱好，如内核、网络、开发、数据库等方面，可以做得非常深入精通、成为这方面的专家。

6、如果真要以后不想做运维了，转到其它岗位也比较容易，不会有太大的局限性。当然了，你得真正用心去做。

7、技术发展方向、网站/系统架构师。

五、运维关键技术点解剖

1、大规模集群管理问题

首先我们先要明确集群的概念，集群不是泛指各功能服务器的总合，而是指为了达到某一目的或功能的服务器、硬盘资源的整合（机器数大于两台），对于应用来说它就是一个整体，目前常规集群可分为：高可用性集群（HA），负载均衡集群（如lvs），分布式储、计算存储集群（DFS，如googlegfs,yahoohadoop），特定应用集群（某一特定功能服务器组合、如db、cache层等），目前互联网行业主要基于这四种类型；对于前两种类似，如果业务简单、应用上post操作比较少，可以简单的采用四层交换机解决（如f5），达到服务高可用/负责均衡的作用，对于资源紧张的公司也有一些开源解决办法如lvs+ha,非常灵活；对于后两种，那就考验公司技术实力及应用特点了，第三种DFS主要应用于海量数据应用上，如邮件、搜索等应用，特别是搜索要求就更高了，除了简单海量存储，还包括数据挖掘、用户行为分析；如google、yahoo就能保存分析近一年的用户记录数据，而baidu应该少于30天、soguo就更少了。。这些对于搜索准备性、及用户体验是至关重要的。接下来，我们再谈谈如何科学的管理集群，有以下关键几点： I、监控

主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行，及潜在问题的及时发现与干预；

a、服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端webserver，我们就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否crash、通过icmp包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，常用方法是采用面业特征码进行判断，或对重点页面进行签名，以网站被黑篡改（报警、并自动恢复被篡改数据）等等，这些只是一部份，还有N多监控方式，依应用特点而定，还有一些问题需解决，如集群过大，如何高性能的进行监控也是一个现实问题。

b、其它就是集群状态类的监控或统计，为我们合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击等问题。II、故障管理 a、硬件故障问题；对于成百上千或上万机器的N多集群，服务器死机、硬件故障概率是非常大的，几乎每时每刻都有服务硬件问题，死机、硬盘损坏、电源、内存、交换机。针对这种情况，我们在设计网站架构时需要充分考虑到这些问题，并将其视为常态；更多的依靠应用的冗余机制来规避这种风险，但给系统工程师足够宽裕的处理时间。（如google不是号称同时死800台机器，服务不会受到任何影响吗）；这就是考验运维工程师及网站架构师功能的地方了，好的设计能达到google所描述自恢复能力，如gfs，糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映，直接对用户拒绝响应。

b、应用故障问题；可能是某一bug被触发、或某一性能阀值被超越、攻击等情况不一而定，但重要的一点，是要有对这些问题的预防性措施，不能想当然，它不会出问题，如真出问题了，如何应对?这需要运维工程师平时做足功夫，包括应急响应速度、故障处理的科学性、备用方案的有效等。III、自动化

自动化：简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手及枯燥的重复性劳动，例如：没有工具前，我们安装系统需要一台一台裸机安装，如2000台，可能需要10人/10天，搞烂N张光盘，人力成本更大。。而现在通过自动化工具，只需几个简单命令就能搞定、还有如机器人类程序，自动完成以往每天人工干预的工作，使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是/非判断、优化选择等。。这些好处非常明显不再多说。。应该说，自动化运维是运维工程师职业化的一个追求，利已利公，虽然这是一个异常艰巨的任务：不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化、变因参数化等因此，自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现。

2、运维中关键技术点解剖（比较实际，现实中的案例，今天先想出这几条，如大家有其它感觉兴趣的，可以提出，一起交流～）

1、大量高并发网站的设计方案

2、高可靠、高可伸缩性网络架构设计

3、网站安全问题，如何避免被黑？

4、南北互联问题,动态CDN解决方案

5、海量数据存储架构