Ask HN: How do I learn DevOps?

This doesn't answer your question directly, but best way to learn is to build your own non-trivial app and deploy it in your own servers at home, or a dedicated server.

You'll learn naturally by writing, deploying, and supporting your own app or by working in a place that doesn't understand technology and makes you do it all.

Basically, every time you run into something that should be someone else's job, do it.

take everything in essential system administration by aeleen frisch and automate it. done.

Google for blogs written by Google's Site Reliability Engineers - SREs. The Visible Ops Handbook is where devops as a movement, seems to have begun. But Devops is really about taking things like ITIL standards more seriously. It is unfortunate that too many people aim for buzzword compliance with any published standard, without looking for the essential meaning of the standard and adapting that to their own environment. Therefore a lot of stuff on the net about ITIL is crap, but the essential principles and practices that ITIL documents, are necessary for any serious Internet service company. And part of that is that software developers have to be involved in engineering how their apps are deployed and operated and CHANGED. No more silos between ops/sysadmins and developers. In the ideal end game of devops, there would be no more ops/sysadmin roles, just software developers, some of whom specialize in maintaining/improving site reliability. If you are in ops then you need to learn professional software development practices (Bob Martin's book Clean Code comes to mind) and if you are a developer, it means that you need to learn more about managed processes (human processes) and about the architecture of the things that run your code. You have heard of cores, but what about L1 cache and false sharing? How much time does your app spend waiting on locks? Why don't you know the answer to that last question? How do you measure/monitor your apps? If you answered Nagios, go back to school. Uptime is irrelevant, it is application health that matters, resource utilization and so on. Send data to Graphite to build up a historical view of your app behavior. If there is too much data being generated then use statsd or metricsd to only send a random sample of the data, because "too much" is a code for "a random sample would be statistically significant therefore I don't need all the data points".

Deploy an application with a lot of dependencies using Chef or another configuration tool that requires you to author new scripts. Set up monitoring that alerts you intelligently when someone hammers it. Deploy the Chaos Monkey and point it at what you authored; see if it stands up. If it doesn't, figure out why. Fix it. Wash, rinse, repeat.

The reason that it's called "devops" instead of just "ops" is to create a separation between the type of ops where you don't EVER break anything and you move real slow and no one ever got fired for buying IBM, and the type of ops where everything's virtualized and software-defined, and things can, will, and should break without any penalty to the operation of the system as a whole.

I am only knowledgeable of the chef world and aws so my advice reflects that. Get a free opscode, github and aws account. (The aws account is pretty limited at the free tier so I would probably just spin up small instances and kill them after I was done "practicing".) Follow along a chef tutorial such as: https://learnchef.opscode.com/starter-use-cases/wordpress/ or https://learnchef.opscode.com/starter-use-cases/multi-node-e...

You should definitely have your own servers to play around with. I use digital ocean which is pretty inexpensive but has an API to your account (example: https://www.digitalocean.com/community/articles/how-to-insta...).

I would look into using vagrant to spin up virtual machines associated with a particular software project. I find that helped me quite a bit with thinking of the server as being coupled to the application server software.