Server Administration
Day-to-day operation of Linux fleets: provisioning, patching, tuning and keeping the lights on.
- Provisioning & baseline config
- Patch & kernel management
- Apache / Nginx / PHP-FPM tuning
- Monitoring & alert design
Software Engineer — Server Support
I keep production Linux infrastructure fast, hardened and online for a global managed-hosting client base. L2/L3 escalations, malware forensics and compromise recovery, InnoDB data recovery, and planned zero-downtime migrations on AWS — diagnosis through to an evidence-backed RCA.
Software Engineer — Server Support
I'm a software engineer working web hosting and server support at
Bobcares in Kochi, handling the managed-hosting side of
infrastructure — the place where a scanner burst without LVE caps, a
disk-full event or a rogue systemd service turns into a customer
outage within minutes.
Most of my day is L2 and L3 escalations across shared, VPS and
dedicated Linux servers for a global client base: reproducing the fault,
attributing load properly with pidstat and iostat instead of
guessing, applying a fix that holds, and writing the RCA the client actually
receives. The rest is planned work — malware forensics and compromise
recovery, database recovery, and migrations customers
shouldn't be able to feel.
I care about two things above all: not losing data, and not surprising the client. The PHP 5.6 → 8.2 migration I led ran header-based ALB routing so the new stack could be tested live before anyone was moved onto it, with a target-group rollback measured in seconds. I'm currently extending that into DevOps and cloud — AWS certifications in progress, GCP next.
Four things I do properly, rather than twenty things I do adequately.
Day-to-day operation of Linux fleets: provisioning, patching, tuning and keeping the lights on.
Escalated tickets that L1 can't close — root-caused, fixed, and documented so they stay closed.
Hardening before the incident, and calm, methodical cleanup after one.
Moving live workloads between servers, panels or providers without customer-visible downtime.
What I work with day to day across a global managed-hosting estate.
Real production problems I've owned end to end, from first alert to written RCA.
Led the migration of a high-traffic AWS-hosted client to Ubuntu 24.04, Apache 2.4 and MariaDB 10.11 with a ~176 GB database — header-based ALB routing so the new stack could be tested live before any user was moved, full dump/restore sync, and a Gitolite auto-deploy pipeline.
→ Seconds-level target-group rollback path
A disk-full event corrupted InnoDB and forced a MariaDB rebuild on a DirectAdmin server. Recovered order, tax, attribute and shipping data for multiple stores by working from pre-rebuild data-directory snapshots.
→ Live commerce data recovered, not written off
Investigated and contained active compromises involving rogue systemd services, /etc/ld.so.preload hooks, hidden payload fetchers, webshells and crypto-mining processes — forensic log analysis, cleanup and post-incident hardening on WordPress and Joomla estates.
→ Contained, cleaned and hardened against repeat
Runbooks, post-mortems and hard-won lessons from managed hosting infrastructure.
The full sequence I follow to move live accounts between servers — pre-flight checks, TTL staging, delta syncs and the rollback plan you hope never to use.
Read runbookEverything I do between "the server exists" and "the server is safe to put traffic on" — SSH, firewall, kernel parameters, updates and audit logging.
Read checklistA repeatable triage order — load average, then CPU vs I/O vs memory, then the actual offending process — so you stop rebooting and start fixing.
Read the methodWhether it's an escalation you can't close, a migration you'd rather not do at 2am, or a fleet that's never been properly hardened — send me the details and I'll tell you honestly what I'd do.