Andrew “Dice” Clay Schafer of Cloudscaling on Change Management – A Scientific Classification.
The Dunning-Kruger effect says we can’t always judge our own level of competence.
Often we prefer confidence over expertise.
You have probably confidently deployed a disaster.
Premise: Everyone is working to enable value creation for a business. (Or should be out the door.)
If you don’t understand what creates value for your organization, how can you be good at your job?
Change Management: A structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state.
You look into doing this in the technology sphere. Soon you get to the ITIL framework and you crap your pants.
Web Operations Renaissance
Process innovation is a differentiator that is driving value creation.
You can add value with performance, scalability, performance, and agility.
The 6 Laws of Reliability by Joe Armstrong of Ericsson (all this comp sci theory stuff was worked out in like the 1960s, just go look it up.)
- isolation
- concurrency
- faulire detection
- fault identification
- live upgrade
- stable storage
One approach – Cowboysaurus Rex. Make changes live to production!
It’s fast and flexible. But we suck at doing it safely. Throwing more meat at it is a poor way of scaling.
The next approach – Signaturus Maximus – laying in the bureaucracy.
It adds adult supervision and has fewer surprises, but it slows things down. And people don’t follow the process. When there’s a crisis, it’s back to cowboy.
Next approach, ITIL Incipio!
Now, there are some good guidelines. But no one knows what it really says. And the process can become an end unto itself. And when there’s afire, you break out of it and go back to cowboy.
Condo Adeptus.
Computers are better than people at doing the same thing over and over. But, nothing can bring down your systems like automation. If you don’t test it, you jack yourself.
Novus Probator.
Your system is an application. Run it through a dev process, and testing. But we suck at testing. Testing is its own skill and is often an afterthought.
Prodo Continuus.
All production all the time- “continuous deploy.” If you build up the scaffolding to support it, you can push to prod without fear (almost). You get feedback from prod very fast. But we still suck at testing. But you don’t break the same thing twice.
What are we neglecting? ell, what are you building?
You have some things that are less important (twitter) and ones that are more critical (your bank) and crazy critical (medical).
When we talk about changes, we assume it’s mostly apps, kinda some OS as those are less sensitive. Maybe CPU, bot not really storage and network. There is a criticality path but as much as you can do infrastructure as code all the way down the stack, the better.
There’s also a continuum of situation – from building to firefighting. Perhaps different approaches are somewhat merited.
Dependencies aren’t just technology. There are people in the value chain who need to know, and they are in different roles from us. We need to be transparent to all those other folks and communicate better.
The wall of confusion between roles (like dev and ops) makes people sad if there’s not communication. Hence, DevOps! But there are many groups and many walls.
David Christensen’s FSOP (flying by the seat of your pants) cycle describes the problem – we don’t even know what best practices are yet. Find some, use the, but go back to flying. Never calcify anything you don’t have to.
Change your organization. “But it’s hard and there’s politics!” Strive to make the place where you work the place you want to work, And if that doesn’t work out, there’s a place you should come work!
Come to DevOpsDays on Friday for more on how to do this!
the agile admin 