# Sridhar Rajarao Sridhar Rajarao's writing -- notes, essays, and longer-form posts. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A working incident response model for GPU clouds DevFeed: [A working incident response model for GPU clouds]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-09-12T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [incident](), [Incident response](), [GPU](), [Monitoring](), [Tooling]() Tags: [communication](), [debugging](), [gpu](), [gpu-cloud](), [grafana](), [incident](), [incident-management](), [incident-response](), [jira](), [management](), [on-call](), [operations](), [ownership](), [pagerduty](), [review](), [slack](), [sre]() ### AI overview This article presents an incident response model for GPU clouds and other customer-facing infrastructure businesses. It emphasizes preparation, named ownership, meaningful alert paths, incident command, separation of technical work from customer communication, and post-incident learning. It argues that tools such as PagerDuty, Jira, Grafana, and Slack are useful only within a clear operating model. ### Source excerpt The tools matter, but they only work when they sit inside a clear operating model: ownership, signal, command, communication, and learning. ## Every service needs an owner DevFeed: [Every service needs an owner]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-09-12T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [systems](), [incident]() Tags: [catalog](), [customer](), [incident](), [on-call](), [ownership](), [platform-engineering](), [production](), [reliability](), [service](), [service-catalog](), [sre](), [startups](), [team]() ### AI overview The article argues that growing organizations need a focused service catalog to make production ownership visible. It recommends recording each service's customer outcome, owning team, current on-call contact, deployment path, health dashboard, runbook, and dependencies, and maintaining those records as part of engineering work. ### Source excerpt A useful service catalog is not an inventory project. It is a public record of who owns a customer outcome when the system is healthy and when it fails. ## How we shipped 15 Tbps for OpenAI in 90 days (Session 2 of 3) DevFeed: [How we shipped 15 Tbps for OpenAI in 90 days (Session 2 of 3)]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-09-12T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [OpenAI](), [Network](), [GPU](), [Server](), [Cache](), [API](), [Oracle Database]() Tags: [api](), [architecture](), [build](), [cache](), [capacity](), [database](), [debugging](), [execution](), [gateway](), [gpu](), [network](), [object](), [openai](), [performance](), [platform-engineering](), [server](), [servers](), [sre](), [storage](), [testing](), [warp]() ### AI overview The second session describes turning an architecture for OpenAI's 15 Tbps system into a delivery plan. It covers coordinated capacity planning across network, gateway, server, storage, and database teams; caching object names through the Inventory API; delivery tracking; and performance validation. Early WARP testing found packet drops caused by an unsuitable MTU of 1500, which was changed to 9100. ### Source excerpt Architecture was only the first week. Session 2 is about the build: capacity, execution discipline, and the first signs that performance would be the real test. ## Why a DevOps Portal Cannot Replace an Operating Model DevFeed: [Why a DevOps Portal Cannot Replace an Operating Model]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-09-11T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [DevOps](), [incident](), [Deployment]() Tags: [deploy](), [deployment](), [devops](), [incident](), [operations](), [platform-engineering](), [production](), [sre](), [startups]() ### AI overview A DevOps portal can reduce operational friction, but it cannot create service ownership, incident discipline, or an operating model. The article recommends defining ownership, health signals, runbooks, escalation paths, and rollback practices before building a small, practical portal. ### Source excerpt A portal can remove friction. It cannot create service ownership, incident discipline, or a working operating model that does not yet exist. ## How Object Storage Performance Affects GPU Training Workloads DevFeed: [How Object Storage Performance Affects GPU Training Workloads]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-30T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [GPU](), [cloud-infrastructure](), [Caching](), [Disk image]() Tags: [ai](), [aws](), [cache](), [compute](), [gpu](), [nvme](), [object-storage](), [performance](), [storage](), [training-data]() ### AI overview This article explains how object-storage latency, network transfers, many small files, and concurrent requests can leave GPUs idle during AI training. It recommends sharding small samples into larger files, reusing connections, and caching data near the GPU; it also notes AWS's suggested shard range of roughly 100 MB to 1 GB for many training workloads. ### Source excerpt The GPU does not care that object storage is durable and scalable. It cares whether the next batch of data arrives before it goes idle. ## AI data centers: the five hard problems money cannot buy away DevFeed: [AI data centers: the five hard problems money cannot buy away]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-30T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [Artificial Intelligence](), [data centers](), [Hardware](), [systems]() Tags: [ai](), [capacity](), [compute](), [data-centers](), [datacenters](), [hardware](), [heat](), [infrastructure](), [power](), [reliability]() ### AI overview The article argues that AI data-center expansion is constrained by the simultaneous need to secure power, grid connections, cooling and water strategies, equipment, skilled workers, permits, and productive compute. It discusses five industry challenges, with the supplied text covering power constraints and the physical and water implications of liquid cooling. ### Source excerpt The AI buildout is not mainly a real-estate problem. It is a race to integrate power, cooling, equipment, permits, and useful compute at the same time. ## Why Senior Leaders Should Attend Post-Incident Reviews for Major Cloud Incidents DevFeed: [Why Senior Leaders Should Attend Post-Incident Reviews for Major Cloud Incidents]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-29T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [incident](), [Cloud](), [control-plane](), [Deployment]() Tags: [cloud](), [control-plane](), [customers](), [deploy](), [incident](), [incident-management](), [leadership](), [major](), [operations](), [post](), [postmortems](), [reliability](), [review](), [service]() ### AI overview The article argues that senior leaders should attend Post Incident Reviews for major cloud incidents because failures can affect many customers and teams. Leadership helps approve cross-team changes, resolve trade-offs, and ensure corrective actions are completed. ### Source excerpt For major incidents, a Post Incident Review is not an operations meeting. It is where leaders remove the blockers that keep the service from becoming safer. ## Why GitHub feels less reliable lately DevFeed: [Why GitHub feels less reliable lately]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-23T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [GitHub](), [incident](), [migration](), [systems](), [Azure](), [GitHub Actions](), [pull-requests]() Tags: [autoscaling](), [capacity](), [concurrency](), [data-centers](), [deployment](), [github](), [incident](), [incident-management](), [istio](), [reliability](), [request](), [resilience](), [sre](), [transformation]() ### AI overview The article argues that GitHub's recent reliability problems reflect the difficult middle of a major infrastructure transformation. It connects incidents to migration complexity, unsafe automation, configuration mistakes, capacity and concurrency weaknesses, database migration errors, and autoscaling problems. ### Source excerpt GitHub is not having one outage problem. Its recent incident reports show the difficult middle of a platform transformation. ## Using observability to verify TLS certificate rotation in production DevFeed: [Using observability to verify TLS certificate rotation in production]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-13T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [TLS (Transport Layer Security)](), [observability](), [TLS handshake](), [Automation](), [nginx](), [Kubernetes]() Tags: [automation](), [nginx](), [observability](), [reliability](), [sre](), [tls](), [tls-handshake]() ### AI overview The article explains that automating certificate renewal does not prove that production endpoints serve the new certificate. It recommends externally probing customer-facing endpoints and measuring certificate details and real TLS handshakes across proxies, regions, ingress controllers, CDNs, gateways, and other endpoints. ### Source excerpt Automation renews a certificate. Observability proves every endpoint is serving it and customers can complete a TLS handshake. ## Cloud provider postmortems: volume vs depth DevFeed: [Cloud provider postmortems: volume vs depth]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-05T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [Cloud](), [incident](), [SRE](), [site-reliability-engineering](), [engineering-culture]() Tags: [2017](), [2025](), [2026](), [aws](), [azure](), [cloud](), [dynamodb](), [engineering-culture](), [gcp](), [incident](), [incident-management](), [postmortems](), [s3](), [sre](), [transparency](), [writeup]() ### AI overview The article compares public postmortem practices among Google Cloud, Azure, and AWS. It argues that Google Cloud emphasizes high volume and speed, Azure emphasizes detailed transparency and customer accountability, and AWS publishes fewer writeups with greater depth and industry influence. ### Source excerpt GCP publishes 100+ postmortems a year. AWS publishes almost none. Azure has become the transparency leader. What each posture reveals about engineering culture, and what SREs should steal from all three. ## Jira Service Management Projects: Consolidation Versus Splitting at Scale DevFeed: [Jira Service Management Projects: Consolidation Versus Splitting at Scale]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-07-28T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [jira](), [atlassian](), [Architecture & Design](), [Security]() Tags: [atlassian](), [compliance](), [coupling](), [deployments](), [incident-management](), [jira](), [jsm](), [security](), [sre](), [tooling]() ### AI overview The article compares Atlassian's recommendation to consolidate Jira Service Management work into fewer projects with the multi-project approach used by hyperscalers. It argues that consolidation suits smaller organizations, while separate projects can provide stronger security boundaries, limit configuration blast radius, and preserve team autonomy at scale. ### Source excerpt Atlassian recommends consolidation. Hyperscalers use many. Both are right for different problems. Five real reasons to split, and what works at each scale. ## Direction, then review: my pattern for using AI at work DevFeed: [Direction, then review: my pattern for using AI at work]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-07-27T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [Artificial Intelligence](), [Claude](), [ChatGPT](), [Automation](), [GitHub](), [Notion](), [Slack](), [API](), [Markdown](), [Grafana]() Tags: [ai](), [api](), [automation](), [chatgpt](), [claude](), [developers](), [github](), [leadership](), [markdown](), [productivity](), [sre](), [workflows]() ### AI overview The author describes using Claude and ChatGPT as junior contributors whose output improves with clear direction and review. Three examples cover synchronizing GitHub Markdown runbooks with Notion, aggregating operational data into a Slack Canvas published to Notion, and refining an audit report for executives. ### Source excerpt How I use Claude and ChatGPT like junior developers on my team. Three concrete workflows from this month, and a five-point checklist for reviewing AI output. ## ITIL vs SRE: why the big clouds went their own way DevFeed: [ITIL vs SRE: why the big clouds went their own way]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-07-26T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [SRE](), [site-reliability-engineering](), [Development](), [Terraform](), [pulumi](), [Availability](), [feature flags](), [incident]() Tags: [automated](), [aws](), [azure](), [cloud](), [feature-flags](), [gcp](), [human-review](), [hyperscaler](), [incident](), [incident-management](), [infrastructure-as-code](), [itil](), [on-call](), [postmortems](), [pulumi](), [release](), [reliability](), [service-catalog](), [sre](), [terraform]() ### AI overview This opinion article compares ITIL practices with SRE operations at hyperscaler scale. It argues that human change boards, single production instances, developer-to-operations handoffs, documentation-first configuration management, and weekly release windows do not fit environments serving millions of external customers. It describes automated approvals, gradual deployments, service-team ownership, infrastructure as code, continuous release, error budgets, SLOs, and blameless postmortems as alternatives. ### Source excerpt The big clouds don't run ITIL. Five assumptions ITIL makes that break at hyperscaler scale, and what AWS, Azure, GCP, and OCI use instead. ## Rewiring incident response, with AI in the loop DevFeed: [Rewiring incident response, with AI in the loop]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-07-25T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [incident](), [Incident response](), [Slack](), [Artificial Intelligence](), [Grafana](), [jira]() Tags: [ai](), [engineering](), [grafana](), [incident](), [incident-management](), [incident-response](), [jira](), [operations](), [slack](), [sre](), [startups]() ### AI overview An account of restructuring incident response at a growing company, moving from a single Slack thread to a durable incident stack. The article describes gaps in paging, Grafana alerts, and Jira visibility, and explains how AI helped draft SLAs, build dashboards, and write boilerplate while human judgment remained central. ### Source excerpt Six weeks in at a new company, rewiring incident response from one Slack thread to a working stack, with AI compressing the parts that used to take a quarter. ## How we shipped 15 Tbps for OpenAI in 90 days (Session 1 of 3) DevFeed: [How we shipped 15 Tbps for OpenAI in 90 days (Session 1 of 3)]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-06-08T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [cloud-infrastructure](), [Network architectures](), [Network Configuration](), [OpenAI]() Tags: [architecture](), [gpu](), [network](), [network-configuration](), [object-storage](), [openai](), [platform-engineering](), [production](), [region](), [scale](), [service](), [sre](), [storage](), [teams]() ### AI overview Session 1 describes how a team closed the architecture for OpenAI's second Object Storage instance in the same physical region as its primary. The production system was designed for 15 Tbps of GPU-fleet traffic and a three-month delivery timeline, with major architecture decisions completed in one week. ### Source excerpt OpenAI wanted a second Object Storage instance, in customer-facing production, at 15 Tbps, in three months. Session 1 covers the first week: closing the architecture. ## Storage at scale: what I actually watched DevFeed: [Storage at scale: what I actually watched]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-05-28T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [dashboards](), [site-reliability-engineering](), [Latency](), [Availability](), [control-plane](), [Databases](), [Replication]() Tags: [availability](), [control-plane](), [database](), [latency](), [metrics](), [reliability](), [replication](), [service](), [sre](), [storage]() ### AI overview An SRE practitioner describes seven metrics for judging the health of a large-scale storage service, covering availability, durability, latency, synthetic canaries, hotspots, IOPS, and metadata-database behavior. ### Source excerpt For eight years I ran SRE for a storage system measured in exabytes. The dashboard I checked every morning shrank to seven numbers. Here they are. ## Five rules for running an incident DevFeed: [Five rules for running an incident]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-05-27T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [incident](), [Learning]() Tags: [customer-experience](), [incident](), [incident-management](), [on-call](), [outage](), [postmortem](), [production](), [recovery](), [reliability](), [root-cause-analysis](), [rules](), [signal](), [speed](), [sre](), [team]() ### AI overview This opinion article presents five rules for handling production incidents: assess severity by customer impact, use an Incident Commander, mitigate before investigating root cause, maintain regular communication, and use postmortems for learning and accountable follow-up. ### Source excerpt The difference between a 10-minute incident and a 3-hour outage is rarely technical. Five things I wish every on-call team locked in before their first big page. ## Three 5xx and one 4xx: the codes I actually care about DevFeed: [Three 5xx and one 4xx: the codes I actually care about]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-05-26T00:00:00Z Content type: tutorial Language: en Sources: [Sridhar Rajarao]() Topics: [HTTP](), [site-reliability-engineering](), [API](), [nginx](), [servers]() Tags: [api](), [http](), [load-balancer](), [nginx](), [production](), [reliability](), [scale](), [sre]() ### AI overview An SRE-oriented guide to interpreting HTTP status codes 500, 502, 503, and 429 in production. It connects each code with likely causes and recommended operational responses, including checking logs, investigating backend failures, load shedding, and client backoff. ### Source excerpt How I read 500, 502, 503, and 429 in production at scale, and what each one is really telling you. ## Operational Readiness: The Review That Catches Problems DevFeed: [Operational Readiness: The Review That Catches Problems]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-05-25T00:00:00Z Content type: tutorial Language: en Sources: [Sridhar Rajarao]() Topics: [Development](), [incident](), [Artificial Intelligence]() Tags: [on-call](), [operational](), [ops](), [problems](), [production](), [reliability](), [sre](), [validation](), [verification]() ### AI overview An operational readiness review is useful only when checklist items are backed by evidence and verified before a service launches. The article explains common failure modes, recommends attaching artifacts to each item, and describes AI applications for evidence gathering, gap detection, and summary drafting while keeping the final readiness decision with human reviewers. ### Source excerpt A short, verifiable checklist for production launches. What to ask, why ORRs become theater, and where AI helps. ## Service Levels: SLI, SLO, SLA DevFeed: [Service Levels: SLI, SLO, SLA]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-05-24T00:00:00Z Content type: article Language: en Sources: [Sridhar Rajarao]() Topics: [Availability](), [telemetry](), [Artificial Intelligence]() Tags: [ai](), [availability](), [rca](), [reliability](), [service](), [slo](), [sre](), [telemetry]() ### AI overview The article distinguishes SLI, SLO, and SLA as a hierarchy: measured reality, an internal target, and a customer contract. It explains how the gap between SLO and SLA creates an error budget and describes AI uses such as detecting SLO erosion, correlating telemetry, and drafting root-cause analyses while leaving operational judgment to engineers. ### Source excerpt What SLI, SLO, and SLA actually mean, why the order matters, and where AI helps.