在经过v1.0~v1.4四个版本迭代后，SREWorks的核心底座已经表现出极高的稳定性和成熟性。在v1.5版本中，SREWorks开发团队在核心底座上，进行了较多的数智化能力迭代。同时，在数智能力迭代过程中，我们也维持着与SREWorks用户较高的沟通频率。我们发现大家普遍对于监控数据之上的数智化能力比较关注，于是我们在这些点上做了一些深挖分析，发现普遍都会遇到这样几个问题：自研监控系统在数据体量上升后，可靠性下降。日志等各类非结构化的数据引入，导致工程复杂性急剧上升，实时性方面也面临更大的挑战。简单的表达式(expression)往往无法满足业务多样化的监控需求。于是很多用户选择从自研监控系统切换至流计算引擎Flink，但是Flink

01千里之行，始于足下了解和掌握纯c语言的eBPF编译和使用，有助于我们加深对于eBPF技术原理的进一步掌握，也有助于开发符合自己业务需求的高性能的ebpf程序。上一篇文章《eBPF动手实践系列一：解构内核源码eBPF样例编译过程》中，我们了解了基于内核源码的ebpf程序的编译步骤。其中编译过程对内核源码的依赖的内容，主要体现在对kernel-devel和kernel-headers两个rpm包的文件内容的依赖（centos环境下）。这给我们脱离内核源码进行独立的ebpf程序编译提供了可能。本文将介绍如何仅依赖于kernel-devel和kernel-headers等rpm包进行纯c语言的eBPF程序的编译和使用。02eBPF开发的基础环境准备主流的linux发行版大多是基于rpm包或deb包的包管理系统。不同的包管理系统，搭建eBPF开发环境时所依赖的包，也略有差别。本文将分别进行介绍。2.1

作者钟炯恩——阿里云大数据基础工程技术团队运维专家01引言突破规模化运维瓶颈是诸多IT规模增长的企业及组织当前遇到的比较棘手的问题。面对这些问题，多数人的第一反应是上云。但是上云之后我们会发现，即使云上的架构规模增大，也依然存在同样的问题，有时候甚至更严重，因为弹性扩容的云服务器远比买一台物理机更方便，从而导致集群规模也急剧增加。那么，规模化运维为什么会遇到瓶颈？总的来说，规模化运维遇到的瓶颈可以分为三类，分别为稳定性瓶颈、成本瓶颈以及效率瓶颈。第一，稳定性瓶颈，这往往是我们最关注的点。对稳定性影响最大的因素是变更，由变更导致的故障占据70%-80%。因此，我们一般会通过严管变更来减少故障时间，进而提升系统的稳定性。这会导致出现一种微妙的平衡：如果限制变更的次数，则我们会选择将多个变更集中在一次变更里进行，而这会增加回滚的难度，从而导致单次的故障时间变长；而如果不限制变更次数来约束每个变更必须能够回滚，则我们可能会将一个变更分拆为多个变更，虽然出了问题可以立即回滚，影响小，但由于变更总量较大，最终系统的可用性会陷入瓶颈，无法提升。除此之外，在大规模集群中，在成千上万的机器里总会出现一些性能存在问题的机器，可能是硬件问题，可能是内核问题，也可能无法明确问题。而这些机器使得整个系统在某些性能或功能上表现出不明原因的不稳定，如果无法在第一时间抓住它，则会持续产生影响。以物理机为例，物理机的硬件日化故障率约0.03%，而在所有硬件故障中，有1%属于比疑难杂症，无法明确。如果机器保有量为1万台，则平均每月会碰到一例非典型的疑难杂症，影响业务。由此可见，在规模化的效应下，原本罕见的问题会变得常见。第二，成本瓶颈。在过去的一段时间里，这类瓶颈可能不太被重视，但是在降本增效的今天，这些问题变得尤为突出。热点机器是在分布式系统中常出现的问题，明明有大量可用资源，而流量却都打到一台机器上，导致整个集群性能低。而热点机器的成因非常复杂，可能是架构问题，可能是业务问题，也有可能是底层软件、硬件的问题。成本瓶颈的另一方面包括从预算到执行的精细化管理。如果是物理机，则需要考虑采购周期；如果是云服务，则需要考虑区分包年、包月、按次计费等计价模型，还需考虑不同区域费用单价的差异。如果无法很好地对上述问题进行管理，则会导致弹性弹得越猛，成本越高。资源使用的削峰填谷是成本方面需要解决的更高难度的问题。在空间维度上，可以用算法来计算如何减少跨地域依赖，从而节省成本；在时间维度上，可以通过白天运行应用服务，晚上运行离线计算来最大限度利用机器资源。第三，效率瓶颈。该类问题往往发生在人机交互之中。在全自动化的流程中，为了业务需要可能会配置特例化的人工干预节点，导致后续人工干预越来越频繁。那么，如何在业务定制和自动化的标准中保持中立、保持平衡？一个管理平台往往有非常多的功能和配置，配置是直接暴露YAML或json，还是提供可视化的人机交互，也是很大问题。如果提供很多可视化交互，可能会带来较高的开发成本；但如果直接暴露YAML，会存在由改动引发的问题。另外，某些小问题原本很好排查，但在大规模集群中可能需要串联上下游许多机器才能发现，导致排查小问题的时间开销也变得越来越大。那么，如何解决上述瓶颈中涉及的问题？经过大量实践，我们总结出了一套规模化运维的流水线。流水线里包含6大环节，分别是交付、监测、管理、控制、运营、服务。有了全链路图之后，我们可以按图索骥进行查漏补缺。对于已经拥有的能力，可以演进增强；对于尚未拥有的能力，可以用成熟的开源方案进行补位。上图展示了业界常见的开源方案对于上述6大环节中能力的支撑。●

1►他山之石了解和掌握纯c语言的ebpf编译和使用，有助于我们加深对于eBPF技术原理的进一步掌握，也有助于开发符合自己业务需求的高性能的ebpf程序。目前常见和主流的纯c语言的ebpf编译使用方法，主要是两种。一种是内核源码中原生提供的编译方式。另外一种是libbpf-bootstrap项目中提供的skeleton编译方式。libbpf-bootstrap方式和社区5.x以上内核结合的比较好，以后再做介绍，今天我们选择基于4.18内核的基于内核源码的原生编译方式做介绍。在国内学习ebpf技术，就不得不提到《Linux内核观测技术BPF》书籍译者狄卫华老师。狄老师还有一个网站《深入浅出

算法部分是通过部署在机器上的定时调度的程序去执行的，因此它的实时性非常低。此外，我由于部署在单机上，算法的性能也很难得到保证，所以我们需要去对这一套传统算法工程链路进行改造优化。04使用

在大规模集群的场景下，如何进行云原生时代的架构演进，以及如何将复杂的运维需求进行工程化落地，成为了诸多IT规模增长企业及组织的重要课题。此次分享将通过案例和实践来介绍：基于开源的SREWorks云原生数智运维平台如何突破规模化运维的瓶颈，提升整个架构生态的可用性和稳定性。不仅如此，本次分享我们也会介绍，如何在当前的架构基础上，利用AI以及大数据能力实现数智运维，实现运维能力的飞跃。

2022年3月SREWorks项目正式开源，到目前为止已经整整一周年了。自开源以来，我们始终立足云原生运维场景，秉承“数据化、智能化”的运维思想，采用“小步快跑”的快速迭代方式，使得整个SREWorks项目也取得了长足的进步。于此同时，得益于社区用户、企业伙伴的积极参与和贡献，也为SREWorks项目的发展注入了新的活力。下面我们来回顾一下SREWorks的开源故事并展望其未来的发展。01开源故事相信大家或多或少听说过飞天的5K项目，这是中国云计算领域的一个里程碑式的项目，我们团队承担了其中的运维工作。超大规模集群的运维保障任务，让我们意识到：如果没有系统性的运维工程，即便我们再殚精竭虑，集群稳定性也是会是一件靠天吃饭的事情。于是我们逐步将大量的运维实践进行工程化落地，使之成为了一个可靠的运维平台，在内部我们称之其为ABM：Apsara

文章结构项目背景演进分析monorepo架构演进Webpack与Rollup如何平滑迁移构建优化组件的可扩展与可插拔演进总结版本动态01项目背景SREWorks是一个面向企业级复杂业务的开源云原生数智运维平台，是大数据SRE团队多年工程实践的锤炼及沉淀。前端统一托管工程（frontend）作为平台的重要一环，提供了一套serverless体验的配置化前端低代码技术方案：低代码、配置化是前端低代码方案的基础特性。frontend工程采用React+antd为主的技术框架，设计了一套组件映射、编排、解析、渲染的工程体系：以antd组件为自由编辑粒度，用户在前端设计器通过可视化交互或者json编辑的方式，依据运维工作的实际使用场景，对组件进行属性配置/组件嵌套拼装；同时根据使用景目标需求对页面组件进行布局的编排、数据源的绑定以及在合适点位插入Dynamic

组件对于组件而言，我们定义了几个固定类型，分别是构建、部署和状态感知。其中构建前面介绍过了，状态感知是可选的，会在最后进行介绍。这里主要介绍下部署逻辑。组件部署的时候，一样会执行对应的

大家上午好！我是来自阿里云大数据基础工程技术团队的郭耀星，花名雪尧。今天我很高兴能够来到QCon，与大家分享我的经验和心得。在当前的多云环境中，作为运维支撑团队，如何在分裂严重、存在多个不同环境的异构Kubernetes底座情况下，高效率地管理与交付业务应用，是一个值得探讨的话题。在开始正式分享之前，先做一个简单的自我介绍，我是

Pipelines）2►DataOps能够解决哪些问题？下面列举一些常见的数据相关的问题，对于想要实施DataOps的公司来讲，可以判断一下是否有遇到：1.

在v1.3版本之后，SREWorks团队收集了较多的用户反馈，大家普遍对于SREWorks的内网离线安装有较大的诉求。于是团队决定进一步增强这部分的安装能力。前端工程部分(frontend)，为了开发者更加敏捷高效的协作开发，以及便于社区开发者参与共建前端组件生态。我们对前端工程架构进行了重新梳理拆分，按照Monorepo模式架构演进;

中动态容量维持模块，将集群水位始终控制在安全水位附近。在某些紧急情况下，集群的瞬时值可能会过高，触发集群整体稳定性问题。当水位已经超过了所能够承载的安全水位上限，则需要进入应急处理流程，通过

资源使用水位参差不齐，导致部分机器在某一维度的资源快速达到性能瓶颈，进而形成热点机器。为了提高业务集群的稳定性，需要找到集群中的这些热点机器，进行热点分析并解决。但是，寻找热点机器也不仅仅依赖

在v1.2版本发布之后，SREWorks团队着手开始了v1.3版本的迭代。此次v1.3版本融合了较多用户需求，以及对底座机制进行了较大调整和优化，故发版时间长了很多。下面让我们切入正题，来看看这些大变化究竟是哪些？1►插件机制1.

云原生是在云计算场景下的再升级，其核心是创新，是一次比物理机上云更彻底的创新。云原生让工作负载摆脱束缚，能够自由地在各种平台上运行。诚然，这种创新带来了更多的可能性，但也增加了架构的复杂度。之前我们总说云计算是数字时代的“水电煤”。但各种工作负载复杂的启动关系，创建容易释放难的计算资源，似乎并没有那么“随取随用”。究其根因，那些没那么弹性的架构，其中依然残留了各种物理机时代的逻辑结构。SREWorks

通过一系列概念的定义，完成了对一个应用的抽象，实现了角色职责的分离，将应用交付这件事情与底座解耦，使得跨云快速交付应用成为可能。开发同学也不再关心底座实现细节，只关心自己的应用模型即可。OAM

的方式进行描述。控制器的描述示例如下：通过helm将vvp这个应用的所有yaml下发，监听service的状态变化，同步更新ingress资源的状态。default:

的阅读和配置就可以对这种复杂的部署产生一个较为深入的认知。如果是常见的业务应用，虽然不同的部署之间差异不大（比如日常预发生产），但是因为快速迭代及需求变化，未必可以一开始就做好相关的变化限制，用

当我们想要对程序执行操作的时候，不需要告诉helm我们要对哪个对象进行变更，只用传入程序名称，Helm会帮助我们对程序下的每个对象执行相应的操作。这个包含了一组yaml文件的程序包，就叫做Helm

SREWorks的开源吸引了大量用户来尝试部署和使用我们的产品，其中不乏一些初次接触Kubernetes的朋友。随着SREWorks云原生运维平台使用的持续深入，部分用户对于其中的原理和概念还存在一些困惑。因此，我们特推出《Kubernetes资源编排系列》，从底层的Pod

在v1.1版本发布之后，SREWorks团队开始了常态化的功能版本迭代，v1.1提供了组件插拔能力，v1.2更进一步，发布了规划已久的运维市场，助力团队构筑运维生态，也会发布诸多企业用户关注的纯内网源码构建方案。下面是本次

高。以此形成整个链路证据链的推导，做到关联下钻分析，定位到真实的根因。第三个就是最高频的问题，作业在运行过程中有报错。核心的思路是收集各个组件的日志，比如提交的日志、调度的日志、failover

daemon作为docker的服务端，由于需要系统的ROOT权限等要求，导致其不能天然地运行在另一个docker容器之中。这也为镜像构建云原生化提出了新的技术问题。2.2

引子"低代码"一词似乎是最近几年才流行起来的词汇，2015年前后AWS、Google、Oracle等厂商开始入局低代码领域时，国内氛围还没有很高。2018年5月，快速应用开发的低代码平台

ElasticSearch/MySQL/MinIO当前不少公司的生产环境下均包含可靠的存储模块，比如ES/MySQL/MinIO等，所以部分用户在部署应用时不希望使用SREWorks

开源Elasticsearch是一个基于Lucene的实时分布式的搜索与分析引擎，是遵从Apache开源条款的一款开源产品，是当前主流的企业级搜索引擎。作为一款基于RESTful