you see on the Web, who probably don't know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise. This is true even when you factor in the greater flexibility and velocity of startups. - Tim Bray, 2010 tbray.org/ongoing/When/201x/2010/01/02/Doing-It-Wrong
67 deploys of 496 changes by 18 people” – Flickr Dev Blog December 17th 2008 "10+ Deploys Per Day: Dev and Ops cooperation at Flickr" youtu.be/LdOe18KhtT4 at Velocity 2009
on April 25, 2013, Quora released new versions of the site 46 times. This was a normal day for us.” - Quora engineering.quora.com/Continuous-Deployment-at-Quora “Deployment every 11.6s, 1,079 max in one hour. 10,000 mean number of hosts per deployment, with 30,000 maximum” - Amazon. com youtu.be/dxk8b9rSKOo “On the Google Consumer Surveys team, 8 minutes after you commit code it's live in production.” - Google developers.google.com/live/shows/772717729 “10+ deploys per day.” - John Allspaw, 2009 youtube.com/watch?v=LdOe18KhtT4
word 'devops,' thinking it's just about development and operations working together. Systems thinking advises us to optimize the whole; therefore devops must apply to the whole organization, not only the part between development and operations." — Patrick Debois
going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise." — Ward Cunningham, 1992 c2.com/doc/oopsla92.html
well that their industry counterparts are competitors in name only? Although they operate in the same industry, serve the same market, and even use the same suppliers, these extraordinary, high-velocity organizations consistently outperform all the competition ― and, more importantly, continually widen their leads. amzn.to/244hF7Z
likely beyond our abilities, safe systems are close to achievable when the four following conditions are met ... 1. See problems as they occur. amzn.to/244hF7Z
likely beyond our abilities, safe systems are close to achievable when the four following conditions are met ... 1. See problems as they occur. 2. Swarm and solve problems as they are seen to build new knowledge (fast). amzn.to/244hF7Z
pull the Andon cord and the whole production line stops immediately, and it doesn't start again until the issue has been resolved. I've pulled it thousands of times and it's good because it makes everyone personally responsible for producing the highest quality car." Bridie Tucker Team Member, Trim Assembly Toyota Burnaston, UK On a typical Toyota plant, the Andon cord is pulled ~3500 times every day.
likely beyond our abilities, safe systems are close to achievable when the four following conditions are met ... 1. See problems as they occur. 2. Swarm and solve problems as they are seen to build new knowledge (fast). 3. Spreading new knowledge throughout. amzn.to/244hF7Z
this capability] was that a young crew and their officers setting out for their first cruise on a US naval vessel benefits from the collective experience gained from over 5,700 reactor-years of experience behind them." — Dr. Steven Spear amzn.to/244hF7Z
likely beyond our abilities, safe systems are close to achievable when the four following conditions are met ... 1. See problems as they occur. 2. Swarm and solve problems as they are seen to build new knowledge (fast). 3. Spreading new knowledge throughout. 4. Leading by developing amzn.to/244hF7Z
deploys / day in May 2011 May 4, 2016. AWS Summit Stockholm ~50 million deploys / year ~136K deploys / day “Deployment every 11.6s, 1,079 max in one hour. 10,000 mean number of hosts per deployment, with 30,000 maximum” - Amazon. com youtu.be/dxk8b9rSKOo
and Operations ("the Process") Create new products and services that improve the lives of customers by using hypothesis-driven development and fast feedback from users. Enable fast flow from Development to Production and reliable service to customers by standardizing work, reducing variability and batch sizes. Feature design and implementation may require work that has never been performed before. Estimates are highly uncertain. Outcomes are highly variable. Integration, Test and Deployment operations must be performed frequently (i.e. whenever an engineer checks in code into version control, multiple times per day) and as quickly as possible. Cycle times should be well-known and predictable. Outcomes should have low variability.
of devs and ops to share a "common source of truth" • effectiveness of our automated testing in the deployment pipeline • ability to quickly deploy into production without causing chaos and disruption • ability to detect and correct problems through monitoring • ability for devs and ops to work together in a way that is win/win • how quickly devs can get feedback on their work
time to restore service change fail rate How long is the delay between a request for a change, and a production system operating with that change implemented? How long does it take for an abnormal behavior in the system to be restored to the normal standard agreed way of operation? How many changes and features are being released to production in a fixed period of time? How often the system fails or service is disrupted?
practices high cooperation Cross-functional teams. Many organizations create cross-functional teams that include representatives from each functional area of the software delivery process (business analysts, developers, quality engineers, ops, security, etc.). This allows everyone to share the responsibility for building, deploying and maintaining a product. How to build a Generative Culture
practices Messengers trained Blameless postmortems. By removing blame, you remove fear; and by removing fear, you enable teams to more effectively surface problems and solve them. Mistakes happen. Holding blameless postmortems is a valuable way to learn from mistakes. How to build a Generative Culture
practices Risks are shared Shared responsibilities. Quality, availability, reliability and security are everyone’s job. One way to improve the quality of your services is to ensure that devs share responsibility for maintaining their code in production. The improvement in collaboration that comes from sharing responsibility inherently reduces risk: With more eyes on the software delivery process, it’s a given that some errors in process or planning will be avoided. Automation also reduces risk, and with the right tool choice, can enable collaboration. How to build a Generative Culture
practices Bridging encouraged Breaking down silos. In addition to creating cross-functional teams, techniques for breaking down silos can include co-locating ops with the dev team; including ops in planning throughout the software delivery lifecycle; and implementing ChatOps.6 How to build a Generative Culture
practices Failure leads to inquiry Blameless postmortems. Our response to failure shapes the culture of an organization. The more you focus on the conditions in which failures happen, as opposed to blaming individuals for failures, the closer you’ll get to creating a generative culture. How to build a Generative Culture
practices Novelty implemented Experimentation time. Giving employees freedom to explore new ideas can lead to great outcomes. Some companies give engineers time each week for experimentation. Others host internal hack days or mini-conferences to share ideas and collaborate. This is how many new features and products have originated, and it shows how much value employees can generate for an organization when they’re released from habitual pathways and repetitive tasks. How to build a Generative Culture
are a number of ways IT leaders can invest in their teams: • Establish a dedicated training budget and make sure people know about it. Also, give your staff the latitude to choose training that interests them. • Encourage staff to attend technical conferences at least once a year and summarize what they learned for the entire team. • Set up internal hack days, where cross-functional teams can get together to work on a project. • Hold regular internal DevOps mini-conferences.
deploy feature to production & get big new contract from a client. example of non-value adding activities: • bug fixes • rework • features never to be released • changes that make environments stop working
Value Adding Valuable Effort Costs Time Costs Money Adds Value VALUABLE Non-Value Adding Valueless Effort Costs Time Costs Money Adds No Value WASTE Obvious Waste where to draw the line between valuable and waste is not clear
in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.” – Dr. W. Edwards Deming "Out of the Crisis", 1982
vimeo.com/165186982 Measure Efficiency, Effectiveness, and Culture to Optimize DevOps Transformation devopsenterprise. io/media/DOES_forum_metrics_102015.pdf DevOps Lessons Learned at Microsoft Engineering infoq.com/articles/devops-lessons-microsoft Devops: A Software Revolution in the Making? cutter.com/sites/default/files/itjournal/fulltext/2011/08/itj1108.pdf Ben Rockwood - SmartOS Operations www.youtube.com/watch?v=96PGoXHli3Q DevOps Solves Business Problems puppetlabs.com/blog/devops-solves-business-problems-gene-kims-top-aha-moments Projects are Evil and must be Destroyed evan.bottch.com/2010/08/29/projects-are-evil-and-must-be-destroyed/ DevOps is not a technology problem. DevOps is a business problem. dev2ops.org/2010/11/devops-is-not-a-technology- problem-devops-is-a-business-problem/
devops
emiki
kimujun
sonatard
oracle4engineer
uhyo
shimastripe
yuki_ink
re_taro
kakehashi
amixedcolor
sadnessojisan
trallard
stephaniewalter
tammyeverts
michaelherold
trishagee
destraynor
jrom
tanoku
brad_frost
addyosmani
marktimemedia
![Leading in IT Education Topology of Org. Culture [Westrum 1994]](https://files.speakerdeck.com/presentations/cac822bef04b438b962a19ffb94238ed/slide_41.jpg){kind=link}
