阿里巴巴DevOps实践指南(十九)| 监管控一体化运维

阿里巴巴DevOps实践指南(十九)| 监管控一体化运维

编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》,扫描上方二维码或前往:https://developer.aliyun.com/topic/devops,下载完整版电子书,了解阿里十年DevOps实践经验。

阿里巴巴的运维体系经历了脚本时代、工具时代和 DevOps 时代,目前正在实现自动化运维并探索智能化运维阶段。在 2008-2009 年,阿里巴巴的运维还处于脚本时代,大量的运维工作需要通过脚本来实现。随着业务规模扩大和复杂度的提高,脚本的方式越来越难以维护,因此阿里巴巴开始引入运维工具。在运维工具时代,阿里巴巴的运维体系经历了:从工具团队和运维团队并行的阶段,到为了更好地保障工具质量统一的工具团队阶段,再到逐渐有 DevOps 思想和职能的偏软件的工具团队阶段。最后,阿里巴巴应用运维团队迎来了一场大变革,以前的应用运维团队全被打散,合并到各业务的软件开发团队中去,全面践行 DevOps 思想。

阿里巴巴DevOps实践指南(十九)| 监管控一体化运维

进入 DevOps 阶段后,成熟的流程化运维工具虽然提升了一部分运维效率,但是各个工具之间实际是独立割裂的,例如监控工具和运维工具是割裂的,巡检工具和快恢工具也是割裂的,这导致日常应用持续运维过程中,从监控发现、定位并快速恢复问题的链路很长而且低效。对运维开发来说,期望的状态是业务应用上线后可以“No Ops”,监控及运维系统能自行发现异常并自动解决,把应用及业务带回正常状态,处理结束后,发一个消息通知下即可。 朝着“No Ops”方向努力,阿里巴巴应用运维开始了“监管控一体化”的体系建设。

新挑战

随着阿里巴巴业务的持续发展及技术架构地不断演进,新的场景和问题不断出现,这些都给以应用为中心的监控运维带来了新的挑战。

超大规模

阿里巴巴不但拥有众多形态各异的业务,而且体量大,特别是每年天猫双 11 大促,需要超大规模的 IAAS 资源支撑。2015 年之前,阿里巴巴每年都要花费巨额费用来购买服务器,建设一代又一代的 IDC 数据中心;2015 年至 2019 年,阿里巴巴走向全面云化的过程。在这个时期,阿里巴巴的基础设施一部分在云下数据中心,另一部分在阿里云上的数据中心,还需要支持同城多活到异地多活,所以必须要有强大的云上云下一体化超大规模资源管理的能力;2019 年阿里巴巴实现全面云化之后,又开始面对一个新的超大规模资源管理场景:混合云。

运维效率

业务发展瞬息万变,特别是公司的重要业务,迭代变更的速度非常快。在超大规模集群管理的前提下,为了保障业务的连续性和快速迭代,我们需要有能力持续高效地对应用进行发布、部署、变配等运维变更。这也就是 DevOps 的持续运维领域要去解决的问题。

运维安全

安全性是任何行业的基础,在 IT 运维领域更是如此。系统宕机、数据异常、数据丢失、删库跑路等运维故障和事件层出不穷,这可能给企业带来致命的打击,甚至关乎业务的生死存亡。因此,防范和杜绝高危运维故障是 DevOps 一直不懈追求的目标。在当代众多业务形态和云技术架构下,如何保障企业 IT 运维的安全运行至关重要。

业务连续性

在阿里巴巴传统的监控和运维模式下,应用的运维开发需要在监控系统上配置一些监控项和预警规则。当监控项触发预警规则时,运维开发会收到预警通知。紧接着运维开发需要打开电脑,在运维工具平台上创建相应的处理工单。当运维系统工单执行完成后,运维开发要持续观察监控项是否回归正常。若遇到节假日或休假期间接到预警通知,不能及时上线查看情况时还需要联系团队其他同学上线处理;若在半夜睡梦中接到预警通知,需要立马清醒下自己的大脑,打开电脑上线处理。整个预警异常处理过程持续时间较长,并且需要人为参与的工作很多,人力成本大,这使得运维开发的工作幸福感很低。

另一方面,随着业务地不断发展,系统也在不断增加,监控项和预警也急速增多,慢慢地运维开发就会对预警信息变得麻木或轻视,容易错失一些重要的报警信息,进而导致线上业务故障。近年来,淘宝直播、盒马线下门店、饿了么外卖、钉钉在线教育等新业务形态蓬勃发展,这些业务基本上对生产故障都是零容忍,原来系统最佳的 99.99%可用性已经不能满足新业务的要求,而传统的监控、运维各自为战、单打独斗的模式更无法满足新业务 100%业务连续性的要求。

解决思路

为了保证生产业务的连续运行,提高业务系统从异常预警到异常恢复的整体效率,解放人力成本的同时又能确保安全,我们考虑将监控预警和运维执行联动起来,视为一体,从而实现异常自动发现、自动快速定位以及自动快速恢复的目的,达到一种“No Ops”状态的应用运维。

在应用监管控一体化建设之前,传统的监控和运维是分开的状态,运维开发想要在应用迭代变更期间关注系统运行态势,需要事前在监控平台上定义和配置好这些应用所要关注的各项指标。在应用变更期间需要不断主动查看应用监控指标的变化,或者为每个指标设置预警规则,通过订阅接收配置好的监控报警来及时获取应用的运行异常。当应用变更出现异常报警后,运维开发需要看监控、应用日志、应用调用链路等信息分析异常原因,决策需要到运维平台上执行什么任务才能恢复,最后验证任务执行结果是否符合预期。因此,明确需求->配置监控指标和报警->分析异常原因->决策处理方式->执行任务->验证执行结果,整个过程都需要运维开发的介入。

阿里巴巴DevOps实践指南(十九)| 监管控一体化运维
阿里巴巴DevOps实践指南(十九)| 监管控一体化运维

解决方案

以保障业务持续性为源动力,在逐步推进监管控一体化建设过程中,阿里巴巴从实战经验沉淀出一套业务系统安全工程标准,实现了业务异常故障提前发现、自动定位、快速恢复地自动联动,在监控、运维、安全防护领域探索出了多样化的解决方案。

安全防护

在推进 DevOps 的过程中,我们要求的底线是不能对既有的现状带来更多不可控的因素,特别是高危场景的防护,不能因为运维工作移交到运维开发人员而造成全局系统性风险,因此安全防护方案孕育而生。

全景监控

监控是运维的基础,传统的资源监控或者应用监控模式已经不能满足运维开发快速发现生产故障的需求。基于阿里的大规模实践,我们发展出了以应用为中心,从上层业务到 PaaS 直至底层资源的全链路监控解决方案,为业务异常发现和定位提供了强有力的支撑。

多样化运维

为了实现监管控一体化,促进业务异常能快速自动恢复,应用运维从原来的单事件执行模式,探索出以应用为中心的可编排运维、智能化运维、ChatOps 等运维模式,打开运维领域新视角。

总结

阿里巴巴应用运维监管控一体化的建设随着业务形态和技术架构还在不断地探索和发展,本文主要介绍了应用运维监管控一体化建设的背景和思路。我们以应用为中心,从应用监控管角度出发,通过全视角监控实时掌握应用的运行状态,通过高效发布部署和灵活的运维编排对应用进行安全变更,通过智能化运维和安全防护实现应用的高级防护,我们将在下面的章节为你详细展开。

免费下载《阿里巴巴DevOps实践指南》

阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。

前往:https://developer.aliyun.com/topic/devops,下载完整版电子书。

阿里巴巴DevOps实践指南(十九)| 监管控一体化运维

上一篇:阿里巴巴DevOps实践指南(八)| 以特性为核心的持续交付


下一篇:阿里巴巴DevOps实践指南(十八)| 基于制品元数据提升交付效率