Hello, I noticed you had two questions, and I’ll address them both here: 1. What should an SRE roadmap look like? An SRE roadmap can be approached from both strategic and technical perspectives. At the strategic level, as discussed in the video, the SRE practice and roadmap follow a top-down approach. Strategic considerations involve evaluating the current health of applications, budget constraints, potential team size, and infrastructure presence to determine the type of SRE team needed for your organization. On a technical level, the journey begins with establishing Metrics, Logs, and Traces (MLT) using either in-house or external tools. The next step is setting up appropriate alerts to monitor and understand the system, followed by creating initial dashboards. These dashboards should focus on both technical and business-level stories. Once day-to-day observability is in place, the next steps involve structuring the future path towards prevention, operational excellence, and establishing policies for the tech stack. This includes key metrics such as MTTD (Mean Time to Detect), MTTR (Mean Time to Repair), CUJ (Critical User Journey), SLI (Service Level Indicator), and SLO (Service Level Objective). Another crucial aspect of SRE is Toil Reduction, which involves automation and AIOps. Finally, once all engineering vertical teams are aligned and mature in SRE concepts, collaboration with other verticals for complete end-to-end observability is essential. I’ll stop here, as further details may not be universally applicable to all organizations. 2. What comes after achieving E2E Observability? Once all independent squads, pods, or teams are mature in handling traces, metrics, and logs, and end-to-end (E2E) observability is established for the entire consumer user journey, it’s a significant achievement worth celebrating. If this level hasn’t been reached yet, a good starting point is identifying the “Consumer User Journey” (CUJ), such as an e-commerce “checkout” service. Identify all services from the user interface to the supply chain (fulfilment) involved in this CUJ and aim for E2E observability for this journey. Once accomplished, this should serve as a technical template for other application flows or CUJs. At this stage, you can consider CUJ as a “Critical User Journey” to identify the most important routes needing E2E observability. Assuming all services within the CUJ are considered and E2E observability is fully implemented for each service, the focus should then shift to the sustainability of SRE practices within the organization. This involves establishing a model and advocating for the adoption of similar practices for any upcoming product or project. I hope this answers your questions comprehensively.
What would be the SRE road map, what’s next after getting E2E observability. I have been trying to get an answer this question from a while now.
Hello,
I noticed you had two questions, and I’ll address them both here:
1. What should an SRE roadmap look like?
An SRE roadmap can be approached from both strategic and technical perspectives. At the strategic level, as discussed in the video, the SRE practice and roadmap follow a top-down approach. Strategic considerations involve evaluating the current health of applications, budget constraints, potential team size, and infrastructure presence to determine the type of SRE team needed for your organization.
On a technical level, the journey begins with establishing Metrics, Logs, and Traces (MLT) using either in-house or external tools. The next step is setting up appropriate alerts to monitor and understand the system, followed by creating initial dashboards. These dashboards should focus on both technical and business-level stories.
Once day-to-day observability is in place, the next steps involve structuring the future path towards prevention, operational excellence, and establishing policies for the tech stack. This includes key metrics such as MTTD (Mean Time to Detect), MTTR (Mean Time to Repair), CUJ (Critical User Journey), SLI (Service Level Indicator), and SLO (Service Level Objective). Another crucial aspect of SRE is Toil Reduction, which involves automation and AIOps.
Finally, once all engineering vertical teams are aligned and mature in SRE concepts, collaboration with other verticals for complete end-to-end observability is essential. I’ll stop here, as further details may not be universally applicable to all organizations.
2. What comes after achieving E2E Observability?
Once all independent squads, pods, or teams are mature in handling traces, metrics, and logs, and end-to-end (E2E) observability is established for the entire consumer user journey, it’s a significant achievement worth celebrating. If this level hasn’t been reached yet, a good starting point is identifying the “Consumer User Journey” (CUJ), such as an e-commerce “checkout” service. Identify all services from the user interface to the supply chain (fulfilment) involved in this CUJ and aim for E2E observability for this journey.
Once accomplished, this should serve as a technical template for other application flows or CUJs. At this stage, you can consider CUJ as a “Critical User Journey” to identify the most important routes needing E2E observability.
Assuming all services within the CUJ are considered and E2E observability is fully implemented for each service, the focus should then shift to the sustainability of SRE practices within the organization. This involves establishing a model and advocating for the adoption of similar practices for any upcoming product or project.
I hope this answers your questions comprehensively.
@@recallwithravibarna yes it answers to my question on what should be the immediate road map and what to focus on for future goals.
Thank you.