• 谁才是自动化运维好帮手[/url]

• Ansible在自動化运维系统中的应用实践 1.概述 互联网技术的发展，机房里面机器的数量随之增加运维的难度和复杂度也在增加，需要投入的运维人员囷成本也在增加从而催生了一系列的自动化运维工具（Ansible、SaltStack、Puppet）的产生来减少运维的成本。

• 23.1 自动化运维 随着Linux运维的发展我们可以发现，傳统的linux运维有比较多的缺点： 1. 传统运维效率低大多工作人工完成； 2. 传统运维工作繁琐，很容易出错； 3. 传统运维每日重复做相同的事情； 4. 傳统运维没有标准化的流程； 5. 传统运维的脚本繁多不方便管理； 这些缺点在公司规模较大的时候就体现得尤为明显。而自动化运维就被囚们提出来目的就是为了解决传统运维...

• Puppet 很像，可以说 Saltstatck 整合了 Puppet 和 Chef 的功能更加强大，更适合大规模批量管理服务器并且它比 Puppet 更容易配置。结合轻量级...

• Ansible维护模式通常由控制机和被管理机组成因为Ansible的特性不像其他运维工具那样需要在被监控的目标上安装agent，所以我们的侧重点呮需要放在安装了Ansible的服务器上（当然用于实验环境的话可以是一台笔记本台式机或者仅仅只需要一台虚拟机即可）。Ansible可以通过SSH进行远程鏈接到对端主机上然后执行你想要执行的playbook或者指令。所有的远程主机都可以在invento...

• Ansible基础1、ansible架构Ansible：Ansible核心程序 HostInventory：记录由Ansible管理的主机信息，包括端口、密码、ip等 Playbooks：“剧本”YAML格式文件，多个任务定义在一个文件中定义主机需要调用哪些模块来完成的功能。 CoreModules：核心模块主要操作昰通过调用核心模块来完成管理任务。 Custom...

• 之前做的一个Python项目采用了Django的MTV框架搭建，实现的是主机的CMDB平台运维管理与作业平台运维管理基本功能 基本的搭建步骤： 1.确定平台运维管理的基本功能有哪些：实现主机的自动添加，删除修改；实现所管理主机配置信息的监控；实现指定对象的批量管理 2.根据上面的功能，设计对应的页面方式布局，规划如何交互的：如何执行命令与显示 3.根据上面的规划，拟定需要怎样的架构分别需要几个模块（M...

• Ansible特点： ?基于Python开发，非常容易进行二次开发 ?Ansible丰富的内置模块，基本可以满足一切需求 ?管理模式非瑺简单一条命令可以影响上千台机器。 ?无客户端模式底层通过SSH通信 Ansible原理介绍： Ansible没有客户端，也不需要在被管理主机添加代理程序通过SSH完成底层通信，而SSH在Linux中默认已经存在在Windows中需要powershell...

• Kerberos、LDAP)推送到被管理端执 行,执行完之后自动删除 ansible两种工作模式：

• saltstack是基于python开发的一套C/S架构配置管理工具，底层使用ZeroMQ消息队列进行通信使用SSL证书签发的方式进行认证管理，ZeroMQ使saltstack能快速在成千上万台机器上进行各种操作它是一款消息队列软件saltstack通过消息队列来管理成天上万台主机客户端，传输指令相关操作而且采用RSA key方式进行身份确认，传输采用AES方式进行加密以保證它的安全性。 ...

我给中小型运维团队的定义是整個团队人数（所有运维工程师 + 运维开发工程师）为 20 人以下一般这样的团队，能为自动化投入的资源也许就 1、2 个开发人员

BAT 等大公司的 DevOps 平囼运维管理功能涵盖的范围非常全面而且各种高大上，这么庞大的体系对于中小型运维团队要靠手头顶多 2 名运维开发工程师来实现落地僦懵了，不知该从何入手所以往往大部分中小型运维团队要么传统人肉运维黑路走到底，要么指望公司咬牙上 DevOps 商业服务

然而，仅靠购買商业服务也未必能完全解决问题主要原因有：

1 . 历史项目成本考虑：商业平台运维管理不支持个性化，历史项目未必能直接对接商业平囼运维管理需要通过运维与业务侧均重构以适应商业平台运维管理，对接成本甚至高于自建平台运维管理且要高速运行的业务侧停下配合也并不靠谱；

2 . 商业机密数据的考虑：商业平台运维管理会存储运维 / 部分业务相关数据，这对于安全要求较高的行业来说自建平台运維管理的可控度更高；

然而，中小型公司的自建平台运维管理大多都算是重复造轮子虽然各家业务情况各异，但也有可以抽象成可复用嘚架构体系这也是商业自动化平台运维管理的价值所在，如果团队是 10 人以下且没专职开发人员再且业务技术历史债务不重的情况下选擇商业服务也不失为明智之举。

我们经常看到各种大厂的自动化平台运维管理一般包含且不限于以下内容：CMDB、配置中心、管控平台运维管悝、数据平台运维管理、CI/CD、作业平台运维管理、容器管理、扩容缩容、辅助运营、监控中心 等等各种高大上词汇让人目不暇接。

由于中尛型团队的用人成本必须控制得极其精确一般不会有太多人力资源投入到自动化平台运维管理的开发，所以必须找出最核心功能以达箌快速落地投入生产环节使用为目的。我们不可能对上述功能点面面俱到这样只会让自己无从下手。

其实最核心的功能模块只有两个：CMDB（配置平台运维管理）和作业平台运维管理我们作为中小型的运维团队，其实能把这两部分完成即可满足 80% 的业务需求在此基础上，再根据自身业务需求再考虑开发其他高级扩展功能如 CI/CD、数据分析、业务监控、辅助运营等

需求驱动导向，大家也不会因为上线一个小项目僦招人做自动化平台运维管理在什么情况下我们才需要做自动化平台运维管理呢？

去年随着手游项目的发展，公司业务需求处于一个飛速增长的阶段在短时间内已经发展到将近数十个项目（含各种渠道、平台运维管理、分区），业务形态各异包括页游、手游、站点、app 等，这样众多的项目运维管理成本非常高传统的运维管理方式很难高效率、高质量地管理和把控如此多的产品和项目。

随着虚拟化、雲、微服务等技术的发展再加上有众多的云服务提供商（阿里云、腾讯云、UCloud 等），应用程序的底层运行环境愈发多样化各种运维对象嘟需要通过一个平台运维管理进行统一的操作和管理。

为了应对以上问题并高质量完成运维保障服务我们必须做到：

通过平台运维管理統一管理所有运维对象，对项目组、对运维部门的所有操作都程序固化；

实现所有项目的持续集成、自动化部署、项目组自助操作以提升發布效率和降低故障率；

有一个完善的配置中心为所有运维自动化的底层数据和配置基础驱动所有运维脚本、工具、组件正常运行；

明確了目标之后，你会发现这三个目标正好对应三个运维术语：标准化、流程规范化和 CMDB

标准化：从主机名、IP、操作系统、文件目录、脚本等一系列运维对象都制定标准规范，业务部门和运维部门都遵守同一套标准基于这套标准去建设统一的平台运维管理。

流程规范化：主偠是涉及 程序文件打包、开发测试线上环境管理、发布流程 等多部门协作的规范必须落实到程序固化或者文档固化，打造 Dev 和 Ops 之间的标准茭付环境

CMDB：这是一切运维自动化体系建设的基石，其它如配置管理、作业执行、资产管理等需要基于 CMDB 才能形成体系构建完善的运维对潒生命周期和操作闭环。

标准化包含的范畴非常多从最简单的操作系统版本、主机名、IP 段、系统帐号密码到软件安装的目录、参数、配置文件等等，也许不同的公司有其特有习惯和历史遗留所以这个没有一个全业界的统一模式。

现在只需要把贵司的习惯用文档的形式固囮下来再彻底检查生产环境的情况是否满足规范所述，不满足则按规范操作

对于历史不是太悠久的项目要修正不会太困难，如果连这點都嫌麻烦的话也不用谈什么运维自动化了。

简单画个思维导图标准化的范畴主要包含但不限于以下内容：

流程规范化是在建立了标准化之后，为了规范运维内部以及与外部门合作的一系列复杂事件的细节做法比如要发布新版本、上线新项目、业务扩容缩容等。

这一蔀分不太容易展开因为不同公司有自己的做法和习惯，无论是怎样做请用文档规范和约束各部门人员的行为，这样才能方便程序化和洎动化不然程序就要写多很多 if-else 语句或者需要配置化来兼容各种不规范情况，徒增开发人力消耗

不用赘述，CMDB 的设计肯定是运维自动化建設的重中之重设计好的话，运维平台运维管理的开发可以有事半功倍的效果

CMDB（Configuration Management Database）配置管理数据库，是记录所有运维对象信息的数据库所有运维流程需要基于 CMDB 的数据进行操作，形成操作闭环操作的结果会反馈到 CMDB 中。

此系统提供了一整套接口界面与其它任何需要信息的系统进行对接这也是设计初衷，将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统而运维需要做的就是维护 CMDB 本身基礎数据的完整性、准确性，CMDB 与各流程系统、垂直功能系统结合之后实现信息数据一处变更处处同步。

传统方式：通过 SSH 登录到该机器关閉所有业务程序，关机在控制列表删除该 IP，下架登录资源管理系统删除该机器信息。

自动化方式：在 CMDB 中编辑其状态系统自动调用底層工具关闭服务、关机，并自动将机器信息在 CMDB 中更新状态

区别：传统方式各个步骤都是非原子性每一步都可能有错漏的问题，如忘记删除控制列表 IP 或者忘记更新资源管理系统信息运维流程无法达到操作闭环。而真正的自动化方式是应该需要达到操作闭环无需人工干预。

CMDB 的设计有一个最大的误区是想建立一个大而全的属性表恨不得想把全部运维对象的全部属性都找出来，比如：

从零散的运维对象来拼湊 CMDB 基本都是吃力不讨好的因为这样的设计方式根本没有从业务出发。

而真正能解决业务问题的 CMDB 必须回到业务上面来从核心的三层关系開始组建 CMDB，这三层概念从大到小分别是：业务、集群、模块（游戏行业术语一般叫项目、分区、服务）

设计思路应该是这样的我所运维┅个业务，它有哪些集群集群下有哪些模块？模块下有哪些机器机器有哪些属性？各种属性之间有什么关联关系

通过这样的思维方式慢慢把真正的 CMDB 组织起来......

当然，运维对象远不止那么少还需要大家根据自家业务多多挖掘，这个过程比较艰辛但不需要一步到位，先確定好核心对象再慢慢完善补充其他对象。

我们把 CMDB 的某个对象称为配置项一个典型的配置项如一台主机、一个域名、一个 IP 。

举个例子一台主机，其属性获取的三种方式：

云服务商 api：有部分属性不能通过 agent 获得的如 EIP、Region、Zone 等如果不是用云主机的就不需要这一部分；

手工维護：有些属性不能自动获取，只能通过人工录入不过这类属性还是尽量越少越好；

由点到面可以看出，配置项的属性类别基本可以分成彡类：

人工录入 ：自动化系统所需的业务 - 集群 - 模块关系每台主机运行什么服务等等。

了解属性类别可以帮助我们更好更快地完善配置项嘚各种属性自动获取机制尽量避免人工干预。

再聊聊主机主机是一个承上启下的核心对象，在它身上有很多属性会被各种功能所使用所以我们要先理清它和其他对象的关联关系。

这里的业务 - 集群 - 模块 - 主机属于物理概念是机器所在的物理层次关系，因为机器必然伴随著机房、网络、光纤之类的硬件概念虽然说是物理层次，但是你用云服务的话就不存在主机这个实体。

而服务是机器的一个业务属性一个机器可以对应多个服务，作为服务的下一级别是进程比如一个 web 服务会有 nginx、tomcat 等若干个进程，定义一个服务则需要与之关联的进程進程的主要属性会有进程名称、起停命令、占用端口等。

作业是一系列运维操作的抽象定义任何一个运维操作都可以分解成一步一步的操作步骤和操作对象，不论是发布变更还是告警处理都是可以分步骤的。

命令：一个可以独立的操作最简单的如关服、开服、执行 xx 脚夲等；

文件分发：把指定的文件分发到目标机器的目标路径；

作业：一系列命令、文件分发的有序组合，作业的步骤可以由 “命令”、“攵件分发” 以及 “执行对象” 组成；

举一个相对复杂的操作过程如更新代码并重启服务：

1 . 对 web：关闭 tomcat (/home/tomcat/bin//document/bkprod/000119.html ），我所接触过的几个自动化平台运維管理（包括商业的和网易内部的）都是应用了类似的设计方式 这算是一个经过众多运维团队考验的最佳实践，如果没有什么特殊业务需求基本可以按这种模式启动以提高开发效率。

然而每家公司的具体业务形态决定了必然会有差异化的需求，随意列举几个吧

作业權限系统，不同角色用户可操作不同级别的作业；

作业运行前确认比如某测试同事启动作业，需要对应主程或者主策划确认才启动；

等待确认超时时间比如等待 30 分钟，未确认则取消启动；

作业异常返回则报警邮件通知到运维组以及对应项目组同事；

灰度执行按作业的設置，先在测试服运行再到正式服；

作业配置克隆，快速搭建新的项目的作业配置；

差异化需求的开发可以在后期慢慢迭代改进

因为莋业平台运维管理是一个让运维定制各种线上操作，封装任意能通过脚本完成的功能可以供自己或者项目组自助使用，尽可能做到运维無人值守运维提供解决方案，那么其最大作用就是为运维部门节约人力杜绝重复劳动。

作业执行作为自动化平台运维管理的核心功能必须挖掘其利用效率，比如根据执行日志统计每天、每周、每月执行次数执行总耗时等数据，以估算出平台运维管理为运维人员节省哆少人力

项目同事放下手头工作 ->通过邮件或者 IM 通知运维同事执行某项操作 ->运维同事放下手头工作，读邮件或 IM理解项目同事的操作内容 ->執行操作 ->通过邮件或者 IM 反馈项目同事 ->运维同事返回原来工作 ->项目同事放下工作读邮件或 IM 再返回原工作

项目同事操作平台运维管理直接执行某项操作得到反馈

这个过程对于项目同事和运维同事双方总共至少能节约人力 15 分钟，减少了很多沟通、理解、反馈的时间成本

对于比较瑺规的普通操作则无需运维同事干预，除非执行异常才需要运维人员介入

我们通过统计得知平台运维管理每月执行作业的总次数为 N，每佽预计节约人力资源 15 分钟（0.25 小时）则每月总节约人力为 0.25＊N 小时，假设 N 为 1000则每月节约运维部门 250 个小时的人力资源。

一个运维人员一天也僦工作 8 小时（不加班的话~）一个月为 21*8=168 小时，那么节约 250 小时则约等于 1.5 个运维人员的月工时

由此可见当作业平台运维管理的执行次数越大樾能形成规模化，对人力资源的节省效果越有利假设当 N = 10000 的时候，相当于节约了近 15 个运维人员的月工时效果还是相当可观的。

平台运维管理的执行数据可以利用 echarts 做报表让运维同事实时查看历史执行次数和预计节约人力。

图表解析：X 轴是时间以每个月作为一个时间区间，统计该月一共执行了多少个作业Y 轴的是作业的执行总次数（蓝色轴，单位次）然后假设每个作业约节约人力 15 分钟，最终计算出每月節约人力总时间（红色轴单位小时）。

作业平台运维管理可以让运维人员解放了很多劳动力但是我们也不可能保证每个作业都能正常運行，若在执行异常的情况下我们可以为异常的原因打上标签，打标签可以根据错误输出关键字匹配自动分类或者人工归类然后统计各种异常情况的比例，再重点分析并处理异常比例高的情况

图表解析：由上图可以看出这是各种异常的数量分布情况，异常的分类是需偠运维预先定义并且有足够的区分度然后根据作业在一个时间区间内统计出各种异常的比例，再利用饼状图可以方便找到比例最高的若幹项如上图是【运维脚本 bug】和【业务代码异常】比例最高，再着重分析解决这类异常的原因来降低运维操作故障率

运维自动化平台运維管理的建设本质是运维团队服务化能力的变现过程，它让我们从大量重复无规律的人肉操作中解放出来专注于运维服务质量的提升。甴于文章篇幅所限未能和大家全面介绍整个自动化平台运维管理的设计思路，按系统的核心程度来划分最核心的是 CMDB 和作业平台运维管悝，当完成这两部分之后次核心的 CI/CD、数据平台运维管理、监控平台运维管理也可以投入开发，后面的运营辅助、故障自愈、智能扩容缩嫆甚至 AiOps 等也需要

温峥峰百田信息运维技术专家，DevOps team leader运维自动化平台运维管理负责人，曾就职于网易游戏专注于运维自动化建设、DevOps 实践與海量游戏技术运营。知乎 id @Hi 峰兄

最好能给个具体的例子吧

• 1.国内外ITSM軟件各有所长单纯从某个维度去对比可能会有失偏颇；
  2.国外的ITSM软件行业发展历史悠久，软件产品总体上会相对成熟一些；很多国际厂商嘟是从高端起步的经过二十余年的积累与沉淀，尤其是数千家客户的实践经验与不断升级优化使之具备了丰富的管理实践经验
  3.没有最恏的，只有最适合自己的建议大家根据自己公司/部门的具体需求，反复调研来选择适合自身的软件产品。比较过程中不建议客户直接仳较产品功能及细节好比小米手机是4核的，苹果4S是双核的品质一样吗？
  4.可能有人会强调国外软件价格高，在国内的服务能力不好②次开发难度大，本地化不足等缺点但是国外很多软件厂商在中国设立了分支机构，上述的问题也就迎刃而解了
  5.如果注重短期效益，鈳以选择国产小软件；如果考虑到长远的收益还是建议选择国际品牌大厂商。