DEV Community: FT MJ

Production Maintenance Drill: An OPS Checklist in Action Validating Production Readiness Through Hands-On Practice

FT MJ — Sun, 08 Mar 2026 19:29:43 +0000

In this assignment, I stepped into the shoes of a production support engineer and performed a comprehensive maintenance drill on a live EC2 instance running an Nginx web server. The goal was simple but critical: validate that the production server is healthy, secure, and reliable — and document every step of the process.

This drill simulated exactly what real DevOps and SRE teams do when they investigate production issues, perform routine maintenance, or respond to incidents.

📋 Phase 1: Network & Connectivity Checks
Before diving into application-level checks, I verified that the server could actually communicate with the outside world. Network issues are often the root cause of "it's down" scenarios.

Check Network Interfaces
bash
echo "Manjay Verma - Maintenance Drill"
ip a
What I observed: Active network interfaces with a valid private IP.

Why it matters: If no interface is up, the server cannot communicate with anything — including you.

Verify Default Gateway
bash
echo "Manjay Verma - Maintenance Drill"
ip route
What I observed: Default gateway route is present.

Why it matters: Without a default route, the server cannot reach external services or the internet.

Test DNS Resolution
bash
echo "Manjay Verma - Maintenance Drill"
host pravinmishra.com
What I observed: DNS resolution works — domain successfully resolved to IP.

Why it matters: If DNS fails, applications cannot reach external APIs or services.

Check Packet-Level Connectivity
bash
echo "Manjay Verma - Maintenance Drill"
ping -c 4 thecloudadvisory.com
What I observed: 0% packet loss.

Why it matters: Packet loss in production can indicate network instability or congestion.

Inspect Open Ports
bash
echo "Manjay Verma - Maintenance Drill"
sudo ss -tulpen
What I observed:

Port 22 → SSH (listening on 0.0.0.0)

Port 80 → Nginx (listening on 0.0.0.0)

No unexpected ports open

Why it matters: Every open port is a potential attack surface. Only required services should be exposed.

Check Firewall Status
bash
echo "Manjay Verma - Maintenance Drill"
sudo ufw status
What I observed: ufw not installed

Why it matters: In production, firewall rules should restrict traffic to required ports only. This is a security gap that needs addressing.

🚦 Phase 2: Service Health Validation
Once network connectivity was confirmed, I validated that the Nginx service was running correctly.

Check Service Status
bash
echo "Manjay Verma - Maintenance Drill"
systemctl status nginx --no-pager
What I observed: Nginx service is active and running under systemd.

Verify Boot-Time Enablement
bash
echo "Manjay Verma - Maintenance Drill"
systemctl is-enabled nginx
What I observed: Nginx is enabled, meaning it starts automatically after reboot.

Why it matters: Ensures service availability after server restarts.

Test Configuration Syntax
bash
echo "Manjay Verma - Maintenance Drill"
sudo nginx -t
What I observed: Configuration syntax is valid.

Why it matters: Always validate configuration before restarting to prevent downtime from bad configs.

Verify Process Structure
bash
echo "Manjay Verma - Maintenance Drill"
ps aux | grep -E "nginx: master|nginx: worker" | grep -v grep
What I observed: Both master and worker processes are running.

Why it matters: Nginx uses a master process to manage workers. Missing worker processes means the service isn't actually serving traffic.

Confirm PID on Port 80
bash
echo "Manjay Verma - Maintenance Drill"
sudo ss -lptn '( sport = :80 )'
What I observed: Nginx PID is correctly bound to port 80.

Why it matters: Confirms the service is listening on the expected port.

Perform Safe Restart Drill
bash
echo "Manjay Verma - Maintenance Drill"
sudo systemctl restart nginx
systemctl status nginx --no-pager
What I observed: Restart completed successfully.

Rollback plan: If nginx fails to restart, revert config changes and validate using nginx -t before restarting again.

📊 Phase 3: Log Analysis
Logs are the production engineer's best friend. I generated test traffic and examined what got logged.

Generate Test Traffic
bash
curl -s http://34.230.8.38 > /dev/null
curl -I http://34.230.8.38
Review Access Logs
bash
echo "Manjay Verma - Maintenance Drill"
sudo tail -n 30 /var/log/nginx/access.log
What I observed: My curl requests appeared in the logs, confirming traffic reached Nginx.

Why it matters: Access logs show who is requesting what and help identify traffic patterns or attacks.

Check Error Logs
bash
echo "Manjay Verma - Maintenance Drill"
sudo tail -n 30 /var/log/nginx/error.log
What I observed: No recent errors.

Why it matters: Empty error logs suggest no current runtime failures — a good sign.

Examine Systemd Journal
bash
echo "Manjay Verma - Maintenance Drill"
sudo journalctl -u nginx --no-pager -n 50
What I observed: Service-level events and restart history.

Why it matters: Journal provides additional context that might not appear in application logs.

💾 Phase 4: Resource Health
Production services don't just need working software — they need healthy infrastructure.

Check Uptime
bash
echo "Manjay Verma - Maintenance Drill"
uptime
What I observed: Server has been running continuously.

Review Memory Usage
bash
echo "Manjay Verma - Maintenance Drill"
free -h
What I observed: Memory usage is within acceptable limits.

Check Disk Space
bash
echo "Manjay Verma - Maintenance Drill"
df -h
What I observed: Disk usage is below critical threshold.

Inspect /var Directory Usage
bash
echo "Manjay Verma - Maintenance Drill"
sudo du -sh /var/* | sort -h
What I observed: No single directory consuming excessive space.

Why it matters: If disk fills up completely, services cannot write logs and may crash. Monitoring disk usage prevents this.

⚠️ Phase 5: Incident Simulation (The Best Part)
Theory is useful, but practice is irreplaceable. I intentionally broke the configuration to understand real incident response.

Break the Config
bash
sudo nano /etc/nginx/sites-available/default

Removed one semicolon to break the config

Observe the Failure
bash
sudo nginx -t
Result: Configuration test failed with syntax error.

Fix and Recover
bash

Restored the missing semicolon

sudo nginx -t # Configuration test passes
sudo systemctl restart nginx
curl -I http://34.230.8.38 # HTTP/1.1 200 OK
Root Cause: Syntax error in nginx configuration (missing semicolon)

Fix: Restored valid configuration and validated using nginx -t

Prevention: Always test configuration before restarting. Never assume — verify.

🔒 Security & Reliability Notes
Based on my maintenance drill, here's the current security posture:

✅ SSH access uses key-based authentication (no password login)

✅ Open ports restricted to 22 (SSH) and 80 (HTTP)

✅ Nginx is enabled on boot for automatic recovery

✅ No secrets or private keys were exposed during this exercise

⚠️ Firewall not configured — this should be addressed

💡 Cost optimization: I will stop the EC2 instance when not in use to prevent unnecessary charges

📌 Key Learnings
This week taught me that real production validation goes far beyond checking if a website loads. Here's what I learned:

Area Key Takeaway
Network Connectivity issues often masquerade as application problems
Services Verify not just "running" but "actually serving traffic"
Logs Logs tell the real story — access, errors, and system events
Resources Disk, memory, and CPU monitoring prevent surprises
Incidents Breaking things safely teaches more than reading docs
Recovery Always have a rollback plan and test configuration changes
🚀 Next Steps
This maintenance drill revealed both strengths and gaps. Moving forward, I will:

Implement firewall rules to restrict traffic to only required ports

Set up automated monitoring with alerts for:

High disk usage

Service failures

Unusual traffic patterns

Practice more failure scenarios to build muscle memory for incident response

Document runbooks so recovery steps are clear and repeatable

💭 Final Thoughts
Production maintenance isn't glamorous, but it's essential. This drill simulated exactly what on-call engineers do daily: validate, investigate, fix, and learn.

The most valuable takeaway? Simulating failures in a controlled environment builds confidence for handling real outages. By deliberately breaking and fixing Nginx, I experienced the full cycle of detection, diagnosis, recovery, and prevention — all without impacting real users.

Have you performed similar maintenance drills? What unexpected issues did you discover? Share your experiences below!

🚀 Running a 5-Day Mini Sprint in Jira and Shipping a Real Website Change to EC2

FT MJ — Sun, 08 Mar 2026 19:22:33 +0000

Hands-On DevOps: From Jira Sprint to Live Deployment on AWS EC2
In this assignment, I practiced a real DevOps workflow by running a mini Scrum sprint in Jira, implementing a small improvement to a portfolio website, and deploying the change to a live server on AWS EC2.

Rather than a big-bang release, the focus was on shipping small, incremental updates daily, tracking progress in Jira, and verifying each change on a public URL.

The improvement was simple but meaningful:

Pravin Mishra Portfolio v1.0 — Deployed on

— By Manjay verma

This footer was added to the website and deployed live to an EC2 instance.

🎯 Sprint Goal
The sprint goal defined in Jira was:

Ship a visible "Pravin Mishra Portfolio" footer (version + deploy date + author) to EC2 and document progress daily in Jira.

This simulated how real engineering teams commit to a measurable outcome for each sprint.

🧩 Sprint Setup in Jira
The sprint was managed using the following workflow:

Create a Story in Jira

Break it into 5 daily subtasks

Track daily updates using Daily Scrum comments

Move tasks across the board

Track progress using the Burndown Chart

Subtasks created:

Day 1 — Implement footer & deploy

Day 2 — Make deploy date dynamic

Day 3 — Polish UI & improve accessibility

Day 4 — Update homepage tagline

Day 5 — Demo + retro + review burndown

This structure ensured that progress was visible and measurable every single day.

🏗️ DevOps Workflow Used
The workflow followed a typical DevOps pipeline:

Code changes locally

Commit using Git

Deploy to EC2

Verify on public website

Update Jira ticket

📊 Project Workflow Diagram
text
┌─────────────────────────┐
│ Jira Sprint │
│ Story + Subtasks │
│ Daily Scrum Updates │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Local Development │
│ Edit HTML/CSS/JS │
│ Add Footer Feature │
└────────────┬────────────┘
│ Git Commit
▼
┌─────────────────────────┐
│ Git Repo │
│ Version Control │
│ Feature Branch │
└────────────┬────────────┘
│ Deploy via SCP
▼
┌─────────────────────────┐
│ AWS EC2 Server │
│ Nginx Web Server │
│ Portfolio Website │
└────────────┬────────────┘
│ Public Access
▼
┌─────────────────────────┐
│ Live Website │
│ Footer Version Visible │
│ Deploy Date + Author │
└─────────────────────────┘
⚙️ Day-by-Day Sprint Execution
Day 1 — Implement Footer and Deploy
The first task was to add a footer section to the HTML template:

html

Pravin Mishra Portfolio v1.0 — Deployed on 09 Mar 2026 — By Manjay

After implementing the footer:

Changes were committed using Git

The site was deployed to EC2

The footer appeared on the live website

This step validated the end-to-end delivery pipeline.

Day 2 — Make Deploy Date Dynamic
To improve the feature, the deploy date was generated automatically using JavaScript:

html

const d = new Date();
const options = { day: '2-digit', month: 'short', year: 'numeric' };
document.getElementById("deployDate").innerText =
d.toLocaleDateString('en-GB', options);

Now the footer automatically displays the current deployment date, eliminating manual updates.

Day 3 — UI Polish and Accessibility
The footer was enhanced for better usability and accessibility:

Improvements included:

Increased padding

Better font size and contrast

Responsive layout testing

The UI was verified on both desktop and mobile views using browser DevTools.

Day 4 — Update Homepage Tagline
The homepage text was updated to promote the DevOps learning community:

Join DMI Cohort 3 on Discord and start your DevOps journey

This change improved community visibility and engagement.

Day 5 — Demo, Retro, and Burndown Review
The final day focused on reviewing the sprint:

Activities included:

Recording a demo of the live website

Showing the footer with version, date, and author

Reviewing the burndown chart in Jira

Writing retrospective notes

Retrospective Example:

What went well What to improve
Daily incremental updates helped maintain momentum Automating deployment using CI/CD would improve efficiency
DevOps principle observed: Continuous Delivery

📈 Key DevOps Learnings
This assignment demonstrated several important DevOps practices:

1️⃣ Incremental Delivery
Instead of one large change, small improvements were delivered daily, reducing risk and enabling faster feedback.

2️⃣ Traceability
Every change was tracked in Jira and linked to the user story, creating a clear audit trail.

3️⃣ Deployment Proof
Each change was verified on a public EC2 URL, confirming that the feature worked in production.

4️⃣ Agile Collaboration
Using stories, subtasks, and daily scrum updates mirrors how real Scrum teams operate.

🌍 Final Result
By the end of the sprint:

✔ A visible footer was deployed
✔ The deploy date was automated with JavaScript
✔ UI was polished and accessibility improved
✔ The homepage tagline was updated
✔ All changes were tracked through Jira
✔ The website was live on EC2

This exercise demonstrated how Agile + DevOps workflows help teams ship reliable improvements quickly and consistently.

💡 Final Thoughts
This mini sprint highlighted a fundamental principle:

Small daily improvements with proof are better than one large delayed release.

By combining Jira sprint management, Git version control, and EC2 deployment, this assignment simulated a real-world DevOps delivery cycle — proving that even simple improvements can teach powerful lessons when executed with the right processes.

FullStack Diaries

FT MJ — Sun, 22 Feb 2026 15:52:44 +0000

From Local Git to Live EC2 Deployment — My DevOps Week 3 Journey (DMI Cohort 2)

Author: Manjay Verma
Program: DevOps Micro Internship (DMI) — Cohort 2
Week: 3 — Git & GitHub Workflow

🌟 Introduction

As part of the DevOps Micro Internship (DMI), Week 3 focused on mastering Git, GitHub collaboration workflows, and deploying a real static website on AWS EC2 using Nginx.

This week transformed my understanding of:

Version control systems

Branching strategies

Open-source contribution workflow

Production-style deployment on Linux servers

This blog documents my complete hands-on journey.

Part 1: Setting Up Git Locally
Created a Project Repository

I created a project named:

CodeTrack

Initialized Git:

git init
🔍 What I Learned

Git tracks changes using snapshots.

.git directory stores commit history.

Version control prevents accidental loss of code.

🔹 Part 2: Git Identity Configuration

Configured Git identity locally and globally:

git config user.name "Manjay Verma"
git config user.email "..."
🔍 Key Learning

Local config applies per repository.

Global config applies system-wide.

Enterprise environments prefer local config.

🔹 Part 3: Staging, Committing & Clean History

Created:

index.html

style.css

Performed staged commits:

git add .
git commit -m "Initial commit: Add index and style files"

Then made a small change and committed separately.

🔍 What I Learned

Clean commit messages improve collaboration.

Small commits are easier to review.

Commit history tells the project story.

🔹 Part 4: Branching Workflow (Feature-Based Development)

Created feature branch:

git checkout -b feature/contact-page

Added:

contact.html

Updated index.html

Merged back to main:

git merge feature/contact-page
🔍 Key Learning

Feature branches isolate development.

Main branch remains stable.

This is industry-standard Git workflow.

🔹 Part 5: GitHub Collaboration Workflow

Steps followed:

Forked upstream repository

Cloned my fork

Added upstream remote

Created feature branch

Pushed to origin

Created Pull Request

git remote add upstream
git push origin feature/update-readme
🔍 What I Learned

Difference between origin and upstream

Why forks are required in open-source

How Pull Requests enable collaboration

🔹 Part 6: Deploying to AWS EC2 (Production-Style)

Launched instance in:

Asia Pacific (Mumbai)

Using:

Ubuntu 22.04

t2.micro (Free Tier)

Security Group (SSH + HTTP)

Connected via SSH:

ssh -i codetrack-key.pem ubuntu@

Installed Nginx:

sudo apt update
sudo apt install nginx -y

Deployed static site to:

/var/www/html/
🌍 Live Deployment Result

My website is now live on AWS EC2 using Nginx.

This gave me hands-on experience with:

Linux server management

Security Groups

Public IP configuration

Service management using systemctl

🔥 Production-Level Checks Performed
sudo systemctl status nginx
curl localhost
netstat -tulpn | grep 80
🔍 What I Learned

Always verify services are running.

Always test port bindings.

Deployment is not complete until verified.

🚧 Challenges Faced
❌ SSH Connection Timeout

Fixed by correcting Security Group inbound rules.

❌ GitHub 403 Permission Error

Fixed by properly forking repository and setting correct origin.

❌ "origin does not appear to be a git repository"

Fixed by adding remote URL.

Each issue strengthened my troubleshooting skills.

🎯 Key DevOps Concepts Practiced

Git internals

Branching strategy

Clean commit hygiene

Fork & PR workflow

Linux server configuration

Nginx deployment

Security best practices

🧠 My Biggest Takeaway

DevOps is not just about tools — it’s about:

Clean workflow

Reproducibility

Verification

Security awareness

Professional documentation

This week moved me closer to real-world DevOps engineering practices.

🚀 What’s Next?

Next goals:

Automate deployment using CI/CD

Use GitHub Actions

Attach custom domain

Deploy using Docker

🙌 Acknowledgment

Thanks to the DevOps Micro Internship (DMI) program and mentors for structured hands-on guidance.