SRE in Practice: DAY 1 OF 30 What is SRE?

What you will learn

• What SRE is and how its mindset differs from simply keeping servers running 

• Why "the server is up" and "the service works" are different statements 

• How to walk through the layers of an outage, from the host up to the user's experience 

• A safe, read-only lab using curl and basic Linux checks, with expected results 

• How this fits into the 30-day roadmap

Prerequisites

1. Linux fundamentals
File system, permissions, processes, systemd services, package management, and reading logs with journalctl.

2. Networking basics
TCP/IP, DNS, ports, HTTP and status codes (200, 404, 503), load balancers, and TLS at a basic level.

3. Scripting
Bash for daily tasks, and Python basics for automation.

4. Cloud fundamentals
Compute, storage, networking, and identity and access (IAM) on Azure, AWS, or GCP. One cloud is enough to start.

5. Git and CI/CD
Version control, branches, pull requests, and how a build and deployment pipeline works.

6. Infrastructure as Code
Terraform and Ansible basics. (If you followed my Terraform in 7 Days series, you already have a head start.)

7. Monitoring basics
What metrics, logs, and alerts are, and how to read a dashboard.

8. Troubleshooting mindset
Stay calm, form a hypothesis, test one thing at a time, communicate clearly, and write things down.

1. The problem: up, but not working Imagine you get a message:

 "The application is down." You check the server. The VM is running. The web server process is active. A ping gets a reply. Every dashboard that watches the machine is green. And yet users see an error page. This is one of the most common situations in operations, and it is exactly the situation Site Reliability Engineering (SRE) was created to handle. A successful ping or a running service tells you that a component exists. It does not tell you that a user can complete the task they came to do. 

Core idea: measure reliability from the user's point of view, not only from the server's point of view. 

2. What is SRE? 

Site Reliability Engineering applies software-engineering principles to operations to help build and run reliable, scalable, and observable services. The discipline began at Google in the early 2000s, where engineers were asked to treat operations problems as engineering problems: measure them, automate them, and fix their root causes. SRE is not a single tool. It is a set of practices: 

The four questions behind the SRE mindset

• Can users complete the task they came to do? This is the real definition of "working".

 • Are requests succeeding within an acceptable time? A response that takes 40 seconds is often as bad as no response. 

• Can we detect and respond to failures before they grow? Good monitoring finds problems before customers report them. 

• What can we automate or improve to prevent repeat incidents? Fixing the same problem manually twice is a signal to engineer it away.

3. A production-style example

A web application runs on a Linux VM. The web server forwards requests to an application, which needs a database.

What the infrastructure team sees:

 • The VM is running

• The web server process is active

 • CPU and memory are normal 

What the user sees: 

• Every request returns HTTP 503 Service Unavailable 

• No one can log in or complete a purchase 

The root cause: the application cannot connect to its database. 

Perhaps the database service stopped, a firewall rule changed, a credential expired, or the connection pool is exhausted. 

The web server is healthy, and it honestly reports that the application behind it cannot serve the request. 

About HTTP 503

503 Service Unavailable means the server is currently unable to handle the request. The server is

reachable and answering, but the service behind it cannot do the work right now. Note that real applications

may return other 5xx codes (500, 502, 504) for similar dependency failures, depending on how they are

built. The point is the same: a 5xx response means the user's request failed, even when the host is healthy

The request path and where it breaks

4. Different levels of "up"

"Is it up?" is really six different questions. Each level proves something, and none of the lower levels proves the ones above it.

5. Hands-on lab: check the application response 

Step 1: request the endpoint

Replace localhost with the host and path you are testing.  

What the options do: -i prints the response headers, so you see the status line. --max-time 5 stops waiting after 5 seconds, so a hung service does not hang your terminal.

curl -i --max-time 5 http://localhost/

Expected Results

Step 2: get just the status code and timing

code curl -sS -o /dev/null --max-time 5 -w "HTTP %{http_code} in %{time_total}s\n" \ http://localhost/

Example output on a healthy system (your numbers will differ): HTTP 200 in 0.012s. If the request fails before any response arrives, the status prints as 000. Important: by default curl exits with code 0 even when the server returns 503, because the transfer itself succeeded. Add --fail if you want a non-zero exit code for HTTP errors in scripts.

Step 3: look one layer down (read-only) 

If Step 1 shows a problem, work down the layers. Replace myapp with your service name. 

code systemctl status myapp --no-pager # is the service running?

 code ss -ltn # which TCP ports are listening? 

code journalctl -u myapp -n 50 --no-pager # last 50 log lines for the service 

Add -p to ss to see process names (it needs root to show other users' processes). Service names, log locations, and available tools vary by distribution, and some commands require sudo. Use only the access you are authorized to have. 

Step 4: test the dependency

 In our scenario the failing dependency is the database. From the application host, check whether its port is reachable. Use your own database host and port (for example 5432 for PostgreSQL or 3306 for MySQL). 

code nc -zv db-host 5432

A message such as succeeded or open means the TCP connection works. Connection refused or a timeout means the database is not reachable on that port, which matches our 503 scenario. The exact wording differs between nc versions, and the tool may not be installed everywhere.

6. How SRE responds to this kind of failure 

An SRE does not stop at "restart it and see". The work has four stages:

7. Common mistakes

• Treating a successful ping as proof the application works 

• Monitoring only CPU, memory, and disk, and nothing about user-facing requests

• Checking only the home page, while login or checkout is broken

• Alerting on every small symptom, which trains people to ignore alerts 

• Restarting services as the only fix, with no root-cause follow-up 

• Changing production while troubleshooting without approval or a rollback plan

8. Quick check: test yourself

• A host answers ping, but users get errors. Name two other layers you would check.

• What is the difference between a 503 response and a connection timeout? 

• Why does curl return exit code 0 on a 503, and how can you change that?

• Write one question an SRE would ask that a server-only dashboard cannot answer. 

• In your own workplace, what is one user-facing action you could test automatically?

Suggested answers: other layers include the service process, listening port, HTTP endpoint, and dependencies; a 503 means a response arrived but the service cannot serve it, while a timeout means no complete response arrived; curl reports transfer success unless --fail is used.

9. Wrap up

Glossary

The 30-day roadmap at a glance

Your turn: Have you ever seen a server marked "UP" while the application was down? What was the cause? Share it in the comments on the LinkedIn post. Coming next, Day 2: SRE vs DevOps. 

Follow https://www.linkedin.com/in/leadwithsree/ for further updates.