当前位置:澳门贵宾厅 > www.vip8888.com > 在云计算和 DevOps 的双重压力下,今天主要跟大家分享
在云计算和 DevOps 的双重压力下,今天主要跟大家分享
2020-01-25

作者 | 滕圣波策划 | 田晓旭

Markdown

运维是从 IT 诞生之初就一直存在的重要角色,在 IT 类企业中,尤其是互联网企业,运维、开发和测试被称为是驱动技术进步的三驾马车。而金融、政府、医药、教育、制造、运输等其它行业,为了进行数字化转型,也纷纷建立了自己的或大或小的数据中心,并为了维持这些 IT 系统的正常运转,设立了大量的运维岗位。可以说,信息技术已经并且正在改变我们身边的一切行业,而只要有 IT 系统的地方,就有运维同学的身影和贡献。

7月15日上海的《DevOps&SRE超越传统运维之道》主题沙龙上,数人云工程师保珠从核心理念、金融行业ITSM特性、发布协调、监控告警、总结定位等方面详细地阐述了数人云在金融场景下的落地实践。

但最近几年,云时代的到来,让很多运维同学倍感焦虑,“云计算是未来”得到了大多数人的认同。2019 年 Q1,公有云 IaaS 市场同比增长 74%。越来越多的企业,开始把自己线下的数据中心和机房搬迁上公有云。而一旦企业放弃了自建的 IT 基础设施,甚至把员工的办公电脑都搬到了云上,由公有云厂商提供服务,那么企业是否还需要这么多运维人员呢?

Markdown

与此同时,DevOps 思潮席卷全球,大家纷纷尝试“组织机构变革”,打破开发 测试 运维之间的边界,由开发人员来直接负责自动化的测试和运维工作。更进一步,从 DevOps 进化出了 AI Ops 甚至 No Ops,人工智能开始在运维领域显露身手。而云计算与 DevOps 正好是天生一对。云是 DevOps 最好的平台,而 DevOps 是云上的最佳实践。

今天主要跟大家分享数人云SRE的落地实践,因为目标客户主要是金融行业,所以基于ITSM特性,介绍实际场景中的发布协调和监控告警。

在云计算和 DevOps 的双重压力下,运维的未来会何去何从?

SRE核心理念

Markdown

SRE是谷歌十数年运维过程中演练出来的模式,在实践过程中积累了很多经验,跟传统运维有一些区别。是建立在DevOps的思想上的运维方面具体实践。

Markdown

SRE岗位工作职责有:

SRE跟传统运维的工作职责类似,但在工作方式上有很大区别:
1)应急响应主要落实在对监控、应急事件的处理以及事后总结。

2)日常运维包括容量规划、性能监控、并更管理。

3)工程研发方面跟传统运维的区别在于参与研发事件、SLO制定和保障以及自动化,自动化运维是长期目标,也是热点内容。

Markdown

SRE的工作原则:
拥抱变化:不担心付出风险而拒绝改变,通过不断的推演和演练发现并解决问题。

服务等级目标:将服务划分等级分配给不同的运维。

减少琐事:节省更多的时间用于开发。

自动化&简单化:开发的主要目的。

云时代的运维是怎么样的?

金融行业ITSM特性

Markdown

金融行业在ITSM的特性主要是分级管理,工作模式上,运维和开发完全隔离,但这是DevOps思想尚未达成的表现。运维团队规模是线性增长的,如上线一个系统时都会分配1—2个运维人员进行跟进。不管从网络还是资源分配上,他们的职责更多在应急事件处理和常规变更上。

证监会和银监会有合规运维的要求,比如两地三个数据中心,这是金融行业比较明显的特性。

Markdown

传统模式和SRE的区别——
传统模式:易招聘,传统行业招聘的运维首先是会Shell,Python等脚本编写,在自动化运维工具上会有新要求,过往经验积累如曾解决的事故,应对的问题。

SRE:难招聘,相对新兴的岗位,很难找到完全匹配的人才;会有开发上的要求,强调自动化,包括在自动化工具里做编程性的内容,团队协作等等。

Markdown

接下来分享SRE在两个客户实际场景的落地:某交易所、某商业银行信用卡中心。

SRE平台架构模型如上图,资源供给层是基于数人云的PaaS平台,以Docker容器化管理做资源调动,应用调度分别基于Mesos和Marathon,目前数人云也开源了名为Swan(Mesos调度器,Github地址:https://github.com/Dataman-Cloud/swan 欢迎Star&Fork)的应用调度系统,目标是把Marathon替换掉。而后是软件技术架构层,对应公司里的架构部门,包括采用RPC框架、缓存、消息中心选型等等。

主要分享的内容在DC SRE这一层。再往上包括产品线有TISRE,也有接近于用户数使用的APP SRE,所以个人理解这是长期的建设过程。

冲浪是一个非常刺激的极限运动。相比海浪的力量,冲浪者的个体力量是渺小的,每一次冲浪都是一次冒险。但智慧并且勇敢的冲浪者会仔细观察海浪的方向并调整冲浪板与海浪方向一致,当海浪抵达时,冲浪者会站起来,在海浪的冲击下急速前进,享受浪尖上的快感。

实践—发布协调

Markdown

发布协调在日常的工作中应用很多,如应用上线、变更管理。在SRE指导下,某项目现场成立了类似于发布协调的团队。成立SRE团队与金融行业系统上线特点有关:

如何解决以上问题,达到发布进入可控,降低发布失败率,缩短发布时间周期?

Markdown

上述问题,在SRE的思想中,首先要建立发布协调团队。目前SRE工程师只能自行培养。团队推荐构成:项目经理、架构师、运维工程师、开发工程师。沟通方式以发布上线会议为主,不断Check系统或者产品开展工作。

Markdown

团队的职责包括:审核新产品和内部服务,确保预期的性能指标和非性能指标。根据发布的任务进度,负责发布过程中技术相关问题,以及协调外包公司的开发进度等等。

最重要的是要做到发布过程中的守门员,系统是否上线要由发布协调团队决定。

Markdown

团队在整个服务生命周期过程中,不同阶段,都要进行会议审核才能继续开展工作。会议根据发布的检查列表包括三个方面:架构与依赖、容量规划、发布计划。

在架构与依赖方面的逻辑架构,部署架构,包括请求数据流的顺序,检查负载均衡,日志规范着重配合监控方面的要求。同时检查第三方监控调用时是否进行测试管理等等。

容量规划主要是根据压缩报告做容量预估,以及峰值,比如微信活动比较多,所以会根据预估峰值的公司预算出来需要的资源,再落实到容器上,制定详细计划保障发布的成功率。

制定发布计划,确保成功。

Markdown

在SRE的指导中,每件事都要落实到工具当中,由工具去检查每个事项是否落实到位。当时做了发布平台,包括PipeLine、Jenkins,通过其调用负载均衡上的配置F5和配置中心,以及服务注册中心的机制。所有的发布事项基于容器云平台,功能模块包括变更管理、发布管理、流程模板及发布过程监控。

Markdown

上图是发布平台项目大盘图,可以看到项目在发布流程中执行情况——成功率和失败率。没有发布平台前,整个上线过程管理人员不能实时看到发布具体情况,是卡在网络还是某一个服务上,因此进度不可控。

有了这样的运维大盘后,整个发布过程能进行可视化跟踪,关键节点需要人工审核。

具体的发布步骤:

整体过程都体现了SRE思想,发布平台的每个步骤均可通过界面配置完成,中间关键点由人工参与,目的是保障产品上线的成功率,避免在上线过程中手动配置产生问题,导致回滚事件发生。

Markdown

有了发布协调团队后,上线的成功率、自动化程度和发布效率明显提高,减少了人肉操作落实在Jenkins、PipeLine的配置项上,降低错误发生几率。

冲浪者很清楚,自己成功的关键在于找准海浪的方向。我们技术人员也一样,只有保持对新技术的敏感性,并及时调整自己,才能借助浪潮的力量快速进步。

实践—监控告警

Markdown

监控作为一个垂直系统,在数人云的产品体系中举足轻重。监控的重要性深有体会,我们在某金融公司SRE团队中有1—2名监控专员,专员主要职责是维护监控系统。一个是甲方内部人员,另一个是数人云的同事。

监控主要解决的问题:
首先要及时发现,时效性很重要,因此需建立监控系统。

为什么会出现故障,要多做事故总结以及后续的故障跟踪。

Markdown

上图为监控系统架构图,基于Prometheus的时序数据库,红线为监控的数据流向,因是Mesos框架,所以左边会看到Mesos运算节点上的监控项。通过容器化的Cadvisor组件收集主机和该主机所有容器的CPU和内存以及磁盘信息。告警部分使用Prometheus的Altermanager组件,支持Webhook方式,通过短信、邮件形式告警。为了事后总结,需将一些告警事件存在数据库中。

绿线主要体现在日志收集和关键字告警,日志收集通过容器化的Logstash组件,首先收集容器内部的中间件,如Tomcat等Web中间件的日志,也能收集应用日志,根据需要会把一些信息丢到Kafka里面,通过大数据平台做在线日志分析。

Markdown

日志关键字告警是通过自研组件在日志传输过程中过滤关键字进行事件告警。

容器服务的健康状况通过Marathon的事件Pushgateway推到Prometheus,最后在前台以自己开发的UI查看监控信息和告警上的配置。为方便使用Prometheus的查询做统一封装,减少API使用复杂度。

Markdown

在SRE体系里很明确提到了监控的4大黄金指标:延迟、流量、错误、饱和度:

以上指标要在运维的过程中不断优化,如一些告警可能是网络原因进而产生其他问题,如网络交换机出现问题,直接挂掉平台的Marathon组件,应用上很明显是第三方服务调用,接连会产生很多问题,要把共性问题聚合,减少误告警次数。但减少误告警也可能会把有效告警卡掉,也值得思考。

Markdown

故障跟踪和事后总结类似,人工操作会延长恢复时间,告警发生时一般由一个人处理,随着时间延长而升级策略,如超过半个小时会逐级上报调用更多的资源处理故障。在故障跟踪上解决线上问题为主,处女座强迫症为辅,做好总结Root Cause更好的反馈到自动化工具上。

Markdown

事故总结非常重要,解决不意味着结束,要追溯原因,如交换机重启,导致Marathon的一些问题,总结后发现,最好的解决办法是交换机重启时通知运维,停掉相关组件,交换机恢复后,再启动,如此不影响业务的实际运行。

要从失败中学习,把告警的事件做记录建立知识库,发生问题时方便检索,快速找到解决方案,要总结解决某个事故时如何更快发现问题所在,建立反馈机制,在SRE监控过程中,不断跟产品做实时反馈,包括连接池的使用情况等,鼓励主动测试,平时运维不会发生的事,尽可能想办法去看结果。

给大家讲一个真实的故事。2009 年,阿里云刚刚成立的第二年,时任淘宝技术总架构师行癫宣布淘宝网将抛弃 Oracle,转投云上的自研数据库。获知此消息后,八十多个 Oracle DBA 把当时的 DBA 负责人后羿堵在会议室里,“如果上边铁了心要干,兄弟们的前途在哪里?”还好,技术人是讲理的,一场恶斗转化成了几十个工程师坐在会议室促膝谈心。既然上云是战略,为何不顺势而为?就这样,一群 Oracle DBA,开始亲手拆毁自己安身立命的系统。2013 年 7 月,淘宝最后一个 Oracle 数据库下线。时至今日,整个阿里集团,所有的核心业务 100% 跑在公共云上。

目标定位

Markdown

SRE目标定位内容很多,在各个行业落地时不尽相同,所以要基于现实,拥抱变化,为了更好应对事故,坚持做推演和演练,在事故总结方面对产品做建言,故此在工具的研发上也会有决策权。

是啊,既然上云势不可挡,我们何不顺势而为,看看云上运维是什么样子的?

首先,云上运维和传统的运维,操作的目标是不一样的。传统的运维人员,需要能够熟练的手动操作来自众多厂家的计算、网络、存储等硬件设备,而云上的运维人员完全接触不到物理设备,取而代之的是云上的虚拟资源,例如云服务器,云盘,虚拟交换机等。云厂商将对资源的操作全部抽象成了软件定义的 API 接口,并用统一风格的 SDK、命令行进行封装,提供给运维人员使用。云厂商提供的图形化的运维控制台,也不过是 API 的封装而已。

其次,云上运维是高度简化的。传统的运维,需要学习来自众多“大厂”的认证,例如,网络运维要学思科的认证,数据库运维要学 Oracle 的认证,系统运维要学 IBM 的认证,等等。而在云上,虚拟专有网络产品将网络设备的管理和运维变得统一和简单,云上数据库产品实现了智能化的数据库管理,云服务器实现了动态的扩缩容和热迁移,这些都大幅降低了运维操作的门槛。云上的运维人员不再需要感知底层基础设施的细节,更不需要考取高难度的认证。即使是创业阶段的小企业也可以拥有和大企业同等的运维能力。

但是运维简化,并不意味着运维的重要性降低,相反,在云上,运维变得比以前更加重要了。

云时代运维面临的挑战

为什么在云时代,运维变得更重要了呢?主要有两个原因,一是云上运维的范畴比以往扩大了,二是云上企业对于稳定性的要求更高了。

从范畴上看,云上运维包含了从蓝图规划,到上云交付,再到云上管理的全过程。如果我们具体到流程和阶段,包括了设计选型、资源交付、系统交付、运维调优、扩缩容、资源运营、备份容灾,安全 审计等等。

从稳定性方面看,通常云厂商只负责基础设施的稳定,上层应用仍由企业开发人员自主开发,同时云上应用本身的稳定性也由企业自己的运维人员负责。如果具体来说的话,企业运维人员需要负责持续发布过程中的蓝绿发布、灰度发布、分批发布、自动回滚等的实现,以及应用层的监控、事件告警体系的建设。另外,云上基础设施的稳定性不能单纯依靠云厂商,也需要企业运维人员的相互配合。例如阿里云的云服务器单台实例的可用性达到 99.975%,但仍然存在着万分之 2.5 的不可用时间。企业的云运维人员可以采用监控、负载均衡、多机热备、两地三中心等常用的高可用设计,在不是百分百可靠的基础设施上,搭建百分百可靠的应用。

具体来说,云上运维主要面临着以下挑战:

首先,运维排查问题的难度增加了。由于云上“黑盒子”的存在,当故障突然发生时,运维人员往往只能看到服务出现异常了,很难快速判定问题出在哪里?是云服务商的基础设施出问题了,还是我自己的代码出 bug 了? 甚至就算排查出是云服务商某个服务的问题,部分运维人员也只能打电话给客服寻求帮助,而从客服得到的回复往往难以令人满意,从而耽误了故障恢复时间。

第二,云服务发出的消息、日志、事件等难以有效处理。如果运维人员每天收到几千条短信或者邮件,一定是无法及时处理的,只能无脑忽略。但是又不能设置邮件规则将它们全部扔到垃圾箱里,因为会担心漏掉重要的通知,比如服务器宕机的通知。

第三,资源的膨胀带来了管理的复杂性。所有的资源都是软件概念,对于一个大企业来说,这些资源可能分布在全球的十几个 region,分散在几十个云产品的控制台,服务于几百种不同的负载或者在线服务。更可怕的是,这些资源一直在变化。如何有效的跟踪、审计、创建、释放并保证无浪费?

第四,云产品的频繁升级带来了运维的频繁被动变化。云产品的选择非常多,实例类型纷繁复杂,包括预付费、后付费、预留实例券,什么性能突发型、计算型、通用型、GPU 实例、专有宿主机、裸金属实例,容器服务、Kubernetes 或者 Swarm、弹性容器实例,等等。更要命的是,这些云产品还在不停地发布升级,如何选择适合自己的产品?新功能如何才能帮助到业务? 盲目追随云厂商的脚步不是良策。

如何调整才能适应云时代的运维?SRE 可能是答案

如前面所说,企业上云之后,仍然有大量的运维需求。但此时的运维,却又与传统的运维截然不同。企业应该如何进行结构调整以适应上云后的新形势呢?

DevOps 是现在提到的很火的概念,DevOps 实践的整个生命周期是从计划 -》编码 -》构建 -》测试 -》发布 -》部署 -》操作 -》监控,再回到计划,是一个循环。其中发布、部署、操作和监控是属于运维领域的。

DevOps 实践打破了开发和运维之间的壁垒,开发人员可以直接负责运维。云上的运维已经和软件开发融为一体,强调高度的自动化,沉淀了一系列的运维工具和运维平台,并朝着 AIOps 和 NoOps 的方向持续演进。

而反过来,运维人员如果能掌握开发技能,结合自动化工具的使用,是否能够做的更好呢?答案是肯定的。运维人员可以转型升级为兼具开发技能和运维技能的站点稳定性工程师。Google 最早推出了 SRE 这一概念,并使得 SRE 部门成为其承担运维职责的一个研发部门。越来越多的上云后的企业,开始把自己的运维部门改造升级为 SRE 部门。

SRE 听上去很美,但真正要做到并不容易。以阿里云为例,早年阿里云也走过人肉运维的痛苦阶段,尽管运维工程师 7*24 轮班 on call 待命,但客户仍然投诉不断,系统问题不断。后来,阿里云团队开始建设稳定性,通过监控报警将故障的平均发现时间从 1 小时缩短到 10 秒钟,同时借助 AI 预测算法,在某些情况下可以在故障发生前,提前预警并采取行动。现在阿里云每年发布上千次变更,难免会出现变更导致的故障和异常,但是 SRE 团队蓝绿发布、灰度发布、分批发布、自动回滚、热迁移等技术,实现了发布全过程无人值守。

如何才能升级成为 SRE 呢?这三点建议可能对你会有所帮助:

一是学习 DevOps 的实践,熟练掌握至少一种编程技能,从思想和技术上,保持工程师的先进性;二是学习云厂商提供的各种自动化运维工具,并灵活运用,尝试帮助自己企业搭建高效率的自动化运维平台;三是积极参与开源和云厂商的生态建设,伴随运维生态一起成长,如果能产生出运维平台级的解决方案产品,广泛应用于整个行业,那么个人价值和商业价值都会得到体现。自动化一切是云时代运维的首要任务

要想实现云上运维的顺利升级,首要任务就是”自动化一切“,如果列出 Top3,应该是:监控自动化、运维操作代码化、基础设施代码化。

监控自动化

先来看监控,包括了“监”和“控”两个方面。

监控的“监”

“监”,从横向划分,包含了事件,日志,指标,告警四个维度;从纵向划分,分为底层基础设施的“监”和上层应用的“监”。

横向看:事件、日志、指标和告警

什么是事件?对于云服务商来言,事件其实是资源的变化,每一次资源的变化,都是一个事件。例如云服务器的每一次状态变化都是一个事件,包括开机中,运行中,关机中,已停止。

什么是日志?日志是客户行为和云服务内部行为的过程记录,包含时间、操作者、内容、级别等要素。每一条事件,都可以转化成相应的日志,记录到日志服务里。因此,日志的范围,比事件更大。日志服务所提供的,不仅仅是日志的记录,更重要的是日志的聚合和检索能力。例如,运维人员可以随时查看某一个资源在过去某一个时间段的历史记录。

什么是指标?指标是资源运行时的内部属性数据,最典型的指标就是 linux 里面 top 命令所显示的数据,包括 CPU、内存、IO 数据等。这些数据不属于事件,也没有记录下来作为日志的必要,但仍然是很重要的实时数据,是运维人员需要关心的系统健康指标数据,如果一切健康,就可以忽略。

什么是告警?告警可以认为是严重级别的事件,是需要立即采取人工或者自动化动作的事件。运维人员可以根据指标设定阈值来触发一个告警,也可以在事件和日志的基础上设定报警规则,触发告警。

纵向看:底层基础设施和上层应用

底层基础设施的“监”,需要由云服务商来提供基础数据,云厂商的监控往往会提供针对基础设施的事件、日志、指标、告警,运维人员可以很方便的配置和接入。

上层应用的“监”,可选择的产品就很多了,例如阿里云的应用实时监控服务 ARMS 提供了针对上层应用层的事件、日志、指标、告警,用户也可以选择开源的 prometheus 或者 zabbix 来自建。

基础设施和上层应用之间的边界并不是绝对的,其实我们需要的往往是从下到上的全监控。

监控的“控”

“监”的目的,是为了“控”,这里的控,具体指的是对事件和告警的处理。以短信,电话,邮件等方式通知给联系人,是最简单直接的处理方式,但这种方式显然容易被人忽略,而且延时很大。因此,SRE 应该实现自动化的事件处理。

运维操作代码化

如何实现自动化的事件处理呢?程序员可能会自然想到自己写一个 Event Consumer 程序,从云监控拉事件,然后调用资源的 API 进行处理。这个做法看上去很容易,但是具体实现真的这么容易吗?

首先,对于运维自动化平台来说,可靠性非常重要,如果 Event Consumer 只有一个单点,那么一旦出现故障宕机,就无法再处理系统事件。

这时,有经验的程序员可能会说:“我可以引入消息队列服务,进而利用多进程 Event Consumer 来分布式的消费,从而避免单点故障。”

当然,这是个解决方法,但是还会有一个问题,没有任何一个分布式的消息服务,可以实现既不重复也不遗漏消息,我们只能选择不遗漏消息,而接受可重复的消息。但重复消息可能导致重复操作,这不能被运维人员接受。那么,怎么去重呢?我们只能引入分布式的 KV 数据库,比如 Redis,根据 EventID 和原子的 Redis 操作来作为消息去重的工具。

另外,一个事件的处理仅仅是调用一个 API 吗?不一定的,你可能需要对多个资源进行多个 API 调用,这些调用之间彼此有依赖关系,有些甚至必须串行。为了保证多个操作的事务性,即要么全部成功,要么全部失败,这时就需要一个分布式工作流引擎。

什么?你还需要定时的任务?那么,只能再引入分布式的定时任务框架了。

这样一看,是不是越来越复杂?实现一个高可靠、分布式架构的运维平台,显然不是一件容易的事情。何况,运维开发与普通软件开发不同,快速开发是第一位的,因为运维开发的需求变化更频繁,开发周期更短,人力也更为紧张。若没有平台的支持,单纯靠运维人员自己从头搭建一个自动化运维系统,并保证高效稳定持续运行,难度和投入都很大。

为了保证生产系统的稳定,创造了一个运维系统,那么,谁又来保证这个运维系统的稳定呢?这是一个悖论。

如何轻松实现“运维操作代码化”呢?两个建议,一是选择一个可以快速开发的简洁的运维语言,二是选择一个可靠的事件驱动的运维平台,而不是自己从头造轮子。

在运维语言方面,脚本化的语言成为了主流,比如 YAML,JSON 等,在遇到复杂的逻辑的时候,可以借助 Python、Shell,而 C、C++ 之类的语言,运维人员用起来就有点沉重了。

开源的运维平台,我们可以选择 Ansible、Puppet、SaltStack 等等。以 Ansible 为例,其核心卖点之一是“Agentless”,运维人员安装 Ansible 之后,可以直接基于 SSH,编写 YAML 格式的 Playbook,做 Linux 集群的管。另外,各个主流云厂商也为 Ansible 编写插件,因此运维人员可以用 Ansible 管理云上的运维动作。值得注意的是,云服务商也会提供原生的运维平台,比如阿里云提供的运维编排服务 Operation Orchestration Service,简称 OOS),AWS 提供的 System Manager Automation 服务,或者 Azure Automation 服务。

基础设施代码化

云基础设施包括云服务器、云存储、DNS、CDN 等,而传统的云基础设施管理总是面临着各种各样的难题,例如咨询审批流程长、响应不及时,手工安装和配置速度比较慢、难以版本化,易出错、遗漏配置项等等。

为了规避这些问题,我们提出了“基础设施代码化”,它指的是用代码的方式管理基础设施,并且维护管理它的全生命周期,包括审计的要求。代码成为了审计很好的记录,代码变更也可以追溯到人、项目组,解决了变本、追溯和变更历史的问题。

基础设施代码化后,会给我们带来什么样实际的好处呢?

我们举一个例子,假设在阿里云上搭建一个经典的三层在线服务:前面是 SLB 负载均衡,中间是若干台 ECS 作为一个服务集群,后面再挂接一套 RDS 数据库。同时,我们为这三层各自创建了一个 VPC,通过安全组设置安全规则。

在业务初期你可能只需要两台 ECS,但很快会扩大到 3 台、4 台。这时应该怎么办呢?比较直接的办法是在阿里云控制台操作,今天创建一台,明天再创建一台。

但这种方法明显是比较笨拙的,我们能不能使用“基础设施代码化”的方法呢?当然可以。我们把资源,定义在文本文件里,做成配置项,保存到云上。比如有一个配置项叫做 ServersAmount,代表服务器数量。我们把这个配置项从 3 改成 5,ECS 数量就自动从 3 台增加到了 5 台。再把 ServersAmount 从 3 改成 2,会自动释放其中一台 ECS。代码,或者说配置,是有变更历史记录的。代码也是可以很清晰地被审查的。代码还可以很容易的被复制。

怎么实现“基础设施代码化”呢?最关键的是需要一个平台,如果选择从头开发,那就不再是造轮子了,而是在造轮船了。

那么什么样的平台是值得选择的呢?开源的 Terraform 是个不错的选择,它得到了各个主流云厂商的官方支持,用户可以直接使用。不过,Terraform 要求运维人员自己准备服务器来配置安装,还要自己维护这个平台。另外,云厂商也提供了开箱即用的云服务,例如阿里云提供的资源编排服务。

云时代运维的未来发展

正如前文所述,云时代的运维工作正从手动操作过渡到代码开发,只不过这些用于运维的代码,形式不拘一格,可以是配置文件,可以是 YAML 或者 JSON 模板,也可以是传统的 Javascript/Python/Go 等代码。那么,未来,云时代的运维会怎么发展呢?

在我看来,云时代的运维发展其实很大程度上取决于云上应用和基础设施的变化。我们可以大胆分析和预测,未来云时代的运维将会是这样的:

目前主流的云上应用架构是自建 API 网关 + 微服务 + 分布式 RPC+ 消息队列等,这种架构需要的云上基础设施是负载均衡 + 云服务器 + 虚拟专用网络 + 云关系数据库等,其运维方式如前面介绍的。未来几年比较确定的趋势是云上应用开发会越来越多的使用 Reactive 响应式 (反应式) 编程,全异步、事件驱动,对应的基础设施则会容器化,隐藏掉服务器这一层,这预示着运维工作会越来越多的围绕容器编排,比如 Kubernetes 展开。中远期的未来,函数计算这种 Serverless 的开发模式将会流行起来,对应的基础设施则会简化到连容器都看不见了。用户不再为基础设施而付费,而是为实际的计算次数付费。云服务商会利用机器学习等手段,来保证函数计算所需的基础设施是高可靠的和高度灵活的。到时,运维人员已经不需要关心资源的编排了,但是函数内业务的监控和运维动作的自动化还是需要的。更长远的未来,云计算,边缘计算,本地计算,可能会统一到一起,不再区分“线上”和“线下”,取而代之的是一种无处不在,但又不被人感知的计算力。具体来说,应用开发者写完代码,保存起来,就完成了业务的更新。“基础设施”和“资源”这两个概念,将彻底消失,只留下数据本身,包括静态数据以及动态运行时数据。而运维,并不会消失,但会从面向资源的运维,变成面向数据的运维。

下一篇:没有了