Keynote Devops Days Amsterdam - Hacking IT, Culture over Code Bringing Devops into your Organization
•Télécharger en tant que PPTX, PDF•
5 j'aime•1,529 vues
The term DevOps has crossover over from a culture movement around improved IT delivery to a buzzword co-opted by headline minded journalists and companies who want to reinvent their antiquated practices by acquiring new talent. This presentation will talk about DevOps the movement, desired outcomes from DevOps practices and how to bring those practices to your organization especially those with entrenched practices that lack the agility, automation and other benefits of DevOps.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (19)
Similaire à Keynote Devops Days Amsterdam - Hacking IT, Culture over Code Bringing Devops into your Organization
Similaire à Keynote Devops Days Amsterdam - Hacking IT, Culture over Code Bringing Devops into your Organization (20)
Plus de Mark Hinkle
Plus de Mark Hinkle (20)
Dernier
Dernier (20)
Keynote Devops Days Amsterdam - Hacking IT, Culture over Code Bringing Devops into your Organization
- 1. Mark Hinkle Senior Director, Open Source Solutions Citrix Inc. mark.hinkle@citrix.com mrhinkle@gmail.com @mrhinkle Hacking IT, Culture over Code BringingDevopsintoyourOrganization
- 2. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Slides Available on Slideshare http://www.slideshare.net/socializedsoftw are Slides Available on Slideshare Creative Commons Attributions-ShareAlike 4.0 International Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material for any purpose, even commercially. The licensor cannot revoke these freedoms as long as you follow the license terms. Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.
- 3. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code • Manage Citrix Open Source Business Office • Apache CloudStack Committer • Advisory boards Gluster and Xen Project • Joined Citrix via Cloud.com acquisition July 2011 • VP Of Community at Zenoss drove Zenoss Core open source project to 100,000 users, 1.5 million downloads • Former LinuxWorld Magazine Editor-in-Chief • Open Management Consortium organizer • Author - “Windows to Linux Business Desktop Migration” – Thomson • NetDirector Project - Open Source Configuration Management About Me
- 4. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code What Would You Say…You Do here?
- 5. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code I Don’t Code Program HelloWorld; Uses crt; Begin ClrScr; writeln(HeloWorld) ; end.
- 6. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Social “Hacker“ One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations.
- 7. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Interest in Devops is Growing
- 8. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Everyone wants to weigh-in on what devops is….
- 9. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code What is devops? • Automation • Lean • Agile • Devs doing Ops • Ops doing Dev • Tools • Management • Process • Ideology • Cult
- 10. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code WSJ: DevOps Great for Startups, not Ready for the Enterprise? DevOps is a buzzword…Organizational structures are by far the largest hurdles to adoption of enterprise…blah,blah,blah
- 11. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code WSJ: Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival DevOps transformation is well underway…. 8x more frequent production deployments, being performed 8000x faster, with 2x higher success rates…fixing issues 12x faster …IT organizations using DevOps perform better…overall business performance is higher…As Dr. W. Edwards Deming said, “Learning is not compulsory, but neither is survival.”
- 12. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code What makes devops appealing to me
- 13. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code A long time ago, in a galaxy far, far away
- 14. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code I worked for an IT Infrastructure Company
- 15. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Provided Infrastructure to Millions of Users
- 16. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code M&A: A Tale of Two Cities (Silos) • One group valued customer satisfaction • One group valued productivity • Cultural Differences, Distrust, Different learned behaviors
- 17. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code We had A Few “Rules” We respect the individual…..We require complete honesty and integrity…..We make commitments with care….We guard and conserve the company's resources with at least the same vigilance that we would use to guard and conserve our own personal resources….. Clarity in understanding our mission, our goals….We feel a sense of urgency on any matters related to our customers
- 18. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Once We Had a Common Understanding there was Progress
- 19. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Woes of an ISP - 1998
- 20. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code High Customer Acquisition Costs Image Courtesy of Moniker Hill on Flickr
- 21. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Demand for Internet Access Skyrocketing
- 22. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Commoditization
- 23. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code We were Underpants Gnomes Phase 1: Collect all the underpants Phase 2: ? Phase 3: Profit
- 24. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Phase 2: Improving Service Delivery Malcolm Baldridge Criteria for Performance Excellence To help organizations assess their improvement efforts, diagnose their overall performance management system, and identify their strengths and opportunities for improvement…
- 25. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Biggest impact we could make was customer satisfaction, it reduced customer acquisition costs(referrals) and customer support and service costs.
- 26. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code What Made Customers Happy • Quality of Service • Speed to Response • Speed to Recovery • Problem resolution on first call • Self-Service Options
- 27. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code My Aha Moment… No amount of money, no technology or competitive advantage was greater than happy employees that and had a shared belief in what they were doing…
- 28. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code How We Measured Success • Productivity – Customers Helped Over Time • Quality – Customer Satisfaction • Efficiency – Cost for Support per customer • Contributions – “Other Stuff”, Hard to Measure • Attendance – Participation • Employee Satisfaction
- 29. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Awesome Culture -> Success
- 30. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Devops Reminded me of MindSpring • In 2009 this guy(@patrickdebois) on Twitter started making a lot of sense to me… • This other guy (@botchagalupe) kept jabbering about improved operations and eventually Arthur Deming
- 31. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Framework for Devops Discussions Culture Automation Management Sharing
- 32. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code CLAMS
- 33. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Culture
- 34. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Culture(n) - the shared values, attitudes, standards, and beliefs that characterize members of an organization and define its nature.
- 35. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Successful people and organizations work from the inside out. They hold a belief in the importance of what they do. Simon Sinek: http://www.startwithwhy.com/ Culture – Start with Why WHY HOW WHAT
- 36. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Value People over Technology Source: XKCD - http://xkcd.com/705/
- 37. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code The Best DevOps Hacks are Social • Make the Why of Devops Something Everyone Can Get Behind e.g Better products, happier users • No Administrator or Developer Left Behind – Especially the low performers • Reinforce culture and share your values whenever you can
- 38. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Don’t Build New Silos LEGACYOPS LEGACYDEV DEVOPSTEAM
- 39. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Lean
- 40. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code A History of Lean • Henry Ford credited with starting original movement • Kiichiro Toyoda and Taiichi Ohno: 1930’s developed the Toyota Production System • Popularized by Jim Womak The Machine that Changed the World and Lean Solutions in 1990 • 2011 Eric Ries publishes The Lean Start- Up and Lean IT starts to get legs…
- 41. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Create Flow - Stop Pushing, Start Pulling Source:http://ars.userfriendly.org/cartoons/?id=20080627
- 42. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Follow a Process, Be Critical of Results, Never Stop Improving
- 43. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Automation
- 44. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code A Cambrian Explosion of Open Source Automation
- 45. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Automate All the Things, Not Just Deployment and Config management
- 46. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Measurement
- 47. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Measurements and Metrics
- 48. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code #monitoringsucks - The Myth of the Nines Availability % Downtime per Year Downtime per Month Downtime per Week 99.9% (three nines) 8.76 hours 43.2 minutes 10.1 minutes 99.95% 4.38 hours 21.56 minutes 5.04 minutes 99.99% (four nines) 52.6 minutes 4.32 minutes 1.01 minutes 99.999% (five nines) 5.26 minutes 25.9 seconds 6.05 seconds 99.9999% (six nines) 31.5 seconds 2.59 seconds .0605 seconds Average polling interval for monitoring - 5 minutes Even superhuman operations people can’t be alerted and take action in under 5 minutes. One outage per year could drop service level to three nines or worse.
- 49. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Key Performance Indicators (KPIs) • Map IT measurements to organizational performance • Don’t get buried in the measurements • Revisit those KPIs • Use metrics to identify the cause of KPI trends • DevOps (the people) satisfaction • Customer Satisfaction • Keep it simple, six or less
- 50. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Sharing
- 51. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Sharing -> Teaching -> Listening Sharing (v) – to let someone else have or use a part of (something that belongs to you) e.g. knowledge Lecturing (v) - talk seriously or reprovingly to (someone) Teaching (v) - to cause or help (someone) to learn about a subject by giving lessons Listen(v) - make an effort to hear something; be alert and ready to hear something.
- 52. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Summation
- 53. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code
- 54. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code The Days of the BOFH are Numbered Source User Friendly: http://ars.userfriendly.org/cartoons/?id=20130726
- 55. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Continuously Deploy Culture
- 56. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Measure Happiness, Measure Devops Happiness raises nearly every business outcome productivity by 31%, and accuracy on tasks by 19%, as well as a myriad of health and quality of life improvements. Source: The Happiness Divdiend - http://blogs.hbr.org/2011/06/the-happiness-dividend/
- 57. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code Professional: mark.hinkle@citrix.com Personal: mrhinkle@gmail.com Professional: 919.228.8049 Professional: http://www.cloudstack.org Personal: http://www.socializedsoftware.com Twitter: @mrhinkle Mark R. Hinkle Senior Director Open Source Solutions Citrix Systems Inc. Open Source Enthusiast Contact Me
- 58. By Mark R. Hinkle @mrhinkle mrhinkle@gmail.com DevOps: Culture over Code
Notes de l'éditeur
- http://mitpress.mit.edu/books/new-hackers-dictionary
- DevOps is a cutlural cahnge that strives to improve the delivery of
- CIO Journal printed by the WSJ - DevOps Is Great for Startups, but for Enterprises It Won’t Work—Yet http://blogs.wsj.com/cio/2014/05/13/devops-is-great-for-startups-but-for-enterprises-it-wont-work-yet/
- Wall Street Journal – Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival http://blogs.wsj.com/cio/2014/05/22/enterprise-devops-adoption-isnt-mandatory-but-neither-is-survival/
- I worked for MindSpring and Award winning, PC World pick, Top 5 C|Net, PC Magazine. Alex Trubek was our spokesperson We did a good job making users happy.
- Delivered Internet Access (Dial-Up, ISDN, Cable, DSL) Web access web sites Email
- I came to MindSpring through a
- MindSpring Core Values & Beliefs / 14 Deadly Sins http://en.wikipedia.org/wiki/MindSpring
- Customer Acquisition Everyone was competing for internet customers, tons of free trials, little customer loyatly Rapid Commoditization The Internet was becoming a household requirement and it was much like phone service as the offerings were the same with little differentiation Thin Margins In many cases it was more expensive to deliver access then what customers paid Demand was Enormous S Images Courtesy of Moniker Hill on Flickr - https://www.flickr.com/photos/monkerino/191842293/in/photolist-hXf2K-85Q2yw-95tW1z-4i1sqF-4i1stH-4i5xQb-4i5y3N-ank3ZY-egB3hj-4XVoiM-9R1Yz6-8Hyg43-34wBtZ-8KTxdF-xBpQG-4i1srn-9AXSQ-5NUTy9-94PV5S-8iAJHT
- Internet Transit Prices (1998-2014) U.S. Internet Region http://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php Cost for Internet transit in the U.s was approximately $1200 per megabit per second in 1998 Today cost for internet transit in the US is about $.94 per Mbps
- http://www.nist.gov/baldrige/ In the early and mid-1980s, many U.S. industry and government leaders saw that a renewed emphasis on quality was necessary for doing business in an ever-expanding and more competitive world market. But many U.S. businesses either did not believe quality mattered for them or did not know where to begin. The Malcolm Baldrige National Quality Improvement Act of 1987, signed into law on August 20, 1987, was developed through the actions of the National Productivity Advisory Committee, chaired by Jack Grayson. The nonprofit research organization APQC, founded by Grayson, organized the first White House Conference on Productivity, spearheading the creation of the Malcolm Baldrige National Quality Award in 1987. The Baldrige Award was envisioned as a standard of excellence that would help U.S. organizations achieve world-class quality. In the late summer and fall of 1987, Dr. Curt Reimann, the first director of the Malcolm Baldrige National Quality Program, and his staff at the National Institute of Standards and Technology (NIST) developed an award implementation framework, including an evaluation scheme, and advanced proposals for what is now the Baldrige Award. In its first three years, the Baldrige Award was jointly administered by APQC and the American Society for Quality, which continues to assist in administering the award program under contract to NIST. The Baldrige Criteria for Performance Excellence serve two main purposes: (1) to help organizations assess their improvement efforts, diagnose their overall performance management system, and identify their strengths and opportunities for improvement and (2) to identify Baldrige Award recipients that will serve as role models for other organizations. In addition, the Criteria help strengthen U.S. competitiveness by improving organizational performance practices, capabilities, and results facilitating communication and sharing of information on best practices among U.S. organizations of all types serving as a tool for understanding and managing performance and for guiding planning and opportunities for learning The Baldrige Criteria for Performance Excellence provide organizations with an integrated approach to performance management that results in delivery of ever-improving value to customers and stakeholders, contributing to organizational sustainability improved organizational effectiveness and capabilities organizational and personal learning
- Quality of Service - Connection speeds Speed to Response – How Quickly we answered the phone – If we answered a phone call in under 45 seconds customer satisfaction was very high, 45 seconds to 10 minutes on hold and satisfaction was relatively the same First Call Resolution was not as big a factor in customer satisfaction but provided a huge reduction in waste Self Service was also a big factor, change password, update account information online
- http://gapingvoid.com/corporate-culture/
- Photo courtesy of Matt Moor on Flickr http://www.flickr.com/photos/mattmflickr/7453204160/in/photostream/
- http://www.inc.com/encyclopedia/corporate-culture.html
- Most people say what we do and how we do it. Most tangible to the Apple Computer wants to challenge the status quo, they think different. We believe that in everything we do we should challenge the status quo. The way we we challenge the status quo is through simple, elegant design. We just happen to make great electronics What is the why for your organization? We do what we do so people can accomplish awesome stuff through the use of technology How we do that is by providing good coordination between developer and operations so that We provide automated, scalable, fault tolerant solutions to people. People don’t invest in what you do, why you do it.
- What is the Why of your Organization? Deliver services so that you can do awesome stuff. At Apache CloudStack I like to think about our Cloud users as people who are proving the existing of the Higgs Boson or running culture How Open source devlopment model to make our IT more efficient What We create cloud computing software to enable users to access the resources they need on demand
- Courtesy Doc Searls - https://www.flickr.com/photos/docsearls/5500714140/in/photolist-dSA9Bi-auR8jn-fu5X2f-bTHTce-c2m9DU-5GMvAV-E99M-5XDYbN-9o5AEY-cPkrKh-E9aS-fpKoDq-hq1y1M-4dYuXC-27hTDj-fyssX2-bVVC9G-E9c6-7FwX1A-kTNGSK/ via https://creativecommons.org/licenses/by/2.0/
- Overproduction http://www.pdx.edu/fadm/sites/www.pdx.edu.fadm/files/02_Introduction%20to%20Lean%20Principles%20-%20Supergraphic.pdf http://www.leanproduction.com/intro-to-lean.html http://www.leanproduction.com/intro-to-lean.html Making something before it is truly needed. This is a particularly serious form of waste because it leads to excess inventory that is often used to mask other underlying problems and inefficiencies. Pace production so the rate of manufacturing matches the rate of customer demand (Takt Time). Use a pull system to control how much is manufactured (Kanban). Reduce setup times so that smaller batches can be economically manufactured (SMED). Waiting Time when work-in-process is waiting for the next step in production (no value is being added). It can be truly illuminating to look at the time from order to shipment and ask – how much of that time is actually spent on true value-added manufacturing. Design processes so that the flow is continuous and there are minimal (or no) buffers between steps in production (Continuous Flow). Use standardized work instructions to ensure that a consistent method and consistent times are used for each step of production (Standardized Work). Transport Unnecessary movement of raw materials, work-in-process or finished goods. Design a linear, sequential flow from raw materials to finished goods (Value Stream Mapping). Make sure work-in-process is not placed into inventory (Continuous Flow). Avoid continual changing of job priorities (Theory of Constraints). Motion Unnecessary movement of people (movement that does not add value). Ensure that work areas are logically organized (5S). Consider alternate arrangements of equipment that reduce motion (Value Stream Mapping). Overprocessing More processing than is needed to produce what the customer requires. This is often one of the more difficult wastes to detect and eliminate. Compare customer requirements to manufacturing specifications (Kaizen). Look for potential simplifications to the manufacturing process (Kaizen). Inventory Product (raw materials, work-in-process, or finished goods) quantities that go beyond supporting the immediate need. Bring raw materials in only as they are needed (Just-In-Time). Reduce or eliminate buffers between steps in production (Continuous Flow). Refer to Overproduction countermeasures (Takt Time, Kanban, and SMED). Defects Production that is scrap or requires rework. Design processes so they are less likely to produce defects (Poka-Yoke). Design processes to detect abnormalities so they can be immediately corrected (Jidoka). Look for the single most frequent defect and determine why it occurs (Root Cause Analysis). Create work instructions that provide a consistent method of manufacturing the part. (Standardized Work). Lean concepts become a lot more intuitive and easy-to-understand when they are traced to the ultimate goal – eliminating waste. verproduction Making something before it is truly needed. This is a particularly serious form of waste because it leads to excess inventory that is often used to mask other underlying problems and inefficiencies. Pace production so the rate of manufacturing matches the rate of customer demand (Takt Time). Use a pull system to control how much is manufactured (Kanban). Reduce setup times so that smaller batches can be economically manufactured (SMED). Waiting Time when work-in-process is waiting for the next step in production (no value is being added). It can be truly illuminating to look at the time from order to shipment and ask – how much of that time is actually spent on true value-added manufacturing. Design processes so that the flow is continuous and there are minimal (or no) buffers between steps in production (Continuous Flow). Use standardized work instructions to ensure that a consistent method and consistent times are used for each step of production (Standardized Work). Transport Unnecessary movement of raw materials, work-in-process or finished goods. Design a linear, sequential flow from raw materials to finished goods (Value Stream Mapping). Make sure work-in-process is not placed into inventory (Continuous Flow). Avoid continual changing of job priorities (Theory of Constraints). Motion Unnecessary movement of people (movement that does not add value). Ensure that work areas are logically organized (5S). Consider alternate arrangements of equipment that reduce motion (Value Stream Mapping). Overprocessing More processing than is needed to produce what the customer requires. This is often one of the more difficult wastes to detect and eliminate. Compare customer requirements to manufacturing specifications (Kaizen). Look for potential simplifications to the manufacturing process (Kaizen). Inventory Product (raw materials, work-in-process, or finished goods) quantities that go beyond supporting the immediate need. Bring raw materials in only as they are needed (Just-In-Time). Reduce or eliminate buffers between steps in production (Continuous Flow). Refer to Overproduction countermeasures (Takt Time, Kanban, and SMED). Defects Production that is scrap or requires rework. Design processes so they are less likely to produce defects (Poka-Yoke). Design processes to detect abnormalities so they can be immediately corrected (Jidoka). Look for the single most frequent defect and determine why it occurs (Root Cause Analysis). Create work instructions that provide a consistent method of manufacturing the part. (Standardized Work). Lean concepts become a lot more intuitive and easy-to-understand when they are traced to the ultimate goal – eliminating waste.
- We have a dirth of automation tools at our disposal and many o Ansible Foreman - http://theforeman.org/ - Foreman is a complete lifecycle management tool for physical and virtual servers. Func -
- Don’t just automate production, automate test, automate recovery Chaos Monkey http://bob.ippoli.to/erl_testing_2011/ http://appirio.com/category/tech-blog/2013/03/deliver-value-with-unit-testing-in-the-cloud/
- CIO.gov - https://cio.gov/performance-metrics-and-measures/ There is overlap between measures and metrics. Both can be qualitative or quantitative, but what distinguishes them is important. Measures are concrete, usually measure one thing, and are quantitative in nature (e.g. I have five apples). Metrics describe a quality and require a measurement baseline (I have five more apples than I did yesterday). In a Section 508 program, measures are useful for demonstrating workloads and activity, and metrics are useful for evaluating compliance, processes effectiveness, and measuring success against established objectives.
- Cloud computing promises highly available systems, but if you have a reactive approach you won’t achieve that goal. If you want a five nines service level you have 5.26 minutes to find, fix and recover Build redundant, highly environment systems
- Visualizations of Continuous Delivery - http://continuousdelivery.com/2014/02/visualizations-of-continuous-delivery/ Nhan Ngo, a QA engineer at Spotify, made four fabulous visualizations while reading Continuous Delivery. She has very kindly agreed to make them available under a Creative Commons license so feel free to share them, download them, and print them out (click to get a higher resolution version). - https://www.linkedin.com/pub/nhan-ngo/11/938/ba5