IT运维心得分享范文.docx

IT运维心得分享范文

第一篇：IT运维心得分享范文360公司运维心得分享在很多“外人”的眼中，运维工程师的工作不过是搬机器、调网络、装软件、处理故障、7×24小时值班，简单而又枯燥至极。但事实并非如此，运维工作涵盖很多技术领域，运维工程师要掌握硬件、软件、操作系统、开发等多方面的知识，核心目标是为亿万用户使用的产品保驾护航。当今互联网行业的发展日新月异，新技术层出不穷。为了适应发展趋势，运维工程师只有提升技术能力才能更好地完成艰巨的运维任务，必须要对传统运维发出自我挑战。在360，运维团队由基础运维团队、网络运维团队和应用运维团队三部分组成。我们将运维从技术支持领域升级，进行产品化改进，核心目标是为了降低运维成本、缩短研发周期、让产品试错更廉价。理想很丰满，现实很骨感，从最初服务少量项目、几十台服务器，发展到大量具有数亿用户的项目，我们也在不断摸索，在试错中成长。在这个过程中，我们经历了两次重要的升级。第一次升级：运维工具化运维工作中有很多琐碎的、重复的事情，初期我们只有两个IDC，服务器数量有限，项目数量也较少，靠纯手工劳作还可以应付。但随着时间的推移，项目暴增，随之IDC和服务器的数量也成倍增长，同时360各项目都是小团队在做，开发风格不同、习惯各异，但极致要求响应速度，如果运维工作按照之前方式进行，很难满足需求。大势所趋，我们必须进行工具化升级，将重复的事情自动化。在工具化过程中，我们秉着低成本、拿来即用的原则，借鉴业界成型的方案，同时将精力用在对开源软件的研究中，有开源工具就绝不自己凭空创造。初期，我们只围绕开源软件做周边脚本开发，不动核心代码，在实践中总结经验。例如，在最基础的部署软件环境中，我们基于YUM搭建了自己的包管理系统，将常用软件打包，同时根据项目做成模板，这样无论是初始安装还是扩容都能在分分钟完成。配置文件管理利用Puppet完成，服务器批量操控依赖SaltStack。就这样我们的运维兵器谱在不断地丰富。另外，运维工作离不开监控报警，这是一件让无数运维人苦不堪言的事情。而会休息才会工作，监控体系必须优化。我们的监控大概分为系统级、应用级、项目逻辑和用户体验四部分。系统级主要监控硬件和网络等；应用级主要监控常用软件的健康状况；项目逻辑监控主要模拟用户行为探测项目功能点是否运行正常；用户体验监控主要联动博睿和基调等第三方监控一起优化用户体验。我们用过的工具很多，开源工具有Nagios、Cacti、Ganglia、Zabbix等，同时自己也开发了一些针对项目场景的监控工具，但万变不离其宗，都是围绕上述几个维度进行监控，然后再进行分级预警和报警。为了减少报警骚扰，我们分级处理，将报警分为邮件预警、短信报警和疯狂短信报警。以磁盘空间监控为例：每天下午6点，统计磁盘使用率超过80%的机器，发出邮件预警，下班前解决；在预警的基础上，超过85%触发短信报警；超过90%就要持续报警，避免事故的发生。此外，随着服务器数量的增多，硬件故障在所难免，架构设计需要考虑高可用方案，冗余范围内的服务器故障会以邮件预警的方式发出，避免对运维工程师的骚扰。有了监控工具和分级机制，还需要有好的制度。为了大部分人可以安心休息，我们每天有专人负责处理常规报警，遇到无法解决的问题才要求他人协助。第二天的负责人要针对第一天的报警找出根本原因，并尽力解决，因为如果无法根治，困扰将持续发生。所谓线上无小事，实际工作中复杂场景引发的问题数不胜数，所以可以宽容第一次错误，但不能接受同样问题发生第二次，要不断地总结和完善。工具化是运维的必经之路，是向更高层发展的基础，面对运维这样复杂的学科，这样一个极其磨炼人意志的工种，运维工程师需要用聪明的方式解决复杂的问题，节省时间，去做更有意义的事情。第二次升级：运维产品化我刚提出运维产品化时，有朋友开玩笑说，你做后端运维吃苦受罪这么多年，看着产品经理吃香的喝辣的，羡慕嫉妒也想转行做产品吧。也有人说，你是在偷换概念，不就是做自动化运维平台嘛。其实提出这个概念，一方面是源于有了足够的工具化积累；另一方面是想换一种思路做运维，培养产品观，站在用户的角度思考问题，让处于后端的运维工程师主动挖掘需求，围绕运维做更多的探索，提升团队技术能力，解决海量用户带来的问题。有了这个想法，就需要将无形的技术转变为有形的产品形态，同时要赋予它好的寓意。我们的产品取名为HULK——绿巨人，意在让小伙伴们借助巨人的肩膀成长，轻点鼠标，运筹帷幄。想到做这个平台，源于对实际工作需求的观察。产品经理有了创新点之后，开发工程师就想以最快的速度上线，但又会很痛苦，因为产品就好比宝塔明珠，塔基需要一层层地盖。而开发工程师是与运维工程师合作最紧密的兄弟，“兄弟有难得拔刀相助”，因此我们明确了开发工程师就是运维平台的用户，运维工程师在平台的建设中扮演了多重角