{"id":1638,"date":"2026-02-15T04:48:57","date_gmt":"2026-02-15T04:48:57","guid":{"rendered":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/"},"modified":"2026-02-15T04:48:57","modified_gmt":"2026-02-15T04:48:57","slug":"you-build-it-you-run-it","status":"publish","type":"post","link":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/","title":{"rendered":"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition (30\u201360 words)<\/h2>\n\n\n\n<p>You build it you run it means the same team that develops production software also operates and supports it in production. Analogy: a chef who not only creates a dish but also serves and handles customer feedback at the table. Formal line: a product-team-centric operational model where ownership spans code, deployment, monitoring, incidents, and lifecycle.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is You build it you run it?<\/h2>\n\n\n\n<p>You build it you run it is an operational mindset and organizational model that ties development ownership to production operations. It is NOT merely a slogan for developers to &#8220;be on-call&#8221; without support; it requires tooling, clear SRE practices, and organizational changes to succeed.<\/p>\n\n\n\n<p>Key properties and constraints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Product team ownership across the software lifecycle.<\/li>\n<li>Accountability for reliability, security, performance, and cost.<\/li>\n<li>Requires observability, automation, and clear on-call practices.<\/li>\n<li>Constrains teams by coupling feature work with operational toil unless automation is provided.<\/li>\n<li>Varies by company size; small teams can be fully autonomous, while large orgs will need platform teams and guardrails.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Aligns with cloud-native patterns: microservices, Kubernetes, serverless.<\/li>\n<li>Integrates with SRE concepts: SLIs, SLOs, error budgets, toil reduction.<\/li>\n<li>Works with platform teams providing self-service infrastructure and policy-as-code.<\/li>\n<li>Complements GitOps, CI\/CD, infrastructure as code, and observability pipelines.<\/li>\n<\/ul>\n\n\n\n<p>Diagram description (text-only):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Developers push code into repo -&gt; CI builds and runs tests -&gt; CD deploys to environment -&gt; Runtime platform (Kubernetes\/serverless) runs services -&gt; Observability collects traces, logs, metrics -&gt; On-call engineers receive alerts -&gt; Incident triage and remediation -&gt; Postmortem and SLO adjustments -&gt; Team iterates on code and automation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">You build it you run it in one sentence<\/h3>\n\n\n\n<p>The team that designs and delivers the software is responsible for operating it in production, including handling incidents, capacity, and reliability commitments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">You build it you run it vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from You build it you run it<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>DevOps<\/td>\n<td>Shared culture and practices; not always full ownership<\/td>\n<td>Often used as synonym<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>Site Reliability Engineering<\/td>\n<td>SRE is a role\/practice focused on reliability; not full product ownership<\/td>\n<td>People assume SRE runs everything<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>Platform as a Service<\/td>\n<td>Platform provides infrastructure but teams still operate apps<\/td>\n<td>Believed to remove ops entirely<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>NoOps<\/td>\n<td>Goal to remove operational tasks via automation<\/td>\n<td>Often unrealistic for complex systems<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>Product Ops<\/td>\n<td>Focus on product processes not infrastructure<\/td>\n<td>Confused with platform teams<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>GitOps<\/td>\n<td>CI\/CD pattern for declarative deployments<\/td>\n<td>Not equal to ownership changes<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>Ops Team<\/td>\n<td>Centralized operations run by separate group<\/td>\n<td>Can coexist but changes responsibilities<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>Managed Services<\/td>\n<td>Cloud provider runs parts of stack<\/td>\n<td>Teams still manage application logic<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>Blameless Postmortem<\/td>\n<td>Post-incident practice; a component of the model<\/td>\n<td>Not synonymous with ownership<\/td>\n<\/tr>\n<tr>\n<td>T10<\/td>\n<td>On-call Rotation<\/td>\n<td>Scheduling practice for availability<\/td>\n<td>On-call is a piece, not the whole model<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<p>Not needed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does You build it you run it matter?<\/h2>\n\n\n\n<p>Business impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Faster time-to-market: Teams that operate their own services can iterate features and fixes faster without waiting for handoffs.<\/li>\n<li>Stronger customer trust: The same team owns customer-impacting issues and can rapidly align fixes with product context.<\/li>\n<li>Controlled risk and cost: Teams directly feel the cost of inefficiency and are incentivized to optimize.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduced incidents caused by handoff gaps because the author understands runtime behavior.<\/li>\n<li>Increased velocity when operational tasks are automated and integrated into the development workflow.<\/li>\n<li>Improved product quality since teams measure and own SLIs and SLOs.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs and SLOs become team-owned targets; error budgets guide feature releases.<\/li>\n<li>Toil must be measured and minimized; platform teams should absorb repetitive tasks.<\/li>\n<li>On-call is rotated within teams; SREs typically act as consultants, platform enablers, or escalation support.<\/li>\n<\/ul>\n\n\n\n<p>3\u20135 realistic \u201cwhat breaks in production\u201d examples:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Latency spike due to inefficient database queries under new feature load.<\/li>\n<li>Memory leak in a microservice causing OOM and pod restarts.<\/li>\n<li>CI\/CD misconfiguration deploying broken migrations, causing downtime.<\/li>\n<li>Third-party API rate limits throttling critical user flows.<\/li>\n<li>Misconfigured network policy causing cross-service failures.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is You build it you run it used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How You build it you run it appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>Edge<\/td>\n<td>Teams own CDN and WAF config for their domains<\/td>\n<td>Request latency and cache hit<\/td>\n<td>CDN, WAF logs<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>Network<\/td>\n<td>Teams define service mesh and egress rules<\/td>\n<td>Connection errors and latency<\/td>\n<td>Service mesh metrics<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>Service<\/td>\n<td>Teams deploy and run microservices<\/td>\n<td>Request rate, error rate, latency<\/td>\n<td>APM, metrics<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>Application<\/td>\n<td>Teams own business logic and APIs<\/td>\n<td>Business transactions and errors<\/td>\n<td>Traces, logs<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>Data<\/td>\n<td>Teams own DB schema and ETL jobs<\/td>\n<td>Query latency and failures<\/td>\n<td>DB metrics<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>IaaS<\/td>\n<td>Teams manage VMs where needed<\/td>\n<td>Host CPU, disk, network<\/td>\n<td>Cloud monitoring<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>PaaS\/Kubernetes<\/td>\n<td>Teams deploy to shared clusters<\/td>\n<td>Pod health and resource usage<\/td>\n<td>K8s metrics<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>Serverless<\/td>\n<td>Teams own functions and triggers<\/td>\n<td>Invocation rate and duration<\/td>\n<td>Function metrics<\/td>\n<\/tr>\n<tr>\n<td>L9<\/td>\n<td>CI\/CD<\/td>\n<td>Teams own pipelines and deploys<\/td>\n<td>Pipeline success and deploy time<\/td>\n<td>CI logs<\/td>\n<\/tr>\n<tr>\n<td>L10<\/td>\n<td>Observability<\/td>\n<td>Teams own alerts and dashboards<\/td>\n<td>SLI\/SLO status and logs<\/td>\n<td>Observability platforms<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>Not needed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use You build it you run it?<\/h2>\n\n\n\n<p>When it\u2019s necessary:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Small to mid-sized teams where domain ownership spans product and operations.<\/li>\n<li>Systems requiring domain expertise for rapid incident remediation.<\/li>\n<li>When you need fast feedback loops between customers and developers.<\/li>\n<\/ul>\n\n\n\n<p>When it\u2019s optional:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Massive monolithic legacy systems where a phased approach is needed.<\/li>\n<li>Highly regulated environments where centralized controls are mandatory.<\/li>\n<li>Early-stage prototypes where costs of full operations ownership are disproportionate.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For low-criticality batch jobs where central automation is more efficient.<\/li>\n<li>When teams lack bandwidth to absorb operational responsibilities without platform support.<\/li>\n<li>In safety-critical systems requiring specialized ops or certification.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If teams deploy independently and iterate weekly -&gt; adopt full You build it you run it.<\/li>\n<li>If compliance or certification requires centralized controls -&gt; hybrid model with platform guards.<\/li>\n<li>If toil &gt; 20% of team&#8217;s time and automation not available -&gt; invest in platform first.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: Teams are on-call; basic alerts; platform provides CI\/CD.<\/li>\n<li>Intermediate: Teams own SLIs\/SLOs, automated deployments, shared platform APIs.<\/li>\n<li>Advanced: Teams run full observability, automated remediations, cost-aware deployments, and self-service platform.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does You build it you run it work?<\/h2>\n\n\n\n<p>Components and workflow:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Code repository and feature branch -&gt; CI runs tests and builds artifacts.<\/li>\n<li>CD pipeline deploys to environments using declarative configs (GitOps).<\/li>\n<li>Runtime platform hosts service (Kubernetes\/serverless\/PaaS).<\/li>\n<li>Observability pipeline collects metrics, traces, and logs to a central store.<\/li>\n<li>Team-owned SLIs feed SLO dashboards; alerts are generated from SLO thresholds and operational signals.<\/li>\n<li>On-call rotation responds to alerts; runbooks accelerate triage.<\/li>\n<li>Postmortems feed improvements into code, platform, and runbooks.<\/li>\n<\/ol>\n\n\n\n<p>Data flow and lifecycle:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Source code -&gt; build artifacts -&gt; deployment manifests -&gt; runtime -&gt; telemetry -&gt; alerting -&gt; incident -&gt; remediation -&gt; postmortem -&gt; code change.<\/li>\n<\/ul>\n\n\n\n<p>Edge cases and failure modes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform outage prevents teams from deploying; fallback manual processes needed.<\/li>\n<li>Sensitive services with strict compliance may require central audits, complicating autonomy.<\/li>\n<li>Teams may prioritize features over operational work if error budgets are not enforced.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for You build it you run it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Self-service platform with guardrails: Platform team offers APIs and templates; product teams deploy autonomously.<\/li>\n<li>Federated SRE model: SREs embedded in product teams part-time while central SRE provides tooling.<\/li>\n<li>Serverless-first teams: Teams use managed compute to minimize infrastructure ops and focus on app-level ops.<\/li>\n<li>Kubernetes-native microservices: Teams own namespaces, Helm\/OCI-based manifests, and observability sidecars.<\/li>\n<li>Hybrid managed: Critical infra is managed centrally; product teams run applications and own SLIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>Alert fatigue<\/td>\n<td>Alerts ignored<\/td>\n<td>Poor thresholds or noisy signals<\/td>\n<td>Threshold tuning and dedupe<\/td>\n<td>Rising alert count<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>Slow deployments<\/td>\n<td>Long release cycles<\/td>\n<td>Lack of automation<\/td>\n<td>Improve CD and tests<\/td>\n<td>Deploy duration metric<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Ownership gaps<\/td>\n<td>Issues bounced between teams<\/td>\n<td>Unclear responsibility<\/td>\n<td>Define ownership and runbooks<\/td>\n<td>Increased MTTR<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>Cost overruns<\/td>\n<td>Unexpected cloud bills<\/td>\n<td>Inefficient resources<\/td>\n<td>Cost monitoring and alerts<\/td>\n<td>Cost per service<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>Toil creep<\/td>\n<td>Team spends time on ops<\/td>\n<td>No automation<\/td>\n<td>Create automation runbooks<\/td>\n<td>Time-on-toil metric<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>Security drift<\/td>\n<td>Vulnerabilities remain<\/td>\n<td>Poor scanning or patching<\/td>\n<td>Automated scans and policy<\/td>\n<td>Vulnerability trend<\/td>\n<\/tr>\n<tr>\n<td>F7<\/td>\n<td>Platform outage<\/td>\n<td>All teams impacted<\/td>\n<td>Central platform failure<\/td>\n<td>Multi-region and fallback<\/td>\n<td>Platform health events<\/td>\n<\/tr>\n<tr>\n<td>F8<\/td>\n<td>SLO neglect<\/td>\n<td>SLOs miss targets<\/td>\n<td>No enforcement<\/td>\n<td>Error budget policy<\/td>\n<td>SLO burn rate<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>Not needed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for You build it you run it<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLI \u2014 Service Level Indicator \u2014 measurable signal of service behavior \u2014 common pitfall: poorly defined metrics.<\/li>\n<li>SLO \u2014 Service Level Objective \u2014 target for an SLI \u2014 common pitfall: unrealistic targets.<\/li>\n<li>Error budget \u2014 Allowable SLO breach \u2014 why it matters: balances reliability and velocity \u2014 pitfall: ignored by product teams.<\/li>\n<li>On-call \u2014 Rotational duty to respond to incidents \u2014 pitfall: inadequate handover.<\/li>\n<li>Blameless postmortem \u2014 Incident review focused on learning \u2014 pitfall: skipping action items.<\/li>\n<li>Toil \u2014 Repetitive operational work \u2014 why it matters: reduces productivity \u2014 pitfall: not measured.<\/li>\n<li>Observability \u2014 Ability to understand system state via telemetry \u2014 pitfall: siloed data.<\/li>\n<li>Metrics \u2014 Numeric telemetry over time \u2014 pitfall: missing high-cardinality context.<\/li>\n<li>Tracing \u2014 Distributed request flow data \u2014 why it matters: root-cause visibility \u2014 pitfall: sampling blind spots.<\/li>\n<li>Logging \u2014 Event records for troubleshooting \u2014 pitfall: unstructured logs.<\/li>\n<li>Runbook \u2014 Step-by-step incident remediation guide \u2014 pitfall: stale content.<\/li>\n<li>Playbook \u2014 High-level incident strategy \u2014 pitfall: too vague.<\/li>\n<li>Incident commander \u2014 Role coordinating response \u2014 pitfall: overloaded single person.<\/li>\n<li>Postmortem \u2014 Incident analysis document \u2014 pitfall: assigning blame.<\/li>\n<li>Fault injection \u2014 Controlled testing of failures \u2014 why it matters: resilience practice \u2014 pitfall: insufficient scope.<\/li>\n<li>Chaos engineering \u2014 Systematic fault testing \u2014 pitfall: lack of safety checks.<\/li>\n<li>CI\/CD \u2014 Automation for build and deploy \u2014 pitfall: insufficient testing gates.<\/li>\n<li>GitOps \u2014 Declarative deploys via git \u2014 pitfall: misaligned reconciliation loops.<\/li>\n<li>Platform team \u2014 Team providing infra capabilities \u2014 pitfall: becoming gatekeepers.<\/li>\n<li>SRE team \u2014 Reliability engineers focused on tooling and scale \u2014 pitfall: operating as siloed ops.<\/li>\n<li>Canary deployment \u2014 Gradual release to subset of users \u2014 pitfall: low-traffic canaries.<\/li>\n<li>Blue\/green deployment \u2014 Fast rollback pattern \u2014 pitfall: doubling costs temporarily.<\/li>\n<li>Feature flags \u2014 Toggle features at runtime \u2014 pitfall: flag debt.<\/li>\n<li>RBAC \u2014 Role-based access control \u2014 why it matters: secure delegation \u2014 pitfall: over-privileging.<\/li>\n<li>Policy-as-code \u2014 Enforceable infra policies \u2014 pitfall: complex policies.<\/li>\n<li>Service mesh \u2014 Network-layer control for microservices \u2014 pitfall: added complexity.<\/li>\n<li>Sidecar pattern \u2014 Injected helper container per pod \u2014 pitfall: resource overhead.<\/li>\n<li>Infrastructure as Code \u2014 Declarative infra configuration \u2014 pitfall: drift.<\/li>\n<li>Secrets management \u2014 Secure secret storage and rotation \u2014 pitfall: hardcoded secrets.<\/li>\n<li>Observability pipeline \u2014 Ingest and processing of telemetry \u2014 pitfall: noisy retention costs.<\/li>\n<li>Throttling \u2014 Backpressure mechanism \u2014 pitfall: opaque throttles.<\/li>\n<li>Rate limiting \u2014 Protect downstream services \u2014 pitfall: poor granularity.<\/li>\n<li>Circuit breaker \u2014 Fail fast pattern \u2014 pitfall: brittle thresholds.<\/li>\n<li>Auto-scaling \u2014 Dynamic capacity management \u2014 pitfall: scaling thrash.<\/li>\n<li>Cost allocation \u2014 Chargeback for cloud spend \u2014 pitfall: inaccurate tagging.<\/li>\n<li>Compliance automation \u2014 Automating audits and checks \u2014 pitfall: false positives.<\/li>\n<li>Runbook automation \u2014 Automating repetitive runbook steps \u2014 pitfall: unsafe automations.<\/li>\n<li>Service level report \u2014 Periodic reliability summary \u2014 pitfall: ignored by execs.<\/li>\n<li>Escalation policy \u2014 Rules for staffing escalations \u2014 pitfall: unclear steps.<\/li>\n<li>Incident blamelessness \u2014 Cultural practice post-incident \u2014 pitfall: rhetorical only.<\/li>\n<li>Ownership matrix \u2014 Map of responsibilities \u2014 pitfall: outdated mapping.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure You build it you run it (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Request success rate<\/td>\n<td>Service availability<\/td>\n<td>Successful responses \/ total<\/td>\n<td>99.9% per service<\/td>\n<td>Partial failures hide impact<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Request latency P95<\/td>\n<td>User experience latency<\/td>\n<td>95th percentile latency<\/td>\n<td>300ms for API<\/td>\n<td>Tail latency matters more<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>Error budget burn rate<\/td>\n<td>Pace of SLO consumption<\/td>\n<td>Burn = failures\/time per budget<\/td>\n<td>Threshold 4x normal<\/td>\n<td>Short windows noisy<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>MTTR<\/td>\n<td>Mean time to restore service<\/td>\n<td>Avg time incident -&gt; resolved<\/td>\n<td>&lt; 1 hour for critical<\/td>\n<td>Outliers skew mean<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>Change failure rate<\/td>\n<td>Deploys causing incidents<\/td>\n<td>Failed deploys \/ deploys<\/td>\n<td>&lt; 5%<\/td>\n<td>Hidden failures post-deploy<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>Deployment lead time<\/td>\n<td>Cycle time from commit to prod<\/td>\n<td>Time commit-&gt;production<\/td>\n<td>&lt; 1 day<\/td>\n<td>Flaky pipelines inflate time<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>Toil hours per sprint<\/td>\n<td>Manual ops work<\/td>\n<td>Manual hours logged<\/td>\n<td>&lt; 10% of team time<\/td>\n<td>Underreporting common<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>Cost per request<\/td>\n<td>Efficiency and cost<\/td>\n<td>Cloud charges \/ requests<\/td>\n<td>Varies by product<\/td>\n<td>Allocation errors<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>Alert noise ratio<\/td>\n<td>Quality of alerts<\/td>\n<td>Actionable alerts \/ total<\/td>\n<td>&gt; 20% actionable<\/td>\n<td>Duplicates inflate alerts<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Observability coverage<\/td>\n<td>Signal completeness<\/td>\n<td>Percentage of services with telemetry<\/td>\n<td>100% critical services<\/td>\n<td>High-cardinality cost<\/td>\n<\/tr>\n<tr>\n<td>M11<\/td>\n<td>Security findings resolved<\/td>\n<td>Vulnerability remediation<\/td>\n<td>Findings closed \/ total<\/td>\n<td>SLA-driven<\/td>\n<td>False positives<\/td>\n<\/tr>\n<tr>\n<td>M12<\/td>\n<td>Backup recovery time<\/td>\n<td>Data recovery assurance<\/td>\n<td>Time to restore backups<\/td>\n<td>Meets RTO<\/td>\n<td>Test frequency matters<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>Not needed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure You build it you run it<\/h3>\n\n\n\n<p>Choose 5\u201310 tools and describe.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Prometheus<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for You build it you run it: Metrics collection and alerting for services and infrastructure.<\/li>\n<li>Best-fit environment: Kubernetes and cloud-native stacks.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy Prometheus instance per environment or use multi-tenant model.<\/li>\n<li>Configure exporters for apps and infra.<\/li>\n<li>Define recording rules and alerts.<\/li>\n<li>Integrate with alertmanager.<\/li>\n<li>Set retention and sidecar for long-term store.<\/li>\n<li>Strengths:<\/li>\n<li>Strong metrics model and query language.<\/li>\n<li>Wide ecosystem support.<\/li>\n<li>Limitations:<\/li>\n<li>Scaling and long-term storage require additional components.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 OpenTelemetry<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for You build it you run it: Traces, metrics, and logs instrumentation standard.<\/li>\n<li>Best-fit environment: Distributed systems and polyglot stacks.<\/li>\n<li>Setup outline:<\/li>\n<li>Instrument libraries and SDKs in apps.<\/li>\n<li>Configure exporters to chosen backend.<\/li>\n<li>Standardize sampling and resource attributes.<\/li>\n<li>Validate traces in staging.<\/li>\n<li>Strengths:<\/li>\n<li>Vendor-neutral and broad language support.<\/li>\n<li>Limitations:<\/li>\n<li>Implementation complexity and sampling tuning.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Grafana<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for You build it you run it: Visualization of SLIs, SLOs, and dashboards.<\/li>\n<li>Best-fit environment: Teams needing dashboards across telemetry sources.<\/li>\n<li>Setup outline:<\/li>\n<li>Connect data sources (Prometheus, tempo, logs).<\/li>\n<li>Create SLO dashboards and team views.<\/li>\n<li>Configure alerting rules.<\/li>\n<li>Strengths:<\/li>\n<li>Flexible panels and templating.<\/li>\n<li>Limitations:<\/li>\n<li>Dashboard sprawl without governance.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Jaeger (or Tempo)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for You build it you run it: Distributed tracing analysis for request flows.<\/li>\n<li>Best-fit environment: Microservices with long request chains.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy tracing backend and collectors.<\/li>\n<li>Instrument applications with OpenTelemetry.<\/li>\n<li>Configure sampling and trace retention.<\/li>\n<li>Strengths:<\/li>\n<li>Root-cause tracing visibility.<\/li>\n<li>Limitations:<\/li>\n<li>High cardinality and storage considerations.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 CI\/CD (GitOps-driven e.g., controller)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for You build it you run it: Deployment frequency, lead time, and change failure metrics.<\/li>\n<li>Best-fit environment: Declarative infra and Kubernetes.<\/li>\n<li>Setup outline:<\/li>\n<li>Configure repos with declarative manifests.<\/li>\n<li>Set automated reconciliation policies.<\/li>\n<li>Integrate approvals for critical changes.<\/li>\n<li>Strengths:<\/li>\n<li>Auditable deployment history and rollbacks.<\/li>\n<li>Limitations:<\/li>\n<li>Complexity in multi-cluster setups.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Cloud cost management tool<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for You build it you run it: Cost per service and anomaly detection.<\/li>\n<li>Best-fit environment: Multi-cloud or heavy cloud usage.<\/li>\n<li>Setup outline:<\/li>\n<li>Tag resources and set cost allocation.<\/li>\n<li>Configure alerts for budget breaches.<\/li>\n<li>Integrate with invoices.<\/li>\n<li>Strengths:<\/li>\n<li>Visibility into cost drivers.<\/li>\n<li>Limitations:<\/li>\n<li>Requires accurate tagging discipline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for You build it you run it<\/h3>\n\n\n\n<p>Executive dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Overall SLO status, Error budget burn rate, Top impacted services, Monthly incident count.<\/li>\n<li>Why: High-level view for leadership to understand reliability and risk.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Real-time SLO health, Active incidents, Relevant service logs, Recent deploys.<\/li>\n<li>Why: Focused context for incident response and triage.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Request rates and P95\/P99 latencies, Error counts with stack traces, Top traces, Resource usage heatmap.<\/li>\n<li>Why: Deep diagnostics for root-cause analysis.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Page vs ticket: Page for high-severity SLO breaches and on-call required issues; ticket for non-urgent degradations and follow-ups.<\/li>\n<li>Burn-rate guidance: Alert when burn rate indicates 25% of error budget could be consumed within 24 hours; escalate at 100% projected burn.<\/li>\n<li>Noise reduction tactics: Deduplicate by alert fingerprinting, group alerts by service and failure domain, apply suppression during known maintenance windows.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Team agreement on ownership and on-call rotations.\n&#8211; Platform or infra baseline (CI\/CD, cluster, observability).\n&#8211; Security and compliance guardrails.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Identify SLIs for critical user journeys.\n&#8211; Instrument metrics, traces, and structured logs.\n&#8211; Standardize labels and resource attributes.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Deploy collectors and exporters (OpenTelemetry, Prometheus).\n&#8211; Ensure pipelines include enrichment and retention policies.\n&#8211; Centralize alerting rules in version control.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define SLI measurement windows and targets.\n&#8211; Create error budget policies and enforcement paths.\n&#8211; Publish SLOs to team and stakeholders.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Create executive, on-call, and debug dashboards.\n&#8211; Use templating to reuse dashboards across services.\n&#8211; Link dashboards to runbooks and incident tools.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Map alerts to teams and escalation policies.\n&#8211; Implement deduplication and grouping.\n&#8211; Test alert flows and paging.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Create runbooks for common incidents with scripts for remediation.\n&#8211; Automate safe rollbacks and canary promotions.\n&#8211; Use chat-ops or CI to run automated recovery steps.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Run load tests and validate SLOs under realistic loads.\n&#8211; Schedule chaos experiments on non-production and staged environments.\n&#8211; Run game days that exercise on-call rotations and runbooks.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Postmortem action item tracking and prioritization.\n&#8211; Regular SLO reviews and tuning.\n&#8211; Invest in platform automation where toil is high.<\/p>\n\n\n\n<p>Checklists:<\/p>\n\n\n\n<p>Pre-production checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs and basic dashboards implemented.<\/li>\n<li>CI\/CD pipeline with test gates.<\/li>\n<li>Secrets and RBAC configured.<\/li>\n<li>Automated canary or rollback configured.<\/li>\n<li>Basic runbook available.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLOs defined and published.<\/li>\n<li>Full observability coverage.<\/li>\n<li>On-call schedule and escalation set.<\/li>\n<li>Automated alerts with thresholds validated.<\/li>\n<li>Cost and security guardrails in place.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to You build it you run it<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Triage using SLO and recent deploys.<\/li>\n<li>Identify incident commander and communication channel.<\/li>\n<li>Collect traces and logs for impacted transactions.<\/li>\n<li>Execute runbook steps; escalate if necessary.<\/li>\n<li>Produce postmortem and assign actions.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of You build it you run it<\/h2>\n\n\n\n<p>1) Consumer-facing API\n&#8211; Context: High-traffic customer API.\n&#8211; Problem: Latency and availability affect revenue.\n&#8211; Why YBIYRI helps: Developers can fix issues faster and tune performance.\n&#8211; What to measure: P95 latency, success rate, error budget.\n&#8211; Typical tools: Prometheus, tracing, CI\/CD.<\/p>\n\n\n\n<p>2) Internal analytics pipeline\n&#8211; Context: Batch ETL jobs feeding dashboards.\n&#8211; Problem: Late data affects decisions.\n&#8211; Why: Teams owning both job code and runtime can ensure reliability.\n&#8211; What to measure: Job success rate, lag, processing time.\n&#8211; Tools: Job schedulers, logs, metrics.<\/p>\n\n\n\n<p>3) Serverless event handler\n&#8211; Context: Function triggered by user events.\n&#8211; Problem: Cold start and cost spikes.\n&#8211; Why: Function owners can tune concurrency and scaling.\n&#8211; What to measure: Invocation duration, error rate, cost per invocation.\n&#8211; Tools: Function metrics, distributed tracing.<\/p>\n\n\n\n<p>4) E-commerce checkout\n&#8211; Context: Checkout is critical revenue path.\n&#8211; Problem: Third-party payment failures.\n&#8211; Why: Team owning integration can manage retries and degrade gracefully.\n&#8211; What to measure: Checkout success rate, third-party latency.\n&#8211; Tools: Traces, feature flags.<\/p>\n\n\n\n<p>5) Multi-tenant SaaS microservice\n&#8211; Context: Shared service for many customers.\n&#8211; Problem: Noisy neighbors affecting latency.\n&#8211; Why: Owners can implement resource quotas and isolation.\n&#8211; What to measure: Per-tenant latency and error rate.\n&#8211; Tools: Service mesh, metrics per tenant.<\/p>\n\n\n\n<p>6) Mobile backend\n&#8211; Context: Mobile clients rely on API.\n&#8211; Problem: Versioned clients and backward compatibility.\n&#8211; Why: Team owning deploys can manage rolling upgrades and feature flags.\n&#8211; What to measure: API error rate per client version.\n&#8211; Tools: Logging, analytics.<\/p>\n\n\n\n<p>7) Data API with strict SLAs\n&#8211; Context: Paid API with contractual SLAs.\n&#8211; Problem: Outages affect renewals.\n&#8211; Why: Ownership enforces SLOs and priority fixes.\n&#8211; What to measure: SLA compliance and incident MTTR.\n&#8211; Tools: SLO tooling and alerts.<\/p>\n\n\n\n<p>8) Security-critical service\n&#8211; Context: Authentication and authorization services.\n&#8211; Problem: Breaches or misconfigurations.\n&#8211; Why: Team owns both features and emergency patching.\n&#8211; What to measure: Suspicious auth failures and patch time.\n&#8211; Tools: Security scans, telemetry.<\/p>\n\n\n\n<p>9) Internal developer platform\n&#8211; Context: Teams consume platform for deployments.\n&#8211; Problem: Platform outages block many teams.\n&#8211; Why: Platform team maintains central services but product teams own app behavior.\n&#8211; What to measure: Platform uptime and deploy success rates.\n&#8211; Tools: Platform monitoring and incident playbooks.<\/p>\n\n\n\n<p>10) Edge compute feature\n&#8211; Context: Low-latency features running at edge.\n&#8211; Problem: Distributed failures and inconsistency.\n&#8211; Why: Team owning deployment topology can tune replication and fallback.\n&#8211; What to measure: Edge latency and regional availability.\n&#8211; Tools: Edge telemetry, CDN metrics.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes microservice outage<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A microservice on Kubernetes experiences frequent OOM kills after a feature release.<br\/>\n<strong>Goal:<\/strong> Reduce incidents and restore stability while enabling safe feature rollout.<br\/>\n<strong>Why You build it you run it matters here:<\/strong> The dev team knows memory characteristics and can iterate resource requests, liveness probes, and code fixes quickly.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Microservice deployed via GitOps into team namespace, Prometheus and OpenTelemetry collectors, Grafana dashboards and alertmanager.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reproduce the issue in staging with load tests.<\/li>\n<li>Increase pod resource requests temporarily and deploy.<\/li>\n<li>Instrument memory allocations and snapshot traces.<\/li>\n<li>Implement code-level fix and add unit tests.<\/li>\n<li>Introduce canary deployment with health checks.\n<strong>What to measure:<\/strong> Pod restarts, memory usage, request latency, SLO status.<br\/>\n<strong>Tools to use and why:<\/strong> Kubernetes, Prometheus, OpenTelemetry, Grafana\u2014standard cloud-native stack.<br\/>\n<strong>Common pitfalls:<\/strong> Permanent overprovisioning as a quick fix; missing namespace isolation.<br\/>\n<strong>Validation:<\/strong> Run scaled load test and simulate spike; verify no OOM and SLOs met.<br\/>\n<strong>Outcome:<\/strong> Reduced OOM incidents, faster recovery, and production-safe canary process.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless billing spike<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A new notification function causes excessive invocations after a faulty loop, increasing costs.<br\/>\n<strong>Goal:<\/strong> Stop runaway cost and add protections to prevent recurrence.<br\/>\n<strong>Why You build it you run it matters here:<\/strong> Function owners can immediately patch code and add throttles or safeguards.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Managed serverless platform with function metrics and billing alerts.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Disable function via feature flag or platform console.<\/li>\n<li>Patch code to fix loop and add idempotency and rate limiting.<\/li>\n<li>Implement invocation quotas and cost alerts.<\/li>\n<li>Add automated tests for invocation limits.\n<strong>What to measure:<\/strong> Invocation rate, cost per hour, error rate.<br\/>\n<strong>Tools to use and why:<\/strong> Function platform metrics, cost management, and CI for tests.<br\/>\n<strong>Common pitfalls:<\/strong> Relying solely on manual disabling; not adding automated guardrails.<br\/>\n<strong>Validation:<\/strong> Simulate high invocation in staging and verify throttles fire.<br\/>\n<strong>Outcome:<\/strong> Runaway cost contained; guardrails prevent same class of issue.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident response and postmortem<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A payment processor outage during peak leads to revenue loss.<br\/>\n<strong>Goal:<\/strong> Rapid mitigation, clear RCA, and prevention steps.<br\/>\n<strong>Why You build it you run it matters here:<\/strong> The product team owning payments coordinates fixes and follows through with ops changes.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Payment service, SLOs, tracing for transaction flows, runbooks for failover.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Trigger incident commander and page on-call.<\/li>\n<li>Failover to backup payment gateway following runbook.<\/li>\n<li>Capture traces for failing transactions.<\/li>\n<li>Conduct blameless postmortem and assign action items.\n<strong>What to measure:<\/strong> Transaction success rate, MTTR, customer impact.<br\/>\n<strong>Tools to use and why:<\/strong> Tracing, SLO dashboards, incident management tool.<br\/>\n<strong>Common pitfalls:<\/strong> Incomplete evidence collection and missing follow-through on action items.<br\/>\n<strong>Validation:<\/strong> Run failover drill in staging and execute postmortem template.<br\/>\n<strong>Outcome:<\/strong> Faster failovers and improved payment reliability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost vs performance tuning (cost\/performance trade-off)<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Team needs to reduce costs without degrading user experience for an analytics query service.<br\/>\n<strong>Goal:<\/strong> Achieve cost savings while maintaining SLOs.<br\/>\n<strong>Why You build it you run it matters here:<\/strong> The team has domain knowledge to make trade-offs and implement optimizations.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Query service on cloud VMs with auto-scaling and query cache.<br\/>\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Measure cost per query and profile hot paths.<\/li>\n<li>Implement caching for heavy queries and tune instance types.<\/li>\n<li>Introduce autoscaler rules based on SLO-relevant metrics.<\/li>\n<li>Monitor SLOs and adjust scaling or cache TTLs.\n<strong>What to measure:<\/strong> Cost per query, P95 latency, cache hit rate.<br\/>\n<strong>Tools to use and why:<\/strong> Profilers, cost management, monitoring.<br\/>\n<strong>Common pitfalls:<\/strong> Overaggressive scaling down causing latency spikes.<br\/>\n<strong>Validation:<\/strong> A\/B test changes against traffic baseline and verify SLO compliance.<br\/>\n<strong>Outcome:<\/strong> Lower cost with stable user experience.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<p>List of mistakes with symptom -&gt; root cause -&gt; fix (selected 20)<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Symptom: Constant noisy alerts -&gt; Root cause: Broad alert thresholds -&gt; Fix: Narrow SLO-based alerts and add dedupe.<\/li>\n<li>Symptom: Teams not responding to pages -&gt; Root cause: Alert fatigue -&gt; Fix: Reduce noise and rotate on-call fairness.<\/li>\n<li>Symptom: Postmortems missing actions -&gt; Root cause: No ownership of action items -&gt; Fix: Assign next steps with deadlines and track.<\/li>\n<li>Symptom: Slow rollouts -&gt; Root cause: Manual deploy steps -&gt; Fix: Automate CD and adopt canary releases.<\/li>\n<li>Symptom: Hidden cost spikes -&gt; Root cause: Poor tagging -&gt; Fix: Enforce tagging and cost alerts.<\/li>\n<li>Symptom: Missing telemetry for a service -&gt; Root cause: No instrumentation policy -&gt; Fix: Mandate OpenTelemetry and onboarding checks.<\/li>\n<li>Symptom: Unclear ownership after incident -&gt; Root cause: No ownership matrix -&gt; Fix: Maintain updated ownership documents.<\/li>\n<li>Symptom: Frequent toil -&gt; Root cause: Lack of automation -&gt; Fix: Invest in runbook automation and platform features.<\/li>\n<li>Symptom: Security vulnerabilities persist -&gt; Root cause: Poor scanning integration -&gt; Fix: Integrate SCA\/DAST in pipeline and fix SLAs.<\/li>\n<li>Symptom: Platform becomes gatekeeper -&gt; Root cause: Centralized approvals -&gt; Fix: Move to self-service with policy-as-code.<\/li>\n<li>Symptom: Flaky tests block deploys -&gt; Root cause: Poor test isolation -&gt; Fix: Fix tests and isolate external dependencies.<\/li>\n<li>Symptom: Overprovisioned resources -&gt; Root cause: Simple fixes instead of profiling -&gt; Fix: Profile, right-size, and autoscale.<\/li>\n<li>Symptom: High MTTR -&gt; Root cause: No runbooks or poor observability -&gt; Fix: Create runbooks and improve telemetry granularity.<\/li>\n<li>Symptom: Alerts about the same root cause appear separately -&gt; Root cause: Fragmented observability -&gt; Fix: Consolidate signals and use correlated alerts.<\/li>\n<li>Symptom: Feature flags become technical debt -&gt; Root cause: No flag lifecycle -&gt; Fix: Enforce flag cleanup policy.<\/li>\n<li>Symptom: Data loss during incidents -&gt; Root cause: No tested backups -&gt; Fix: Implement regular backup validation.<\/li>\n<li>Symptom: Slow query performance -&gt; Root cause: Unoptimized schema -&gt; Fix: Add indexes and caching; measure impact.<\/li>\n<li>Symptom: Inconsistent environments -&gt; Root cause: Infrastructure drift -&gt; Fix: Use IaC and GitOps with reconciliation.<\/li>\n<li>Symptom: Escalation chaos -&gt; Root cause: Unclear escalation policy -&gt; Fix: Document and test escalation paths.<\/li>\n<li>Symptom: Observability costs explode -&gt; Root cause: High cardinality metrics and retention -&gt; Fix: Sample traces, reduce retention for low-value data.<\/li>\n<\/ol>\n\n\n\n<p>Observability pitfalls (at least 5 included above):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Missing instrumentation, fragmented signals, high-cardinality telemetry costs, unstructured logs, and alert misconfiguration. Fixes include standardizing OpenTelemetry, correlating signals, sampling, structured logging, and alert tuning.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Teams own services end-to-end and rotate on-call responsibilities.<\/li>\n<li>Keep on-call guardrails: compensated rotations, clear breakout criteria, and escalation support.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbook: Actionable step-by-step for common incidents.<\/li>\n<li>Playbook: High-level strategy for complex incidents.<\/li>\n<li>Keep runbooks versioned and testable; playbooks should be reviewed quarterly.<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use canary and blue\/green strategies for risky changes.<\/li>\n<li>Automate rollback triggers based on SLO deviations.<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Measure toil and automate repetitive tasks with runbook automation and platform capabilities.<\/li>\n<li>Invest platform engineering to provide shared services.<\/li>\n<\/ul>\n\n\n\n<p>Security basics:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Integrate scanning in CI, enforce least privilege RBAC, and rotate secrets.<\/li>\n<li>Regularly test incident response for security incidents.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review active SLOs and recent alerts; rotate on-call and update runbooks.<\/li>\n<li>Monthly: Review error budget consumption, backlog of reliability work, and cost reports.<\/li>\n<li>Quarterly: Run game days and SLO target reviews; update ownership and runbooks.<\/li>\n<\/ul>\n\n\n\n<p>What to review in postmortems:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Root cause analysis, contributing factors, action items with owners, trends across incidents, SLO impacts, and whether automation or platform changes could prevent recurrence.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for You build it you run it (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>Metrics store<\/td>\n<td>Stores time-series metrics<\/td>\n<td>Prometheus exporters and alerting<\/td>\n<td>Core for SLIs<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>Tracing backend<\/td>\n<td>Collects distributed traces<\/td>\n<td>OpenTelemetry and APM<\/td>\n<td>Key for root cause<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>Logging platform<\/td>\n<td>Stores and indexes logs<\/td>\n<td>Log collectors and dashboards<\/td>\n<td>Useful for deep digs<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>CI\/CD<\/td>\n<td>Automates builds and deploys<\/td>\n<td>Git repos and registries<\/td>\n<td>Enables safe releases<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>Incident mgmt<\/td>\n<td>Tracks incidents and communications<\/td>\n<td>Paging and chat tools<\/td>\n<td>Formal incident lifecycle<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>Cost mgmt<\/td>\n<td>Monitors cloud spend<\/td>\n<td>Billing APIs and tags<\/td>\n<td>Prevents surprise bills<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Secrets mgmt<\/td>\n<td>Secure secret storage<\/td>\n<td>CI and runtime integrations<\/td>\n<td>Critical for security<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>Policy engine<\/td>\n<td>Enforces policies as code<\/td>\n<td>GitOps and admission controllers<\/td>\n<td>Guardrails for teams<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>Platform infra<\/td>\n<td>Provides shared runtime<\/td>\n<td>Cluster and cloud APIs<\/td>\n<td>Enables self-service<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>SLO tooling<\/td>\n<td>Tracks SLOs and error budgets<\/td>\n<td>Metrics and alerting<\/td>\n<td>Drives reliability decisions<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<p>Not needed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What levels of team maturity are required to adopt You build it you run it?<\/h3>\n\n\n\n<p>Teams need basic CI\/CD, instrumentation, and a willingness to be on-call; platform support accelerates adoption.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does You build it you run it mean developers must do all ops tasks?<\/h3>\n\n\n\n<p>No. It means responsibility for outcomes; many ops tasks should be automated or handled by platform teams.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How does error budget enforcement work?<\/h3>\n\n\n\n<p>Teams agree on SLOs; when error budget is depleted, releases may be restricted until recovery actions complete.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What about security and compliance?<\/h3>\n\n\n\n<p>Policy-as-code and audits must be integrated; sensitive workloads may require hybrid ownership.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to prevent burnout from on-call duties?<\/h3>\n\n\n\n<p>Limit on-call load, provide compensated rotations, enforce quiet hours, and reduce alerts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can large enterprises use this model?<\/h3>\n\n\n\n<p>Yes, with federated ownership, platform teams, and strict guardrails.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to measure ownership success?<\/h3>\n\n\n\n<p>Use MTTR, change failure rate, SLO compliance, and toil percentage.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What if teams ignore SLOs?<\/h3>\n\n\n\n<p>Enforce via governance: escalate to managers, restrict deployments when budgets fail, and prioritize fixes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does serverless remove operational work?<\/h3>\n\n\n\n<p>It reduces infra ops but teams still handle application-level failures, costs, and integration issues.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to start small?<\/h3>\n\n\n\n<p>Pilot with a non-critical service, define SLIs, add instrumentation, and iterate.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How are platform teams expected to operate?<\/h3>\n\n\n\n<p>They provide self-service tools, guardrails, and automation, not approval gatekeeping.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is the role of SREs?<\/h3>\n\n\n\n<p>SREs should advise, build automation, and help scale reliability practices across teams.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to manage cross-team dependencies?<\/h3>\n\n\n\n<p>Define SLAs between services, enforce via SLOs, and maintain shared observability for dependencies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is the minimal observability coverage to be safe?<\/h3>\n\n\n\n<p>Critical services should have metrics, traces for key paths, and structured logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When should you automate runbooks?<\/h3>\n\n\n\n<p>When incidents are repetitive and safe to automate; start with read-only automation and evolve.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do you handle multi-region failure in this model?<\/h3>\n\n\n\n<p>Design for graceful degradation, define failover runbooks, and test region failovers regularly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How often should SLOs be revisited?<\/h3>\n\n\n\n<p>At least quarterly or after major architecture changes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to balance innovation and reliability?<\/h3>\n\n\n\n<p>Use error budgets to gate releases: allow innovation when budgets permit; pause when budgets exhausted.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>You build it you run it ties product delivery and operations, creating faster feedback loops, clearer accountability, and better-aligned incentives. Success depends on observability, automation, SLO discipline, and platform enablement. Teams must avoid common pitfalls like alert fatigue and ownership gaps and invest in tooling and culture.<\/p>\n\n\n\n<p>Next 7 days plan:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Identify one service to pilot YBIYRI and list current owners and telemetry.<\/li>\n<li>Day 2: Define 1\u20132 SLIs and an SLO for the pilot service.<\/li>\n<li>Day 3: Instrument metrics and traces for the critical paths.<\/li>\n<li>Day 4: Create basic on-call rota and a one-page runbook for top incidents.<\/li>\n<li>Day 5: Implement simple alert thresholds and schedule a simulated incident drill.<\/li>\n<li>Day 6: Review results, document postmortem, and assign improvements.<\/li>\n<li>Day 7: Plan platform or automation investments to remove top sources of toil.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 You build it you run it Keyword Cluster (SEO)<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary keywords<\/li>\n<li>you build it you run it<\/li>\n<li>you build it you run it meaning<\/li>\n<li>you build it you run it 2026<\/li>\n<li>you build it you run it SRE<\/li>\n<li>\n<p>you build it you run it ownership<\/p>\n<\/li>\n<li>\n<p>Secondary keywords<\/p>\n<\/li>\n<li>team ownership production<\/li>\n<li>developer on-call best practices<\/li>\n<li>platform engineering self-service<\/li>\n<li>SLO based development<\/li>\n<li>\n<p>observability for teams<\/p>\n<\/li>\n<li>\n<p>Long-tail questions<\/p>\n<\/li>\n<li>what does you build it you run it mean for developers<\/li>\n<li>how to implement you build it you run it in kubernetes<\/li>\n<li>can large companies adopt you build it you run it<\/li>\n<li>how do sres fit into you build it you run it model<\/li>\n<li>what metrics measure you build it you run it success<\/li>\n<li>how to prevent burnout in you build it you run it on-call rotations<\/li>\n<li>what tooling is required for you build it you run it adoption<\/li>\n<li>how to design slos for product teams<\/li>\n<li>how to automate runbooks safely<\/li>\n<li>what are common failure modes in you build it you run it<\/li>\n<li>how to align cost optimization with you build it you run it<\/li>\n<li>\n<p>how to integrate security into you build it you run it<\/p>\n<\/li>\n<li>\n<p>Related terminology<\/p>\n<\/li>\n<li>SLI<\/li>\n<li>SLO<\/li>\n<li>error budget<\/li>\n<li>blameless postmortem<\/li>\n<li>GitOps<\/li>\n<li>OpenTelemetry<\/li>\n<li>Prometheus<\/li>\n<li>Service mesh<\/li>\n<li>runbook automation<\/li>\n<li>feature flags<\/li>\n<li>canary deployment<\/li>\n<li>blue green deployment<\/li>\n<li>incident commander<\/li>\n<li>platform engineering<\/li>\n<li>chaos engineering<\/li>\n<li>observability pipeline<\/li>\n<li>CI\/CD<\/li>\n<li>infrastructure as code<\/li>\n<li>secrets management<\/li>\n<li>policy as code<\/li>\n<li>cost allocation<\/li>\n<li>telemetry enrichment<\/li>\n<li>automated rollback<\/li>\n<li>escalation policy<\/li>\n<li>stability engineering<\/li>\n<li>reliability engineering<\/li>\n<li>fault injection<\/li>\n<li>distributed tracing<\/li>\n<li>metrics aggregation<\/li>\n<li>alert deduplication<\/li>\n<li>incident lifecycle<\/li>\n<li>ownership matrix<\/li>\n<li>toiling metrics<\/li>\n<li>runbook testing<\/li>\n<li>service level report<\/li>\n<li>security scanning in CI<\/li>\n<li>deployment lead time<\/li>\n<li>change failure rate<\/li>\n<li>mean time to restore<\/li>\n<li>observability coverage<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[149],"tags":[],"class_list":["post-1638","post","type-post","status-publish","format-standard","hentry","category-terminology"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.5 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School\" \/>\n<meta property=\"og:description\" content=\"---\" \/>\n<meta property=\"og:url\" content=\"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/\" \/>\n<meta property=\"og:site_name\" content=\"SRE School\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-15T04:48:57+00:00\" \/>\n<meta name=\"author\" content=\"Rajesh Kumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Rajesh Kumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"27 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/\",\"url\":\"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/\",\"name\":\"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School\",\"isPartOf\":{\"@id\":\"https:\/\/sreschool.com\/blog\/#website\"},\"datePublished\":\"2026-02-15T04:48:57+00:00\",\"author\":{\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201\"},\"breadcrumb\":{\"@id\":\"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/#breadcrumb\"},\"inLanguage\":\"en\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/sreschool.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/sreschool.com\/blog\/#website\",\"url\":\"https:\/\/sreschool.com\/blog\/\",\"name\":\"SRESchool\",\"description\":\"Master SRE. Build Resilient Systems. Lead the Future of Reliability\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/sreschool.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201\",\"name\":\"Rajesh Kumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en\",\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g\",\"caption\":\"Rajesh Kumar\"},\"sameAs\":[\"http:\/\/sreschool.com\/blog\"],\"url\":\"https:\/\/sreschool.com\/blog\/author\/admin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/","og_locale":"en_US","og_type":"article","og_title":"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School","og_description":"---","og_url":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/","og_site_name":"SRE School","article_published_time":"2026-02-15T04:48:57+00:00","author":"Rajesh Kumar","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Rajesh Kumar","Est. reading time":"27 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/","url":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/","name":"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - SRE School","isPartOf":{"@id":"https:\/\/sreschool.com\/blog\/#website"},"datePublished":"2026-02-15T04:48:57+00:00","author":{"@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201"},"breadcrumb":{"@id":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/#breadcrumb"},"inLanguage":"en","potentialAction":[{"@type":"ReadAction","target":["https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/sreschool.com\/blog\/you-build-it-you-run-it\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/sreschool.com\/blog\/"},{"@type":"ListItem","position":2,"name":"What is You build it you run it? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"}]},{"@type":"WebSite","@id":"https:\/\/sreschool.com\/blog\/#website","url":"https:\/\/sreschool.com\/blog\/","name":"SRESchool","description":"Master SRE. Build Resilient Systems. Lead the Future of Reliability","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/sreschool.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en"},{"@type":"Person","@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201","name":"Rajesh Kumar","image":{"@type":"ImageObject","inLanguage":"en","@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g","caption":"Rajesh Kumar"},"sameAs":["http:\/\/sreschool.com\/blog"],"url":"https:\/\/sreschool.com\/blog\/author\/admin\/"}]}},"_links":{"self":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts\/1638","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/comments?post=1638"}],"version-history":[{"count":0,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts\/1638\/revisions"}],"wp:attachment":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/media?parent=1638"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/categories?post=1638"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/tags?post=1638"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}