Exploration of what DevOps is and isn't, and how this IT environment model can be used to improve our work at UW.

1. DevOps
What is it?
Do we want it all?
How are we doing?

2. What is DevOps? (according to Wikipedia)
• software DEVelopment and information technology OPerationS
• “A set practices that emphasize the collaboration and communication
of both software developers and information technology professionals
while automating the process of software delivery and infrastructure
changes”
• “Establishing a culture and environment where building, testing, and
releasing software can happen rapidly, frequently, and more reliably”
• Generally agreed to have started around 2008-2009 (devopsdays.org)

3. What is DevOps? (my personal definition)
• The art and science of identifying and automating the routine parts of managing
information, software, and technology for rapid, reliable deployment
• A framework/toolset that helps technologists focus on the interesting parts of our
work and lets non-technologists focus on their core jobs
• By this metric, DevOps in some form has been around as long as there has been
systems administration
• “Fighting fires” is not interesting in a good way
• Unplanned incidents consume resources uncontrollably (wildfire)
• Planned, proactive fire management is better
• Forestry to manage the forest, plus understanding how fires could start and
when controlled burns are needed, is best

4. What motivated me to think about DevOps?
• The Phoenix Project: a novel about IT, DevOps, and helping your business
win by Gene Kim, Kevin Behr, George Spafford
(http://itrevolution.com/books/phoenix-project-devops-book/ )
• Our protagonist inherits an IT infrastructure which is badly broken
• Catastrophe -> heroic recovery -> maybe learning (repeat)
• Incremental improvements to understanding, infrastructure
• Ticketing system to make work visible (with actual tickets: KanBan!)
• Identify and ameliorate bottlenecks (Brent)
• Prioritize IT work by understanding business needs, IT infrastructure
• Develop knowledge of and skill in workplace politics

5. Real life DevOps example: npm
• https://speakerdeck.com/ceejbot/devops-at-npm-scaling-the-registry
• CJ Silverio, CTO at npm, describes how they scaled up infrastructure
to create a usable global Node.js registry
• Moved from best guess predictive scaling to reactive monitoring
and scaling to proactive improvements based on reliable metrics
• Infrastructure was exciting for several months while trying to meet
increasing demand
• Sometimes learned what needs to be monitored by having it break
• “The goal is to be boring”

6. Real life DevOps example: Etsy
• https://codeascraft.com/2012/05/22/blameless-postmortems/
• John Allspaw, CTO at Etsy, writes about their culture where failure
is expected and used to learn how to make improvements
• Human error is inevitable
• Equip ourselves to better deal with problems that may arise
• Give people the authority to make things better
• Just Culture requires understanding personal reactions to failure

7. Does Arts need DevOps?
(audience participation time)
• Why are we here?
• Do we develop technology solutions to help Arts work effectively?
• Are we solely/primarily a support organization?
• Should we be?
• Should central IT be where DevOps happens?
• How effectively do we work across units?

8. What DevOps Isn’t (busting a few myths, 1/n)
• A replacement for Agile
• The Agile Manifesto http://agilemanifesto.org/principles.html (created in
2001) is about building and maintaining software responsively
• In a sense, DevOps is an extension of work flow practices used in
Agile/Extreme/Lean/Scrum methods to technology management
• Agile is not a prerequisite for DevOps
• Flexible IT service delivery can support Agile software development
• Our job isn’t over when code is fully tested and in production
• Do we use Agile/Lean software development or project
management?

9. What DevOps Isn’t (2/n)
• A replacement for ITIL
• ITIL is a set of best practices
• ITIL and ITSM describe capabilities needed to support DevOps
• Service design is relevant
• Problem management is relevant to DevOps, too
• Many processes codified in ITIL can be automated
• This includes change, configuration, release processes
• As with Agile, DevOps can enable ITIL implementation
• Do we use ITIL? Has this changed in the past year?

10. What DevOps Isn’t (3/n)
• NoOps (entirely eliminating IT Operations)
• Many IT operations tasks become self service under DevOps
• Pushes some operations functionality to groups that don’t
have an operations focus, e.g. development
• Operations still has responsibility to maintain and develop
the environment that makes everyone’s job less frustrating
• Are there areas of our work where we use NoOps? Do we
consume any NoOps services? Would we like to?

11. What DevOps Isn’t (4/n)
• Linked primarily to Open Source
• Principles are universal
• You don’t need a LAMP stack: independent of underlying technology
• Some DevOps requirements are common in Open Source environments
• automated testing
• configuration management
• version control
• How much of our work relies on vendor solutions? Open
source? Home grown software?

12. What DevOps Isn’t (5/n)
• Infrastructure as code (nothing but automation)
• Many patterns require automation
• We also need mutual trust, shared goals
• Understanding how technology enables the business and how
people (technologists and non-techs) get things done
• The business of higher education has a lot of moving parts
• How much of our work involves knowing academic,
administrative work flows?

13. What DevOps Isn’t (6/6)
• For tech startups and behemoths/unicorns
• Google, Amazon, Twitter, LinkedIn, Esty, Facebook started with
traditional IT Operations practices
• DevOps practices are widespread across industries
• Financial services (Bank of America, Paychex, World Bank)
• Retailers (REI, Macy’s, GameStop)
• Higher education (UBC, Kansas State)
• US and UK government agencies
• Does DevOps make sense for Arts Computing? For UW?

14. What DevOps is: core concepts
The three ways
The four types of work
Monitoring and visibility

15. The three ways of DevOps
(looks a lot like Toyota Production System)
Left to right flow of work
Right to left flow of information
Creating a culture where errors and feedback are normal

16. Left to right flow of work
• Work in progress always moves forward
• Development -> IT Operations -> end user
• Small batch sizes and intervals
• Do not pass defects downstream
• Constantly optimize for global goals
• Continuous build, integration, deployment
• Create environments on demand
• Limit work in process
• Build safe systems
• Build infrastructure that is resilient to change in requirements, environment, demand

17. Right to left flow of information
• Constant, fast feedback at all stages
• Amplify information
• Identify exceptions
• Speed up exception detection and recovery
• Prevent problems from recurring
• Stop everything when something goes wrong
• Improvement of work takes precedence over the work itself
• Fast, automated testing
• Shared goals among business, development, operations
• Pervasive, visible production telemetry

18. Creating a resilient culture
• Foster continual experimentation
• Reward taking risks
• Learn from both failure and success
• Improve relentlessly
• Innovation demands a high level of trust
• Understand: repetition and practice are needed for mastery
• Develop reliable skills and habits
• How can we help each other be comfortable taking risks?

19. The four types of work that IT does
• Business projects (why we get paid)
• The work of the organization, often software development/projects
• This includes some client support of various kinds as well
• IT projects (how we make it easier to do what we get paid for)
• Infrastructure creation/maintenance
• Internally generated improvement work
• Changes (planned updates because we don’t exist in a bubble)
• Feature development, service delivery, patches
• Unplanned work (forest fires)
• Incidents, problems

20. Why track (and visualize) these types of work?
• Evaluate our performance
• Identify bottlenecks
• Identify priorities
• Plan use of resources
• Avoid resource starvation
• People are resources too
• http://images.itrevolution.com/images/kanbans/waittime_vs_percentbusy.jpg

21. How are we doing?
• Following the three ways (workflow, flow of feedback, flow of trust)
• How much of each of four types of work we do (Arts, IT, change, fires)
• Can we measure this more effectively?
• Identifying and fixing bottlenecks
• Automating what we can
• Figuring out what can be automated
• Understanding the business that makes our work necessary
• Tell me about the Faculty of Arts; how does it work?

22. Where do we go from here? (homework)
• Automate something you do by hand
• Help a client automate something
• Look at what you see in monitoring results
• Fix it so it’s actionable or response is automated
• Find out what your supported departments and programs are
doing/planning and how we can help them
• Prepare to take a two week vacation without checking email
• Check in with team on your progress in 2-6 months (set deadline)

23. Thanks!
Questions?
Comments?