Git to Know You
Git to Know You: SRE Tools
Published June 10, 2025 · Updated August 8, 2026
This list changed. That is kind of the point.
When I first wrote this post in 2025, I started with a list of ten tools I thought were worth learning if you were getting into Site Reliability Engineering. It was useful as a starting point, but a fixed top-ten list is not how this work actually behaves.
Tools change. Platforms absorb features from one another. AI moved into the engineering workflow faster than most of us expected. Cloud-native patterns kept maturing. And the more I wrote, the more obvious it became that the useful part of this series was not the ranking.
It was the progression.
Git to Know You became a beginner-friendly series about the tools and operating ideas that make modern technical teams more reliable, repeatable, and easier to work in. I still care about the products, but I care more about what problem each one teaches you to solve.
The first series is now complete at ten articles. If you are new to SRE, DevOps, cloud operations, or technical delivery, you do not need to know everything before you start. The goal is still to build the mental model one piece at a time.
The complete series
#1. Rundeck — Reduce repetitive work
Rundeck is where I started because toil is one of the fastest ways to burn out a technical team. The article focuses on turning scripts into controlled self-service workflows so routine work does not always require an engineer in the middle.
#2. New Relic — See what is actually happening
New Relic moves from automation into observability. Before you can improve reliability, you need evidence. Metrics, logs, traces, dashboards, and useful alerts help replace guessing with something you can investigate.
#3. PagerDuty — Put structure around incident response
PagerDuty is about what happens after monitoring tells you something is wrong. On-call schedules, escalation paths, alert routing, and clear response ownership turn an outage from an improvised scramble into a repeatable process.
#4. Git — Give change a history
Git is the foundation underneath almost everything that follows. Code, infrastructure, configuration, documentation, and automation all get safer when changes are versioned, reviewable, and reversible.
#5. Terraform — Treat infrastructure like software
Terraform takes the Git mindset into infrastructure. Instead of relying on console clicks and institutional memory, you describe infrastructure in code, review changes, reuse patterns, and make environments repeatable.
#6. GitHub Actions — Automate the workflow around the work
GitHub Actions connects repository events to testing, validation, builds, deployments, security checks, and other repeatable tasks. The important lesson is not simply “automate everything.” It is learning which parts of the workflow should be automatic and where human judgment should remain a gate.
#7. Cursor — Use AI without outsourcing judgment
Cursor brought AI into the series because AI-assisted engineering became part of the real workflow. The useful question is not whether AI can generate code. It is whether you can use it to move faster while still understanding, validating, and owning the result.
#8. Kubernetes — Reconcile workload state
Kubernetes moves the series into container orchestration. The important lesson is desired state: declare how workloads should run, then let controllers continuously work to keep the cluster aligned with that intent.
#9. OpenTelemetry — Standardize the evidence
OpenTelemetry connects distributed workloads to observability. It standardizes how traces, metrics, logs, context, resources, and telemetry pipelines are described and moved without pretending the instrumentation layer is the storage or visualization backend.
#10. Argo CD and GitOps — Reconcile deployment state from Git
Argo CD and GitOps brings the Git and Kubernetes ideas together. Git records reviewed desired state, while Argo CD compares that declaration with the live cluster and reports or reconciles drift.
Where the series landed
The final cloud-native stretch became Kubernetes → OpenTelemetry → Argo CD / GitOps because that progression teaches three different control problems:
Kubernetes → what should the workload state be?
OpenTelemetry → what is the running system actually doing?
Argo CD/GitOps → how should reviewed deployment state reach the cluster?That sequence is more useful than adding tools merely to fill an old list.
AWS is still foundational, but it is also an entire platform rather than one tool. Trying to squeeze compute, networking, IAM, storage, managed services, observability, and Kubernetes into one beginner post would mostly create a shallow catalog. It deserves a more focused treatment if I return to it in a future cloud-foundations series.
The same rule applies to whatever comes next: the learning path should follow what is useful to understand, not what makes an old list look complete.
The bigger idea
The tools are useful, but the workflow between them is what makes the system work.
A healthy technical organization might use Git to control change, Terraform to define infrastructure, GitHub Actions to validate it, Kubernetes to reconcile workloads, OpenTelemetry to standardize operational evidence, Argo CD to reconcile deployments, observability platforms to investigate production behavior, PagerDuty to route incidents, Rundeck to automate known responses, and AI tools to reduce friction throughout the process.
The exact products can change. The operating ideas survive much longer.
That is what I wanted this first series to teach.
Start wherever you are. Learn one tool well enough to understand the problem it solves, then connect it to the next one.
That is a much better way to learn SRE than memorizing somebody else’s top-ten list.