We were interviewing someone for a DevOps position. They were working at a managed network / security services company and needed to change a life and career. Their work was pretty much summarized as “A client files a change request; we implement it at the network device and we’re done”.
No provisioning, no automation, no versioning of configurations was in place. The candidate was not in a position to write code also. Since they were clearly more junior than the position required, we were saddened and in a way gave them some subtle advice to improve on their skills in order to have better luck next time they knock on a door:
- Learn to program in Python.
- Do that because you can learn to code with paramiko and Netmiko.
- Learn some basic git usage.
- It does not matter that your employer does not require you to automate stuff and practice version control. You will write a program in Python that will ssh into the client’s equipment, backup the configuration in git and push the requested changes back.
- You will have automated your work and will have more free minutes per day to read about stuff.
- You will have more to talk about in your next interview.
When you’re not pushed by the environment, you need to begin from somewhere. Oh and understand some basic statistics, because you will need to understand what you graph. It should not only be pretty. It should be useful.
That went away fast. You can finish it in one shot. Especially if you are in one of the most thankless professions, with lots of responsibility and zero authority. The narrative, however thin, feels close to heart because this things happen. Or may have even happened to you or someone you know.
While this is no Phoenix Project, the first sixteen chapters serve to lay the playgound for implementing a proper postmortem process, where no one is afraid to withhold critical information. This along a very useful bibliography is presented in the last chapter.
- A Leader’s Framework for Decision Making
- How Complex Systems Fail
- From Safety-I to Safety-II
- The Field Guide to Understanding Human Error
- Thinking Fast and Slow
- Drop the Pink Elephant
As always, the hard thing is to make people who think that “rolling heads” improve morale and performance, to see the error of their ways.
Since monitoring is at the heart of managing infrastructures, time-series and measurements also, I believe it is time to remember what the first derivative is. Because all those graphs we make with Graphite, Graphana and friends are not only eye-candy. They have some meaning too. “The Art of Monitoring” speaks of the rate of change in its first chapter, but this has a formal name.
Now go hug your SysAdmin.
This is a free report that you can download from O’Reilly’s website. It deals with how DevOps was adopted to facilitate Nordstrom and Texas.gov (with a glimpse of how the Texas.gov CISO inserted security provisioning in the development processes).
If you’ve read The Phoenix Project and felt that OK this is nice, but it is also a novel, the Nordstrom story is an indication of how to adapt this outside a novel concept and into the real world. It is worth your time, especially in cases when you need to appeal to real world examples.
systemd are not very compatible yet. But it is here to stay and one can hold back their machines for only so much. Inevitably, no matter how much you delay it, you will migrate to operating system versions that support it. So here is the path that I figured out for smooth coexistence until systemd grows on you:
Do most of if not everything that you would try to do with systemd with something like puppet or ansible by applying playbooks locally. Configuration management / orchestration software already knows how to handle systemd and they do it well. Take advantage of that then.