�ݺ�ߣshows by User: auxesis

�ݺ�ߣshows by User: auxesis / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: auxesis / Thu, 04 Apr 2013 10:53:32 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: auxesis Escalating complexity: DevOps learnings from Air France 447 /auxesis/escalating-complexity-devops-learnings-from-air-france-447 escalatingcomplexitymwrc2013-130404105332-phpapp01
On June 1, 2009 Air France 447 crashed into the Atlantic ocean killing all 228 passengers and crew. The 15 minutes leading up to the impact were a terrifying demonstration of the how thick the fog of war is in complex systems. Mainstream reports of the incident put the blame on the pilots - a common motif in incident reports that conveniently ignore a simple fact: people were just actors within a complex system, doing their best based on the information at hand. While the systems you build and operate likely don't control the fate of people's lives, they share many of the same complexity characteristics. Dev and Ops can learn an abundance from how the feedback loops between these aviation systems are designed and how these systems are operated. In this talk Lindsay will cover what happened on the flight, why the mainstream explanation doesn't add up, how design assumptions can impact people's ability to respond to rapidly developing situations, and how to improve your operational effectiveness when dealing with rapidly developing failure scenarios.]]>
On June 1, 2009 Air France 447 crashed into the Atlantic ocean killing all 228 passengers and crew. The 15 minutes leading up to the impact were a terrifying demonstration of the how thick the fog of war is in complex systems. Mainstream reports of the incident put the blame on the pilots - a common motif in incident reports that conveniently ignore a simple fact: people were just actors within a complex system, doing their best based on the information at hand. While the systems you build and operate likely don't control the fate of people's lives, they share many of the same complexity characteristics. Dev and Ops can learn an abundance from how the feedback loops between these aviation systems are designed and how these systems are operated. In this talk Lindsay will cover what happened on the flight, why the mainstream explanation doesn't add up, how design assumptions can impact people's ability to respond to rapidly developing situations, and how to improve your operational effectiveness when dealing with rapidly developing failure scenarios.]]> Thu, 04 Apr 2013 10:53:32 GMT /auxesis/escalating-complexity-devops-learnings-from-air-france-447 auxesis@slideshare.net(auxesis) Escalating complexity: DevOps learnings from Air France 447 auxesis On June 1, 2009 Air France 447 crashed into the Atlantic ocean killing all 228 passengers and crew. The 15 minutes leading up to the impact were a terrifying demonstration of the how thick the fog of war is in complex systems. Mainstream reports of the incident put the blame on the pilots - a common motif in incident reports that conveniently ignore a simple fact: people were just actors within a complex system, doing their best based on the information at hand. While the systems you build and operate likely don't control the fate of people's lives, they share many of the same complexity characteristics. Dev and Ops can learn an abundance from how the feedback loops between these aviation systems are designed and how these systems are operated. In this talk Lindsay will cover what happened on the flight, why the mainstream explanation doesn't add up, how design assumptions can impact people's ability to respond to rapidly developing situations, and how to improve your operational effectiveness when dealing with rapidly developing failure scenarios. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/escalatingcomplexitymwrc2013-130404105332-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> On June 1, 2009 Air France 447 crashed into the Atlantic ocean killing all 228 passengers and crew. The 15 minutes leading up to the impact were a terrifying demonstration of the how thick the fog of war is in complex systems. Mainstream reports of the incident put the blame on the pilots - a common motif in incident reports that conveniently ignore a simple fact: people were just actors within a complex system, doing their best based on the information at hand. While the systems you build and operate likely don't control the fate of people's lives, they share many of the same complexity characteristics. Dev and Ops can learn an abundance from how the feedback loops between these aviation systems are designed and how these systems are operated. In this talk Lindsay will cover what happened on the flight, why the mainstream explanation doesn't add up, how design assumptions can impact people's ability to respond to rapidly developing situations, and how to improve your operational effectiveness when dealing with rapidly developing failure scenarios.

Escalating complexity: DevOps learnings from Air France 447 from Lindsay Holmwood

]]> 15939 33 https://cdn.slidesharecdn.com/ss_thumbnails/escalatingcomplexitymwrc2013-130404105332-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 AA261: DevOps lessons in collaborative maintenance /slideshow/aa261/17090333 aa261-130310210244-phpapp01
On January 31, 2000, Alaska Airlines Flight 261 plunged into the Pacific ocean in an extreme "nose down" position, killing all 88 crew and passengers on board. The NTSB concluded AA261's horizontal stabiliser trim system's jackscrew was inadequately maintained, causing the pilots to lose all control of the plane. There are striking parallels with the problems we face daily in IT operations & software development, and the 30 years of give and take between the aircraft manufacturer's engineers, airline maintenance staff, and federal regulators that preceded AA261's simple mechanical failure. In this talk, Lindsay looks at the complex interplay between the parties in the AA261 crash through a DevOps lens, investigating the collaborative approach to maintenance and operation of the MD-83 aircraft, and relating the complexities back to the complex IT systems we build and maintain.]]>
On January 31, 2000, Alaska Airlines Flight 261 plunged into the Pacific ocean in an extreme "nose down" position, killing all 88 crew and passengers on board. The NTSB concluded AA261's horizontal stabiliser trim system's jackscrew was inadequately maintained, causing the pilots to lose all control of the plane. There are striking parallels with the problems we face daily in IT operations & software development, and the 30 years of give and take between the aircraft manufacturer's engineers, airline maintenance staff, and federal regulators that preceded AA261's simple mechanical failure. In this talk, Lindsay looks at the complex interplay between the parties in the AA261 crash through a DevOps lens, investigating the collaborative approach to maintenance and operation of the MD-83 aircraft, and relating the complexities back to the complex IT systems we build and maintain.]]> Sun, 10 Mar 2013 21:02:44 GMT /slideshow/aa261/17090333 auxesis@slideshare.net(auxesis) AA261: DevOps lessons in collaborative maintenance auxesis On January 31, 2000, Alaska Airlines Flight 261 plunged into the Pacific ocean in an extreme "nose down" position, killing all 88 crew and passengers on board. The NTSB concluded AA261's horizontal stabiliser trim system's jackscrew was inadequately maintained, causing the pilots to lose all control of the plane. There are striking parallels with the problems we face daily in IT operations & software development, and the 30 years of give and take between the aircraft manufacturer's engineers, airline maintenance staff, and federal regulators that preceded AA261's simple mechanical failure. In this talk, Lindsay looks at the complex interplay between the parties in the AA261 crash through a DevOps lens, investigating the collaborative approach to maintenance and operation of the MD-83 aircraft, and relating the complexities back to the complex IT systems we build and maintain. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/aa261-130310210244-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> On January 31, 2000, Alaska Airlines Flight 261 plunged into the Pacific ocean in an extreme "nose down" position, killing all 88 crew and passengers on board. The NTSB concluded AA261's horizontal stabiliser trim system's jackscrew was inadequately maintained, causing the pilots to lose all control of the plane. There are striking parallels with the problems we face daily in IT operations & software development, and the 30 years of give and take between the aircraft manufacturer's engineers, airline maintenance staff, and federal regulators that preceded AA261's simple mechanical failure. In this talk, Lindsay looks at the complex interplay between the parties in the AA261 crash through a DevOps lens, investigating the collaborative approach to maintenance and operation of the MD-83 aircraft, and relating the complexities back to the complex IT systems we build and maintain.

AA261: DevOps lessons in collaborative maintenance from Lindsay Holmwood

]]> 1165 2 https://cdn.slidesharecdn.com/ss_thumbnails/aa261-130310210244-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Islands: Puppet at Bulletproof Networks /slideshow/islands-puppet-at-bulletproof-networks/13243245 islands-puppet-at-bulletproof-120607202321-phpapp01
Bulletproof Networks provides managed hosting services to some of the largest companies in Australia. Bulletproof implements strong isolation of customer environments, and this can present unique challenges when re-using Puppet code across our customer base. Additionally, the environments range in size from small to very large, and our tools + processes need to be able to handle both uses cases equally well. In this talk Lindsay + Mick will cover how Bulletproof's approach to these problems has evolved over the last 4 years, and some of the tools Bulletproof has developed and built upon to provide an awesome service to our customers.]]>
Bulletproof Networks provides managed hosting services to some of the largest companies in Australia. Bulletproof implements strong isolation of customer environments, and this can present unique challenges when re-using Puppet code across our customer base. Additionally, the environments range in size from small to very large, and our tools + processes need to be able to handle both uses cases equally well. In this talk Lindsay + Mick will cover how Bulletproof's approach to these problems has evolved over the last 4 years, and some of the tools Bulletproof has developed and built upon to provide an awesome service to our customers.]]> Thu, 07 Jun 2012 20:23:19 GMT /slideshow/islands-puppet-at-bulletproof-networks/13243245 auxesis@slideshare.net(auxesis) Islands: Puppet at Bulletproof Networks auxesis Bulletproof Networks provides managed hosting services to some of the largest companies in Australia. Bulletproof implements strong isolation of customer environments, and this can present unique challenges when re-using Puppet code across our customer base. Additionally, the environments range in size from small to very large, and our tools + processes need to be able to handle both uses cases equally well. In this talk Lindsay + Mick will cover how Bulletproof's approach to these problems has evolved over the last 4 years, and some of the tools Bulletproof has developed and built upon to provide an awesome service to our customers. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/islands-puppet-at-bulletproof-120607202321-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Bulletproof Networks provides managed hosting services to some of the largest companies in Australia. Bulletproof implements strong isolation of customer environments, and this can present unique challenges when re-using Puppet code across our customer base. Additionally, the environments range in size from small to very large, and our tools + processes need to be able to handle both uses cases equally well. In this talk Lindsay + Mick will cover how Bulletproof's approach to these problems has evolved over the last 4 years, and some of the tools Bulletproof has developed and built upon to provide an awesome service to our customers.

Islands: Puppet at Bulletproof Networks from Lindsay Holmwood

]]> 1211 3 https://cdn.slidesharecdn.com/ss_thumbnails/islands-puppet-at-bulletproof-120607202321-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Load testing with Blitz /slideshow/load-testing-13067261/13067261 load-testing-120524185456-phpapp02
We all know that load testing is important, but it's all too common that it's left to the very end of a project and it's invariably the first thing that gets dropped when budgets and timeframes get cut. Furthermore, most of us don't know where or how to start implementing effective load tests, let alone how to analyse the results. Lindsay Holmwood, Software Manager at Bulletproof Networks, will be talking about integrating performance testing into your application development + deploy cycle from the very beginning, using inexpensive and easy to use SaaS tools. There will be a hands on demonstration of the Blitz load + performance testing tool, coupled with a brief dive into the Blitz API internals to retrieve and analyse advanced reporting information.]]>
We all know that load testing is important, but it's all too common that it's left to the very end of a project and it's invariably the first thing that gets dropped when budgets and timeframes get cut. Furthermore, most of us don't know where or how to start implementing effective load tests, let alone how to analyse the results. Lindsay Holmwood, Software Manager at Bulletproof Networks, will be talking about integrating performance testing into your application development + deploy cycle from the very beginning, using inexpensive and easy to use SaaS tools. There will be a hands on demonstration of the Blitz load + performance testing tool, coupled with a brief dive into the Blitz API internals to retrieve and analyse advanced reporting information.]]> Thu, 24 May 2012 18:54:53 GMT /slideshow/load-testing-13067261/13067261 auxesis@slideshare.net(auxesis) Load testing with Blitz auxesis We all know that load testing is important, but it's all too common that it's left to the very end of a project and it's invariably the first thing that gets dropped when budgets and timeframes get cut. Furthermore, most of us don't know where or how to start implementing effective load tests, let alone how to analyse the results. Lindsay Holmwood, Software Manager at Bulletproof Networks, will be talking about integrating performance testing into your application development + deploy cycle from the very beginning, using inexpensive and easy to use SaaS tools. There will be a hands on demonstration of the Blitz load + performance testing tool, coupled with a brief dive into the Blitz API internals to retrieve and analyse advanced reporting information. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/load-testing-120524185456-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /> We all know that load testing is important, but it's all too common that it's left to the very end of a project and it's invariably the first thing that gets dropped when budgets and timeframes get cut. Furthermore, most of us don't know where or how to start implementing effective load tests, let alone how to analyse the results. Lindsay Holmwood, Software Manager at Bulletproof Networks, will be talking about integrating performance testing into your application development + deploy cycle from the very beginning, using inexpensive and easy to use SaaS tools. There will be a hands on demonstration of the Blitz load + performance testing tool, coupled with a brief dive into the Blitz API internals to retrieve and analyse advanced reporting information.

Load testing with Blitz from Lindsay Holmwood

]]> 1267 5 https://cdn.slidesharecdn.com/ss_thumbnails/load-testing-120524185456-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Latency: The Silent Monitoring System Killer /slideshow/latency-the-silent-monitoring-system-killer/11186074 devops-sydney-january-lightning-talk-120121005611-phpapp01
�ݺ�ߣs from a lighting talk presented at the January Sydney DevOps Meetup.]]>
�ݺ�ߣs from a lighting talk presented at the January Sydney DevOps Meetup.]]> Sat, 21 Jan 2012 00:56:07 GMT /slideshow/latency-the-silent-monitoring-system-killer/11186074 auxesis@slideshare.net(auxesis) Latency: The Silent Monitoring System Killer auxesis �ݺ�ߣs from a lighting talk presented at the January Sydney DevOps Meetup. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/devops-sydney-january-lightning-talk-120121005611-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> �ݺ�ߣs from a lighting talk presented at the January Sydney DevOps Meetup.

Latency: The Silent Monitoring System Killer from Lindsay Holmwood

]]> 1761 3 https://cdn.slidesharecdn.com/ss_thumbnails/devops-sydney-january-lightning-talk-120121005611-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Rump - making Puppetmaster-less Puppet meaty /slideshow/rump-making-puppetmasterless-puppet-meaty/7766330 rump-puppetcampeu2011-110428093601-phpapp01
We’re all familiar with the Puppet manifest development cycle: “make your change, commit your change, push your change, run Puppet, debug the output, then go back to the beginning to refactor or fix a bug”. What if you could could shorten the cycle to “make a change, run puppet, commit change”? Enter Rump, a tool for doing Puppet runs locally from a Git checkout. Rump encourages a Puppet workflow where you quickly + iteratively develop your Puppet manifests on a single machine, then push your changes up to a repository to deploy to the rest of your infrastructure. Lindsay will be demonstrating how to setup Rump, showing off some awesome workflows for doing local iterative development, and exposing super cool features like testing your manifests against new versions of Puppet in a single command. ]]>
We’re all familiar with the Puppet manifest development cycle: “make your change, commit your change, push your change, run Puppet, debug the output, then go back to the beginning to refactor or fix a bug”. What if you could could shorten the cycle to “make a change, run puppet, commit change”? Enter Rump, a tool for doing Puppet runs locally from a Git checkout. Rump encourages a Puppet workflow where you quickly + iteratively develop your Puppet manifests on a single machine, then push your changes up to a repository to deploy to the rest of your infrastructure. Lindsay will be demonstrating how to setup Rump, showing off some awesome workflows for doing local iterative development, and exposing super cool features like testing your manifests against new versions of Puppet in a single command. ]]> Thu, 28 Apr 2011 09:35:58 GMT /slideshow/rump-making-puppetmasterless-puppet-meaty/7766330 auxesis@slideshare.net(auxesis) Rump - making Puppetmaster-less Puppet meaty auxesis We’re all familiar with the Puppet manifest development cycle: “make your change, commit your change, push your change, run Puppet, debug the output, then go back to the beginning to refactor or fix a bug”. What if you could could shorten the cycle to “make a change, run puppet, commit change”? Enter Rump, a tool for doing Puppet runs locally from a Git checkout. Rump encourages a Puppet workflow where you quickly + iteratively develop your Puppet manifests on a single machine, then push your changes up to a repository to deploy to the rest of your infrastructure. Lindsay will be demonstrating how to setup Rump, showing off some awesome workflows for doing local iterative development, and exposing super cool features like testing your manifests against new versions of Puppet in a single command. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/rump-puppetcampeu2011-110428093601-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> We’re all familiar with the Puppet manifest development cycle: “make your change, commit your change, push your change, run Puppet, debug the output, then go back to the beginning to refactor or fix a bug”. What if you could could shorten the cycle to “make a change, run puppet, commit change”? Enter Rump, a tool for doing Puppet runs locally from a Git checkout. Rump encourages a Puppet workflow where you quickly + iteratively develop your Puppet manifests on a single machine, then push your changes up to a repository to deploy to the rest of your infrastructure. Lindsay will be demonstrating how to setup Rump, showing off some awesome workflows for doing local iterative development, and exposing super cool features like testing your manifests against new versions of Puppet in a single command.

Rump - making Puppetmaster-less Puppet meaty from Lindsay Holmwood

]]> 2119 4 https://cdn.slidesharecdn.com/ss_thumbnails/rump-puppetcampeu2011-110428093601-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Behaviour driven infrastructure /slideshow/behaviour-driven-infrastructure/6755375 behaviour-driven-infrastructure-110130203633-phpapp02
Does Behaviour Driven Development have a role in the infrastructure world? Enter Behaviour Driven Infrastructure where systems administrators can apply some simple open source tools and BDD principles to make infrastructure management more powerful, more insightful and deliver more value to their customers. The typical enterprise monitoring and configuration management set-up for a website is: - Is the Apache package installed and the appropriate version? - Is the Apache service running? - Can I connect to the HTTP port and is HTML returned? - Multiply this by a few hundred iterations of hosts and types of services and you’re probably looking at your typical Nagios, Puppet, Cfengine, Hyperic set-up. All this monitoring misses something critical though – we’re not actually monitoring that the service does what it should. Yes, it matters whether Apache is installed, the Apache service is running, and you can connect to HTTP but does this actually prove anything about the availability of the service we’re managing and providing for our customers? Nope… We need to demonstrate more than just a check that says the Apache server is up. We need to demonstrate that the service delivered by that infrastructure was available to our customers AND functioning as intended. Enter Behaviour Driven Infrastructure or BDI which applies the principles of Behavioural Driven Development to the management of infrastructure. In this presentation you’ll learn: - How Behaviour Driven Development works - What makes a behavioural test - How to install and use Cucumber to perform BDI - Practical examples of behavioural tests in Cucumber, and - How to integrate BDI into your work flow and your enterprise monitoring and configuration management frameworks.]]>
Does Behaviour Driven Development have a role in the infrastructure world? Enter Behaviour Driven Infrastructure where systems administrators can apply some simple open source tools and BDD principles to make infrastructure management more powerful, more insightful and deliver more value to their customers. The typical enterprise monitoring and configuration management set-up for a website is: - Is the Apache package installed and the appropriate version? - Is the Apache service running? - Can I connect to the HTTP port and is HTML returned? - Multiply this by a few hundred iterations of hosts and types of services and you’re probably looking at your typical Nagios, Puppet, Cfengine, Hyperic set-up. All this monitoring misses something critical though – we’re not actually monitoring that the service does what it should. Yes, it matters whether Apache is installed, the Apache service is running, and you can connect to HTTP but does this actually prove anything about the availability of the service we’re managing and providing for our customers? Nope… We need to demonstrate more than just a check that says the Apache server is up. We need to demonstrate that the service delivered by that infrastructure was available to our customers AND functioning as intended. Enter Behaviour Driven Infrastructure or BDI which applies the principles of Behavioural Driven Development to the management of infrastructure. In this presentation you’ll learn: - How Behaviour Driven Development works - What makes a behavioural test - How to install and use Cucumber to perform BDI - Practical examples of behavioural tests in Cucumber, and - How to integrate BDI into your work flow and your enterprise monitoring and configuration management frameworks.]]> Sun, 30 Jan 2011 20:36:29 GMT /slideshow/behaviour-driven-infrastructure/6755375 auxesis@slideshare.net(auxesis) Behaviour driven infrastructure auxesis Does Behaviour Driven Development have a role in the infrastructure world? Enter Behaviour Driven Infrastructure where systems administrators can apply some simple open source tools and BDD principles to make infrastructure management more powerful, more insightful and deliver more value to their customers. The typical enterprise monitoring and configuration management set-up for a website is: - Is the Apache package installed and the appropriate version? - Is the Apache service running? - Can I connect to the HTTP port and is HTML returned? - Multiply this by a few hundred iterations of hosts and types of services and you’re probably looking at your typical Nagios, Puppet, Cfengine, Hyperic set-up. All this monitoring misses something critical though – we’re not actually monitoring that the service does what it should. Yes, it matters whether Apache is installed, the Apache service is running, and you can connect to HTTP but does this actually prove anything about the availability of the service we’re managing and providing for our customers? Nope… We need to demonstrate more than just a check that says the Apache server is up. We need to demonstrate that the service delivered by that infrastructure was available to our customers AND functioning as intended. Enter Behaviour Driven Infrastructure or BDI which applies the principles of Behavioural Driven Development to the management of infrastructure. In this presentation you’ll learn: - How Behaviour Driven Development works - What makes a behavioural test - How to install and use Cucumber to perform BDI - Practical examples of behavioural tests in Cucumber, and - How to integrate BDI into your work flow and your enterprise monitoring and configuration management frameworks. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/behaviour-driven-infrastructure-110130203633-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /> Does Behaviour Driven Development have a role in the infrastructure world? Enter Behaviour Driven Infrastructure where systems administrators can apply some simple open source tools and BDD principles to make infrastructure management more powerful, more insightful and deliver more value to their customers. The typical enterprise monitoring and configuration management set-up for a website is: - Is the Apache package installed and the appropriate version? - Is the Apache service running? - Can I connect to the HTTP port and is HTML returned? - Multiply this by a few hundred iterations of hosts and types of services and you’re probably looking at your typical Nagios, Puppet, Cfengine, Hyperic set-up. All this monitoring misses something critical though – we’re not actually monitoring that the service does what it should. Yes, it matters whether Apache is installed, the Apache service is running, and you can connect to HTTP but does this actually prove anything about the availability of the service we’re managing and providing for our customers? Nope… We need to demonstrate more than just a check that says the Apache server is up. We need to demonstrate that the service delivered by that infrastructure was available to our customers AND functioning as intended. Enter Behaviour Driven Infrastructure or BDI which applies the principles of Behavioural Driven Development to the management of infrastructure. In this presentation you’ll learn: - How Behaviour Driven Development works - What makes a behavioural test - How to install and use Cucumber to perform BDI - Practical examples of behavioural tests in Cucumber, and - How to integrate BDI into your work flow and your enterprise monitoring and configuration management frameworks.

Behaviour driven infrastructure from Lindsay Holmwood

]]> 5820 13 https://cdn.slidesharecdn.com/ss_thumbnails/behaviour-driven-infrastructure-110130203633-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Burn down the silos! Helping dev and ops gel on high availability websites /slideshow/burn-down-the-silos-helping-dev-and-ops-gel-on-high-availability-websites/6750386 burn-down-the-silos-110130055415-phpapp02
HA websites are where the rubber meets the road - at 200km/h. Traditional separation of dev and ops just doesn't cut it. Everything is related to everything. Code relies on performant and resilient infrastructure, but highly performant infrastructure will only get a poorly written application so far. Worse still, root cause analysis in HA sites will more often than not identify problems that don't clearly belong to either devs or ops. The two options are collaborate or die. This talk will introduce 3 core principles for improving collaboration between operations and development teams: consistency, repeatability, and visibility. These principles will be investigated with real world case studies and associated technologies audience members can start using now. In particular, there will be a focus on: - fast provisioning of test environments with configuration management - reliable and repeatable automated deployments - application and infrastructure visibility with statistics collection, logging, and visualisation ]]>
HA websites are where the rubber meets the road - at 200km/h. Traditional separation of dev and ops just doesn't cut it. Everything is related to everything. Code relies on performant and resilient infrastructure, but highly performant infrastructure will only get a poorly written application so far. Worse still, root cause analysis in HA sites will more often than not identify problems that don't clearly belong to either devs or ops. The two options are collaborate or die. This talk will introduce 3 core principles for improving collaboration between operations and development teams: consistency, repeatability, and visibility. These principles will be investigated with real world case studies and associated technologies audience members can start using now. In particular, there will be a focus on: - fast provisioning of test environments with configuration management - reliable and repeatable automated deployments - application and infrastructure visibility with statistics collection, logging, and visualisation ]]> Sun, 30 Jan 2011 05:52:52 GMT /slideshow/burn-down-the-silos-helping-dev-and-ops-gel-on-high-availability-websites/6750386 auxesis@slideshare.net(auxesis) Burn down the silos! Helping dev and ops gel on high availability websites auxesis HA websites are where the rubber meets the road - at 200km/h. Traditional separation of dev and ops just doesn't cut it. Everything is related to everything. Code relies on performant and resilient infrastructure, but highly performant infrastructure will only get a poorly written application so far. Worse still, root cause analysis in HA sites will more often than not identify problems that don't clearly belong to either devs or ops. The two options are collaborate or die. This talk will introduce 3 core principles for improving collaboration between operations and development teams: consistency, repeatability, and visibility. These principles will be investigated with real world case studies and associated technologies audience members can start using now. In particular, there will be a focus on: - fast provisioning of test environments with configuration management - reliable and repeatable automated deployments - application and infrastructure visibility with statistics collection, logging, and visualisation <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/burn-down-the-silos-110130055415-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds" /> HA websites are where the rubber meets the road - at 200km/h. Traditional separation of dev and ops just doesn't cut it. Everything is related to everything. Code relies on performant and resilient infrastructure, but highly performant infrastructure will only get a poorly written application so far. Worse still, root cause analysis in HA sites will more often than not identify problems that don't clearly belong to either devs or ops. The two options are collaborate or die. This talk will introduce 3 core principles for improving collaboration between operations and development teams: consistency, repeatability, and visibility. These principles will be investigated with real world case studies and associated technologies audience members can start using now. In particular, there will be a focus on: - fast provisioning of test environments with configuration management - reliable and repeatable automated deployments - application and infrastructure visibility with statistics collection, logging, and visualisation

Burn down the silos! Helping dev and ops gel on high availability websites from Lindsay Holmwood

]]> 1631 5 https://cdn.slidesharecdn.com/ss_thumbnails/burn-down-the-silos-110130055415-phpapp02-thumbnail.jpg?width=120&height=120&fit=bounds presentation White http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Behaviour Driven Monitoring with cucumber-nagios /slideshow/behaviour-driven-monitoring-with-cucumbernagios-2444224/2444224 068-joined-091107061958-phpapp01
Writing checks for your monitoring system is boring. You end up writing the same checks again and again, and it can be difficult to verify behavior instead of availability. Wouldn't it be useful to have a standard library of checks you could reuse across your infrastructure? it lets you write reusable behavioral tests in human-readable language.Say hello to cucumber-nagios - it lets you write reusable behavioral tests in human-readable language. As cucumber-nagios output the test results in the Nagios plugin format you can run your checks from any monitoring system that understands the format.]]>
Writing checks for your monitoring system is boring. You end up writing the same checks again and again, and it can be difficult to verify behavior instead of availability. Wouldn't it be useful to have a standard library of checks you could reuse across your infrastructure? it lets you write reusable behavioral tests in human-readable language.Say hello to cucumber-nagios - it lets you write reusable behavioral tests in human-readable language. As cucumber-nagios output the test results in the Nagios plugin format you can run your checks from any monitoring system that understands the format.]]> Sat, 07 Nov 2009 06:19:52 GMT /slideshow/behaviour-driven-monitoring-with-cucumbernagios-2444224/2444224 auxesis@slideshare.net(auxesis) Behaviour Driven Monitoring with cucumber-nagios auxesis Writing checks for your monitoring system is boring. You end up writing the same checks again and again, and it can be difficult to verify behavior instead of availability. Wouldn't it be useful to have a standard library of checks you could reuse across your infrastructure? it lets you write reusable behavioral tests in human-readable language.Say hello to cucumber-nagios - it lets you write reusable behavioral tests in human-readable language. As cucumber-nagios output the test results in the Nagios plugin format you can run your checks from any monitoring system that understands the format. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/068-joined-091107061958-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Writing checks for your monitoring system is boring. You end up writing the same checks again and again, and it can be difficult to verify behavior instead of availability. Wouldn't it be useful to have a standard library of checks you could reuse across your infrastructure? it lets you write reusable behavioral tests in human-readable language.Say hello to cucumber-nagios - it lets you write reusable behavioral tests in human-readable language. As cucumber-nagios output the test results in the Nagios plugin format you can run your checks from any monitoring system that understands the format.

Behaviour Driven Monitoring with cucumber-nagios from Lindsay Holmwood

]]> 3677 7 https://cdn.slidesharecdn.com/ss_thumbnails/068-joined-091107061958-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Flapjack: rethinking monitoring for the cloud /slideshow/flapjack-rethinking-monitoring-for-the-cloud/2433231 141-joined-091105162106-phpapp01
Flapjack is a scalable and distributed monitoring system. It natively talks the Nagios plugin format, and can easily be scaled from 1 server to 1000. Flapjack aims to be simple to set up, configure, and maintain, and easily scales from a single host to multiple. This talk was presented on 30/10/2009 at Devopsdays in Gent, Belgium.]]>
Flapjack is a scalable and distributed monitoring system. It natively talks the Nagios plugin format, and can easily be scaled from 1 server to 1000. Flapjack aims to be simple to set up, configure, and maintain, and easily scales from a single host to multiple. This talk was presented on 30/10/2009 at Devopsdays in Gent, Belgium.]]> Thu, 05 Nov 2009 16:20:47 GMT /slideshow/flapjack-rethinking-monitoring-for-the-cloud/2433231 auxesis@slideshare.net(auxesis) Flapjack: rethinking monitoring for the cloud auxesis Flapjack is a scalable and distributed monitoring system. It natively talks the Nagios plugin format, and can easily be scaled from 1 server to 1000. Flapjack aims to be simple to set up, configure, and maintain, and easily scales from a single host to multiple. This talk was presented on 30/10/2009 at Devopsdays in Gent, Belgium. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/141-joined-091105162106-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Flapjack is a scalable and distributed monitoring system. It natively talks the Nagios plugin format, and can easily be scaled from 1 server to 1000. Flapjack aims to be simple to set up, configure, and maintain, and easily scales from a single host to multiple. This talk was presented on 30/10/2009 at Devopsdays in Gent, Belgium.

Flapjack: rethinking monitoring for the cloud from Lindsay Holmwood

]]> 2679 3 https://cdn.slidesharecdn.com/ss_thumbnails/141-joined-091105162106-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Monitoring web application behaviour with cucumber-nagios /slideshow/monitoring-web-application-behaviour-with-cucumbernagios/1171690 lightning-090319191939-phpapp01
Setting up monitoring for web applications can be complicated - tests tend to lack expressiveness, or and quite often they don't even test the right problem in the first place. cucumber-nagios lets a sysadmin write behavioural tests for their web apps in plain English, and outputs the test results in the Nagios plugin format, allowing a sysadmin to be notified by Nagios when their production apps aren't behaving.]]>
Setting up monitoring for web applications can be complicated - tests tend to lack expressiveness, or and quite often they don't even test the right problem in the first place. cucumber-nagios lets a sysadmin write behavioural tests for their web apps in plain English, and outputs the test results in the Nagios plugin format, allowing a sysadmin to be notified by Nagios when their production apps aren't behaving.]]> Thu, 19 Mar 2009 19:19:34 GMT /slideshow/monitoring-web-application-behaviour-with-cucumbernagios/1171690 auxesis@slideshare.net(auxesis) Monitoring web application behaviour with cucumber-nagios auxesis Setting up monitoring for web applications can be complicated - tests tend to lack expressiveness, or and quite often they don't even test the right problem in the first place. cucumber-nagios lets a sysadmin write behavioural tests for their web apps in plain English, and outputs the test results in the Nagios plugin format, allowing a sysadmin to be notified by Nagios when their production apps aren't behaving. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/lightning-090319191939-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Setting up monitoring for web applications can be complicated - tests tend to lack expressiveness, or and quite often they don't even test the right problem in the first place. cucumber-nagios lets a sysadmin write behavioural tests for their web apps in plain English, and outputs the test results in the Nagios plugin format, allowing a sysadmin to be notified by Nagios when their production apps aren't behaving.

Monitoring web application behaviour with cucumber-nagios from Lindsay Holmwood

]]> 4329 7 https://cdn.slidesharecdn.com/ss_thumbnails/lightning-090319191939-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Your own (little) gem: building an online business with Ruby /slideshow/title-839714/839714 title-26385
]]>
]]> Thu, 11 Dec 2008 16:02:30 GMT /slideshow/title-839714/839714 auxesis@slideshare.net(auxesis) Your own (little) gem: building an online business with Ruby auxesis <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/title-26385-thumbnail.jpg?width=120&height=120&fit=bounds" />

Your own (little) gem: building an online business with Ruby from Lindsay Holmwood

]]> 1117 2 https://cdn.slidesharecdn.com/ss_thumbnails/title-26385-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Deploying Merb /slideshow/deploying-merb-presentation/652745 deployingmerb-1223834740710831-8
Merbcamp talk about deploying your Merb app, covering freezing your app with Git, RubyGems, and Thor; web server configurations; monitoring and performance analysis; and tying it all up with configuration management.]]>
Merbcamp talk about deploying your Merb app, covering freezing your app with Git, RubyGems, and Thor; web server configurations; monitoring and performance analysis; and tying it all up with configuration management.]]> Sun, 12 Oct 2008 11:05:40 GMT /slideshow/deploying-merb-presentation/652745 auxesis@slideshare.net(auxesis) Deploying Merb auxesis Merbcamp talk about deploying your Merb app, covering freezing your app with Git, RubyGems, and Thor; web server configurations; monitoring and performance analysis; and tying it all up with configuration management. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/deployingmerb-1223834740710831-8-thumbnail.jpg?width=120&height=120&fit=bounds" /> Merbcamp talk about deploying your Merb app, covering freezing your app with Git, RubyGems, and Thor; web server configurations; monitoring and performance analysis; and tying it all up with configuration management.

Deploying Merb from Lindsay Holmwood

]]> 585 6 https://cdn.slidesharecdn.com/ss_thumbnails/deployingmerb-1223834740710831-8-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-auxesis-48x48.jpg?cb=1554638561 Engineering leader in Australia, loves music and cycling. fractio.nl/ https://cdn.slidesharecdn.com/ss_thumbnails/escalatingcomplexitymwrc2013-130404105332-phpapp01-thumbnail.jpg?width=320&height=320&fit=bounds auxesis/escalating-complexity-devops-learnings-from-air-france-447 Escalating complexity:... https://cdn.slidesharecdn.com/ss_thumbnails/aa261-130310210244-phpapp01-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/aa261/17090333 AA261: DevOps lessons ... https://cdn.slidesharecdn.com/ss_thumbnails/islands-puppet-at-bulletproof-120607202321-phpapp01-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/islands-puppet-at-bulletproof-networks/13243245 Islands: Puppet at Bul...