平台工程的六大支柱之六:可观测性

为平台团队提供工作流程和检查表,以在平台中实现可观测性

译自 The Pillars of Platform Engineering: Part 6 — Observability

本指南概述了平台工程中六大开发者体验技术领域的工作流程和检查步骤。该指南分六个部分发布,第一部分介绍了指南系列,重点关注安全性。第六部分探讨可观测性。其余部分如下,您可以下载《平台工程六大支柱》完整 PDF 版本获取所有指导、概述和检查表:

  1. 安全性(包括简介)
  2. 流水线(VCS、CI/CD)
  3. Provisioning
  4. 连接性
  5. 编排
  6. 可观测性(包括总结和下一步)

平台工作流程的最后一步是监控和维护部署。您需要在平台中融入可观测性实践和自动化,来衡量软件、服务、平台和产品的质量和性能,以便更好地了解系统行为。高质量的系统可观测性可以更快更轻松地调查和诊断问题。

简单来说,可观测性就是记录、组织和可视化数据。仅提供数据本身不等于实现企业级可观测性。站点可靠性工程、DevOps 等团队首先确定生成、收集、汇总、分析什么数据以获得有意义、可操作的见解。

然后,这些团队采用并构建可观测性解决方案。可观测性解决方案使用指标、追踪和日志等数据类型来理解和调试系统。企业需要在整个技术栈实现统一可观测性:云基础设施、Kubernetes或Nomad等编排运行时平台、Azure托管数据库等云托管服务以及业务应用程序。这有助于团队了解云服务和组件之间的相互依赖。

但是,统一只是将可观测性融入平台工作流程的第一步。在工作流程中,平台团队需要在模块和部署模板中自动实现可观测性的最佳实践。就像平台工程帮助安全功能左移一样,可观测性的集成和自动化也应通过在部署时将可观测性融入容器和镜像来向左转移到基础架构编码和应用程序构建阶段。这可以帮助您的团队从一开始就通过将可观测性自动化到平台工作流程中来构建和实现全面的遥测策略。

将可观测性解决方案集成到基础架构代码中的好处很多:开发人员可以更好地了解他们的系统运作方式和应用程序的可靠性。团队可以快速调试问题并追踪到根本原因。组织可以根据数据做出决策来改进系统、优化性能和提升用户体验。

工作流程:可观测性

企业级可观测性工作流程可能遵循以下八个步骤:

  1. 代码:开发人员提交代码。

注意:根据分配给开发人员的访问控制角色,他们可能直接访问网络控制平面。

  1. 验证:持续集成/持续交付平台向身份提供商提交验证请求(认证和授权)。
  2. 身份提供商响应:如果成功,触发流水线任务(如测试、构建、部署)。
  3. 请求:provisioner 执行请求的模式,比如构建模块、检索工件或根据内外部引擎验证策略,最终预配定义的资源。
  4. Provision:如果不存在,则设置基础设施并进行配置。
  5. 配置:provisioner 配置可观测资源。
  6. 收集:根据配置的发射器和聚合器收集指标和追踪数据。
  7. 响应:向持续集成/持续交付平台提供预配程序请求完成情况,以进行后续处理和/或移交给外部系统,如安全扫描或集成测试。

可观测性需求清单

企业级可观测性需要:

  • 实时问题和异常检测
  • 跨不同控制平面和环境的自动发现和集成
  • 准确的告警、追踪、日志记录和监控
  • 高基数分析
  • 标记、标签和数据模型治理
  • 可观测性即代码
  • 适用于多云和混合部署的可扩展性和性能
  • 自助可视化、配置和报告的安全性、隐私性和访问控制

下一步和技术选择标准

平台构建永远不会完全完成。这不是一个前期规划好、大家签字认可后就结束的项目。它更像是一个迭代的敏捷开发项目,而不是传统的瀑布项目。

您可以从最小可行产品开始,然后必须向组织推广平台。向团队展示他们如何从采用整个开发生命周期的通用模式和最佳实践中受益。与各团队进行流程分析(当前与未来状态),共同工作并理解采用的好处,这可以是有效的。最后,降低入门门槛尽可能简单至关重要。

随着您逐项检查这六个平台支柱要求,平台团队将希望采用用户体验设计师的思维方式。调查不同团队的需求,理解您可能只能满足 80-90% 的用例。一些工作流程将过于精细或独特,无法融入平台。您无法取悦所有人。工具链选择应该是一个跨职能过程,而在最开始获得高层支持对驱动采用至关重要。

关键工具链问题清单:

  • 从业者采用:您是否从询问开发人员他们感兴趣的技术入手?什么可以让他们快速支持业务?他们想学习什么技能,这在市场上是否常见?
  • 规模:此工具是否可以扩展以满足企业预期,在性能、安全合规性和采用简易性方面?您是否可以从同行那里吸取教训,而不是踏入未知领域?
  • 支持:所选解决方案是否由能满足核心关键基础设施服务级协议(24/7/365)并达到客户可用性预期的组织支持?
  • 长期:这些解决方案供应商在财务上是否雄厚,能长期支持这些支柱和核心基础设施?
  • 开发者灵活性:这些解决方案是否提供灵活的接口(图形界面、命令行界面、应用程序编程接口、软件开发工具包)来创建定制用户体验?
  • 文档:这些解决方案是否提供全面、最新文档?
  • 生态系统集成:是否存在可扩展的生态系统集成,以整洁地链接到链中的其他工具,如安全或数据仓库解决方案?

对于已经投资于这些核心支柱的组织,下一步涉及与 HashiCorp 等生态系统合作伙伴合作,以确定工作流改进并使用成熟解决方案来解决覆盖差距。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注