❯whoami

Last login: {{ lastLogin }}

Prazwal Bhattarai

I build and operate the systems that keep software running — and I like to understand them all the way down to the kernel.{{ heroTyped }}

$ id

uid=1000(prazwal)
gid=1000(devops)
groups={{ gr.name }}{{ gr.sep }}

$ uptime

up {{ uptime }} at Gurzu, 1 user
load average: boring, boring, boring

$ printf '%s\n' "$ROLE" "$HOST"

DevOps & Infrastructure Engineer
@ Gurzu Inc.
Nepal · UTC+5:45 (NPT)

❯cat /etc/motd

I keep the path from a developer's commit to production short, boring, and reliable. Boring is the point — a deploy should be the least eventful part of anyone's day.

What pulls me in is the layer below the one I work in — the Linux kernel, how NGINX juggles thousands of connections, what actually happens between typing a URL and seeing a page. I'd rather understand a system all the way down than trust it as a black box.

❯zsh — interactive

prazwal@nepal: ~ — zsh — this one actually works READY

❯~

try:

❯systemctl status delivery.service --what-i-optimise-for

LEAD TIME

commit → prod,
no meeting

Pipelines that are trusted enough to run themselves. If shipping needs a person to babysit it, that's a bug in the pipeline.

MTTR

detect it before
the customer

Dashboards and alerts that point at a cause, not a symptom. An alert nobody acts on is worse than no alert.

TOIL

delete the
runbook

A manual step done twice gets written down; done three times it gets automated and the doc gets deleted.

# the numbers live in the case studies below, with the context that makes them mean something

❯ls ~/works// what I actually do at Gurzu Inc.

[ STATUS: {{ w.status }} ] [ {{ w.tag2 }} ]

TECH STACK{{ w.stack }}

ROLE{{ w.role }}

{{ w.linkK }}[ {{ w.linkV }} ]

❯ls -la ~/decision_logs/// pulled live from prazwal.hashnode.dev

[ {{ r.date }} ][ {{ r.size }} ]READ_FULL_LOG →

→ prazwal.hashnode.dev

❯performance.getEntriesByType('resource')// what it actually cost your browser to load this page

[ VISITS_TOTAL — LIVE ]

$ last | wc -l — you are visit {{ visitOrdHash }}

[ SESSION_UPTIME ]

no restarts, no incidents

[ RESPONSE_TIME ]

{{ apiMs }}ms

measured on this page's own API call

this session · {{ logCount }} requests · {{ logBytes }} transferred

{{ l.t }}{{ l.kind }} "{{ l.m }} {{ l.path }} {{ l.proto }}" {{ l.st }}{{ l.by }}{{ l.ms }}ms

every row is a request your browser really made — paths, sizes and timings measured by the Performance API 304 = served from your cache

❯systemctl status gurzu.service

● gurzu.service — DevOps & Infrastructure Engineer @ Gurzu Inc.

Loaded: loaded (/etc/prazwal/roles.d/gurzu.service; enabled)

Active: active (running) since Fri 2023-12-01; {{ uptime }} ago

Main PID: 1 (delivery-pipeline) · Tasks: 4

{{ t.tree }} {{ t.name }} — {{ t.note }}

● {{ h.unit }} — {{ h.role }} @ {{ h.org }}

Active: inactive (dead) since {{ h.until }}; ran {{ h.span }}

❯mail -s "let's talk systems"

Working on something at the infrastructure layer, hiring for it, or just want to trade notes on how things actually work underneath? My inbox is open — or put 30 minutes straight into my calendar.

[ BOOK A CALL ]

30 minutes over Google Meet, at a time you pick. Best for scoping a piece of work.

[ SEND AN ENQUIRY ]

Describe the problem and I’ll come back with whether I can help, and how.

[ COMPOSE MAIL ]

bprazwal678@gmail.com [ curl -O cv.pdf ↓ ] {{ copiedLabel }}