cv/index.md

57 lines
3.0 KiB
Markdown
Raw Normal View History

2024-02-21 11:07:18 +00:00
---
stylesheet:
- https://cdnjs.cloudflare.com/ajax/libs/github-markdown-css/5.5.1/github-markdown.css
body_class: markdown-body
css: |-
2024-02-25 12:13:58 +00:00
.markdown-body {
font-size: 9px;
}
2024-02-21 11:07:18 +00:00
.page-break { page-break-after: always; }
---
2024-02-25 12:13:58 +00:00
## Nikolai Rodionov
2023-05-02 19:04:18 +00:00
```
> Location: Hamburg, Germany
2023-05-02 19:04:18 +00:00
> Email: allanger@zohomail.com (preffered)
> Github: https://github.com/allanger
```
2024-02-25 12:13:58 +00:00
*This CV is built in a CI pipeline, and uploaded to Minio Bucket, so you should be able to download the latest version here: <https://s3.badhouseplants.net/public-download/n.rodionov.pdf>*
2023-05-02 19:04:18 +00:00
2024-02-25 12:13:58 +00:00
### About me
2023-05-02 19:04:18 +00:00
2024-02-25 12:13:58 +00:00
I'm a DevOps engineer with 5++ years of hands-on experience with a decent amount of tools. One of the most important tools that I love and want to continue working with, is Kubernetes. At least, until I see a better alternative. I think that containers themselves are one of greatest inventions in development, and I'm trying to use them as long as it's possible. Also, I believe that every routine must be automated, because routing is a boring job that lets people lose focus and make mistakes.
2023-05-02 19:04:18 +00:00
2024-02-25 12:13:58 +00:00
I think that there are several things that a DevOps engineer must be able to do:
2023-05-02 19:04:18 +00:00
- To build reliable and stable infrastructure
- Keep this infrastructure up-to-date
- Keep all the source and instructions of this infrastructure clean and simple
- Avoid a human factor as long as possible
- And when it's not possible to avoid it, not to be afraid to take responsibility
Also, I think it's important that before implementing anything, an engineer has understood all the requirements and checked tools that can fulfil them. I often see, how people try to use a tool for its name but not for its functionality, and hence they have to do a lot of additional work and deal with compromises. And if nothing really can fulfil those requirements, you need not be afraid of writing something new *and open-source it*.
2024-02-25 12:13:58 +00:00
### Experience
2024-02-21 11:07:18 +00:00
| Company | Position | Dates |
|------------------|-------------------|---------------------|
| **Giant Swarm** | Platform Engineer | 12.2023 - Until Now |
| **Grandcentrix** | SRE | 02.2023 - 11.2023 |
2024-02-25 12:13:58 +00:00
| **Klöckner.I** | DevOps Engineer | 01.2022 - 01.2023 |
2024-02-21 11:07:18 +00:00
| **Itigris** | DevOps Engineer | 07.2019 - 12.2021 |
| **Etersoft** | DevOps Engineer | 03.2017 - 06.2019 |
2024-02-25 12:13:58 +00:00
#### Tools
- **Environments**: Linux - Containers - Kubernetes - Proxmox
- **Kubernetes**: Helm - Kustomize - Kubebuilder - Helmfile
- **Scripting/Coding**: Bash - Go - Rust - Perl
- **Continuous Integration**: Gitlab-CI - Github Actions - Circle-CI - Woodpecker-CI - Drone-CI
- **Continuous Delivery**: ArgoCD - Flux
- **Infrastructure as Code**: Ansible - Terraform
- **Cloud Providers**: Microsoft Azure - Google Cloud - AWS - Yandex Cloud - Hetzner - Self-Hosted
- **Observability**: Prometheus - Grafana - Loki - Elasticsearch - Kibana - FluentBit - Promtail - Fluentd
- **Secrets/Encription**: Sops - Age - Helm Secrets
- **Databases**: PostgreSQL - MySQL - Percona MySQL - Redis
- **Storages**: Minio - Ceph