Get Started. It's Free
or sign up with your email address
Dev Ops by Mind Map: Dev Ops

1. Decreased Change Failure Rate

2. Genesis. Dev Ops is the result of applying trusted proven lean manufacturing principles of physical items to the technology/IT value stream.

2.1. Agile Manifesto

2.1.1. lightweigh values and principles- to address heavywigh SLDC processes like waterfall.

2.2. Agile Infrastructure

2.3. Continuous Delivery Movement

2.3.1. Pioneered by Jez Humble and David Farley

2.3.2. ability to get changes into production safely quickly and in a sustainable way

2.3.3. Key Tenets

2.3.3.1. comprehensive, fast and reliable test and deployment automation

2.3.3.2. Trunk-based development with continuous integration

2.3.3.3. App Code and config ( infra-code) are all in the same version control

2.3.3.4. Automated Deployment pipeline: automated implementation of systems build, deploy test and release processes

2.3.3.4.1. monitoring & visibility

2.3.3.4.2. feedback

2.3.3.4.3. control

2.3.3.5. Loosely coupled Architecture

2.3.3.6. Continuous Testing

2.4. Toyota Production System

2.4.1. Continuos Learning

2.4.2. Andon Chord

2.4.3. Work Important more important that the work itself

2.5. The Lean movement

2.5.1. Projects vs Products

2.5.1.1. Do Not Change Over Time

2.5.1.2. Cannot be used until completely built

2.5.2. Key Tenets:

2.5.2.1. Manufacturing Lead time was the best predictor of quality, customer satisfaction and employee happiness

2.5.2.2. small batch sizes of work was the best predictor of short lead times

2.5.3. Value Stream Mapping

2.5.3.1. Value is only created when services are running in production

2.5.3.2. Value Stream: sequence of activities required to design a goods/service to customer showing materials and information flow.

2.5.3.3. Technology Value Stream: process required to convert a business hypothesis into a technology enabled service that delivers value to the customer.

2.5.3.3.1. First Phase - Product Design (Design & Dev)

2.5.3.3.2. Second Phase - Product Delivery ( build, testing, deployment)

2.5.3.4. Small batches and build quality in every part of the value stream

2.5.3.5. Key Metric: Lead Time. total time to fulfill a request. Includes wait time in queue

2.5.3.5.1. DevOps Metric 1 : Deployment Lead Time

2.5.3.6. Term: Processing Time. just the time to do the work to complete a task

2.5.3.7. DevOp Metric 2 %Complete/Accurate

2.5.3.7.1. the quality output of each step

2.5.4. Kanban Boards

3. Benefits

3.1. IT Improvements

3.1.1. More Reliability

3.1.1.1. MTTR - how long to restore service after an incident occurred

3.1.2. Higher Throughput

3.1.2.1. Lead time for changes - how long form code commit to successfully running on PROD

3.1.2.2. Deployment Frequency

3.2. Company Improvements

3.2.1. More productivity

3.2.2. Increased Market Share

3.2.3. More profitability

3.2.4. More Market Cap growth

4. 3 Key principles

4.1. Flow: We want fast flow from left to right.

4.1.1. Accelerate Delivery of work from Dev to Operations to customers

4.1.2. Make Work Visible

4.1.3. Limit WIP

4.1.4. Reduce Batch Sizes

4.1.4.1. Small batch strategy - single piece flow

4.1.4.1.1. All steps required to complete each work item are performed sequentially before starting on the next item

4.1.5. Reduce Number Of Handoffs

4.1.5.1. automate and reorg

4.1.5.2. reduces time work spend waiting in queue

4.1.6. Continually Identify & Elevate Constraints

4.1.6.1. BP: Five Focuses Steps

4.1.6.1.1. 1. Identify primary constraint

4.1.6.1.2. 2. Decide how to exploit constraint

4.1.6.1.3. 3. make that no 1 focus

4.1.6.1.4. 4. Elevate that system constraint

4.1.6.2. Typical DevOps Contraints

4.1.6.2.1. Environment Creation

4.1.6.2.2. Code Deployment

4.1.6.2.3. Test Setup and Execution

4.1.6.2.4. Bad Architecture ( tight architecture)

4.1.7. Eliminate Waste

4.1.7.1. Implementing Lean Software Development: From Concept to Cash ( Mary and John Poppendiek) waste is anything the causes delays for the customer and can be bypassed without affecting the result

4.1.7.2. Partially done work - never used decreases value over time

4.1.7.3. Extra Processes ( that aren't needed) added effort increase lead time and

4.1.7.4. Extra Features (that aren't needed) - add complexity and effort to dev test and manage

4.1.7.5. Task Switching

4.1.7.6. Waiting

4.1.7.7. Motion - effort to move information from one work center to another

4.1.7.8. Defects - harder to fix the longer time btw defect creation and detection

4.1.7.9. Non-standard or Manual Work - eg manually creating customer non rebuilding servers.

4.1.7.9.1. Best Practice: dependancies should be automated, self servied and available on demand

4.1.7.10. Heroics:

4.2. Feedback. We want fast and constant feedback from right to left to achieve quality, reliability and safety.

4.2.1. Create safer systems of work by creating fast, frequent high quality information flow throughout the value stream and org

4.2.1.1. results in

4.2.1.1.1. detect and fix problems that are smaller, cheaper and easier to fix

4.2.1.1.2. avert probs b4 they become a catastrophy

4.2.1.1.3. create organization learing

4.2.1.1.4. treat failure as opportunity to learn bs pusing and blame

4.2.2. Complex Systems

4.2.2.1. attributes:

4.2.2.1.1. system beahvior cannot be explained intermeds of components

4.2.2.1.2. doing the same thing twice may not predictably lead to the same result

4.2.2.1.3. no single person know how it all works and how pieces fir togehter

4.2.2.1.4. tightly coupled components

4.2.2.2. Failure Is Inherant

4.2.2.2.1. So need to design a safe system of work where errors can be detected quickly mitigating imact

4.2.2.2.2. Focus on beating able to react quickly. Recover from failure MTTR not prevent failure MTBF

4.2.2.2.3. Dr Spear HBR Harvard. 4 ways to make complex systems safer to work

4.3. Continual Learning and Experimentation

4.3.1. foster high trust culture, and scientific approach to Org improvement and risk taking as part of daily work

4.3.2. Learning Organization & Safety Culture

4.3.2.1. Not name , blame and shame

4.3.2.2. Dr Ron Westrum Healthcare observations

4.3.2.2.1. Patholological

4.3.2.2.2. Beureaucratic

4.3.2.2.3. Generative

4.3.3. Build In Improvements of Daily work

4.3.3.1. In absence of Improvements, process get worse and degrade over time from chaos and entropy

4.3.3.2. reserve time to address technical debt

4.3.3.3. BP: Kaizen blitzes - periods when engineers self organize to fix any problems they want

4.3.3.4. BP: Improvement Kata

4.3.4. Transform Local Discoveries into Global Improvements

4.3.4.1. share code repositries, shared libaries,

4.3.4.2. store and shares post mortem reports

4.3.5. Inject Resilience Patterns into Daily work

4.3.5.1. Apply stress/tension to increase resilience ( Nassim Nickolas Taleb)

4.3.5.2. increase test coverage

4.3.5.3. decrease test execution times

4.3.5.4. re-architect ot improve developer efficiency

4.3.5.5. chaos engineering

4.3.6. Leadership reinforcing a learning culture

4.3.6.1. Traditional Leadership Approach has leaders make all the right decisions

4.3.6.1.1. set objecetives

4.3.6.1.2. allocated resources

4.3.6.1.3. establish incentives

4.3.6.1.4. set the tone

4.3.6.1.5. No HIPO !!

4.3.6.2. Better: create conditions so team can discover greatness in daily work

4.3.6.2.1. coach team to apply scientific learning approach

4.3.6.2.2. help teams gain autonomy by giving them TRUST and VOICE

5. Job of IT.

5.1. Deliver fast uniterupted flow of planned work that delivers value

5.2. minimizing impact and disruption

5.3. provide stable predictable and secure IT services