Skill I want to learn:
- Web security defense
- operating system, coa and system performance
- sql procedures, pl/sql
- ansible
- rest apis and django
- networking commands and linux
- data structures
- design and analysis of algorithms
- docker
- kubernetes
- python scripting for devops
- linux security and hardening
- regular expressions
- bash projects
2. Many points are a lot of huge things really. All the security things for example. Should you know basics like understanding Owasp top 10 - sure. Should you know about ebpf used for line speed matching against known/hypothetical issues - eh, probably not yet. Same with data structures: Knowing about hashes vs lists and something about indexes - sure; writing your own b+tree - meh (unless you want to apply to a company that may want to include it in the interview).
Basically what I'm trying to say is: find out what is actually going to be likely useful, split those things into many levels, get some really basic understanding of each, then see what's useful for you next. Also keep in mind that "regular expressions" is a week of fun to learn, but "kubernetes" or "Web security defense" is a full career.
I started 22 years ago by learning bottom-up: operating system internals, network protocols, programming language theory, etc.
It made everything else much easier to understand, and still pay dividends today. Things click much faster if you know what's behind that shiny new tool.
If you want to be in the cutting edge of SRE/Platform, focus heavily on programming skills. Python or Go but whatever you like, honestly. The goal is to be good at software engineering, not programming.
For quick results: Kubernetes, Docker, Ansible, a public cloud provider, Jenkins or any other CI. That helps you get a job today and keep learning through more difficult projects. Without a job, you'll run out of real-world cool projects. The tutorials and learning projects get boring fast.
I'm afraid there is no linear path to follow. Curiosity goes a long way. Always think about the big picture when thinking about infrastructure. Consider the timespan of solutions.
If you keep agonizing over what to learn instead of actually learning, you will wake up one morning to realize that you haven't learned anything. Don't think about it. Do it.