[Initiative]: Cloud Native Observability Personas

[halcyondude]

Name

Cloud Native Observability Personas

Short description

Develop a set of user personas pertaining to the Observability domain.

Responsible group

TAG Operational Resilience

Does the initiative belong to a subproject?

No

Subproject name

No response

Primary contact

Matt Young

Additional contacts

No response

Initiative description

Develop a comprehensive set of user personas specific to the Cloud Native Observability domain. By defining these roles—ranging from application developers debugging code to platform engineers managing fleet-wide capacity—we aim to provide a shared vocabulary for the CNCF ecosystem. This will enable project maintainers to better target their documentation and tooling, and help end-users understand which observability signals (metrics, logs, traces, profiles, …) are most relevant to their specific role and objectives.

Problem Statement As highlighted in the CNCF Observability Whitepaper, the audience for observability is multidisciplinary: Site Reliability Engineers, DevOps Engineers, Sysadmins, Software Engineers, Infrastructure Engineers, and various stakeholders all consume observability data.

However, a "one size fits all" approach to observability fails at scale. An application developer needs high-cardinality traces and profiling data to debug a specific crash, while a cluster operator needs aggregated metrics to understand capacity. Currently, the ecosystem lacks a standardized definition of these roles. This can lead to mismatched tooling, cognitive overload, and communication gaps.

In Scope

• Conduct research and interviews with the CNCF End User Community to validate real-world roles.
• Define a core set of standard personas (e.g., App Developer, SRE, Platform Engineer, IT/Compliance) relevant to cloud-native observability.
• Map specific Observability Signals (Metrics, Logs, Traces, Profiles, Dumps) to the primary needs of each persona.
• Create a "Persona Matrix" identifying the primary "Jobs to be Done" for each role within the observability lifecycle (e.g., Triage, Root Cause Analysis, Capacity Planning).
• Publish the findings.

Goals

• Establish a shared vocabulary for "Who is observing the system?" across CNCF projects.
• Provide a reference for CNCF projects to self-assess which personas their tools primarily serve.
• Help End Users identify gaps in their current observability strategy by mapping their team structures to standard personas.
• Reduce "alert fatigue" and "data overload" by curating and encouraging persona-centric dashboard and alert design patterns.

Implementation Plan

Phase 1: Research & Discovery

• Leverage the existing work started in TAG Observability Issue #42.
• Conduct structured interviews with End Users to identify challenges and wins in their current organizational structures.
• Specific questions to answer: "Who owns the alert?", "Who looks at the trace?", "Who pays the bill?"

Phase 2: Definition & Mapping

• Draft the Persona Definitions.
• The Persona/Signal Matrix: Create a mapping of signals (Metrics, Logs, Traces, Profiles) to Personas.
• Review with TAG Operational Resilience and TAG App Delivery for feedback.

Phase 3: Publication & Dissemination

• Publish the "Observability Personas" document in the TAG Observability repository.
• Present findings to the TOC and wider community (KubeCon maintainer track or similar).
• Work with CNCF projects (e.g., Prometheus, OpenTelemetry, Jaeger) to encourage adopting these persona tags in their documentation (e.g., "This guide is for [App Developers]").

Resource Requirements

• Participation from TAG Operational Resilience members for reviews.
• Access to CNCF End User community for interviews/surveys.
• Collaboration with TAG Contributor Strategy for consistent persona formatting (if applicable).
• Technical writing support (community contributions) for the final deliverable.

Timeline (draft, dependent on resourcing and level of community contribution)

• Month 1: Finalize survey/interview questions and reach out to End Users.
• Month 2-3: Conduct interviews and aggregate data.
• Month 4: Draft initial Persona definitions and Signal Matrix.
• Month 5: Community Review period.
• Month 6: Final Publication and integration into the Observability Whitepaper v1.1+.

Additional References

• CNCF Observability Whitepaper v1.0
• TAG Observability Issue #42 - Initial Persona Discussion

Deliverable(s) or exit criteria

• Publication of the "Cloud Native Observability Personas" reference document.
• A matrix mapping Observability Signals to Personas.

Tracking document for meeting and progress

https://notes.cncf.io/jo7UB6StQqGM98EOwTlJbQ

[UtkarshSingh-06]

Hi @halcyondude and TAG Operational Resilience team 👋

I’d love to take ownership of the Cloud Native Observability Personas initiative and drive it to completion.

After reviewing the issue and existing discussions, I strongly agree with the core problem: the lack of clearly defined observability personas creates cognitive overload, mismatched tooling expectations, and inconsistent documentation across CNCF projects. Establishing a shared, research-backed persona model would unlock real value for both project maintainers and end users.

Proposed Approach (High Level)

I’m proposing a research-driven, community-validated approach in three phases, aligned with the 6-month timeline in the issue.

Phase 1: Research & Discovery (Months 1–2)

• Review existing CNCF and industry material (Observability Whitepaper, Prometheus / OpenTelemetry / Jaeger docs, SRE literature).
• Run a short community survey (target: 100+ responses) to understand:
  • Which signals different roles actually use (metrics, logs, traces, profiles, dumps)
  • Ownership questions (“who owns alerts?”, “who responds?”, “who pays?”)
• Conduct ~15–20 structured interviews across roles (developers, SREs, platform, security, product).
• Synthesize findings into an initial persona draft and signal-usage patterns.

Deliverable: Research summary + draft persona set grounded in real usage.

Phase 2: Definition & Mapping (Months 3–4)

• Define a standard persona schema (responsibilities, goals, signal preferences, jobs-to-be-done).
• Establish a core persona set (e.g., App Developer, SRE, Platform Engineer, DevOps, Security, Compliance, Product).
• Create a Persona ↔ Signal Matrix and map personas to observability lifecycle stages (triage → RCA → prevention).
• Validate via TAG review, cross-TAG feedback, project maintainers, and end users.

Deliverable: Finalized “Cloud Native Observability Personas” document.

Phase 3: Publication & Adoption (Months 5–6)

• Publish the personas as a markdown document under TAG Operational Resilience.
• Propose lightweight adoption guidance:
  • Persona tags in documentation (e.g. [SRE], [App Developer])
  • Persona-aware doc templates for CNCF projects
• Support integration into a future Observability

If this approach sounds aligned with the goals of the issue, I’d be happy to take the lead on driving it forward and coordinating the work with TAG Operational Resilience.
I’m also very open to feedback — if there are changes you’d suggest to the scope, timeline, or methodology, I’d love to incorporate them before getting started.
Thanks for considering, and I’m looking forward to your guidance on next steps.

[krol3]

Hi @halcyondude and TAG Operational Resilience team 👋

I’d love to take ownership of the Cloud Native Observability Personas initiative and drive it to completion.

After reviewing the issue and existing discussions, I strongly agree with the core problem: the lack of clearly defined observability personas creates cognitive overload, mismatched tooling expectations, and inconsistent documentation across CNCF projects. Establishing a shared, research-backed persona model would unlock real value for both project maintainers and end users.

Proposed Approach (High Level)

I’m proposing a research-driven, community-validated approach in three phases, aligned with the 6-month timeline in the issue.

Phase 1: Research & Discovery (Months 1–2)

• Review existing CNCF and industry material (Observability Whitepaper, Prometheus / OpenTelemetry / Jaeger docs, SRE literature).

• Run a short community survey (target: 100+ responses) to understand:

  • Which signals different roles actually use (metrics, logs, traces, profiles, dumps)
  • Ownership questions (“who owns alerts?”, “who responds?”, “who pays?”)

• Conduct ~15–20 structured interviews across roles (developers, SREs, platform, security, product).

• Synthesize findings into an initial persona draft and signal-usage patterns.

Deliverable: Research summary + draft persona set grounded in real usage.

Phase 2: Definition & Mapping (Months 3–4)

• Define a standard persona schema (responsibilities, goals, signal preferences, jobs-to-be-done).
• Establish a core persona set (e.g., App Developer, SRE, Platform Engineer, DevOps, Security, Compliance, Product).
• Create a Persona ↔ Signal Matrix and map personas to observability lifecycle stages (triage → RCA → prevention).
• Validate via TAG review, cross-TAG feedback, project maintainers, and end users.

Deliverable: Finalized “Cloud Native Observability Personas” document.

Phase 3: Publication & Adoption (Months 5–6)

• Publish the personas as a markdown document under TAG Operational Resilience.

• Propose lightweight adoption guidance:

  • Persona tags in documentation (e.g. [SRE], [App Developer])
  • Persona-aware doc templates for CNCF projects

• Support integration into a future Observability

If this approach sounds aligned with the goals of the issue, I’d be happy to take the lead on driving it forward and coordinating the work with TAG Operational Resilience. I’m also very open to feedback — if there are changes you’d suggest to the scope, timeline, or methodology, I’d love to incorporate them before getting started. Thanks for considering, and I’m looking forward to your guidance on next steps.

Hi @UtkarshSingh-06 , please join to our Monthly TAG Operational Resilience to discuss more how to start and work in this initiative