it运维心得分享

360 公司运维心得分享 在很多“外人” 的眼中，运维工程师的工作不过是搬机器、调网络、装软件、处理故障、 724 小时值班，简单而又枯燥至极。但事实并非如此，运维工作涵盖很多技术领域，运维 工程师要掌握硬件、软件、操作系统、开发等多方面的知识，核心目标是为亿万用户使用 的产品保驾护航。 当今互联网行业的发展日新月异，新技术层出不穷。为了适应发展趋势，运维工程师只有 提升技术能力才能更好地完成艰巨的运维任务，必须要对传统运维发出自我挑战。 在 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 地址分析模块展示地域及运营商分布。同时基于访问 日志状态码做进一步的页面分析，然后以日、周、月维度生成一份体检报告，以及应对方 案推送给开发工程师。这些增值服务是超出预期的，拉近了开发工程师和我们的距离，一 起去探讨、改进，做出更多有利于项目发展的功能。 结束语 运维工作在一家公司中至关重要，但传统的运维模式一定程度上限制了运维工程师的技术 发展，更抑制了创新思维，我们需要利