IT运维心得分享范文

第一篇：IT运维心得分享范文

360公司运维心得分享

在很多“外人”的眼中，运维工程师的工作不过是搬机器、调网络、装软件、处理故障、7×24小时值班，简单而又枯燥至极。但事实并非如此，运维工作涵盖很多技术领域，运维工程师要掌握硬件、软件、操作系统、开发等多方面的知识，核心目标是为亿万用户使用的产品保驾护航。

当今互联网行业的发展日新月异，新技术层出不穷。为了适应发展趋势，运维工程师只有提升技术能力才能更好地完成艰巨的运维任务，必须要对传统运维发出自我挑战。

在360，运维团队由基础运维团队、网络运维团队和应用运维团队三部分组成。我们将运维从技术支持领域升级，进行产品化改进，核心目标是为了降低运维成本、缩短研发周期、让产品试错更廉价。理想很丰满，现实很骨感，从最初服务少量项目、几十台服务器，发展到大量具有数亿用户的项目，我们也在不断摸索，在试错中成长。在这个过程中，我们经历了两次重要的升级。第一次升级：运维工具化

运维工作中有很多琐碎的、重复的事情，初期我们只有两个IDC，服务器数量有限，项目数量也较少，靠纯手工劳作还可以应付。但随着时间的推移，项目暴增，随之IDC和服务器的数量也成倍增长，同时360各项目都是小团队在做，开发风格不同、习惯各异，但极致要求响应速度，如果运维工作按照之前方式进行，很难满足需求。大势所趋，我们必须进行工具化升级，将重复的事情自动化。

在工具化过程中，我们秉着低成本、拿来即用的原则，借鉴业界成型的方案，同时将精力用在对开源软件的研究中，有开源工具就绝不自己凭空创造。初期，我们只围绕开源软件做周边脚本开发，不动核心代码，在实践中总结经验。例如，在最基础的部署软件环境中，我们基于YUM搭建了自己的包管理系统，将常用软件打包，同时根据项目做成模板，这样无论是初始安装还是扩容都能在分分钟完成。配置文件管理利用Puppet完成，服务器批量操控依赖SaltStack。就这样 我们的运维兵器谱在不断地丰富。

另外，运维工作离不开监控报警，这是一件让无数运维人苦不堪言的事情。而会休息才会工作，监控体系必须优化。

我们的监控大概分为系统级、应用级、项目逻辑和用户体验四部分。系统级主要监控硬件和网络等；应用级主要监控常用软件的健康状况；项目逻辑监控主要模拟用户行为探测项目功能点是否运行正常；用户体验监控主要联动博睿和基调等第三方监控一起优化用户体验。我们用过的工具很多，开源工具有Nagios、Cacti、Ganglia、Zabbix等，同时自己也开发了一些针对项目场景的监控工具，但万变不离其宗，都是围绕上述几个维度进行监控，然后再进行分级预警和报警。

为了减少报警骚扰，我们分级处理，将报警分为邮件预警、短信报警和疯狂短信报警。以磁盘空间监控为例：每天下午6点，统计 磁盘使用率超过80%的机器，发出邮件预警，下班前解决；在预警的基础上，超过85%触发短信报警；超过90%就要持续报警，避免事故的发生。此外，随着 服务器数量的增多，硬件故障在所难免，架构设计需要考虑高可用方案，冗余范围内的服务器故障会以邮件预警的方式发出，避免对运维工程师的骚扰。

有了监控工具和分级机制，还需要有好的制度。为了大部分人可以安心休息，我们每天有专人负责处理常规报警，遇到无法解决的问题才要求他人协助。第二天的负责 人要针对第一天的报警找出根本原因，并尽力解决，因为如果无法根治，困扰将持续发生。所谓线上无小事，实际工作中复杂场景引发的问题数不胜数，所以可以宽 容第一次错误，但不能接受同样问题发生第二次，要不断地总结和完善。

工具化是运维的必经之路，是向更高层发展的基础，面对运维这样复杂的学科，这样一个极其磨炼人意志的工种，运维工程师需要用聪明的方式解决复杂的问题，节省时间，去做更有意义的事情。

第二次升级：运维产品化

我刚提出运维产品化时，有朋友开玩笑说，你做后端运维吃苦受罪这么多年，看着产品经理吃香的喝辣的，羡慕嫉妒也想转行做产品吧。也有人说，你是在偷换概念，不就是做自动化运维平台嘛。其实提出这个概念，一方面是源于有了足够的工具化积累；另一方面是想换一种思路做运维，培养产品观，站在用户的角度思考问题，让处于后端的运维工程师主动挖掘需求，围绕运维做更多的探索，提升团队技术能力，解决海量用户带来的问题。有了这个想法，就需要将无形的技术转变为有形的产品形态，同时要赋予它好的寓意。我们的产品取名为HULK——绿巨人，意在让小伙伴们借助巨人的肩膀成长，轻点鼠标，运筹帷幄。

想到做这个平台，源于对实际工作需求的观察。产品经理有了创新点之后，开发工程师就想以最快的速度上线，但又会很痛苦，因为产品就好比宝塔明珠，塔基需要一 层层地盖。而开发工程师是与运维工程师合作最紧密的兄弟，“兄弟有难得拔刀相助”，因此我们明确了开发工程师就是运维平台的用户，运维工程师在平台的建设 中扮演了多重角色，是建设者也是使用者，但目标是为用户解决问题，让我们的用户有极致的用户体验。基于这些想法，我们勾画出了宏伟蓝图，提供一个塔基，第一层提供核心基础服务，如Web、RDB、NoSQL等；第二层提供通用基础服务，构造一个完美的平台，让开发工程师受益。但勾画的平台功 能大而全，需求都是我们替用户假想的，这样做的后果就是进展缓慢，但做出的功能没人用。我们在失败中反思，意识到需求还得从日常工作中去挖掘，平台上每个功能模块都必须解决用户的痛点。互联网精神唯快不破，要围绕“快”找痛点。早期开发和运维的合作中，更多的是邮件、IM及当面沟通，跨团队的沟通成本是第 一个痛点。初期平台建设中，我们从加速流程开始进行摸索，以“需求任务流”为核心，将通用需求规范流程，统一需求提交页面，同时尽量为用户提供选项，而不是随意填写，尽量减少沟通成本，同时为完全自动化打好基础。由于完整的自动化流程开发成本比较高，初期我们还“投机取巧”，用户提交需求以后，只是把格式 化的邮件发送给运维工程师。运维工程师使用半自动化工具干活，完成后再通过平台任务流告知用户结果，手工操作的部分是隐藏在平台后面的，用户不得而知。就 用这种方式，我们的平台积累了不少用户和口碑。之后我们将日常需求分层、分类：主机类包括主机申请、账号授权、软件部署等；Web类包括配置文件管理、域名管理等；DB类包括建库、建表、SQL审核、授权等。再攻克技术难点将一个个需求实现完全自动化，点点鼠标解决问题。

关于需求任务流，还有个小插曲，标准的任务流由提交、审核、驳回/通过组成。但这个流程太死板，例如用户提交的一个需求，在审核的过程中有待商榷，运维工程师会和开发工程师 沟通，最终达成一致意见即可，而如果按标准流程需要驳回再提交。为了让用户少一次操作，我们增加了管理员可编译功能。有些同事反对这样做，觉得不符合常 理。不过有时候常理是需要结合实际场景打破的，就为了让用户使用更简单。

近期为了进一步提升项目试错阶段的速度，我们在平台上推出了一个新功能：“项目孵化器”。以典型的Web业务为例，以往，申请Web Server、账号、数据库实例、负载均衡等是提给运维最基本的需求，每一步都是时间成本。使用“项目孵化器”可以最大限度解决这个痛点，只需在平台上进 行两个步骤：第一步填写业务名称，预估峰值QPS；第二步选用MySQL、MongoDB、Redis等相关数据库资源。两步之后，Web Server、数据库实例等所需资源会瞬间展示在用户面前，同时包管理、配置文件管理、代码发布系统、监控系统等配套辅助功能随之开通。

与之前的模式相比，效率和规范化都有明显提高。说起来很神奇，但实现理念很简单，我们提炼日常项目中的通用方案，构建资源池，在项目发展初期最小量匹配资源。在孵化器的设计阶段，我们听到了很多不同的声音。例如，让用户填信息不够全面，架构太简单不满足全部需求，诸如此类问题，让人头痛欲裂。经过过往项目 分析及用户调研，发现项目尚处于试错阶段，快速试错是首要需求。至于项目发展中衍生出来的需求，可以再用平台扩展功能去解决。当利用孵化器建立一个试错项目之后，用户进入平台想看见什么？展现形式如何？还能做什么？这些问题随之而来。

众所周知，项目中的关联关系是个复杂的问题，解决不好，就像一盘散沙无法联动。为了解决此问题，首先我们确定平台各功能模块以项目名为主键，将项目的域名、负载均衡、Web Server、数据库、通用基础服务等相关联。项目后期各功能模块的扩容可以借助关联关系自动化完成。例如增加一台Web Server，即可自动部署软件环境，完成相关节点授权、上传代码、测试上线。

展现形式上我们借鉴社交网站的实现方案，以“我的项目”为中心，用户进入平台以后默认页展示项目在平台中用到的各功能模块信息，例如域名、主机数量、数据库实例和监控指标等。做到信息清晰可见，操控简单易用。

在平台建设中，我们一直遵循两个准则：第一，把事情由复杂变简单；第二，给用户极致的用户体验。所谓极致，就是要超出用户的预期，但只有挖掘用户潜在的需求，才能做出超出预期的功能。传统的运维模式，大多是开发工程师提需求，运维工程师满足需求，运维工程师主动推进的意识不够。360的文化中有很重要的一点是Ownership，一个项目的成功与失败，运维工程师是有责任的，因此需要在日常工作中时刻提醒自己“这个项目是我的，为了让项目变得更好，我们需要主动思考，为开发工程师提供更多的增值服务”。例如一个项目上线前，会默认部署日志收集模块，收集汇总后进行访问日志自动化分析，以时间维度展示访问量走势，同时辅以IP地址分析模块展示地域及运营商分布。同时基于访问日志状态码做进一步的页面分析，然后以日、周、月维度生成一份体检报告，以及应对方案推送给开发工程师。这些增值服务是超出预期的，拉近了开发工程师和我们的距离，一起去探讨、改进，做出更多有利于项目发展的功能。结束语

运维工作在一家公司中至关重要，但传统的运维模式一定程度上限制了运维工程师的技术发展，更抑制了创新思维，我们需要利用运维“宽泛技术”定位的优势开拓思路。例如运维工作需要和很多开发团队合作，协助架构设计，在这个过程中会接触到很多开发团队的技术积累，可以把各家之所长进行聚合，将一些基础服务进行平台化改造，资源共享。也可以根据项目的需要，主动做技术研究，将基础服务做成一个个小产品，提供给开发团队使用，帮助项目缩短研发周期，稳定发展。在当今技术背景下，运维工程师应该在红海中寻找蓝海的思维模式，培养产品观，由外至内地思考，突破传统运维的壁垒，开拓创新。

第二篇：网络运维培训心得（精选）

第四期网络运维培训心得体会

随着网络时代的到来，网络学习为我们提供了新的人生起点，迎来了新的教育方式，让我们随时随地不受地区、时间与空间的限制，能够快捷、方便地接受更多的新的知识，寻找到适合我们自己的教育教学方法。在网络学习中我与同行们互相交流，互相学习，在互动中我学到了一些粗浅的网络知识，从不知怎样建立博客、怎样进入博客到怎样发表文章等。老师们的答疑解惑让我在学习上信心百倍，更使我的学习进步很快，教育教学工作有了动力和努力的方向。是网络学习让我体味到了人生从来未有过的快乐与欣喜。

网络就象一个强大的磁场，深深地吸引着我，影响着我。使我把它融入我教学工作之中。利用网络教学有助于构建新型的教学模式，真正对教育教学起到全方位的变革作用。

2017年11月24日我参加了鄂尔多斯市信息办组织的第四期网络运维培训。本次培训，我受益良多，现总结心得如下：

本次培训是有包头科技学院的老师以及工程师给我们讲授的，在他们崭新的图书馆电子教室里，刘老师首先强调了“智力储备”。在新的信息技术快速发展的时代，提前储备了足够的知识，就占领了技术的前沿，这是我今后努力的方向。赵老师讲得精简干练，但让我认识到要有作为就要有目标，有思路，有方法，要有管理方案。翟老师语重心长的告诉我们，我们要作为一名管理者，而不是维修工，更让我们的工作有了主体方向。

曾记得开幕的第一天特别的开心，我们学员们做到属于自己的桌子上，由包头科技大学的刘老师致开幕词，刘老师精美的语速，富有风趣的讲解，带来了一阵阵热恋的掌声，刘老师强调了学习的时间安排，上午讲解的老师，以及下午讲解的老师，晚上实验课的老师等等，可想而之老师们对我们学习的认真，对我们学习的上心，我们也下定决心尽自己的最大努力在这仅有的十天中，把我们学习的知识学好，学通，以便日后回到自己的岗位学以致用。

接下来工程师为我们着重讲解了操作系统、应用软件等相关知识。Win7系统要留够50GB的空间，尽量使用纯净版系统进行安装，惭愧的说，我日常用的系统都是Ghost版本，里面总是或多或少有一些广告软件等等，往往给系统的稳定性带来不良后果。这是今后应该注意的地方了，由于自己是首次接受这么大规模的培训，由于工程师的语言过快，思路过于敏捷，使得我很难跟的上，学起来也是非常的吃力，有一点力不从心的感觉，信好工程师老师从我们僵硬的脸上看出了我们的不懂，他有从新的细细的讲解，直到我们听明白，听懂得为止。像这样的老师我只能说是非常非常的敬业，认真。

还学到了一个很有用的dos命令：ipcongfig /all >d:ip.txt这个命令用来备份维修机的IP地址十分方便，要记住，要常用。

对于电脑故障的排查，工程师介绍了计算机系统故障的判断思路和方法：

1、先软件后硬件。

2、先电源后负载。

3、先表面后里面。

4、先外设后主机。

5、先一般故障后特殊故障。

6、先公共性故障后局部性故障。

7、先主要性故障后次要性故障。这些方法十分有助于我理清思路，找到真正的故障所在，能有效的提高工作效率。

工程师还重点介绍了Ghost这个工具软件的使用。尤其是Ghost Explorer 这个小软件的运用是我以前较少使用的。经过学习我了解到：它是一款可以对ghost生成的映像文件进行解压、查看以及编辑程序，利用他可以非常简单的对 GHOST 映像文件进行编辑，可以按自己的意愿向映像文件里添加、删除文件，也可以将需要的文件提取出来。这样，以后再维修无法开机的电脑时就能为老师们最大限度的保留数据了。

关于网络管理工作，还属包头科技大学的赵老师，讲得深入浅出，Ipconfig 命令，Netstat，Nslookup 命令还有用于检查路由tracert 命令等都十分的实用。他还通过分析一些网络故障实例教会我们一些更实际的运用。还给我们讲解了城域网网络分析系统的功能和使用方法。路由器交换机的配置，以及IP地址的分类，子网掩码的计算划分，城域网的建设以及在讲授的过程中不乏讲解他自己的一些学习经历，谋财之道等等知识。

网络为我们提供了丰富的教学情景，它淡化了课堂与“真实世界”之间的距离，扩展了教师的学习空间，在真正意义上实现了教师与真实世界的接触与联系。语文课堂上，课前我们可以到网络上搜索资料（包括文本、图片等），课上再把搜集到的大量资料与伙伴交流共享。在这样的学习情境中，教师可以积极主动去探求知识，保持最旺盛的求知欲望，对资料的搜集、整理与分析为学生批判性思维与创造性思维的培养搭建平台，有利于建构新型的教学模式。

网络学习有利于教师共同探究问题，网上交流等活动，使业余生活趣味化，其核心是要发挥教师学习的主动性、积极性，网络的学习能够给予教师一个自主学习的空间。

参加网络学习，对于我们一线教师来说，绝不是为了一时的兴趣，更不是为了完成任务或是赶时髦、装门面。而是要通过知识的积淀，充实自己、完善自己。铺设一条使自己成为一名合格教师的人生之路。

达拉特旗第二期张伟 时间：2017年12月11日

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

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

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

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

首先明确一下，全文所讲的”运维“是指：大型网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器量级、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、海量数据存储架构

第四篇：IT运维工作心得总结

运维工作心得总结

运维工作直接关系到应用系统运行的正常稳定，但运维工作纷繁复杂，正规化、系统化相对比较弱，如何改变这种现状？从众多的运维工作者的成功失败中进行经验总结，并提升为运维规则，是提高运维水平，保障应用系统正常稳定运行的有效途径。

笔者通过自己的多年运维经验，总结出以下必须遵守的基本运维规则，可以大大减少缺乏经验的运维人员因为自身失误导致系统出故障的可能性。

一、系统变更、升级应先在同样的环境测试通过，执行前应有经过验证的回退预案

运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你出意想不到的难题，因此变更前，一定要在相同或者相似运行环境下进行测试，通过后才能在正式环境下执行变更。同时应准备好变更失败的回退预案，比如，做好系统备份、数据库备份、配置备份，固化变更前的运行现场，让变更有回头的机会。

二、对破坏性的操作要先确认符合预定方案，然后谨慎执行

什么是破坏性的操作？ 比如：

对MSSQLServer，执行update操作，因为不需要commit，所以特别容易忽视也特别危险，还有delete、drop等操作更不用说。

对 Oracle 而言：truncate table_name、delete table_name、drop table_name，这些语句执行起来轻松简单也惬意极了、但记住！即便数据可被回滚、代价也是非常大！

对 Linux 而言，rm-r 所有当前及其子目录的所有数据都将被删除。经历过这种故障的人、大多会给 rm 上个别名 A liasrm='rm-i' 同理、cp 和 mv 也可以有同样的选项：

aliascp='cp-i' alias mv='mv-i' 对window而言，shift+del文件或者目录 对任何系统而言，无备份直接修改文件等

三、备份并验证备份的有效性

不管是硬件还是软件总有意外崩溃的时候，怎么办？备份！！备份的学问很大、按照不同的维度可以分：冷备和热备、实时和非实时、物理和逻辑、全备增量备。

备份有了、可以高忱无忧了吗？不行！尚须验证备份的有效性。一个总有那么几次、备份无法保证 100% 恢复，简单的验证就是找个空库恢复出来。

四、对生产环境永保敬畏之心

这是避免应用系统发生故障的一条铁规，也是被开发、运维人员容易忽视的地方。要坚决杜绝直接在生产环境做开发、测试和bug修复，这些操作只能在开发和测试环境做，否则一旦出事，将欲哭无泪。

五、交接和休假最容易出故障

接手别人的工作要一而再，再而三的确认变更方案，请教人并不见得就是能力不行的表现；

 休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人；

 在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原系统管理人员确认各个操作细节。 六、一定要有监控手段和报警措施

运维人员赖于生存的工具就是报警和监控。

报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮；

 监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替、早做优化。

报警和监控是衣宽带水的好兄弟、相铺相成、互相促进。

七、使用自动切换技术需谨慎

为了保障数据库安全，往往会使用HA或者RAC之类的技术，但是这类技术能否真正在关键时刻起作用，则是需要经过反复验证和确认的。并不是按照文档要求做好了就够的，很多意外因素或者系统因素会导致自动切换技术并不能如期发挥作用。如果到事后才发现这一点，将悔之晚矣。

八、要有偏执狂的精神，方案要检查，检查，再检查

有这么一个人： ① 他在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人

② 在测试机上写好脚本，召集大家 review 操作步骤和脚本 ③ 测试完成以后拷贝到生产环境

④ 登录对应机器，“打开，关闭，打开，关闭”该脚本

⑤ 跟相关人员再次确认执行的操作，顺序，时间点，可能的影响和回滚是否都准备好了

⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本 ⑦ 最后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出

期间姿势端正，呼吸急促而均匀，眼神凝重。操作的人不觉得累，倒是一边观摩的人很累。

九、简单即是美

我们总是面临各种诱惑：新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件...你可以在线下安装，测试，怎么做都行。但是如果想要在生产环境下使用起来、请三思！

能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了  脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做  Linux本身自带的字符界面比那些复杂的图形界面要简洁方便 

如果能做到坚持这九条铁规，你的应用系统就能长久稳定运行了。

第五篇：国家电网变电运维培训心得

体验变电运维 感受美好生活

平凡的岗位，不平凡的经历。培训生活已经进行了大半，一切都在有条不紊的继续进行中，生活总是在忙碌中在能体会到充实和愉悦，培训的这四个月，终将会成为我们的美好回忆。

在过去的培训生活中，我们从无到有，从第一次进行倒闸操作的那一刻，我们在心里就已经明确的认知了自己的工作性质，从枯燥到疲累，从满心欢喜的跃跃欲试到真正了解了工作的辛苦与劳累，从一无所知到胸有成竹，我们在这段历程中整的收获了很多很多，时常会想起自己初来乍到时的满头雾水，到一点点接受适应培训生活的从容不迫，我们在这段经历中真的是成长了太多太多。

想起之前培训时的迷惑与不解，慢慢的才感悟到的的确确的应该用心做好本职工作，只有这样脚踏实地地认认真真的做好每一件事，生活才会充满阳光，工作才会充满乐趣，梦想才会向自己靠拢，人生才会有所作为。今天的我们不管有多麽的平凡，我们也要告诉自己：“一定要做平凡岗位中最优秀的那一位。”用力做工作才能把工作做完，用心工作才能把工作做好。假如你热爱工作，那你的生活就是天堂。假如你讨厌你的工作，你的生活就是地狱。把每一件小事都和自己心目中的目标结合起来。力争做出最优秀的成绩来，人生的理想才能逐步实现。要相信，你的梦想就在你的前方。