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)