on call · DevOps engineer
I keep production running — and bring it back when it falls.
DevOps engineer working with Kubernetes, cloud and on-prem infrastructure. Currently running production for a fintech lending group and mentoring future DevOps engineers at ProstoDevops.
$ whoamiGalust Arakelyan — DevOps engineer$ kubectl get engineer galust -o wideNAME EXPERIENCE CLUSTERS INCIDENTS STUDENTS STATUS galust ~7y 8 ~50 ~100 Running$ cat focus.txtdisaster recovery · kubernetes · vault · terraform · gitlab ci$
- ~7years in Linux infrastructure and DevOps
- 8Kubernetes clusters run hands-on
- ~50incidents root-caused from evidence
- ~100students mentored
incident log
real cases · symptom → root cause → fix- SEV-1INC-01● resolved
Cloud provider lost two of three availability zones
- symptom
- Production down; surviving worker nodes had no internet access, provider storage read-only.
- cause
- Regional outage at the provider; the NAT gateway lived in a dead zone.
- fix
- Ran Velero outside the cluster to back up 10,466 objects, saved 123 images and Vault, Redis, RabbitMQ, Redpanda data, then restored on new on-prem Kubernetes.
- result
- Production state restored on Talos within one day.
- SEV-2INC-02● resolved
Redis Sentinel OOM during an image update
- symptom
- A production Redis node went OOM right after the rollout.
- cause
- Chart drift: the new chart applied its default 192 MiB limit while the live pods needed 4 GiB.
- fix
- Rolled back, moved the real limits into Git, cleaned the stuck Helm and Terraform state.
- result
- 3/3 nodes back, Sentinel quorum 3.
- SEV-3INC-03● resolved
Terraform plan failing with 503 in CI
- symptom
- Every plan in one project died while reading remote state from GitLab.
- cause
- The runner had an uppercase NO_PROXY without the GitLab host, so state calls went through the proxy.
- fix
- Set a project-level NO_PROXY and proved separately that the API was dropping pipeline variables.
- result
- State answers in ~0.07 s, pipeline green.
- SEV-2INC-04● resolved
403 on every allow-listed ingress after migration
- symptom
- Users behind VPN got 403 from all ingresses with an IP allow-list.
- cause
- externalTrafficPolicy: Cluster hid the client address, so allow-lists only saw node IPs.
- fix
- Switched to Local and scripted allow-list updates with a backup of previous values.
- result
- 132 of 136 ingresses fixed in one pass.
latest posts
ls blog/ →side projects
Xelvix VPN
Built and run a commercial multi-node VPN service: a master and 3 nodes on VLESS + Reality (3x-ui), about 50 paying users and 25 online daily.