DevOps Spotlight - How To Start
Since DevOps is a culture of communication and understanding, it’s most important to first UNDERSTAND THE FLOW OF WORK.
DevOps defines four types of work:
- Business Projects (such as a new order system, or ecommerce)
- Internal IT Projects (such as cloud automation, or disaster recovery)
- Changes (such as deployments or server security updates)
- Unplanned Work (such as a site going down, or a server crash)
Using the example in my first article, we can see that poor old Widget World spent so much time with Unplanned Work that they couldn’t focus on important Internal IT Projects to ensure their Business Projects were successful.
Once we understand the work we’re doing, we can reframe it and make it visible.
This is highly important because not having visibility in digital work leads to poor decisions and a lack of focus on core issues in the system.
An example of this is if we’re selling physical products, I can walk into the warehouse and see pallets of inventory stacked up. I understand that there is money invested in these products that won’t be realized until they are sold and shipped to customers.
Where is the digital inventory in our development cycle? This is something we must understand to have visibility in our work.
Once we understand the work we’re doing, we ALWAYS SEEK TO INCREASE THE FLOW OF WORK. This is typically removing constraints.
Another example - If we’re in manufacturing, I can walk onto the factory floor and see pallets of widgets stacking up at one workcenter and understand that it’s waiting on work to finish somewhere down the line. With this understanding, I can shift priorities and resources around to clear this restraint and increase the flow of work, keeping this workcenter producing value as efficiently as possible.
Where are the digital constraints in our development cycle?
They may not even be in the development cycle, but in the operations or deployment - this means that development and operations need to work together to understand the systems and work as a team to remove constraints and increase the flow of work.
Improving quality improves the flow of work.
In traditional development, we pass along the product to the next workcenter (whether that’s another developer, QA, QC or Operations). In DevOps we seek to understand how to pass along knowledge with that product - how it works, how to test it, how it may react differently in other circumstances. This is shifting left in thinking and considers where the product is going and how it should function, not just where it came from.
Never unconsciously pass defects downstream. Understanding of the type of work and how it flows through the system, we implement changes to catch potential defects and correct them before they are released. There may be times that we consciously allow a defect into Production, although these reasons should be rare and not deadline-based. Just like taking on debt, we understand this accumulates technical debt, which comes with a significant interest rate and must be paid at some point in the future.
One of the easiest ways to catch and stop defects entering Production is to ensure environments match across Production, Staging, QA and Development. This is easier these days with Configuration Management tools like Chef, Puppet and Ansible. Cloud providers such as AWS, Azure and Google Cloud Platform make it simple to duplicate similar environments.
We can use DevOps tools (like Jenkins and CircleCI) to automate testing through Continuous Integration, this allows us to identify problems early and adapt our workflows or environment, or even the specs of the project so we can adapt to new knowledge we’ve gained for the best possible business outcome.
It’s also important to shift left on providing accurate and fast feedback to developers. This is AMPLIFYING THE FEEDBACK LOOP. This can be done with Application Performance Monitoring software (such as New Relic or DataDog), or simply shipping Production logs to development or cloud environments where they can be accessed and reviewed.
This allows Development to review how the application is being used in the wild by customers, instead of how it was designed to spec, or how the Quality Assurance and Quality Control teams tested it. Customers always find some unique and interesting way to use a system, and in a lot of cases that should be embraced and the system should be adapted to make these approaches more efficient.
We embrace CONTINUOUS EXPERIMENTATION and learning by practice, not by theory or study. We want to break things so we understand just how far we can go. But we must develop habits to understand when things are too risky and how to return to safety. We bend the rules - we break things - we test - and we learn.
You don’t learn to ride a bike by reading and studying a bike manual, then testing it once a year. You get on the bike every day, every time you fall, until one day you can’t exactly tell when you stopped falling and started riding.
We test not just the code, but every aspect of the system as often as possible. Deployments, team handoffs, Disaster Recovery, Business Continuity, Backups, etc. All of these processes can continue to be improved, but it takes PRACTICE to understand and learn from them.
This is the goal of DevOps - to practice and experiment until there are no surprises. Practice and work to reduce unplanned work. When we deploy to Production (as quickly and often as possible), we know exactly what will happen. And this understanding provides a foundation for business agility to adapt to market changes. This makes customers happy. This makes the business happy. This makes employees happy.
- Part 1: DevOps Spotlight - Why DevOps
- Part 2: DevOps Spotlight - DevOps Matters
- Part 3: DevOps Spotlight - How To Start
