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

1. 3 Key principles

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

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

1.1.2. Make Work Visible

1.1.3. Limit WIP

1.1.4. Reduce Batch Sizes Small batch strategy - single piece flow All steps required to complete each work item are performed sequentially before starting on the next item

1.1.5. Reduce Number Of Handoffs automate and reorg reduces time work spend waiting in queue

1.1.6. Continually Identify & Elevate Constraints BP: Five Focuses Steps 1. Identify primary constraint 2. Decide how to exploit constraint 3. make that no 1 focus 4. Elevate that system constraint Typical DevOps Contraints Environment Creation Code Deployment Test Setup and Execution Bad Architecture ( tight architecture)

1.1.7. Eliminate Waste 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 Partially done work - never used decreases value over time Extra Processes ( that aren't needed) added effort increase lead time and Extra Features (that aren't needed) - add complexity and effort to dev test and manage Task Switching Waiting Motion - effort to move information from one work center to another Defects - harder to fix the longer time btw defect creation and detection Non-standard or Manual Work - eg manually creating customer non rebuilding servers. Best Practice: dependancies should be automated, self servied and available on demand Heroics:

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

1.2.1. Create safer systems of work by creating fast, frequent high quality information flow throughout the value stream and org results in detect and fix problems that are smaller, cheaper and easier to fix avert probs b4 they become a catastrophy create organization learing treat failure as opportunity to learn bs pusing and blame

1.2.2. Complex Systems attributes: system beahvior cannot be explained intermeds of components doing the same thing twice may not predictably lead to the same result no single person know how it all works and how pieces fir togehter tightly coupled components Failure Is Inherant So need to design a safe system of work where errors can be detected quickly mitigating imact Focus on beating able to react quickly. Recover from failure MTTR not prevent failure MTBF Dr Spear HBR Harvard. 4 ways to make complex systems safer to work

1.3. Continual Learning and Experimentation

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

1.3.2. Learning Organization & Safety Culture Not name , blame and shame Dr Ron Westrum Healthcare observations Patholological Beureaucratic Generative

1.3.3. Build In Improvements of Daily work In absence of Improvements, process get worse and degrade over time from chaos and entropy reserve time to address technical debt BP: Kaizen blitzes - periods when engineers self organize to fix any problems they want BP: Improvement Kata

1.3.4. Transform Local Discoveries into Global Improvements share code repositries, shared libaries, store and shares post mortem reports

1.3.5. Inject Resilience Patterns into Daily work Apply stress/tension to increase resilience ( Nassim Nickolas Taleb) increase test coverage decrease test execution times re-architect ot improve developer efficiency chaos engineering

1.3.6. Leadership reinforcing a learning culture Traditional Leadership Approach has leaders make all the right decisions set objecetives allocated resources establish incentives set the tone No HIPO !! Better: create conditions so team can discover greatness in daily work coach team to apply scientific learning approach help teams gain autonomy by giving them TRUST and VOICE

2. Decreased Change Failure Rate

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

3.1. Agile Manifesto

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

3.2. Agile Infrastructure

3.3. Continuous Delivery Movement

3.3.1. Pioneered by Jez Humble and David Farley

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

3.3.3. Key Tenets comprehensive, fast and reliable test and deployment automation Trunk-based development with continuous integration App Code and config ( infra-code) are all in the same version control Automated Deployment pipeline: automated implementation of systems build, deploy test and release processes monitoring & visibility feedback control Loosely coupled Architecture Continuous Testing

3.4. Toyota Production System

3.4.1. Continuos Learning

3.4.2. Andon Chord

3.4.3. Work Important more important that the work itself

3.5. The Lean movement

3.5.1. Projects vs Products Do Not Change Over Time Cannot be used until completely built

3.5.2. Key Tenets: Manufacturing Lead time was the best predictor of quality, customer satisfaction and employee happiness small batch sizes of work was the best predictor of short lead times

3.5.3. Value Stream Mapping Value is only created when services are running in production Value Stream: sequence of activities required to design a goods/service to customer showing materials and information flow. Technology Value Stream: process required to convert a business hypothesis into a technology enabled service that delivers value to the customer. First Phase - Product Design (Design & Dev) Second Phase - Product Delivery ( build, testing, deployment) Small batches and build quality in every part of the value stream Key Metric: Lead Time. total time to fulfill a request. Includes wait time in queue DevOps Metric 1 : Deployment Lead Time Term: Processing Time. just the time to do the work to complete a task DevOp Metric 2 %Complete/Accurate the quality output of each step

3.5.4. Kanban Boards

4. Benefits

4.1. IT Improvements

4.1.1. More Reliability MTTR - how long to restore service after an incident occurred

4.1.2. Higher Throughput Lead time for changes - how long form code commit to successfully running on PROD Deployment Frequency

4.2. Company Improvements

4.2.1. More productivity

4.2.2. Increased Market Share

4.2.3. More profitability

4.2.4. More Market Cap growth

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