研运干货|平台工程、应用可观测性趋势下,质量管理的应对之策

“为变化做好准备。”

这是当下对所有人的一句很重要的话,尤其是对于处在高速迭代与日新月异的技术工程领域的我们。

最近,Gartner在2023十大技术趋势的报告中提到了平台工程(Platform Engineering)应用可观测性(Applied Observability)。 

本文将通过对这两大战略性技术趋势点的进行剖析,看看这对质量测试领域到底意味着什么,以及我们需要做出哪些改变和基建建设来支撑平台工程和应用可观测性的落地。


1,什么是平台工程

“平台工程是一套用来构建和运营支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构。平台工程的目标是优化开发者体验并加快产品团队为客户创造价值的速度。”

——Gartner

我们来看几个关键词:

软件交付和生命周期管理

从需求的产生和定义,再到研发,测试,上线和线上的运营,我们所需要的是一套一体化的全链路的工作流;这条链路上,我们需要链接的是产品的所有技术基建和工程类的工具集;串联了产品生命周期的所有参与角色:业务,BA,产品,研发,测试,运维和市场等等。这一切都是为价值的创造和流动服务。

图片

Picture Source:Gartner

自助式、加快速度

自助式意味着平台提供的服务能力是高内聚,服务间是低耦合的;并且服务的是清晰定义高可用的。

产品的生产参与人员是可以自助按需取用和组织自定的工作流的。

对业务交付速度上的要求,则对工作流程的优化和工具链的自动化和集中度程度提出的高要求。

2,应用可观测性

通常当我们提到可观测性,我们一般会认为由监控工具来采集数字化的数据,例如日志、调用,数据调用等。

其实笔者认为应用的可观测性是泛指所有平台工程工具链产生的一切数据特征或数据特征运算产物和延伸,它是用来驱动决策的,为企业机构获取竞争优势的。应用可观测性是数据驱动型决策的重要支撑。这就意味着任何一个平台的工具组成部分都是一个聚合类的数据源头,任何一个平台都需要一个能把“Information”转化为“Intelligence”的处理中心。

对于质量测试领域,从平台工程的理念来讲,它应是一个聚焦在提供软件质量保障的高耦合的能力模块;对于应用的可观测性来讲,它应是基于软件质量的业务决策统一的数据特征提供者。

其实根据笔者的调研,大多数的企业机构在质量测试侧的活动都是不统一的,分散的。我们或多或少都遇到了没有平台化的痛点。例如:协同和组织的问题、质量标准的难统一、对业务的不理解,成就感低、缺乏统筹和全局的视角为抓手等。

图片

因此,我们亟需引入一个聚焦于质量测试领域的平台化的产品模块。

这个产品模块需要做到:

  • 提供足够的测试工具来支撑多样的测试活动,测试工具得是自助的、自由和插拔的;

  • 支撑面向质量测试目的管理链条的搭建,使用和追踪;

  • 提供公共“连接器”连接一体化架构下的其它平台工具模块来组成业务工作流;

  • 提供统一类型的可观测数据特征模块,例如支撑质量度量体系建设的数据系统。

图片

3,平台工程落地是个庞大的工程

对于任何一个中大型企业来讲,平台工程和应用可观测性的落地都将是一个长期的涉及业务各级角色的战役。

落地这样一个大型的改革性的转变,其最佳的路径是:一个总体的顶层的设计加上可量化的小规模转型(IncrementalChanges)。

质量测试领域的平台化转型是一个绝佳的起点,因为它本身业务的高聚合,提效的成本相对低廉,更能为企业组织更大的平台化转型提供持续正向的推动力和成就感。

(本文首发于:众安工程效能)

  • 5
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错 Flink 的容错比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错和可靠。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理能 Spark Streaming的能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值