$ ./stats.sh
↓25%
Deployment failures
1000+
Manual hours removed / month
100%
Service observability coverage
15+
Live failovers, zero data loss
$ ls ./projects
Most multi-AZ clusters are multi-AZ only on paper. survive-zone reads where pods actually run, takes each zone away in turn and reports which workloads go dark. Every fix it prints is checked against the real Kubernetes scheduler first. Accepted into the Kubernetes krew plugin index.
$ kubectl krew install survive-zoneAI agents with kubectl access usually share one admin credential. blastgate runs every agent request as the human behind the session, measures what each write would destroy, and holds the dangerous ones until a person approves them.
Turns an Alertmanager flood into one incident per root cause, then runs policy-guarded fixes (restart, scale, clear crash-looping pods) with a dry-run switch, so the on-call engineer sees the cause, not fifty symptoms.
Runbooks as YAML, run on Temporal. Steps stop at real sign-off gates instead of a Slack message nobody enforces. When a step fails, an LLM advisor proposes the root cause, but only a pre-approved playbook can ever run.
Tests whether an AI agent's memory really forgot. It plants a synthetic fact, asks the agent to erase it, probes with indirect questions, and signs the evidence into a report anyone can verify.
$ git log --author=SaiPisey2 --merged upstream
$ ./skills.sh
Infrastructure
Kubernetes • Docker • Terraform • Helm
CI/CD & GitOps
ArgoCD • Jenkins • Argo Workflows • GitOps
Observability
Prometheus • Grafana • Tempo • Thanos
Cloud
AWS • GCP • Azure
Automation & Scripting
Python • Bash • Ansible
Security
Trivy • OWASP • Sealed Secrets • Kubernetes Security
verify --credentials
$ ./services.sh
01
I build rock-solid pipelines that turn deployments from high-stress events into non-events. Your code moves to production automatically, securely, and with instant zero-downtime rollback capabilities.
02
I design observability systems that tell you exactly what's failing before your users notice. By setting up clean alerting and auto-healing infrastructure, I make sure you get a full night's sleep.
03
I integrate security directly into your delivery flow. From least-privilege cloud IAM to automated container vulnerability scanning and secrets management, your defense is built in, not bolted on.
04
I codify security and compliance policies into automated checks in the pipeline, so evidence is collected continuously instead of assembled before an audit.
05
I audit and right-size your cloud footprint to eliminate waste: budget boundaries, autoscaling that matches demand, and spot capacity where the workload tolerates it.
06
I run AI and ML workloads with the same discipline as production services: self-healing that turns correlated alerts into automated remediation, training pipelines on Argo Workflows with GPU scheduling, and LLM observability with tracing and token-cost attribution.
$ ./feedback.sh
One thing I noticed about Sai is that he doesn't need everything to be clearly defined before getting started. Give him a production problem and some context, and he'll usually work his way through the infrastructure, identify where the actual problem is, and come back with a practical solution. He has a very strong ownership mindset, which is something I value a lot in infrastructure engineers.
Sanket Nighot
CTO, InfraThrone
Sai is the engineer I would bring into a problem when the first few things we've tried haven't worked. He is comfortable going deep into Kubernetes, networking, CI/CD, cloud infrastructure, and monitoring rather than treating each as a separate area. I particularly liked that he would automate the fix afterwards instead of accepting the same operational issue as something we'd have to deal with again.
Ritik Shukla
Lead DevOps Engineer
What stood out to me about Sai was how seriously he took production issues. He didn't rush into making changes just to get something working again. He would look at the logs, metrics, infrastructure and recent changes, piece everything together, and then explain what he had found. That level of ownership gave me confidence when dealing with difficult technical issues.
Sumedh Gadkari
Assistant Vice President, Barclays
Sai was always someone I could rely on when something technical needed to get done properly. What I appreciated most was that he didn't treat DevOps as just servers, pipelines, and deployments. He understood the operational impact on the business and was good at finding ways to remove manual work and make things more dependable.
Saurav Chaudhary
CEO, InfraThrone
I've always found distributed systems problems interesting, and Sai was one of the few DevOps engineers I worked with who was equally comfortable discussing the infrastructure underneath them. We could talk about databases, Kubernetes, scaling, networking, or failure scenarios without having to simplify the conversation. He approaches infrastructure with an engineer's curiosity rather than just following runbooks.
Murtaza Shajapurwala
Co-founder, KiviDB
Sai doesn't treat security as something that gets added after the infrastructure is built. In conversations around deployments and production systems, security was usually part of the design discussion itself. I appreciated that he was willing to think about the operational side of security - secrets, access, image security, and deployment controls - rather than looking at security as a separate checkbox.
Edafe Ukoh
Product Security Engineer
Sai was very good at taking infrastructure problems that could easily become a blocker for the product team and figuring out a practical way forward. He was responsive when things went wrong, but more importantly, he looked for ways to prevent the same issues from becoming recurring problems. That reliability made it easier for the product team to plan releases and work with engineering.
Rahul Wandile
Senior Product Manager
From a developer's perspective, good DevOps is something you notice when you don't have to think about it. Sai made deployments and infrastructure issues much less painful for the development team. When something broke, he was also willing to look at the application side instead of immediately saying it was an infrastructure problem. That made debugging with him much easier.
Kamlesh Chhipa
Software Development Engineer
Whether it's hardening your platform, untangling a messy CI/CD setup, or just talking infrastructure over a call, let's connect. I'm always up for a good systems conversation.
