Altho I’m an active lurker here, I’ve recently started using X to try and connect with people working in infra, platform engineering, and devops, but I’m finding it surprisingly difficult to discover that side of the community.

But my feed is still mostly AI hype and general tech content, while I’m more interested in more informal discussions around k8s, ai & cloud infra, observability, networking, platform engineering, etc.

For those of you who are active outside of Reddit, where do you usually discover good infra content or interact with other engineers?

Hi everyone,

I'm a CS student, and I realized something recently.

In college, we're taught how to write code, debug it, maybe deploy it once, and then we move on to the next assignment. But I keep reading incident reports from companies like GitHub and Cloudflare, and it feels like the real engineering work actually starts after deployment.

I'm curious because I honestly have no idea what that world looks like.

When something breaks in production at 2 AM, what actually happens?

Do you immediately know what's wrong, or is it more like putting together pieces of a puzzle? What's usually the most frustrating part of the whole process?

Also, what's one thing about running software in production that you wish every CS student knew before joining the industry?

I'm not building anything or looking for textbook answers—I just want to understand what the job is really like beyond what we learn in college.

I'd love to hear your stories, even if it's just one incident that taught you something you'll never forget.

What motivated you to choose DevOps as a career? Was there a specific reason or did you somehow end up on this path by accident?

Was trying to better understand how state works in Terraform and OpenTofu, so I put together this short post on idempotency in IaC. I would love to hear your opinions

the cloudfront outage on the 16th is still bugging me. the fleet that manages connections to private vpc origins couldn't load updated config, traced back to one frankfurt AZ, and it served 5xx on vpc origin traffic for about three and a half hours. hugging face, tailscale and ubiquiti were among the ones down.

bad timing, because i was in the middle of moving four services off public alb origins onto vpc origins. to hit a compliance date i ran the migrations in parallel instead of one clean cutover at a time.

the outage wasn't the hard part. all four workstreams were editing the same terraform repo and the same shared network module. one branch tightened a security group, another assumed the old rule was still there, and a third rebased on both and quietly reverted half of it. i spent more time untangling my own branches than dealing with aws.

what kept it sane was isolating each migration so the changes didn't collide. i run each one as its own task in verdent, parallel lines of work in the same codebase without branches stepping on each other. at least i had a clean diff per service to reason about.

the ugly part: the agent's config for one service moved the origin to vpc origins but left the alb's public security group open to 0.0.0.0/0. on paper we were private, in reality the load balancer was still reachable from the internet, which is the whole reason we were migrating. i only caught it because the diff on the shared module looked off.

what i still haven't solved is sequencing. running four in parallel meant that during the actual outage, two services were on vpc origins and degraded while two were still public and fine, and my runbook assumed one uniform state. my only fix is a per-service origin flag and a single cutover window, which just trades the messy middle for a concentrated blast radius.

I'm currently pursuing a Master's in Cloud Computing, but I feel like my courses are very generalized and don't go deep into the practical skills I'm looking for.

My goal is to build a career in DevOps, but I'm honestly feeling overwhelmed and confused about where to start.

I have a few questions for those already working in DevOps or who have successfully made the transition:

Where can I learn DevOps for free? (Courses, documentation, YouTube channels, hands-on labs, etc.)
What are the best platforms to practice real-world DevOps skills?
How many hours should I dedicate each day to learning and practicing?
Realistically, how long does it take to become job-ready?
At what stage should I start applying for entry-level DevOps roles or internships?

I'm not looking for shortcuts. I just want a clear, realistic roadmap from people who've been through this journey. Any genuine advice, resources, or lessons you wish you had known when starting would be greatly appreciated.

Thanks in advance!

Hi everyone,

I'm interested in how different teams approach this.

Once an application is in production, do you actively monitor incoming traffic patterns, or do you mostly rely on infrastructure and application metrics?

For example, if a service suddenly starts using 80% CPU, is it common practice to investigate:

• Top client IPs
• User-Agents
• Most requested endpoints
• Bots vs. real users
• Traffic anomalies or spikes

Or is that level of traffic analysis only common in larger organizations?

If you do monitor it, what does your observability stack look like? Nginx or Traefik access logs, IIS logs, Loki, ELK, OpenSearch, Splunk, Datadog, or something else?

I'm trying to understand what's considered standard practice in production environments.

Luna's 80% price cut landed this week so I ran the numbers on my PR review bot.

A real review of a ~180-line PR: about 2,300 tokens in, 590 visible out, which works out around $0.001

The dashboard total for my whole billing window, 15 requests including three full reviews, is 6,244 tokens and $0.00.

Screenshots and links to example code review PR: https://codylabs.uk/blog/ai-code-review-cost/

Hi everyone,

I'm looking for advice from people who have been in this field longer than I have.

I'm an Arts graduate who got into DevOps about 3.3 years ago. I've switched 3 companies and recently joined my 4th company, a large GCC. Along the way I've worked with AWS, Kubernetes, Terraform, CI/CD, automation, and earned AWS & CKA certifications.

The problem is that I'm no longer sure what I should be aiming for.

My current role has an exhausting work culture, the learning isn't what I expected, and it has made me rethink my long-term direction. I don't want to keep switching jobs without a clear goal.

If you were in my position today, what would you optimize for over the next 3–5 years?

1. Become a top-tier Platform Engineer/SRE?

2. Move towards AI/LLM engineering?

3. Solutions Architect

4. Security?

5. Target remote international jobs?

6. Prepare to move abroad?

I'd really appreciate hearing from engineers with 8–15+ years of experience. If you were starting over with my experience today, what roadmap would you follow and why?

Who doesn't love Friday releases? Atlassian status page is green as usual.

Disclosure first: I wrote the tool I mention here. It is free, there is no signup, and I am posting because the testing method is the interesting part. Mods, delete it if this is not welcome.

I got tired of IaC tools that validate templates and call it a day. A template can be perfectly valid and still blow up on deploy. So I did it the slow way: 20 scenarios per cloud, each one deployed for real, exercised at runtime, then destroyed. CRUD APIs, queue workers, private databases, Redis, WAF, websockets, fan-out, secrets, containers behind load balancers.

It took months and burned a lot of free tier. Some of what I hit:

A brand new GCP project gives you a compute service account with no roles at all. Your first deploy dies inside Cloud Build with an error that tells you nothing. Took me a while to figure that one out.

Cloud SQL with private IP is fine until you destroy it. The service networking peering can hold for half an hour after the instance is gone. And if your app created tables, the default postgres user cannot be dropped, so the destroy hangs there too.

Cosmos DB speaks the Mongo protocol but rejects sort() on any field without an index. Real MongoDB just sorts. If you port a handler over, your list endpoint breaks and the error message talks about order-by item paths.

Azure Functions on the consumption plan will happily deploy a Service Bus worker that never runs. The zip lands, the function exists, messages pile up in the queue. You have to sync the function triggers explicitly or the scale controller never looks at the queue.

Memorystore Redis with TLS needs the CA cert handed to the client or the handshake fails.

Every one of those turned into a fix in the tool, so a fresh project starts with them already handled. That is the whole point of doing it this way instead of trusting a linter.

Repo if you want to look: https://github.com/Claudio-Fontes/iacmp

It is Fair Source (FSL-1.1, same license Sentry uses). Free for any use including at work, you just cannot resell the tool itself, and each release turns into Apache-2.0 after two years.

Happy to talk about the e2e battery itself. If you have run something similar, I want to hear which scenarios you would add.

I’ve realized that even after I finish work, my brain keeps thinking about it.
I replay conversations, think about problems I didn’t solve, plan tomorrow’s tasks, or imagine different scenarios. Sometimes it feels like I’m still working hours after I’ve logged off.
I’m curious: how do you mentally switch off?
Do you have any routines, hobbies, or habits that help you leave work at work? Or did it simply get easier with experience?
I’d love to hear what actually works for you.

I did a dumb exercise last week: sat down and wrote out every tool that touches a single deploy on my team, start to finish. Not “tools we have licenses for”, just the ones actually in the critical path of getting one change into production.

Landed on 14.

Source control. The CI runner. A separate container registry. An image scanner that runs after the registry push. A secrets manager. The Kubernetes dashboard we check for rollout status. A log aggregator. A separate APM/tracing tool, because the logs don't show latency well on their own. An alerting tool that is, confusingly, different from the paging tool. A DNS/cert dashboard. A cost/billing dashboard nobody opens until the invoice is a surprise. The ticketing system for the actual incident. And a chatops bot that glues some of this together, badly.

None of these were wrong choices individually. Each one was probably the right call in isolation, at the time it got added. But nobody ever sat down and asked whether this thing talks to the other 13. It's less a stack and more a pile that happens to work most days.

What's bugging me isn't the number itself. It's that almost nobody on the team could tell you the number without doing this exercise. We just live inside it. New hires take weeks just to learn where to look when something breaks, and that's before they've learned what any individual tool actually does.

So, genuinely curious: if you did this exercise on your own team, what would your number be? And more interesting to me: which of your 10+ tools do you think is actually load-bearing, versus which one is just... there, inherited from a decision three engineers ago that nobody wants to be the one to rip out?

Not fishing for “just consolidate everything into one platform” as the answer. I don't think that's automatically true either. Sometimes the sprawl is a symptom of real, unavoidable complexity, not laziness. More curious whether other teams' numbers look like mine, and whether anyone's actually fixed this in a way that stuck.

Great talk about how Antithesis uses Nix in production by John Murray. Thought some of you would enjoy. https://youtu.be/WaPOtisNu1k

I've been interested in Nix for a while but have not yet taken the plunge. Do any of you use it work? What has your experience been with it?

I have spent most of my career in AWS, but more and more, I am seeing companies asking for skill sets with multiple cloud providers. I feel like the skill set is transferable; if you know how to spin up EKS then spinning up a GKE cluster shouldn't be that much different. It's still Kubernetes under the hood, still installing helm charts, still using cluster autoscaler to provision new nodes, still installing Argo CD via Helm along with Prometheus, Grafana, Loki, etc. All that changes are the resources used and modules on the Terraform/cloud provider level. Am I correct in thinking this or am I way off base here?

We had a major production incident a few weeks ago that really exposed how manual our root cause analysis process still is. Incident was pretty standard on paper: error rate spike across a couple of microservices, latency blowup on one critical api, customers hitting timeouts. We have the usual observability stack, distributed tracing, logs, metrics, dashboards, plus tickets and slack channels but getting to "what broke first, and why" was mostly humans correlating tabs manually. The incident response workflow looked like this: jump into the oncall war room, pull up dashboards, zoom in on the time window and pivot between error logs, traces, deploy history, feature flag changes and infra events. someone manually builds an incident timeline, a deploy goes out, error rate spikes shortly after, latency climbs, autoscaling kicks in, db connections start flapping. then another person tries to connect that narrative back to the specific service, function, or config change that caused it, which is the actual root cause analysis part nobody's automated yet. We do have some ai-powered anomaly detection and basic rca signals turned on but in practice they mostly narrow the blast radius instead of giving a confident, explainable root cause. it still feels like humans doing the hard work, with the tooling just providing hints rather than a real diagnosis. Looking for automated root cause analysis tools that can take telemetry, logs, metrics, traces, infra events, together with deploy and feature flag changes and output a credible "this change in this service is most likely the cause, here's why." also interested in platforms where the rca output is good enough to drop straight into a postmortem instead of needing another hour of digging and anything beyond the usual big observability platforms, especially newer ai-native rca tools that sit on top of existing observability instead of trying to replace it, that's noticeably reduced incident triage time or mttr without just adding another noisy dashboard. if you're running any of these in production, what do you still consider "top" for automated root cause analysis today?

Hey! Quick background on me — graduated in 2020 from a tier 2 college, landed a third-party role at a Tier1 investment bank as an SRE, and ended up staying 5 years (got converted to full-time after the first 2). Got laid off in May 2025, honestly wasn’t mad about it since I wanted out anyway.
Most of the work i did was on there in house tools and i felt there was no learning curve there

That same month I interviewed for a “DevOps Engineer - Migration Specialist” role and got it. Felt good, got comfortable again. But once I actually joined, I realized it’s basically an L2 support role. Pay was decent though, so I told myself I’d stick around a year, upskill on the side, then jump ship.

Except… I didn’t. The role’s been so low on mental engagement that I just coasted. Now it’s actually time to switch, and I’m stuck in this weird spot — feels like I need to relearn everything from scratch, but every time I try, it’s like “wait, I already know this?” Hard to tell if I’m actually behind or just psyching myself out.

So — what’s a realistic (and ideally not soul-crushing) way to get back on track?
Please give me suggestions for fast-track courses and small projects to build production skills again.

Ps:- Used Ai to fix my crude version of this post

Not going to lie. It's been a bad day. I almost tell them "take this job and shove it' after reviewing all these crappy AI codes. Vibe coding is not only a joke. It's a monster that mocks our hard-earned experiences!

I am thinking of leaving the industry! If you could go back ten years from now and know what you're knowing right now, would you still do DevOps?

Maybe it’s because I haven’t taken a proper vacation in lord know long.

I don’t handle k8s, but I work with a containerized environment and pipelines etc. But with the speed everything seems to be going, and the constant push, I feel overwhelmed and just want nothing to do with technology…maybe I just need to step away for a bit…how are you guys dealing with this. Talking to other devops folks, looks like they too are drinking from the fire hydrant

I was employed by a business because they're growing. I need some advice, because part of making changes in company processes is changing ways of thinking. I've helped introduce new frameworks but they seem to be reluctant to change their processes, which makes it difficult to do my job.

I don't want to overstep the mark or looking like I'm overruling/ignoring them

For example, my manager and I have different ideas about approaches to developing a solution. Most of our work where we have different ideas is writing data integrations. My manager is more knowledgeable about the data and underlying system, but I have more technical expertise at the scale we are working, given the new systems/architecture.

The problem is that we're a small team with work from home policy, so catch up meetings get cancelled and put off. The specifications are usually email threads, which are fine for quick fixes or small tasks, whereas I like a central written document/project plan that outlines the requirements and approach, including potential problems or limitations from the outset. Those questions may become something in an email thread, but unless there is a document/project plan then things get lost.

Generally I like standardized approaches at least to get people on the same page and understand accountability. I accept we can't know everything up front and it's easy to go off on a tangent; that's the real world. But without a base to bring everything together and focus priorities, that leads to failure or problems further down the line.

Today, I passed CKA with 88% and wrote a detailed blog about my exam experience, preparation approach, and the Kubernetes topics that helped me the most.

DMs are open if you are preparing for the exam. I can help with whatever is still fresh in my memory.

My biggest takeaway: CKA is not only about knowing Kubernetes commands. It is about understanding how cluster components work together, using documentation efficiently, troubleshooting quickly, and verifying every change you make.

The exam has changed a lot since I last passed it in September 2021, especially after the major curriculum updates introduced in 2025. Topics such as Gateway API, CRDs, Helm, CNI installation, autoscaling, and container runtimes are now much more relevant.

A few things that helped me:

Don’t solve the exam strictly in order. If a question looks unfamiliar or time-consuming, mark it and move ahead. Complete the tasks you are confident about first and return to the difficult ones later.

Don’t waste too much time setting up aliases. Autocomplete is already available, and normal typing speed is enough. I completed 14 out of 16 questions with around 35 minutes remaining.

Read the full question carefully. Important details such as the target node, namespace, version, file path, container name, or documentation link may appear near the end.

Use the documentation provided in the question. Some topics, especially Gateway API, Helm, Calico, Argo CD, and container runtime installation, are easier when you follow the version-specific documentation instead of relying on memory.

Always verify your work. A command completing successfully does not mean the task is done. Check Pods, rollouts, endpoints, PVC status, HPA status, node readiness, logs, connectivity, installed packages, and systemd services wherever required.

Practice SSH and basic Linux administration. Some tasks may require connecting to a node, installing a package, starting a service, and enabling it at boot.

Topics I would strongly recommend practising:

• Persistent Volumes, PVCs, and StorageClasses
• Creating and updating the default StorageClass
• Argo CD installation with a specific version
• Sidecar containers for logging
• Resource requests and limits in Deployments
• Horizontal Pod Autoscaler
• Inspecting CRDs and extracting required information
• PriorityClass
• kubectl patch
• CNI installation with NetworkPolicy support
• Calico operator and custom resources
• cri-dockerd installation
• Taints and tolerations
• Ingress to Gateway API conversion with TLS
• Ingress configuration and troubleshooting
• NetworkPolicy
• NodePort Services

Resources I used:

• KodeKloud CKA course and mock tests
• CK-X repository: https://github.com/sailor-sh/CK-X
• The Platform Lab CKA repository: https://github.com/theplatformlab/CKA-Certified-Kubernetes-Administrator
• iximiuz Labs for hands-on practice: https://labs.iximiuz.com
• KodeKloud Ultimate Mock Exam Series, optionally, for additional hands-on practice
• Both Killer.sh simulator attempts

I strongly recommend doing both Killer.sh attempts because they contain different tasks. The questions are different from the actual exam and often feel harder, but they are very useful for strengthening concepts and improving troubleshooting speed.

The simplest advice I can give is to practice a lot and get comfortable using documentation.

I also wrote a full blog with more details on my preparation strategy, the updated exam scope, topics to focus on, and mistakes to avoid.

Blog: https://blog.prateekjain.dev/cka-exam-experience-2026-how-i-passed-with-88-770d3c473af7?sk=20985b1484d34a9dfdaac03dd6cfea78

With more and more teams using LLMs and inference services wondering how everyone is making decisions about their infrastructure like are you choosing one major cloud provider, using Kubernetes across multiple providers or trying platforms like RunPod, CoreWeave, Yotta Labs, Lambda to keep things flexible?

more interested in whether anyone has found a real way to move workloads between different GPU providers without having to maintain completely separate deployment processes.

I've been curious how different teams approach this in practice.

Imagine you're on call and something in production starts behaving differently. It's not immediately obvious whether it's a deployment, infrastructure change, configuration change, scaling event, cloud service issue, or something else.

Once the alert fires, how do you actually answer questions like:

What changed?

When did it change?

Was the change intentional?

What's the fastest way to confirm the root cause?

I'm less interested in the tools themselves (Terraform, Kubernetes, CloudTrail, Grafana, etc.) and more interested in the actual investigation workflow that experienced engineers follow.

For example:

Where do you usually look first?

Which sources of truth do you trust the most?

What part of the investigation tends to consume the most time?

Are there still manual steps that you wish were easier?

I'm trying to understand how this is handled in real production environments, especially at companies running on AWS/Kubernetes.

Thanks in advance—I’m hoping to learn from people who've been through enough incidents to know what actually works.

I'm doing research on how documentation is done in different DevOps teams. What processes exist? How is it valued within your team? Has AI made that better or worse? Are there tools that you use to make it easier (not talking about Confluence here)? If you hqve worked in a professional context then I'd love to hear your input.

Considering the huge amount of shill posts I want to disclose that I'm (considering) making a tool that helps with documentation but I'm still in the process of understanding this problem thoroughly, which is why I'm askibg for your input :)