This week I had an opportunity to present to a group of customers at the NowForum in NYC. The interaction was great and this blog post is a result of some of the specific questions my co-presenter, Chris Collazo and I received. Interestingly enough of the five questions that stuck out to me most, three were from global 1,000 companies and two were from organizations with less than 5,000 employees. Although the application of DevOps & ITSM joint best practices may be a bit different in these org's, the overall
principles are just as valid for both.
Why do DevOps
Here are some key findings from Puppet's 2016 State of DevOps Report
200 X more frequent deployments
2,555 X faster lead times
24 X faster MTTR
50% less time remediating security issues
22% less time on unplanned work & rework
What is DevOps / History
DevOps often means different things to different people. However typically it refers to the collaborative relationship between the DEVelopment and the OPerationS teams within a given organization. The goal being the things highlighted above in the "Why do DevOps" section of this post. In a nutshell it is communication, collaboration and shared business outcome goals across the teams within IT, including not only just Dev & Ops, but also every other IT team in the most respected IT organizations. Success is much easier when everyone is aligned to the same scoreboard, regardless of if they are in Dev, Ops, Security, etc.
DevOps is a movement that is a continuation of the Agile Methodology. Many people point to a presentation at the 2009 Velocity conference by John Allspaw and Paul Hammond titled "10 Deploys Per Day: Dev and Ops Cooperation at Flickr" as the birthplace of the DevOps movement. This is a must watch if you have not seen it.
Please keep in mind that although some people would say ITSM only gets in the way of DevOps, it is my firm believe that ITSM actually makes DevOps better when everyone is aligned.
How do people do it? (the 3 ways)
In "The Phoenix Project" the authors describe the underpinning principles of DevOps patterns as "The Three Ways."
The First Way: Flow
In this way, the focus overall is throughput. Therefore as you can imagine "Theory of Constraints" is a major factor. As Dr. Eliyahu Goldratt points out in his book "The Goal", making a change to anywhere in the system that is not the constraint (or bottleneck) is cosmetic at best. Instead we should focus on identifying the single constraint that dictates the flow, then working to remove this constraint, thereby improving the whole system.
The Second Way: Feedback Loops Amplified
Faster flow is great, but not at the expense of quality. We must improve feedback & visibility to realize the gains of faster flow. Reducing the time between iteration feedback and ensuring dev listens to the feedback are the key goals here.
The Third Way: Continual Learning
As a continuation of the second way, in the third way we seek to dramatically reduce not only the feedback cycle time but also the TTM (time to market) of our code by reducing its scope. Think of how many micro pushes you could make in a day rather than a complete system upgrade every six months. This also greatly reduces the risk as these micro changes can often be implemented on a reduced scale and flagged active only once we are comfortable we understand their impact. In a failure scenario our risk is also greatly reduced as micro changes often affect a very limited scope of targets, therefore the rollback, if needed is not as impactful.
Another consideration is mastery coming from repetition. If I stay in very traditional support role with a code drop twice a year over a 30 year career, then I am supporting 60 code drops in my entire career. If I go with DevOps style micro code drops 5 times a month, then I get the experience gained over 30 years in just one year. For believers in continuous iteration, this gives me more chance to learn and get better.
Adoption Challenges
Challenges
Breaks Business as Usual
Requires shared Dashboard / Tools
Transparent change tracking
3 Keys to Success
Usually restructuring of teams required (NOT EASY)
Communication is KEY!
Shared Views / Reporting — Do we see things the same way?
Add Value Now
There are many great tools out there from Jira, Jenkins, OnTime Scrum, Microsoft TFS to Puppet, Chef, Salt Stack and Ansible. These are solid solutions and should be leveraged, but none of these tear down the walls between Dev & Ops. Dev may have automated app release, but are they just throwing releases over the same wall quicker? Ops may have automation delivery, but do they truly understand the delivery pipeline?
This is where ServiceNow gives visibility to the dependencies that are always there. How much better would it be to have both sides of this looking at the same dashboard, as opposed to how we typically look at different dashboards based on your role, then wonder why the other person doesn't't see it our way?
Metrics Important to DevOps (btw - we cover them all in single pane of glass )
Mean Time between Deployments
Average and Max Deployments per hour (or min, month, year, etc)
Deployment Lead Time
MTTR (Mean Time to Recovery)
Change Success Rate
Task Time per Person
Risk Score by Service
Visibility and Accountability | How ServiceNow can help!
ServiceNow has been providing visibility and accountability to organizations for a long time. In the DevOps movement, we are ready today with the proven system you need to move forward, just give us a chance to show you. Here are some key ways we can help:
End-to-end value stream in a single system — from idea to deplo
Single system of record, traceability
Visualize shared goals around successful change as well as stability
Integrate with best of breed tools
Git, Jenkins, Puppet, Chef, etc…
Reporting and asset tracking.
Agile values applied to IT Operations
High levels of automation that can rely on
Operations and Development data
Action Steps
1 — Watch "10 Deploys Per Day: Dev and Ops Cooperation at Flickr". and read "The Phoenix Project".
2 — Make a conscious effort to get key champions on each team in your org.
3 — Take a close look at your CAB metrics. Is this a point of contention with your developers? If it is, then what can be automated? Many organizations leverage ServiceNow's workflow process to make determinations on the approval process such as standard changes being auto approved with notification of all potentially affected parties, some changes requiring CAB meeting approval and higher risk/impact changes going to an executive CAB.
Becoming a truly agile Fast Fish is a journey of 10,000 steps, but we know the way and help you get started today!
Changing the way people work is what we do …
Call us in and we can help you get this key planning done.
