云上架构与运维峰会演讲合集.pdf

卷首语从 IDC-Hosting 到 Cloud-Hosting，再到 Cloud-Building，云计算已是势不可挡的趋势。如今，人们讨论的已经不仅是上云，而是如何用好云。云计算所拥有的“软件定义一切”的特性，推动了敏捷弹性、DevOps、智能运维和基础设施即代码（Infrastructure as Code，简称IaC）等自动化运维趋势。2012 年 12 月 10 日，阿里云举办云上架构与运维峰会，希望通过分享云上架构与运维的最佳实践，促进业内 DevOps 与 IaC 理念的落地，帮助企业“用好云管好云”，释放云的技术红利。本书将 2021 云上架构与运维峰会中的技术干货沉淀下来，以飨读者。目录序5依云而生，把握云技术红利6理念与趋势7敏捷、可靠、智能：云上应用架构新模式8CloudOps：自动化运维新思路22云原生时代的运维体系进化35最佳实践52大搜车面向复杂业务场景的研发运维体系治理实践53SOUL 云上运维架构创新实践分享62日均订单量千万级，饿了么云上运维最佳实践75观点碰撞84云时代下，企业运维面临的挑战与机遇85Q1 企业为什么要上云？88Q2 云上运维工作最大的挑战与解法？90Q3 国内 XOps 的接受度与落地情况如何？92Q4 云时代，运维人员核心竞争力何在？94依云而生，把握云技术红利6序依云而生，把握云技术红利刘湘雯 阿里云副总裁、市场营销与公共事务部总经理（本文为 2012 年云上架构与运维峰会开场致辞）纵观世界历史，每一次生产力的大幅提升和人类文明的进步，都依赖于科技的进步。当前全球正在加速迈入数字经济时代，重构生产体系、创新生活方式和再造政府治理流程。以云为核心的数字技术创新体系成为了数字经济发展的底座，云与网络、终端深度融合，正在形成新型计算体系结构，向下带动芯片、服务器、数据中心等硬件体系发展，向上通过云原生革新传统 IT软件发展路径，催生低代码、DevOps、智能运维等新的开发和运维方式，让云更加易用，并构建了繁荣的应用生态。云原生是云计算的再升级，容器、K8s 和 OAM 正在成为云原生时代的“安卓”操作系统，成为云计算新界面。对于开发者来说，云原生正在重塑整个软件生命周期。对于企业来说，云原生是企业数字创新的最佳路径。使用云原生技术后，开发者无需考虑底层的技术实现，只需做好自己的业务，就可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等，充分享受云的技术红利。目前千行百业正在拥抱云原生，加速企业数字化创新，根据Gartner 的报告，到 2022 年，将有 75%的全球化企业在生产中使用云原生的容器化应用。阿里巴巴是云原生的引领者和最佳实践者。2020 年双 11 电商核心系统 100%云原生化，建设了全球最大容器集群、最大 Mesh 集群，神龙架构和容器组合，实现 1 小时扩容 100 万容器，混部利用率提升 50%，万笔交易成本 4 年下降 80%。2021 年双 11 云原生进一步扩大应用规模，在线业务容器达到百万规模，国际化核心应用 100%实现云原生。除了自身应用，阿里云研发了超过 300 个云原生产品和近千个技术解决方案，帮助我们的客户更好地使用云原生。阿里巴巴还拥有国内最全面的云原生开源贡献，开源项目数量超过 1000 个，涵盖大数据、云计算、AI、中间件、容器、Serverless 等领域。借本次云上架构与运维峰会的机会，希望与大家分享交流云上架构与运维的最佳实践，促进业内 DevOps、基础设施即代码的理念落地，与各位嘉宾共同探讨如何更好地使用云原生，更好地使用云，充分释放云的技术红利。敏捷、可靠、智能：云上应用架构新模式敏捷、可靠、智能：云上应用架构新模式时代发展到今天，各行各业的企业均面临着不同的机遇和挑战。首先的关注点就是社会的生活方式与生产方式的全面的数字化，无论是传统企业还是互联网企业，他们的生产系统、办公系统、商业销售、客户交互，都会不可逆转地全面线上化，比如今的外卖平台或者出行交通系统，都可以用手机操作来达成线上交易。其次企业所面临的外部环境变化极快。比如消费者的喜好和需求，随着消费层级及大环境在不断变化，进而很多零售企业也需要不断地加快产品上线，提高产品的核心竞争力，To C 的互联网企业也如此。10 月的云栖大会上，阿里云的客户映客分享，其新应用上线的频率高达 1 次/周。即便不考虑消费者，竞争对手也在不断地互相拼速度，。当下现状还伴随着不可控的疫情影响，以及监管政策、地缘政治等时刻影响着行业环境。人工智能、5G、大数据等新技术、同样也给了企业更多的能力和工具创新、实现自我变革和发展。敏捷、可靠、智能：云上应用架构新模式敏捷、可靠、智能：云上应用架构新模式不管是从业务需求场景还是技术趋势来说，架构的发展要求整体来讲都是要更可靠、更敏捷、更智能。越来越多的企业，重视高可用架构的构建，使用双活、多可用区、多地域、混沌工程等丰富的手段来提升应用的可靠性。微服务、Serverless 也是近年来非常热门的话题。以上均是相较之前更为敏捷的 IT 架构，某种程度上，也可以称作其是更可靠的架构。同时移动互联网、物联网的到来也让数据大爆发，大数据和 AI 等大计算需求场景也在日益增加。那么云计算如何能帮助客户构建一个可靠、敏捷和智能的架构呢？1、可靠在可靠的层面，可以分为两部分：基础设施层的可靠以及应用层的可靠。敏捷、可靠、智能：云上应用架构新模式敏捷、可靠、智能：云上应用架构新模式基础设施除了做到自身高可靠，还需要透明开放。很多客户上云之后，觉得基础设施层变成了一个黑盒，因此要求提供方能清晰地告诉他们底层的基础设施在发生什么，以便他们能做更好的主动运维。其实这个需求非常合理，因此，ECS 会把这些信息尽可能多地开放给用户，封装成不同的接口和事件，提供给用户，比如用户可以随时获取云服务器、操作系统等基础设施的最新情况。系统预测到客户方的机器可能会宕机、检测到 CPU 和内存用到警戒线了，都会发送事件，客户可以选择订阅。有用户反馈，最吸引他能长期使用阿里云产品的一点就是，阿里云有非常丰富和全面的接口。阿里云的接口，迄今为止是国内最全面、最丰富、最细致的，甚至在全球范围内，也是毫不逊色的。2、敏捷这个世界变化太快，怎么办？所谓天下武功，唯快不破！面对变化，唯一的办法就是比变化更快。敏捷、可靠、智能：云上应用架构新模式敏捷、可靠、智能：云上应用架构新模式阿里云作为领先的基础设施，首先要做到的就是快速交付。阿里云弹性计算提供了多种开箱即用的基础资源，仅云服务器就有上百款规格，并且提供极致的弹性能力。今年 7 月，阿里云作为首个也是唯一一个通过信通院大规模云平台性能测试的云厂商，在信通院工作人员的见证下，18 分钟扩容了 1 万台云服务器，而这还不是阿里云最快的速度。2021 年 10 月的云栖大会上，阿里云弹性容器实例 ECI 的研发同学，现场演示了在 6 秒内扩容了 3000 个 POD。借助阿里云弹性计算强大的弹性伸缩能力，客户可以快速地交付和部署底层资源，轻松应对流量峰值或者扩容新业务。针对不同的资源交付方式，阿里云还提供了丰富的付费模式，客户可以兼顾灵活与实惠。敏捷、可靠、智能：云上应用架构新模式敏捷、可靠、智能：云上应用架构新模式在业务层，企业需要根据自己的业务，引入相对应的机器学习、大数据等相关的技术，实现智能客服、自动驾驶等能力，这些都需要大量的数据和算力作为基础。为此，阿里云弹性计算针对这些场景提供了量身定做的大数据和本地盘实例，以及 GPU 和 NPU 等实例，为上层业务创新提供最适合的基础设施。在 PaaS 层面，阿里云提供了丰富的人工智能服务、机器学习和大数据框架等，客户可以轻松构建上层的应用智能。在基础设施层，阿里云的调度系统、故障预测和运维系统等，都广泛使用人工智能技术，使阿里云成为全球领先的 IaaS 技术平台。同时在弹性计算服务的用户体验上，我们也利用人工智能技术为客户提供一个更为聪明的基础设施。敏捷、可靠、智能：云上应用架构新模式敏捷、可靠、智能：云上应用架构新模式整体来看，阿里云弹性计算已经不仅仅是一个提供计算资源的平台，而进化成了一个支持应用全生命周期服务的云平台。阿里云通过强劲可靠、覆盖全场景的云服务器，高效智能的自动化运维套件，还有灵活弹性的资源供给，帮助客户构建可靠、敏捷、智能的云上架构。今年，阿里云还推出了面向办公场景的无影云电脑、以及面向合作伙伴服务上云的计算巢平台。敏捷、可靠、智能：云上应用架构新模式敏捷、可靠、智能：云上应用架构新模式三、从上云到用好云，把握技术红利三、从上云到用好云，把握技术红利上云已经成为了业界的共识。云计算虽已发展十余年，但这仅仅还是开始。我们观察到，很多的客户还没有把云的红利与优势充分地利用起来，比如云改变得最多的运维领域，大部分客户还处于半手工半自动化的阶段。所以，现在很多企业的关注重点，已经从上云变成了用好云。我们相信，未来十年，用好云，将为企业释放巨大的技术红利。CloudOps：自动化运维新思路CloudOps：自动化运维新思路DevOps 从提出到广泛使用已经超过 10 年了，近几年，我们能看到 DevOps 的一些趋势：1、DevOps 的范围和内容随着公共云平台的兴起有了非常大的变化，不再需要像传统运维一样自行管理基础设施，术业有专攻，DevOps 和 SRE 使企业能够以更高的变化率构建和发布应用程序。2、随着微服务改造和服务治理的深入以及云原生理念的深入，我们看到了垂直化和规范化带来的好处是快速交付，越来越多的企业架构有着服务化的设计，意味着服务的主题从内部延伸到更大的范围，这样应用数量激增无疑给运维带来了前所未有的挑战，在极度复杂的网状应用结构下，可观测性的实时性和准确性是个巨大的挑战，同时因为某些不受关注的应用产生了远大于预期的爆炸半径。3、过去的几年，自动化已经是 DevOps 中最重要的策略，但是随着企业应用的变化和越来越快、越来越敏捷的组织和应用交付形态，包括从传统的单体或者产品思路，到今天的开放化背景下，API 化和 AS Service 化对自动化的要求更加迫切。CloudOps：自动化运维新思路CloudOps：自动化运维新思路提升交付速度上:DevOps 的敏捷组织和自动化构建可以极大提升交付速度，对于应用需要的大量资源，云平台就是一个巨大的资源池，可以按需创建释放，通过结合云和 DevOps 可以极大的提升从资源到应用的构建速度。提升灵活性:DevOps 文化天然在灵活性上有着巨大的优势，让企业运营人员更加关注业务创新，而云计算能够快速自助的交付资源适应运营的需求。增强系统的可靠性:通过系统建设以及标准化和工具化建设，DevOps 对于系统可靠性的帮助是巨大的,通过工具和平台建设避免和降低人为问题和故障，同时高效的组织融合可以减少内部的不必要沟通。而云平台的首要责任就是可靠性和可用性，云天然提供了高可用的基础设施，以及工具和服务化能力，可以大大降低系统成本，创建更具弹性、安全性和标准化的系统。DevOps 和云的助力企业更好的实现降本增效。3、DevOps 进化的下一站：CloudOps从传统的研发到运维的模式到 DevOps，极大改善了从组织文化到应用交付部署的效率，对于系统交付和运维是巨大的进步，方便企业更加专注业务创新。如今，随着越来越多的企业使用了云资源，将基础设施的运维责任主体委托给了云厂商，我们认为一个新的时代已经到来，就是以云为中心的 DevOps，将重新定义 DevOps，通过充分的结合云计算和 DevOps 的优势和能力，我们定义了一个新的词汇：CloudOps，着重强调如何在云平台上更好的践行 DevOps，再次实现运维的进化。CloudOps：自动化运维新思路CloudOps：自动化运维新思路5、云资源如果不做好成本管理、阈值设计和资源量化管理将带来巨大的浪费，应该如何优化？结合上面提到的几个部分的挑战。我们归纳 CloudOps 的 5 个建设与衡量维度：1、自动化能力DevOps 最核心的一个能力是自动化能力，同样，自动化能力是云最核心的能力，为了提升自动化能力和可编程能力，云平台暴露了大量的开放 API，同时也提供了大量的自动化产品和能力。借助于云平台提供的自动化能力，企业可以减少寻找更多的 DevOps 专家，充分的使用云平台的自动化能力。CloudOps：自动化运维新思路CloudOps：自动化运维新思路度；通过监控体系暴露出来更多的 metrics；在应用出现问题之后，通过简单的自助诊断服务可以简化问题发现时间，借助于我们的管控运维通道云助手甚至可以一键修复问题。弹性能力是云计算的最重要的能力之一，通过超大规模的资源池配置能力，快速实现分钟级的资源需求供给，满足不同规模场景的弹性需求，借助于灵活的弹性能力可以充分的帮助企业降低成本、提升可用性。在云上使用弹性能力可以整体提升企业业务的灵活性和稳定性。2、弹性能力弹性能力按照业务需求可以分为 2 个方向，一个是垂直的弹性能力，一个是水平的弹性能力。垂直弹性适合于应用不太能水平扩容的场景，常见的如单体应用、独立应用、有状态应用的场景下，需要快速升级或降低配置以应对业务变化。水平弹性比较适合于分布式应用、无状态应用，通过控制台、API 和我们的自动化工具可以实现分钟级的扩容数千台计算资源。CloudOps：自动化运维新思路CloudOps：自动化运维新思路可观测性能力最近几年是 DevOps 中非常受关注的特点，为了支持不同层次的用户需求，云平台通常会提供以下几大类监控服务能力：云资源监控、应用层 APM、用户业务层监控。除了在基础设施、数据上的容错能力外，云服务厂商通常也会提供应用服务的容错能力，帮助用户构建具备弹性、容错能力的分布式系统。例如通过安全组采用一些断网演练通过 AHAS（Application High Availability Service），可以通过流量防护、故障演练、多活容灾、开关预案等实现应用的自动化流量控制、业务降级与预案执行。4、安全与合规能力根据 Flexera 2021 state of cloud report，81%的企业最关心的是云上安全，排第一位，75%的企业非常关注云上合规。所以安全和合规是云上重中之重的话题。云平台提供了众多策略、控制和技术，共同帮助用户确保数据、基础设施和应用安全，保护云计算环境免受外部和内部网络安全威胁和漏洞的影响。CloudOps：自动化运维新思路CloudOps：自动化运维新思路以云服务器为例，它的资源成本主要由计算、存储、网络三大部分构成。在云上，计费方式直接决定资源的定价，选择合适的计费方式可以直接节省成本。如相比使用按量计费，选择抢占式实例最高可节省 90%的成本；同时，不同产品提供丰富的规格和计费方式，选择合适的规格能有效的降低资源成本；同样通过提升资源的利用率也能够比较大的节省开支。为了实现成本优化和资源量化，我们也提供了一系列的产品，从成本分析、资源优化、资源规格、资源使用洞察和自动化工具可以充分的帮助企业降低不必要的云上资源支出。6、CloudOps 成熟度模型全景云上运维是一个从简单到复杂，从成长到成熟的过程管理，以降低成本提高效率为核心目标。在现实中，根据使用者的上云状态、使用规模等，其云上运维的思路都不尽相同。我们结合常用的成熟度的模型将 CloudOps 的成熟度模型分为 5 个等级。CloudOps：自动化运维新思路云原生时代的运维体系进化云原生时代的运维体系进化云原生已经成为数字经济技术的创新基石，并且正在深刻地改变企业上云和用云的方式。云原生的用云方式可以帮助企业最大化获得云价值，也给企业的计算基础设施、应用架构、组织文化和研发流程带来新一轮变革。而业务和技术挑战也催生了新一代云原生运维技术体系。本文整理自阿里云资深技术专家、容器服务研发负责人易立在阿里云联合主办的“2021 云上架构与运维峰会”中的演讲实录，分享了云原生时代运维技术发出的重要改变，以及源自阿里云超大规模云原生应用发展进程中的 CloudOps 实践。阿里云资深技术专家、容器服务研发负责人易立一、一、新商业带来新机遇与新挑战新商业带来新机遇与新挑战阿里云对云原生的定义是因云而生的软件、硬件和架构，帮助企业最大化获得云价值。云原生技术带来的变化包含几个维度：云原生时代的运维体系进化云原生时代的运维体系进化与传统单体应用相比，分布式的微服务架构具备更快的迭代速度、更低的开发复杂性和更好的可扩展性。但同时，它的部署和运维的复杂性却大大增加。我们需要如何应对？此外，“脉冲”计算成为常态。比如双十一大促期间，零点需要的算力是平时的数十倍；一个突发的新闻事件，可能让上千万用户涌向社交媒体。云计算无疑是处理突发流量洪峰的更加经济、高效的方式。如何上好云、用好云、管好云，如何让应用可以更加充分利用基础设施的弹性，成为企业运维团队的关注重点。这些业务和技术挑战也催生了云原生的运维技术体系 CloudOps。二、二、云原生时代运维技术变革云原生时代运维技术变革1、云原生运维解决之道CloudOps 要解决几个关键问题：标准化：标准化可以促进开发团队与运维团队的沟通和协同，标准化也有助于生态分工，推动更多自动化工具的出现。自动化：只有自动化运维，才能支撑互联网规模的挑战，才能持续支撑业务的快速迭代与稳定性。数智化：数据化、AI 增强的自动化运维成为未来发展的必然趋势。2、容器“应用集装箱”重塑软件供应链在传统的应用分发、部署过程中，常会由于缺乏标准导致工具碎片化，比如 Java 应用和 AI应用的部署，需要完全不同的技术栈，交付效率低。此外，为了避免应用之间的环境冲突，我们经常需要将每个应用单独部署在一个独立的物理机或者虚拟机上，这也造成了很多资源浪费。云原生时代的运维体系进化云原生时代的运维体系进化3、容器技术加速不可变基础设施理念落地。在传统的软件部署和变更过程中，经常会出现因为环境间的差异导致应用出现不可用的问题。比如，新版本应用需要依赖 JDK11 的能力，而如果部署环境中没有更新 JDK 版本，就会导致应用失败。“It works on my machine”也成了开发人员打趣的口头禅。而且随着时间的推移，系统的配置已经不可考，采用原地升级的方式在变更的时候一不留神就会掉进坑里。不可变基础设施（Immutable Infrastructure）是由 Chad Fowler 于 2013 年提出的一个理念，其核心思想是“任何基础设施实例一旦创建，就变成为只读状态，如需要修改和升级，则使用新的实例进行替换。”这种模式可以减少配置管理的复杂性，确保系统配置变更可以可靠地、重复地执行。而且一旦部署出错时可进行快速回滚。Docker 和 Kubernetes 容器技术正是实现 Immutable Infrastructure 模式的最佳方式。当我们为容器应用更新一个镜像版本的时候，Kubernetes 会新创建一个容器，并且通过负载均衡将新请求路由到新容器，然后销毁老容器，这避免了令人头疼的配置漂移问题。4、Kubernetes：分布式资源调度的标准及 CloudOps 最佳载体目前，容器镜像已经成为了分布式应用交付的标准。Kubernetes 已经成为了分布式资源调度的标准。越来越多的应用，通过容器方式进行管理、交付：从无状态的 Web 应用，有状态的数据库、消息等应用，再到数据化、智能化应用。云原生时代的运维体系进化云原生时代的运维体系进化向上支撑应用，提供了标准化的 API 来支持应用生命周期，并且提升应用的可移植性。不同的是，Linux 的计算调度单元是进程，调度范围限制在一台计算节点。而 Kubernetes 的调度单位是 Pod 一个进程组，它的调度范围是一个分布式集群，支持应用在公共云、专有云等不同环境间进行迁移。对于运维团队而言，Kubernetes 成为实现 CloudOps 理念的最佳平台。首先是 K8s 采用声明式 API，让开发者可以专注于应用自身，而非系统执行细节。比如，在Kubernetes 之上，提供了 Deployment、StatefulSet、Job 等不同类型应用负载的抽象。声明式 API 是云原生重要的设计理念，有助于将系统复杂性下沉，交给基础设施进行实现和持续优化。此外，K8s 提供了可扩展性架构，所有 K8s 组件都是基于一致的、开放的 API 进行实现和交互。开发者也可通过 CRD（Custom Resource Definition）/Operator 等方式提供领域相关的扩展，极大拓宽了 K8s 的应用场景。最后，K8s 提供平台无关的技术抽象：如 CNI 网络插件,CSI 存储插件等等，可以对上层业务应用屏蔽基础设施差异。5、为什么是 Kubernetes？Kubernetes 的成功背后的魔法就是控制循环，Kubernetes 有几个简单的概念。云原生时代的运维体系进化云原生时代的运维体系进化解决容器应用在大规模生产环境的自动化和稳定性挑战。OpenKruise 提供了增强的应用灰度发布，稳定性防护，Sidecar 容器扩展等多种能力。OpenKruise 开源实现和集团内部版本代码保持一致。支撑了阿里集团应用 100%云原生化，也已经在苏宁、OPPO、小米、Lyft 等企业得到广泛应用。欢迎大家社区共建和使用反馈。7、GitOps：声明式 API 催生的应用交付流程与协同新方式基础架构即代码（Infrastructure-as-Code，IaC）是一种典型的声明式 API，它改变了云上资源管理、配置和协同的方式。利用 IaC 工具，我们可以将云服务器、网络和数据库等不同云资源进行自动化的创建、组装和变配。云原生时代的运维体系进化云原生时代的运维体系进化首先，从应用定义到基础设施环境，所有的配置都以源代码的方式保存在 Git 中；所有变更、审批记录也记录在 Git 的历史状态中。这样 Git 成为 sourceof truth，我们可以追溯变更历史、可以回滚到指定版本。GitOps 与声明式 API、不可变基础设施相结合，保障了应用环境的可复现性，提升了交付与管理效率。GitOps 在阿里集团已经被广泛使用，在阿里云容器服务 ACK 中也有支持。目前GitOps 开源社区也在不断完善相关的工具和最佳实践，大家可以关注相关进展。8、云原生催生稳定性思想变革分布式系统存在高度复杂性，在应用、基础设施、部署过程中任何一个地方的问题，都可能导致业务系统的故障。面对这样的不确定性风险，我们有两种做法：一种是“听天由命”，信佛祖，不宕机；一种是通过系统化的方法进行主动出击，提升系统的确定性。云原生时代的运维体系进化云原生时代的运维体系进化三、三、云原生云原生 CloudOpsCloudOps 之路之路最后我将结合阿里实践，介绍我们在 CloudOps 上的一些探索。在传统组织中，开发和运维角色是严格分开的。而不同业务线也构建了一个一个的烟囱化架构，从基础设施环境与运维，到应用运维与开发，都是独立的团队，缺乏良好的协同与复用。云时代的到来也在改变着现代 IT 组织和流程。首先，公共云、专有云成为了不同业务部门间共享的基础设施。然后，SRE（Site ReliabilityEngineering）理念开始得到广泛接受。是通过软件和自动化手段，来解决系统的运维复杂性和稳定性问题。由于 Kubernetes 的标准化、可扩展性和可移植性等优势，越来越多企业的 SRE 团队基于 K8s 管理云环境，极大提升了企业运维效率与资源效率。云原生时代的运维体系进化云原生时代的运维体系进化第三 Designfor automation：类似扩缩容、故障恢复等工作尽可能自动化完成。最后 Observabilityby-design：为每个生产应用定义 SLO，并建立相关的可观测性体系，持续关注请求量，延迟、错误数、饱和度等黄金指标。第二项是建设稳定性应急体系，也就是我们日常所说的 1-5-10 快恢能力，它包含：1 分钟发现-包括通过黑盒、白盒监控能力。5 分钟定位-提供诊断大盘，利用工具实现自动化根因定位。10 分钟止损-包含系统化的预案的设计与持续积累，和自动化预案执行。最后一项是日常稳定性保障，主要包含：变更管理规范化 所有发布做到可灰度、可监控、可回滚。问题跟踪流程化-凡事有交代，件件有着落，做一个靠谱青年。故障演练常态化 通过巡检、突袭、压测等手段查漏补缺，让故障预案持续保鲜。2、拥抱云原生运维技术体系云原生已经成为势不可挡的技术趋势。Gartner 预测到 2025 年，95%数字化运维将通过云原生平台进行支撑。云原生时代的运维体系进化云原生时代的运维体系进化最后做一个快速总结。基于容器、Kubernetes 等云原生技术，提供的开放社区标准、不可变基础设施、声明式 API 会成为企业 CloudOps 的最佳实践，也将在这个基础上推进数据化、智能化体系建设，将运维复杂性进一步下沉，让企业可以聚焦于自己的业务创新。阿里云也将持续向外输出自身在超大规模云原生实践和探索中的能力沉淀，与更多企业、开发者一起，躬身入局，全面拥抱云原生运维技术体系。53大搜车面向复杂业务场景的研发运维体系治理实践最佳实践大搜车面向复杂业务场景的研发运维体系治理实践大搜车基础设施部负责人李同刚2021 年 12 月 10 日，大搜车集团基础设施部负责人李同刚在云上架构与运维峰会上，分享了大搜车在研发运维体系治理的一些实践。以下是他的演讲实录：一、业务介绍一、业务介绍大搜车面向复杂业务场景的研发运维体系治理实践大搜车面向复杂业务场景的研发运维体系治理实践异构业务主要有 SaaS、软件定制和直播。SaaS 负责云上的部署，为客户提供业务层面上专业的技术支持，并且基于开源做一些改造。软件定制类似于传统的项目制方式，因为里面存在甲乙方的关系，甲方会要求软件底层的架构尽量开源，不能有个性化的改动。二、技术挑战二、技术挑战1、中间件升级挑战大搜车面向复杂业务场景的研发运维体系治理实践大搜车面向复杂业务场景的研发运维体系治理实践收购了其他公司以后也会产生很多的技术挑战：语言异构：Java、Dolang 和 NODEJS 服务之间的调用会影响开发效率。研发流程体系不统一，包括工具也不统一，同样会影响整个团队的合作效率。线上的环境复杂，传统的虚拟机和 k8s 同在的，导致操作情况比较复杂。稳定性保障体系不统一，规范、告警体系和监控工具不统一。三、业务要求三、业务要求快速、稳定、高效地去满足业务上的需求，是各个业务线的诉求。因为商业是在不断往前走的，大搜车针对业务上的需求和挑战，做了一些解决方案。四、解决方案四、解决方案大搜车面向复杂业务场景的研发运维体系治理实践大搜车面向复杂业务场景的研发运维体系治理实践如上图，研发流程的最底层是阿里云 IaaS 层，它包括了 ECS ASK 和网络、存储功能。搜车研发规范包含了 GitFlow 规范以及其他部署规范，质量服务层里面有一些 API 自动化测试工具和精准测试工具等。研发协作平台贯穿了从需求到发布的整个流程，负责落实全部的质量规范。有了底层研发协作平台数据的积累，才可以做最上面这一层的数据化运营平台。这一层主要是针对研发协作平台做一些原子性的指标体系的规划，还有研发协作体系的业务指标，比如说测开比、线上的稳定指标等等。2、统一稳定性保障体系如上图，稳定性保障体系的最底层是一些规范，比如 sla 的规范、架构的高可用的规范，包括复盘规范。监控数据源包括 RDS、Redis、Pod、JVM 等等，他们都会在这一层得到统一。SLS 存储层可以用机器学习算法去做告警的自适应，SLS 告警层主要处理监控、降噪和通知管理。最上层的故障处理系统，主要负责故障的闭环，从告警-故障-复盘-更新分析-改进追踪的整个流程。要把自己的数据源和定义尽可能地用到云上的服务里去，这样才能提升整个保障体系的投入产出比。大搜车面向复杂业务场景的研发运维体系治理实践大搜车面向复杂业务场景的研发运维体系治理实践一、做正确的事：要用客观且产品化的思维去考虑，什么是正确的事，而不是靠主观意愿来判断。要更多地走进业务，去调研客户的需求，从客户的角度去考虑。二、正确地做事：首先把握方向，其次避免过多地去关注过程，而是要从结果去反推，我们应该做什么样的决策。SOUL 云上运维架构创新实践分享SOUL 云上运维架构创新实践分享在加入 Soul 之初，我就面临着四个困难和三个亟待解决的问题：第一个困难就是人力短缺。运维部门只有 4 名同学，研发线只有 200 个同学，对于一家年轻的公司来说，1：50 这个比例是比较高的。第二个困难是无成型运维工具，工具是存在的，单点上看功能不完备，整体上看运维层面没有串联起来，这大大增加了运维成本。第三个困难则是业务高速迭代，每周一个小版本，两周一个大版本，这与公司业务线的发展体系有关，而且 Soul 也在不断探索一些新的领域。第四个则是基础架构的缺失，导致接入和使用方式多种多样，每个部门保持自己独立的基础架构，这种工作形态同样也大幅提高了运维成本。在这些困难下，我们认为，如何短期内提高运维效率，是 Soul 运维部门当时阶段首要解决的问题。因为只有提升了运维的效率提升，我们才有更多的时间去做更多的事情，包括提升业务的稳定性、更好地支撑业务快速迭代等。SOUL 云上运维架构创新实践分享SOUL 云上运维架构创新实践分享2、优化发布平台Soul 也是用了中小型标配的 Jenkins、以及一部分阿里云 EDAS 产品能力，这两款产都不是一个完整的发布体系，都有部分功能缺失，于是我们就选择通过以下几个方面建设 CI/CD 体系：发布周期：由于没有固定的发布窗口，大大延长了故障的时间，无法及时处理故障问题，降低了用户的产品试用体验。比如凌晨上线，到第二天上班才知道故障的发生。完整迭代：从 DEV 环境到 QA 再到代码扫描，再到灰度最后到线上，完整的迭代周期串联是团队当初急需要做的。发布效率：发布当时面临最大的问题是稳定性差，CI/CD 一体执行，发布底层 salt 和 ansible 执行效率低下；首先我们需要将 CI、CD 分离；编译所需参数存储于 CMDB 中，打包动作逐渐脱离 jenkins，将编译功能集成在发布平台中；CD 部分去掉 salt，全部替换为 ansibleapi；参与度：降低运维的参与度，提高研发与平台交互度，让运维有更多时间更多关注迭代内容、周期、发布次数等。SOUL 云上运维架构创新实践分享SOUL 云上运维架构创新实践分享4、运维工单平台的 0-1Soul 运维工单平台是运维对研发甚至是对公司唯一的入口。在此之前，内部均使用邮件方式沟通，但随之而来的是邮件丢失、延迟等问题，导致需求处理延误、因权限管理不清晰而有部分同学自行操作，继而发生各种问题。Soul 工单平台更接近云管控，逐渐替代掉阿里云控制台的权限，同时我们使用工单的方式逐渐的规范研发同学对中间件和阿里云底层资源的认知，主要分三个阶段：阶段一：纯手工打造。工单平台抽象高频的操作和需求，但依然是人工执行。这个阶段的工单平台，更多仅像一个 web 入口，无太多自动化能力。阶段二：人工决策，自动执行。这个阶段持续时间较长，工单需完成自动化能力补齐。阶段三：自动决策，自动执行。将业务对资源的需求与资源类型/资源规格转化，常态化需求描述以及个性化需求描述，需要通过工单平台入口使得运维更加靠近业务。到此阶段，在半年时间内，运维自身效率已提到提升，有了更多的时间参与稳定性架构改造，同时运维人员也更多的精力关注业务动向。SOUL 云上运维架构创新实践分享SOUL 云上运维架构创新实践分享2、故障定位与处理稳定性的生命周期中，故障与非故障的时间占比非常重要，非故障时间需要增加架构的稳定性建设、复盘、演练，才能让故障的时间占比下降，使业务的稳定性向着更加健康的方向发展。最近一年时间里，着重于稳定性建设时间，增加演练次数，下面也会着重分享稳定性改造的相关案例。3、稳定性改造在过去一年当中，稳定性建设方面，Soul 大致进行了下图中的六个工作，我们将从中挑出三个较有代表性的方面展开分享。SOUL 云上运维架构创新实践分享SOUL 云上运维架构创新实践分享在 K8s 平台方面，Soul 当时使用的是 Promethues。Promethues 最大的问题是无成型 web 交互，查询及报警语句有相对较高的门槛。到 2021 年 3 月，我们开始正式做监控治理，使用 OpenFalcon 进行底层云产品的监控，同时将公司内部的多套 Promethues 及阿里云的 Promethues 服务进行合并，统一 Promethues 数据源。这样公司里面只有两款监控产品：一个面向底层资源，一个面向 K8S。2021 年 6 月，我们开始自研监控系统 OWL，从名字“猫头鹰”上能看出来，我们希望它能代替运维同学在晚上值班。OWL 监控沿用 OpenFalcon 前端的页面，兼容 Promethues 数据，将 Promethues 的查询及报警语句抽象出来，进行格式化的展示，并添加报警功能。这一点类似于 grafana 的 promethues 插件部分，目前已经将所有的报警整合在 OWL 报警平台当中，同时也实现了信息采集及报警功能完善。下一个阶段是报警网关，报警网关还需要拥有报警接手+解决+报警升级的能力，方便运维同学对问题的跟踪。随着报警逐渐的添加，报警的数量也逐渐在增长，也出现了报警信息被淹没的情况，为了方便运维同学对问题的跟踪，报警网关进入了下一阶段的迭代，报警接手+解决+报警升级，减少群里的重复性报警的同事又不会漏掉关键报警；第二个改造：接入层改造SOUL 云上运维架构创新实践分享SOUL 云上运维架构创新实践分享第三个改造：MySQL 切换 PolarDBMySQL 切换 PolarDB 是 2020 年，Soul 与阿里云深度合作的第一个项目，改造的背景是MySQL 分库分表机制有问题，磁盘与 CPU 不匹配，单实例已超过阿里云 SLA 标准，达到了 6T的数据。而 Soul 的业务场景是读多写少，同时团队也在考虑分布式 DB，这两个特性与 PolarDB 与Soul 的匹配程度非常高，团队人员用了 1 个月时间，将大于 1T 的 30 组 MySQL 实例，全部迁移至 PolarDB，迁移后无论是在费用、稳定性及使用率多个方面均正向收益。对于以上的架构的改造，对于 Soul 来说，不一定是最好的，但却是最实用的、短期内可以支撑业务的高速迭代方案。SOUL 云上运维架构创新实践分享日均订单量千万级，饿了么云上运维最佳实践日均订单量千万级，饿了么云上运维最佳实践饿了么资深架构师朱琳骐12 月 10 日，饿了么资深架构师朱琳骐在 2021 云上架构与运维峰会上，分享了饿了么云上基础架构的演进历程。以下是他的演讲实录：经过 10 多年的运营，饿了么的业务不仅从起步时的个位数的订单成长到了现在的千万级别，同时还完成了从外卖业务到“爱什么来什么”综合业务形态的演进。我会以业务的需求和变化为主线，聊一聊这 10 多年我们的技术是如何演进的。一、架构的演进历程一、架构的演进历程2014 年前饿了么和传统的技术性公司并没有特别大的区别，主要是以传统的独立应用方式来进行部署。随着移动互联网的兴起，外卖业务迅猛发展，传统模式的架构只能支撑百万单量。为了支撑业务的灵活多变和不断提升的单量，饿了么进行两次非常大的技术升级。日均订单量千万级，饿了么云上运维最佳实践日均订单量千万级，饿了么云上运维最佳实践传统单体架构有着耦合度高、交付慢、运维效率低下等诸多缺陷。随着业务架构的调整，单体服务也逐步按照领域进行了微服务体系的升级。为了提升运维效率、交付效率和稳定性，我们构建出了 elss、appos、ice 3 三位一体的自动化发布平台，来提升产业的交付效率，还有自研的 maxq（当时的 rabbitmq 无法支撑业务单量）、apirouter、covrus、dal 等多个中间件，以及 Pylon+huskar 微服务框架来增强业务的扩展能力，724 小时的团队结合