当前位置:澳门贵宾厅 > www.vip8888.com > 目前在新炬网络旗下轻维软件负责运维平台的研发,需要通过运维与业务侧均重构以适应商业平台
目前在新炬网络旗下轻维软件负责运维平台的研发,需要通过运维与业务侧均重构以适应商业平台
2020-05-06

可以看出,流程包含了一系列 “对象”-“操作” 的有序的命令以及文件分发的集合。“对象”可以是一个组、一个或者多个 IP,在执行命令时候可以在系统的页面动态指定目标对象。

宋辉

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

原文来自微信公众号:DBAplus社群

我给中小型运维团队的定义是整个团队人数为 20 人以下,一般这样的团队,能为自动化投入的资源也许就 1、2 个开发人员。

CMDB其实也是个老生常谈的问题,各大企业做CMDB的项目非常多,但成功的不多,最主要的原因就是把CMDB当成了excel在管,搭个平台、建个模型把各种配置数据统一录入到系统里面就结束了。这样的CMDB当然会失败。另外CMDB要以业务为中心,更多的关注在资源管理,能提供资源的整体视图,很好的展现业务及应用与资源的关联关系,除了系统视图、逻辑视图、物理视图外,需要增加业务流程视图,管理业务流程各节点与各服务之前的关系。

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

Q2:中间都会用到哪些软件?

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

今天给大家讲的主要是思路,很少涉及具体的技术,里面包括了许多的内容,每个企业的实际情况及IT发展阶段、甚至管理模式都不太一样,大家可以选择性的参考与借鉴。运维是企业IT的基础,未来运维的挑战只会比现在更大,及早构建一个新一代的运维管理平台意义非凡,我们在此方面积累了许多成功的经验,也具有了一定的产品体系,欢迎大家与我们进行更深入的探讨。

2 . 对 server:关闭业务主进程 (/home/server/bin/stop.sh)

这样我们基本上就能构建起一个非常智能和敏捷的监控系统,实现初步的机器管理机器的目标,达到自动的事件闭环管理。

对 web 组:执行 stop tomcat;对 server 组:执行 stop server;对 app 组:执行 stop app;

(4)分阶段实施,先看到成效,再进行能力扩充,不要想着一口吃个胖子,很多企业连基础监控都还没做好,就想着要搞人工智能,有点不切实际。因此充分考虑未来的方向,预留发展空间在平台建设整体规划时,需要充分考虑数据分析能力及运维大数据能力,AI是运维的未来。

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

对于运维管理平台的目标,一方面是在系统出现问题时能找到真正根源的节点,同时也能分析出其内在的深度的原因(如除了定位到某个应用出了问题,还要能定位到是哪段代码或某条SQL),并进行自动有效的处理;反之要能通过所有节点蛛丝马迹的指标变化,预测系统的运行走势,在出现问题前能采取有效的措施进行处理。

总结

在此基础上,我们可以将自动化运维平台上集成的各种操作、流程、场景封装成API,对外系统提供调用及操作。如可以提供给监控平台,进行故障自愈;提供给CMDB进行配置及关系自发现等。

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

CMDB一半是技术,一半是管理,成功的CMDB需要重视CMDB看不见的能力与价值。

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

五、小结

由点到面可以看出,配置项的属性类别基本可以分成三类:

四、建设思路:7大核心模块

而真正能解决业务问题的 CMDB 必须回到业务上面来,从核心的三层关系开始组建 CMDB,这三层概念从大到小分别是:业务、集群、模块

如前面的架构图所示,整个平台分为三个层次:监控及运维操作、运维大数据分析及门户与集成平台。集成平台主要用于下面两层能力的自定义构建与场景化,通过下面两层的服务化接口,构建面向不同维护人员的运维场景,以支撑更多的个性化应用。利用各种报表工具,进行多维度的自定义数据分析与运维能力集成。通过集成平台,构建运维一体化PaaS平台,提供面向业务的运维监控、运维操作及决策分析平台。

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

模块五:新一代运维管理平台,需要引入对用户体验数据的监测与分析,结合系统平台数据,真正做到端到端的监测与分析能力。

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

覆盖全面,具备统一数据采集的能力。对于监控告警平台的建设,这个是老生常谈了,为什么还要来说?因为很多的监控平台没有用好或用不起来。相对于传统的监控系统,我们更强调设备覆盖的完整性和指标覆盖的完整性,强调统一集中采集平台的能力,而不只是用来做监控和告警,更重要的是用于整个运维数据的采集中心,为后面所有运维决策、人工智能等提供方便的数据来源。对于已经有了许多专业网管的企业,建议进行统一数据采集的融合,提升或新建一个专业网管做为一级网管,其它下沉为二级网管。

执行细节是第一步对 web 组的 3 台机器同时发起 stop tomcat 命令,等待 3 台机器全部返回结果后,如果结果返回 0 表示命令执行成功,这时候才继续进行第二步对 server 组的流程。如果第一步返回结果不为 0,则提示流程执行失败,提示需要人工检查,终止后面的流程。

第一个阶段,以专业化网管工具为代表,包括网络设备、主机、数据库、中间件、存储等进行专业监控管理的各种专业化工具。第二阶段,以ITIL流程化管理为代表的综合网管,通过事件、服务、流程等贯穿监控、变更、资产管理等一系列IT运维管理。第三阶段,以敏捷、DevOps为代表的运维管理平台,主张开发运维一体化、自动化,强调需求、资源的服务化。

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

模块二:建立自动化运维操作能力,以操作及流程或场景为闭环,构建集中运维操作平台。

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

大家好,我叫宋辉,目前在新炬网络旗下轻维软件负责运维平台的研发。从03年毕业到现在在IT行业混了有14年多了,其中有12年是在从事运维相关的工作,应该说见证了整个IT行业十多年的大发展,也经历了许多的技术及产品的兴衰起落,感触良多。

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

直播链接回放

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

在当前的IT系统建设及数据中心规模扩强的速度下,没有一套合适的运维管理平台,运维工作将举步维艰,因此建设一个更可靠、更智能的运维管理平台就显得尤为重要。

澳门贵宾厅,前言

?topicId=2000000218877425null

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

集中运维操作平台的能力要求包括:

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

新一代运维管理平台,主要是以业务为中心,通过问题快速发现与修复、运维批量操作与自动化,保障业务系统高效稳定运行为目标,实现运维的可视化、自动化及智能化。IT业务系统的软硬件设备及之间的依赖请求关系,组成了一个巨大的多维立体网络,中间的任一个节点出现问题,都可能引发业务系统的异常。

手机版澳门贵宾厅,从零散的运维对象来拼凑 CMDB 基本都是吃力不讨好的,因为这样的设计方式根本没有从业务出发。

通过把CMDB做为整个运维管理平台资源的入口(其实这也是CMDB数据消费的非常大的一个场景),可以解决CMDB设备数据不完整的问题,甚至说不费吹灰之力。CMDB的配置数据及关系数据,可以通过监控或自动化运维平台去进行自发现,确保数据的完整性。

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

问题发现及自愈能力(监控告警)自动运维操作能力(自动化运维)资源配置管理能力(CMDB)用户体验管理能力(业务监控、用户体验管理)组件深度性能分析能力(如数据库性能分析、应用性能分析等)运维大数据分析(如大数据日志、AIOps)门户及场景集成(数据分析、Portal,运维场景集成)。

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

平台的基础能力除了兼容各种设备的操作能力,还包括文件上传、下发、脚本执行、配置管理、软件包管理、流程编排等基础能力。前面提到的对各种软硬件设备的操作能力在平台上就体现成一个个的原子操作,通过流程编排,可以快速将各种原子操作编排成一个一个的业务场景,如上线部署、安全扫描、健康巡检、安装部署、故障诊断、资源开通等各种能力。

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

之前很多企业的运维是不关注业务的,只是在业务反馈用户投诉或系统出现故障时,才会响应分析系统平台的问题。这种方式是非常不合适的,往往只能做到被动响应,无法做到主动预防。用户体验包括以下几个部份的内容:

一个运维人员一天也就工作 8 小时,一个月为 21*8=168 小时,那么节约 250 小时则约等于 1.5 个运维人员的月工时。

Q1:目前运维自动化实践在哪个行业和客户落地的比较成熟?A1:自动化运维来说,在互联网落地成熟度较高,因为互联网行业的设备标准化能力较好。但传统行业随着云的普及和落地,标准化程度不断提高,自动化运维大有可为。

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

CMDB数据消费场景(基于规则的告警根因分析)

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

对于自动化运维平台,需要非常关注安全的管理,因为基于此平台基本可以对整个IT系统环境执行任何操作,这个具有很大的安全隐患。当然有许多互联网公司的运维管理理念是用人不疑,充分授权,这种方式对于效率是非常大的提升,但在传统行业不一定能行得通。因此平台需要有安全管理能力,能对原子操作的执行、执行的对像、时间进行权限控制,另外支持对整个操作过程的审计,对于敏感操作能进行二次授权等。这样安全和效率才能兼得。

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

QA

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

IT运维管理是一个非常宽泛的范围,整个IT生命周期都跟运维有着关系,运维难做,运维管理平台更难做,这个领域缺少标准和规范,目前也就Gartner对ITOM/ITOA有一些功能范围上的定义。

命令: 一个可以独立的操作,最简单的如关服、开服、执行 xx 脚本等;

这7模块各就其位,相互协助,构建新一代运维管理平台的核心。

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

个人觉得包括几个方面原因,如管理思维的问题、技术架构的问题、组织文化的问题等。我们今天重点讨论技术方面的问题,个人认为要建好一个运维管理平台,应该遵循如下的原则:

3 . 对 web:分发新的站点文件 (scp xxx yyy)

前面已经提到AI是运维的未来,任何现象都可能跟某个隐含的数据有密切的关系。因此依赖于大数据、人工智能等新型的技术,将人对问题、故障分析的经验移植到代码上,甚至在不久的将来,对于运维,机器干得比人还要出色。当然对于真正的AIOps我们还处在很初级的阶段,但必须从现在开始准备。

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

对于采集回来的指标,一般可通过阀值等配置告警,但现实系统基于阀值的方式存在一定的弊端,无法对指标的异常波动做出准确的预警,如CPU使用率从20%,突然上升到70%,虽然没有触发告警阀值,但实际上系统性能可能已经发生了比较严重的恶化,需要引起关注。我们给某些企业建设的统一监控平台,指标量已达到200多万,我们需要有从这200多万的指标进行异常波动检测及快速预警的能力。一般会利用一些大数据算法进行智能基线的计算及预警。

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

目前第三阶段还在迭代演进中,随着人工智能的新起,AIOps的概念开始盛行,因此结合敏捷及智能,成为新一代运维管理平台的建设的核心目标。

作业异常分析

第一步先要把数据集中起来,建议先构建大数据日志分析平台,形成大数据分析能力,把设备日志数据、应用日志数据集中起来,提供基本的关键字搜索、统计、告警、趋势分析等能力。这些是对于传统监控告警一个非常重要的补充。

温峥峰

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

三、建设原则

需求驱动导向,大家也不会因为上线一个小项目就招人做自动化平台,在什么情况下我们才需要做自动化平台呢?

目前大多数的应用还是属于数据密集操作型的,也就是重数据库的,对于这些应用、应用本身代码级的诊断和数据库的深度诊断分析能力要求更高。应用组件深度分析能力主要体现在:

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

A2:这个是一个大的方案,里面有很多的平台模块,形成合力。里面具体的一些点,可以有很多开源的解决方案,如监控的Zabbix、自动化运维的Ansible,CMDB也有开源的。但开源的方案一般较难打通和基于企业业务情况构建场景。

使用平台后:

随着信息化建设的不断发展,企业的IT已从原来的一个后台管理职能,转变成了生产营销中心,IT越来越多地渗透到企业生产运营之中。同时IT技术架构也在逐步朝微服务、容器、云化、开源等方向演进,在新的架构规划体系下,IT系统将变得更加复杂,对于平台的运维支撑能力、资源支撑能力等带来更高的要求。

开发的时候其界面和操作方式可以参考蓝鲸的作业平台,我所接触过的几个自动化平台都是应用了类似的设计方式 ,这算是一个经过众多运维团队考验的最佳实践,如果没有什么特殊业务需求,基本可以按这种模式启动以提高开发效率。

集成平台通过调用平台服务化API接口,提供自定义场景集成能力,快速构建各种应用场景。如下图所示,通过CMDB的数据查询接口在平台自动构建一个系统拓扑,通过采集监控模块的API接口把系统运行指标数据、告警事件映射到拓扑图上,通过自动化运维模块API,把常见的运维操作能力集成到拓扑图上,这样可以快速构建一个可视化的智能运维场景,这些都无须运维人员有任何开发能力,大大降低运维开发的难度。

图表解析:X 轴是时间,以每个月作为一个时间区间,统计该月一共执行了多少个作业。Y 轴的是作业的执行总次数,然后假设每个作业约节约人力 15 分钟,最终计算出每月节约人力总时间。

应用组件深度分析能力,通过监控或智能告警等一般可以定位到一个软硬件设备的状态出现异常,但异常的真正原因是比较难排查的。重启、扩容应用或许可以短期内解决问题,但真正的原因可能是代码的缺陷或低效的SQL语句或数据库本身的资源争用导致的。

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

CMDB应该成为整个运维管理平台的资源及配置管理中心,成为运维的第一入口。如监控、自动化运维等均涉及大量的资源管理,不允许各自建设一套各自的资源体系,监控和自动化运维操作的资源应该来源于CMDB。整个大的流程是应该在设备上架开通后,录入CMDB,再从CMDB接入监控或运维;设备下线后,先从监控及自动化运维的平台进行监控及运维操作下线,再从CMDB进行下线。在设备没有录入CMDB时,不允许接入监控及自动化运维。这样就可以避免CMDB数据更新不及时的问题,按照CMDB管理上的经验,如果都不需要接入监控和自动化运维的设备,肯定是属于三不管的设备,上面也不会有什么重要的业务,就算CMDB里面没有数据,也无关紧要。当然这些管理上的要求,必须通过技术手段上的限制去落地。

比如一个作业定义如下:

Oracle认证大师,15年以上运维管理经验、Oracle数据库技术支持,支持过的数据库超1千套长期为大型企业核心业务系统数据库提供方案设计,在性能优化、故障处理、应急容灾、安装配置等技术领域有独到的见解和丰富的实践经验

作业权限系统,不同角色用户可操作不同级别的作业;作业运行前确认,比如某测试同事启动作业,需要对应主程或者主策划确认才启动;等待确认超时时间,比如等待 30 分钟,未确认则取消启动;作业异常返回则报警邮件通知到运维组以及对应项目组同事;灰度执行,按作业的设置,先在测试服运行,再到正式服;作业配置克隆,快速搭建新的项目的作业配置;

模块七:集成平台构建运维场景集成能力

下面可以大致画个图勾勒出作业平台的主要对象

二、运维平台发展历史

节约人力预估

浏览器、APP上终端用户的真实体验,这部份数据可以通过流览器插码及APP SDK收集。如现在比较流行的APM for APP及Browser模块。通过应用拨测的方式,在各IDC部署拨测终端,模拟用户对系统平台进行拨测,对响应时长,错误率、成功率等进行分析。业务系统平台数据侧的统计与分析,如基于流程数据的统计、基于应用日志的统计,对系统业务量及响应时间等用户体验数据进行统计与分析。利用抓包解码的方式,对网络流量数据进行解码,分析与统计终端用户的体验数据。

作业这个概念的提出,即可以将运维工作的各种“变更”、“发布”、“故障处理”等零碎操作分解成一个个可复用、可扩展、可执行的独立操作命令,那么最终平台化的自动调度将成为可能。

今天主要跟大家分享一下新一代运维管理平台的建设思路,选这个主题,一方面是因为运维在整个IT生命周期中作用越来越重要,另一方面新的技术及架构给运维带来了新的方向与思考。如何做好运维,成为更多企业及运维人员关心的重点,在这里结合个人在这个行业的一些经验,跟大家做个探讨。

自发现: 机器内部获得,如 python psutil、puppet fact、ansible setup 等途径。

讲师介绍

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

接下来考虑基于大数据日志分析平台构建运维大数据分析能力,将统一监控平台的海量指标数据同步到日志分析平台,构建成运维大数据平台,一方面,基于这些数据可以进行大量主题的分析,如容量分析、性能分析、事件分析、隐患分析等。另一方面,利用监控告警事件、CMDB资源关系、设备及应用日志,进行关联分析,同时利用各种人工智能、机器学习算法,进行基于人工智能的运维分析与诊断。

5 . 对 web:启动 tomcat (/home/tomcat/bin/startup.sh)

广义上的运维平台发展经历了三个阶段:

agent 获得:如 cpu、memery、disk、ethX 之类的硬件信息,一般用 python psutil 模块可以获取大部分所需要的属性;云服务商 api:有部分属性不能通过 agent 获得的如 EIP、Region、Zone 等,如果不是用云主机的就不需要这一部分;手工维护:有些属性不能自动获取,只能通过人工录入,不过这类属性还是尽量越少越好;

一、运维平台的重要性

1 . 对 web:关闭 tomcat (/home/tomcat/bin/shutdown.sh)

关于CMDB的数据消费,数据越完整消费价值越大,把资源数据提供给监控、自动化运维平台进行接入,把关系数据提供给监控平台进行基于规则的告警关联分析、根因分析等。与监控数据结合进行维保分析,对于低频使用的机器,可以降低维保级别等。对于低频使用机器,结合上线时间,进行设备下线、退网提醒等。CMDB结合监控、自动化运维等平台,可以不断完善数据,也可以构建更多更有价值的消费场景。

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

实际落地时需要结合企业使用的技术架构进行选择,也可以采用多种技术手段结合的方式进行。在这个领域互联网公司有非常成熟的经验值得借鉴。

外系统 API: 需要通过云服务商 API、Zabbix API、K8s API、其他业务系统 API 等途径。

模块一:构建统一的监控告警平台,实现集中采集和告警,更快速地发现和发析及处理问题。

主要对象

举个例子,按照原来的流程,如果需要新上线一个应用,需要涉及云平台划分虚拟机资源、安装配置系统软件、开通网络防火墙、进行应用部署、进行安全扫描及加固、部署接入监控等事项。在传统企业当中,往往涉及多个部门或多个团队,如基础平台、数据库、中间件、网络、开发、安全、监控等,按照现有的基于流程的方式,需要提N个工单,花上1-2个月的时间才能搞定这个事情。但如果基于集中操作运维的平台的能力,把应用上线做为一个业务场景,把所有步骤能编排成一个大的流程,自动去执行,中间的关键步骤前可加入审批的控制,这样一个流程可能1-2天就跑完了。这就是技术的价值。

如何设计

依据日志数据中的标签、埋点及关系,构建基于日志数据的场景分析能力。应用场景包括业务指标分析、业务链路分析、接口性能分析、用户体验分析、故障隐患分析、故障根因分析等。

6 . 对 server:启动业务主进程 (/home/server/bin/start.sh)

统一监控平台的能力要求包括:

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

应用端的深度分析,利用应用探针技术或应用日志埋点,对应用代码级的方法、请求进行分析,实现代码级的诊断,在应用请求量、成功率、响应时间等出现异常时能快速定位问题节点及代码。这个在当前的微服务和分布式架构下显得尤为重要,蜘蛛网式的应用架构,在出现性能问题时,如果没有明确的调用链路分析手段,将是非常致命的。数据库的深度分析,对于目前企业大多数应用来说,数据库仍处于非常核心的地位,对于数据库的维护管理显得尤为重要,一条SQL语句搞跨一个系统的事经常出现,不管是Oracle,还是DB2、MySQL,SQL Server,这些数据库都需要最高级别的深度监控和分析,包括数据库低效SQL的分析、一键式的性能诊断、SQL语句的自动优化、SQL上线前性能审核、SQL版本比对分析等。许多企业都有好几种关系型数据库,构建一个有强大SQL性能管理为核心的数据库统一管理平台非常关键。我们在为许多大型企业构建新一代运维管理平台时,都会重点考虑构建数据库的深度分析管理能力。

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

(2)运维平台的建设和落地应该由运维来驱动。运维是个非常专业的工作,虽然DevOps的理论已经非常深入人心,但真正解决和提升的更多是在持续集成和交付上的能力,对于专业的运维,渗透得并不是那么成功,如很多互联网公司也尝试过由开发团队来做运维,但也仅限在应用运维这一层,同时导致各自为政,工具建设泛滥的问题。阿里的DevOps也经历了几个阶段,最终成型落地也是让运维带一群开发进行运维平台的建设,提升运维的工具化能力。因此运维平台还是要由运维来主导建设,虽然运维不管业务,但需要站在业务的视角来构建运维平台。

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

模块六:大数据日志分析及运维大数据能力

作者介绍

以集中操作中心为目标,覆盖对数据库、中间件、主机、网络设备、存储、云平台、硬件甚至应用程序接口的操作管理、批量调度、作业任务管理能力。当后面该平台成为整个运维的操作调度中心,这样做的好处就显而易见了,打通所有系统软硬件的操作能力后,将非常容易构建起基于任何流程的运维自动化的业务场景,通过技术手段贯打通原来的组织的壁垒。

配置项属性

相对于业务化的场景,对于平台的建设,我们要提供的就是构建这些场景的基础能力。一方面是兼容各种软硬件设备的操作能力。如能对防火墙执行一个策略下发,能对云平台执行一个新建虚拟机的操作。目前有很多的开源工具,如Ansible、Saltstack等,在自动化运维领域做得很好,但这两个工具核心的能力还是在对于主机的脚本执行管理能力,需要通过自建或扩充对于各种软硬件设备的操作支持能力。

作业定义时有各种增删改查操作,每个执行过的作业需要记录执行人、执行时间、结束时间、返回值等信息。执行顺序

下面分别介绍每一个平台模块的建设思路:

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

对于监控系统来说,有一个非常重要的能力,就是进行告警,但许多人都觉得告警太多,导致许多人对传统的告警失去信心。

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

对于CMDB数据的完整性,需要除了管理上的要求,需要构建自发现的能力,对于配置项的属性及关系,大部份可以通过自发现来实现。CMDB应该与监控系统及自动化运维平台保持非常好的联动关系,监控及自动化运维的资源数据来源于CMDB,同时监控及自动化运维作为CMDB配置项属性及关系数据自发现的最主要的来源。这样无须独立为CMDB构建复杂的自发现模块。

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

CMDB关系数据不完整,另外有很大一个方面的原因是,设备量太多,维护团队很难知道哪些配置项关系有问题,无从下手。平台应该提供业务视角的数据校验的能力,如一个业务系统,包括应用、数据库、中间件、主机、存储、网络等很多设备,这些设备构成了一个拓扑关系,但如果数据不完整,这个拓扑关系就是不完整的,我们很容易看到哪里出现了中断,去把这个关系补上就好了。所以我们虽然很难发现一个完整的业务系统拓扑,但通过数据校验,能发现拓扑关系的缺失,再提供快速便捷的修复能力,这样关系就能慢慢完整了。这也符合CMDB的数据众包修复原则。

作业需要按顺序执行,当一个步骤成功后才能执行下一个步骤,如果执行失败需要停止运行作业,并保留执行的各种日志。

我们的经验是,一方面降低对低级别的告警的关注,只对致命或严重级别的事件进行短信通知,这些告警发送给相应专业的维护人员。另一方面,通过技术手段,建立告警依赖和告警关联分析,只对根因告警进行通知,对被影响的告警进行屏蔽。目前基于规则的告警依赖这个实现起来复杂度非常高,而且严重依赖于CMDB的能力,基于算法的告警关联分析准确度有待考验,我们更希望在基于算法的方向,来解决这个问题,目前已取得初步成效,后面有机会可以跟大家做进一步的分享。

CMDB

为了达到这个目标,结合现在市面的工具,我们将其总结为7个能力的建设,包括:

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

一键式的数据库深度分析

一个机器下架的操作:

轻维软件CEO

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

模块三:构建统一资源管理能力,成为整个运维平台的资源中心、配置中心。

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

(3)以业务为中心来进行构建,打通业务与设备的关联。随着微服务及分布式架构的兴起,在运维管理中,会逐步淡化系统的概念,各种微服务通过流程编排组成了各种面向用户的业务。传统的分层架构逐步往网状架构转型,对于运维平台提出了新的能力上的要求。

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

提升了问题发现的能力、预警通知的能力后,接下来就需要构建问题自愈的能力,这里需要引用关联我们另外一个模块的能力,就是自动化运维平台,通过调用自动化运维平台的脚本或流程平台,实现问题的快速自愈,即通过事件与自动化运维操作的关联,构建IT系统的自愈能力。

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

建设一个具有先进性、扩展性及未来性的新一代运维管理平台非常重要,但同样难度也不小,个人认为整体上的规划至关重要,有了清晰的战略才能有良好的落地与效果。7种能力就像7种武器,互相搭配,各舞所长,才能发挥最大作用。

流程规范化

要求具备的能力包括:

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

(1)运维管理平台包括非常多的功能和模块,不可能一步到位,建议从整体的思路构建,考虑数据上的融合和各子系统之前的协同,一个模块一个模块构建,架构清晰、稳定、方便扩展。模块多了就必须要考虑数据标准的问题,其实跟现在企业各系统之间的数据孤岛是同样一个问题,各平台之间很难产生联动的价值。这个具体的做法,会在后面讲到。

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

运维管理平台包括监控、ITSM、CMDB、自动化运维操作、日志分析、用户体验、APM、数据库管理、云平台管理、网络管理、业务监控、拨测、运维大数据等这些类别,有些企业建设了很多项目或购买了许多工具,但仍觉得用不上、不好用、用不起来,为什么?

作业执行情况分析

模块四:关注用户体验,运维需要重视和关注业务及用户。

项目背景

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

标准化:从主机名、IP、操作系统、文件目录、脚本等一系列运维对象都制定标准规范,业务部门和运维部门都遵守同一套标准,基于这套标准去建设统一的平台。流程规范化:主要是涉及 程序文件打包、开发测试线上环境管理、发布流程 等多部门协作的规范,必须落实到程序固化或者文档固化,打造 Dev 和 Ops 之间的标准交付环境。CMDB:这是一切运维自动化体系建设的基石,其它如配置管理、作业执行、资产管理等需要基于 CMDB 才能形成体系,构建完善的运维对象生命周期和操作闭环。标准化

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

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

原文来自微信公众号:高效开发运维

使用平台前:

作业平台 定义

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

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

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

文件分发: 把指定的文件分发到目标机器的目标路径;

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

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

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

4 . 对 server:分发服务端文件 (scp xxx yyy)

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

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

通过平台统一管理所有运维对象,对项目组、对运维部门的所有操作都程序固化;实现所有项目的持续集成、自动化部署、项目组自助操作以提升发布效率和降低故障率;有一个完善的配置中心为所有运维自动化的底层数据和配置基础,驱动所有运维脚本、工具、组件正常运行;如何达成目标