allanger
/
cv
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Activity

Fix a typo
ci/woodpecker/push/build Pipeline was successful Details

This commit is contained in:
Nikolai Rodionov 2024-03-05 11:22:59 +01:00
parent f6474effdb
commit 4cb433f938
Signed by: allanger
GPG Key ID: 0AA46A90E25592AD
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
index.md
View File

@ -20,7 +20,7 @@ css: |-
### About me
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.
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 the 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 that's the boring job that lets people lose focus and make mistakes.
I think that there are several things that a DevOps engineer must be able to do:
- To build reliable and stable infrastructure
@ -29,7 +29,7 @@ I think that there are several things that a DevOps engineer must be able to do:
- 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*.
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*.
### Experience