(Part 2) Top products from r/devops

• SSL, Public and Private Keys
  
  Public and private SSH keys and connections aren’t hard when you grok how SSL/TLS works. Encryption in general is good to have a handle on conceptually, I’d recommend picking up and reading a short introduction on the basics.
  
  
• With the CLI, pick a shell. Bash is the most universal one, Zsh works as well, but in any case read the man page for the one you pick after you’ve played with it a bit.
  
  Copying, listing, renaming, or unlinking files is usually embedded in your shell of choice itself. As the the shell is the way you call and run programs, you can’t know it enough.
  
  The GUI of whatever desktop you’re used to using is effectively a shell itself, and has the same function: copy, list, rename, remove files and run programs. The difference is, instead of executing a command as you would on the CLI (i.e., entering the path to the file binary and hitting “enter”), you click on an icon representing the same file.
  
  
• The primary tools of a Linux or Unix system are, in order of importance, man, find, grep, ssh, chmod, and chown. Then your editors: vi, emacs, or joe. nano is easy to use, but a little skill with a more advanced editor goes a long way.
  
  
• Networking tools and understanding are important too, especially in DevOps, so get to know your local flavor of ping, netstat, host, and tcpdump.
  
  When you get all that, Ansible is nothing; it’s a way to systematically SSH into machines based on a local inventory and run a set of commands or scripts on all of them.
  
  Never learned puppet, but it’s just one alternative to Ansible which looks to achieve the same thing: treating a set of hosts like they’re numbered cattle instead of carefully named and spoiled pets.
  
  Edit: I suppose you can PM me your questions, if you want. Trying to write out and explain things helps me understand them better.

I'd make sure I have a really solid understanding of systems and networks, e.g. how Linux works. This book seems like a great overview and I love No Starch Press. There's also this book which is used by Carnegie Mellon's introductory systems course, though that might be a bit too deep to dive into straight away, more like something that could be used if you want a deeper understanding of how systems work. You should have some familiarity with C just as foundational knowledge. The guy who wrote Learn Python The Hard Way also wrote an intro to C, Learn C the Hard Way. He's added a lot more material than the last time I checked (~Dec 2012) which looks like it covers a lot of topics so it would be great to work through it.

Some more technical books on this subject that are well regarded and can be used as reference books are Advanced Programming in the Unix Environment, Unix Network Programming, and The Linux Programming Interface

Also in addition to Python I'd also suggest learning some Ruby (Practical Object-Oriented Design in Ruby and Programming Ruby 1.9 & 2.0 are two resources I'd recommend), it's what Chef is/was implemented in and is fairly nice to work with.

Also a "Windows" DevOps guy.

I'd recommend this .NET Rocks podcast episode. It's a pretty healthy way of look at the meta.

1. Understand where this hype train came from -- i.e. Gene Kim's The Phoenix Project. It's a good read and illustrates all the prescriptive advise sold by consultants nowadays is just that--sold.
   
2. All labels are arbitrary, but sometimes you need the hype train to get stuff done inside organizations. This is a fact of life; I'm sorry.
   
3. Understand your goals and objectives. Are you there to reduce the feedback loop for the developers? Are you there to help unburden the release management operations in the SDLC? Are you there because they really wanted a systems engineer who can also handle the developer stuff?
   
4. While tools aren't what make the man, try to get a sense of what tools won't become vaporware. Some companies can go as far as to rewrite the kernel by hand if they need to. Is your Org one of those companies?
   
5. Understand where the process breaks down. Sometimes new tools won't do it better. All tools have an activation cost, some strange edge case, and tons of implementation pains. But sometimes--even if under the hood it works EXACTLY THE SAME--the transparency/ease-of-use are worth it to the organization.
   
6. This is the single best book I have ever read for my business career: Never Split the Difference: Negotiating As If Your Life Depended On It
   
7. If you're a Windows guy, learn to love Powershell. This is seriously the backbone of the direction MS is going. Even with the best orchestration/container/whatever tools on the market, you're gonna have to get down and dirty with it.

I'll take a hard left on the reading recommendations because the usual recommendations have been covered.

A lot of people going through these transformations do not understand nor internalize something more fundamental about how they work and misuse their most precious resource of all - time. So I recommend Tom Limoncelli's Time Management for System Administrators frequently for engineers that seem to get overwhelmed a lot at work. All companies are trying to do a lot more with a lot less than they used to only 9 years ago, and this means it is very, very common for people to be doing the jobs of what used to be 1-3 other people in the 90s or early 2000s. Additionally, look into some of the articles and events from http://www.humanops.com/

You may also want to read books from W Edwards Deming, one of the most commonly cited forefathers of Agile before they even made the term. This book should be a good introduction to improving quality output of products
and perhaps services if an organization is experiencing issues with declining quality of product https://www.amazon.com/Essential-Deming-Leadership-Principles-Business/dp/0071790225/

You may also want to read High Output Management by the late Andy Grove as well as Ben Horowitz's the Hard Thing About Hard Things. These are management books but if you're talking about methodologies and cultural transformations (forget devops for a moment), you're basically doing management consulting IMO rather than engineering consulting. And because there is no company cultural transformation that has succeeded without executive oversight, you should be trying to think more like a manager to succeed here as well. If your clients do not respect and understand the principles of successful technology company managers (I've never heard of anyone trying to do "devops" as a culture that wasn't also coinciding with trying to make a non-technology company more of a technology product company - this also includes software vendors that are fundamentally sales and marketing in core competency and culture), it is difficult to imagine that they will achieve something other than by following average / mediocre managers outside technology.

I think you're on the right path with Flask if you really want to expose this information with a web (HTTP/S) interface. You'll learn lots, but may also open your environments up to security risks.

If your ultimate goal is to share with other teams, I'd look towards implementing a shared code repository first (GitLab, GitHub, BitBucket, etc.) You could start there because you should use code repositories and versioning. You can move on to some into Flask, HTML, CSS, and Javascript afterwards. I can easily recommend Front-End Web Development as a good place to start for beginner web learning. They also use Bootstrap in their example projects.

It helps to talk 'manager' langugage - perhaps read Switch or a similar business change focused work to help get into the mindset. The 'do it well in one spot and expand on that' method is basically the 'bright spots' concept in that book.

I also don't really enjoy coding. I got into the industry by studying for (and not quite passing) the Red Hat Certified Systems Administrator exam. Took me a year on my own to get through this prep book cover to cover (note that the current version for the current test is here, though.) Of note, I only had about a year's worth of linux experience when I started studying. At that point, I had: stood up a basic LAMP stack, implemented Apache and Postfix/Courier/Roundcube. At the time I was working as a (not so successful) photographer, and my goal at that time was to create a web hosting company that would let models host their website portfolios and send/receive IMAP email through their own domains. A month after I got the whole platform running, a little site came along called https://www.modelmayhem.com/ . Oops. I'm still super glad I did; working as an infrastructure engineer is the most rewarding job I've ever had.

Anyway, I'm just saying that you don't have to be a programming guru, but you'd do well to at least master bash, and become intermediate in one scripting language (I usually recommend python.)

Working Effectively with Legacy Code is a good book that sounds applicable to your circumstance. Michael Feathers defines untested code as legacy code, which makes sense to me. Unfortunately untested code tends to be untestable, but tests are required to confidently make changes, so you have to chip away at the monolith strategically.

For the future, a good book on growing new systems alongside tests that inform design is Growing Object-Oriented Software, Guided by Tests

https://www.amazon.ca/Business-Life-Dont-Deserve-Negotiate/dp/0965227499

I litterally saw that book on the shelf of a family member, nothing more to it Haha. Needed to share the coincidence.

The founder of Gruntwork also wrote a great book which has just been updated: Terraform: Up and Running

It took three years of work for me to put all the pieces together and figure out what's going on (and formulate my own opinions on what should be going on).

It's good to hear others echo many of my opinions (I only found out about DevOps when a coworker in QA suggested I read https://www.amazon.com/DevOps-Software-Architects-Perspective-Engineering/dp/0134049845 ).

A local minimum is definitely the way it feels, leadership is very comfortable with the way things are - which is very frustrating. If I made change, I don't know if I'd be thanked for it - but I don't think I'd be vilified for it either.

More like CS University curriculum. Such as https://www.amazon.com/Modern-Operating-Systems-Andrew-Tanenbaum/dp/013359162X/

/u/lordv0ldemort I would recommend:

https://www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380

https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Agile Testing is solid on principles. Don't be scared of the agile label, it's a sound foundation for understanding test automation.

I'm not sure what you mean by "from a DevOps perspective" though. To use an extreme example, if the test engineers are writing Selenium tests and running them locally in a QA silo, reading a book about modern test automation isn't going to help you communicate with them.

You'll be showing up in a tuxedo to find everyone else is wearing jeans and an old Mickey Mouse t-shirt. Yes, you're both wearing pants and your torso is covered, but that's about where the common ground ends.

There is a book devops troubleshooting that has alot of the scenarios you are asking for. Link

https://www.amazon.com/gp/product/0133390098/

The Design of Everyday Things by Don Norman. Then read the k8s docs. If you're working complex systems the book is also relevant.

https://www.amazon.com/dp/0465050654

Kaiten: Japan's Secret Manned Suicide Submarine and the First American Ship It Sank in WWII https://www.amazon.com/dp/0425272699/