The question that comes up the most when I talk to people who are interested in DevOps is "Where do I start?"
Most of the time, the answer they're looking for is a list of tools and technologies to learn, so they usually look disappointed when they hear my answer.
If you want to get started in DevOps, if you want to deliver faster and keep up with everything that's being asked of you without killing yourself in the process, tools and technology are the wrong places to start.
First, you need to change the way you view and manage your work.
Step 1 - Define what matters
What's the purpose of your work? Care and feeding of servers, or "developing" might be what you do, but they aren't reasons in themselves. "Keeping everything working" is almost a reason but mostly in the vein of "I eat to live."
Chances are, the purpose of your work is a little meta - it's to support the needs and goals of your employer, to provide value in some way. So what does your employer value? If you don't know, it's time to ask and figure out how your work relates.
You'll arrive at some ideas you can measure and center your work around - things like systems uptime, mean-time-to-resolution, code quality, customer satisfaction, and so on.
This is where you start. Everything going forward is tied to the baselines you set and how you measure your progress against the new metrics you're now tracking. You're about to bring some science to your job - observing, measuring, and iterating.
Step 2 - Kanban ALL the things!
Before you start automating and building robots to do all the work, you need to gain visibility to that work.
You don't have to use kanban, although I would highly recommend it as an easy place to start. (Also, personal kanban is my spirit animal.) But you do need some sort of methodology that gives the entire team visibility to the work backlog and highlights bottlenecks that slow work down or otherwise impact the performance indicators you defined in step one.
This will require that your team starts collaborating, both internally and with other groups. They may not be used to this. You may not be used to it either, but people have to talk to one another if they aren't already.
Once the team starts talking about what they're working on you'll quickly discover opportunities to quash duplicate work, misplaced work ("Why is our group even handling this?"), and problems that were otherwise going untracked or getting piled on one person.
If you're a developer and have already been using Scrum or some sort of Agile methodology, some of these concepts might not be completely new to you. Even if that is the case, you may not be accounting for all of the backlog or might only be focused very narrowly on project work.
Step 3 - Automate and iterate
By now you should have a better idea of your team and employer's goals as well as the work the team needs to accomplish. After dropping items from the backlog that are 1.) of little to no value, and/or 2.) never actually going to be worked on (it's important to be honest about this), it's time for some experiments.
Use your kanban to identify the biggest bottlenecks that slow down processing of the backlog and attack them with process and automation. It will be tempting to attack low hanging fruit for easy wins, but it's important to treat the bottlenecks as if nothing else matters (because it kind of doesn't).
Note: Quality issues are bottlenecks and should be treated as such. If people have to constantly spend time fixing crappy code, failed builds, or similar issues - that's getting in the way of other work.
It's usually OK to throw some smaller improvements into your sprints that fit around other work but automating away the problems that significantly delay work (like waiting for Ops to manually build out environments) is where the focus should be. Most of the other stuff is just distraction.
As you put different processes and automation in place, make note of it and track those events against your performance indicators. Measure. Iterate. Measure again.
Step 4 - Keep learning
It's hard for me to imagine anyone succeeding with DevOps without regularly dedicating some time to reading. For most, working via DevOps practices will feel a little foreign at first, so the more you know about what others are doing and the ideas that inspired DevOps, the more comfortable you'll be.
There are a ton of great books that cover DevOps concepts and related topics like lean manufacturing, interpersonal relationships(!), and automation. Here are a few:
- The Phoneix Project: A Novel About IT, DevOps, and Helping Your Business Win
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
- Personal Kanban: Mapping Work | Navigating Life
- The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services
- Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale
- Site Reliability Engineering: How Google Runs Production Systems
- The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer
DevOps is a buzzword that gets thrown around to the point that a lot of people think it's just a fad or marketing-speak. It definitely can be depending on what the person saying "DevOps" means.
In my experience though, the people and process components of DevOps are really powerful and can change your day-to-day work and make things better. Unfortunately, these are the components of DevOps that usually get ignored. People tend to chase the shiny penny of automation without all the front end work that ensures they're automating the right things.
If you're interested in "DevOpsing", I can't stress enough how important it is to start with steps 1 and 2 before doing anything else. If you do, I can almost guarantee you'll achieve some level of success, even if it's just in how you handle your own work.
Originally posted on chrisdodds.net
Top comments (6)
The one word I've not read is consistency (even used CTRL+F). It's one of the things I've been interested in since the 90's. I learned about inconsistency and programming when went to show someone a VB application, and it complained about a missing OCX-file. I Further learned when I tried to compile a Linux application under Windows. It used to infuriate me that nobody seemed to care.
For me efficiency and consistency are the only two drivers for any need to think about combining development and operations. Cost savings are almost tangential, because you could probably save money (short-term) by not testing, or following any one of a number of poor practices.
Once we've got consistency and efficiency (mostly for things few "want to care about"), we can proceed forward knowing the ground won't swallow us (or our free time) whole.
I think reliability is at the top of my list for "reasons to do DevOps". It's helped a lot by consistency, but that doesn't cover the whole of it. Establishing shared ownership and getting rid of the "well, that's an Ops problem" or "this is a Dev problem, send it back to them" goes a long way towards increasing reliability.
I'm fully on your side as far as shared ownership. It's probably because the businesses I work with are a lot smaller, but I still think it's important they have as much to gain (if not more) from embracing cross-over and all the benefits. Anyway great article, enjoy the weekend!
Though I mostly agree, I'd step back a bit and say step 1 definitely matters. Goin' Kanban is a good thing but it might not be the second important thing on your list, same as automation (even if it is extremely relevant and possibly can't be stressed enough either).
At the bottom, however, personal experience: Question organizational "walls". In quite a few approaches so far I have seen people considering DevOps to be something forcing "Ops" people to change their behaviour so to be more effective. But seeing one is trying to go *Dev*Ops makes it rather obvious there's "Dev" in this organizational context too. If there's "Dev", there is also very likely to be some product responsibility, someone in charge to do development planning and to earn money with whatever Dev and Ops do.
For me, the important thing about DevOps is and always has been that these folks - Development, Operations and "Product" people - do need to be aware that they do have a shared interest in earning money with a product. That's not just development, it's also not just operations, it's not just planning -- it's rather all these things put together. In some way this is where the "error budget" idea outlined in the Google SRE book jumps in:
This idea only works if the "product" person knows enough about the operation issues of the system (s)he's in charge for, too - downtimes, bottlenecks, required administration effort, ... .
This idea, too, only works if (talking agile development) a dev team is aware of operational issues and has a Definition Of Done that includes operation non-functional requirements as well. Maintainability needs to be first-class citizen in each software component built, but this doesn't happen out of the blue.
By now, most of these things (still) are sort of isolated: Product planning very often happens in (best case) in a customer-driven echo chamber where operation issues aren't of much relevance. Development is in a process to quickly work through this product planning and strategy, doing agile implementations of user stories and isn't really aware of operations issues. And operations, at the end of that line, is supposed to do effective maintaineance of all this in a production environment. Getting operations feedback and requirements back into the product development cycle and getting development, operations and planning people to speak to each other in a structured and planned way should be way up your priorities list. ;)
Really liked the detailed article on this topic. I wish I found it earlier. However, recently I completed the courses from this site: bit.ly/2K6Bygt and also achieved my certification. Anyone who wants to start career with DevOps in the shortest possible time, can try the training I took. Highly recommendable for the fellow learners.
Nice! I'd recommend a look at the best DevOps tutorials.