内容简介:现如今,随着云计算和分布式的落地和发展,越来越多的服务器都转到云上,微服务架构的落地也让现在的 IT 系统架构越来越复杂。我们的服务、应用所面对的规模也越来越大,这样的需求需要强大的运维管控系统在后面支撑。智能运维(AIOps)的概念现在很火,旨在借助人工智能机器学习和算法将 IT 运维人员从繁重的工作中解救出来,但是对于智能运维大家都在探索当中,AIOps 的技术并不是很成熟。大多数企业还处在对自动化运维的需求迫在眉睫的阶段,需要运用专业化、标准化和流程化的手段来实现运维工作的自动化管理。因此本次 Inf
现如今,随着云计算和分布式的落地和发展,越来越多的服务器都转到云上,微服务架构的落地也让现在的 IT 系统架构越来越复杂。我们的服务、应用所面对的规模也越来越大,这样的需求需要强大的运维管控系统在后面支撑。
智能运维(AIOps)的概念现在很火,旨在借助人工智能机器学习和算法将 IT 运维人员从繁重的工作中解救出来,但是对于智能运维大家都在探索当中,AIOps 的技术并不是很成熟。大多数企业还处在对自动化运维的需求迫在眉睫的阶段,需要运用专业化、标准化和流程化的手段来实现运维工作的自动化管理。因此本次 InfoQ 记者采访了小米资深架构师孙寅,和大家一起了解小米的自动化运维平台是如何演进的。
背景介绍
小米自动化运维平台从 2013 年开始建设。截止目前,小米有 300+ 业务线,5W+ 服务器规模。6 年里伴随着互联网业务的陡峭增长,小米运维平台也发生了天翻地覆的变化。平台整体建设情况大致可以分为三个阶段:
1. 工具型平台(2013~2014 年)
这个阶段,平台主要在解决一些基础痛点问题,如资产难以管理、软硬件难以有效监控、人肉发布效率低下错误率高等,因此孵化了 CMDB+ 服务树、监控系统(Falcon)、发布系统等几个一直沿用至今的 工具 型平台的核心组件。并且借助推广这几个核心组件,对业务进行了基础标准化。
2. 体系化平台 (2014~2015 年)
在此阶段,团队逐步补齐了整个运维闭环中的各个环节,如预算交付、OS 自动安装和环境初始化、域名、负载均衡、备份等。并通过打通运维闭环中的各个环节和体系化设计,建设起了跨越系统的自动化体系,如服务器交付自动初始化、各种场景的监控自动发现、发布和负载均衡变更联动等等。
3. 数据中心操作系统(DCOS)(2016 年至今)
在此阶段,以容器 PaaS 为标准化载体,构建自动化程度更高、能力更丰富、体系更内聚的基础架构生态系统,包括:
-
监控:丰富细化了各种具体场景的监控,如:
- 公有云、网络设备、南北 / 东西网络、域名、负载均衡、容器集群等;
- 端到端访问质量监控,模拟用户真实访问发现最后一公里问题;
- 分布式调用跟踪监控,穿透式跟踪故障点;
- 精准报警和根因分析,整合各类型监控,依赖决策树、机器学习等能力自动寻找根因。
-
服务组件:自助创建集群,自动配置最佳实践,具备故障自愈能力的服务组件,如 MySQL 、 Redis 、 Memcached 、Kafka、ES 等;
-
CI/CD:打通整个开发、测试、交付链条的自动化 Pipeline;
-
服务治理:流量路由、流量镜像、服务保护、白名单、熔断、链路跟踪、服务拓扑;
-
故障:故障注入、故障自愈、故障跟踪。
平台架构设计
小米自动化运维平台的整个平台体系架构,可参考下面图示:
-
图示底部是 IaaS 层的各种资源及其管理平台,如网络管理、多云接入、域名、负载均衡等。
-
上面承载了庞大的 PaaS 体系,划分为四大部分,容器、应用、服务治理、故障容灾。
-
左右两侧是一些公共能力,如 CMDB、监控、安全。
配置管理(CMDB)由于和内部资产、环境、流程有比较紧密的耦合关系,业内也并没有比较成熟的开源实现,因此基本完全自研。
部署发布系统使用了 Puppet 对运行环境进行变更和管理,植入了 God 为每个进程提供自动恢复的能力,使用了 Docker 来解决编译一致性的问题,同时也支持了静态发布 Docker 容器。
小米早期使用了开源监控系统 Zabbix,但由于监控规模得扩大、监控场景得复杂化、配置难度大等原因,我们内部自研了监控系统 Falcon,也就是业内著名的企业级监控 Open-Falcon。随着使用场景得继续丰富,目前也已支持监控数据旁路到 ElasticSearch、仪表盘支持 Grafana,同时还在探寻数据存储使用时序数据库 Beringei,以支持更好的扩展性和便于实现更丰富的报警判别功能。
平台建设的难点
由于整体建设的规划比较清晰,因此并没有比较大的挑战,如果一定要找,可能在于一些魔鬼细节上面。比如:
-
灵活的服务树设计,并未能解决组织架构频繁变更后带来的树结构混乱,同时因为体系中的各种系统都与服务树有很强的耦合,以致后期不得不想办法构建一棵新的组织结构树,来为服务树“打补丁”;
-
忽略了服务命名的 POSIX 规范,以致于一些严格遵守命名规则的开源组件出现了冲突。
标准化的问题,是所有平台体系的共通问题,无标准,不平台。早期平台标准化的主要有三个方向:
-
服务命名,这个标准主要是通过服务树来完成的,体系中的各种系统也都统一使用相同的服务命名规范,因此服务命名逐渐就成了事实标准;
-
服务目录,这个标准是通过部署发布系统来规范的,使用该系统的服务,会自动按照相应的规范生成目录。目录的标准化,也继续推进了其他和运行环境有关的自动化系统的演进;
-
监控方法,这个标准是通过监控系统来实施的,各种类型场景的监控,都以遵循监控系统的监控协议来上报,并可实现为监控系统的插件。
后期在 DCOS 阶段,由于服务都在容器云内调度,运行环境高度内聚,很多标准可以由平台自动生成,标准化也就因此变得更加容易。
整个平台体系的设计思路一以贯之,各个系统间有很多联合设计,以完成更长路径的自动化,而不仅仅解决每一个原子事务的自动化。例如:
-
预算交付系统,和服务树、监控系统配合,达到自动监控基础监控项的能力;
-
域名系统、负载均衡系统、云对接系统、发布系统配合,达到自动配置管理接入层的能力;
-
还有,动态 CMDB、分布式跟踪、决策树配合,得到故障精准定位能力。
平台实践
小米的自动化运维平台主要指的是容器云平台。众所周知,基于 Docker、Mesos、kubernetes 等开源组件实现的容器云平台,天生具有资源编排能力,对无状态应用的扩容也无比简单。
资源协调方面,我们增加了基于 LVM 的磁盘空间资源,以及基于 tc 模拟的带宽控制资源,用于更精细化控制容器间的资源隔离。
扩容能力方面,小米的实现有一些时代的烙印,也有一些巧妙之处值得借鉴:
-
早期使用 Mesos 的 Batch 任务框架 Chronos,来实现定时扩缩容能力。这种方式比较巧妙地解决了实现定时难以解决的分布式容错问题;
-
用 Falcon 的集群监控策略 + 触发钩子,作为自动扩缩容的条件,这样继承了业务已有的监控指标和监控策略,同时还可自动作为抑制报警的条件。
举例说明这种方案的联动效果:
上图为某服务的自动扩缩配置,由于业务代码按照监控标准,已上报了 JobAlarmCount 指标,因此系统可与监控系统对接,直接使用该指标自动生成集群监控策略,并以此作为自动扩缩容的触发条件。
该例中当 JobAlarmCount 的集群平均值连续 1 次大于 100,就触发扩容,每次扩容 5 个实例,当连续 5 次小于 5,就触发缩容,每次缩容 2 个实例。每次触发扩缩容,都通过报警机制发送到 uic.dev 报警组,同时扩缩容的上下限,分别是 50 和 20。
这样的自动扩缩容配置,可以在业务出现容量问题时,快速(连续 2 次)触发扩容,当业务恢复正常后,平缓触发缩容。同时实例数量的上下限,用于保护资源和业务的可靠性。
小米自动化运维的技术探索
前沿技术方面,小米自动化运维目前主要在探索这样几个方向:
-
混沌工程:对于每天层出不穷的可靠性问题,依靠人(SRE)的经验每天去排除,是既不靠谱也不经济的方式。混沌工程是把经验转化为探索规则,对在线系统进行或计划或随机的应用探索,来学习观察系统的反应,以发现系统不可靠因素的工程体系;
-
Service Mesh(服务网格):通过把 RPC 框架可以完成的功能,下沉到基础设施层,以便统一迭代建设,同时解决多语言栈难以统一的痛点;
-
故障精准报警(根因分析):业内有工程和机器学习两个流派,我们选择工程派,用动态 CMDB+ 分布式跟踪 + 决策树来寻找根因;
-
故障自愈:在根因分析的基础上,通过构建灵活的预案构筑框架,逐步提升可故障自愈的比例。
写在最后
结合小米几年间自动化运维平台建设的经验,孙寅认为,当前这个技术时代,不管企业规模大或小,都建议不要绕开开源自造轮子。如果企业规模小,直接用开源组件来解决企业痛点,如果企业规模大,可以改进或借鉴开源组件以解决性能和扩展性类问题,将各种开源技术组装、二次开发来解决复杂场景里的功能需求。
同时无论起步处于哪个阶段,都应该自订标准,因为开源组件仅是解决某一类问题的痛点,但标准是未来让组件协同,解决整体复杂场景问题的基础。
作者简介
孙寅,前百度资深架构师,曾负责百度运维平台多子系统;现小米资深架构师,负责小米运维体系基础架构、基础平台。
以上所述就是小编给大家介绍的《小米自动化运维平台演进设计思路》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 小米流式平台架构演进与实践
- 小米流式平台架构演进与实践
- 小米崔宝秋:小米 AIoT 深度拥抱开源
- 小米8 SE和小米9 SE 开源 Android 9 Pie 内核代码
- 小米8 SE和小米9 SE 开源 Android 9 Pie 内核代码
- 开源改变了小米什么?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Data Mining
Jiawei Han、Micheline Kamber、Jian Pei / Morgan Kaufmann / 2011-7-6 / USD 74.95
The increasing volume of data in modern business and science calls for more complex and sophisticated tools. Although advances in data mining technology have made extensive data collection much easier......一起来看看 《Data Mining》 这本书的介绍吧!