Blog

Roundup: Patterns for Performance and Operability

Patterns for Performance and OperabilityI recently posted a review of Patterns for Performance and Operability by Ford et al on the SoftwareOperability website. I think that this book is exceptionally useful in its treatment of both performance and operability, and anyone who cares about how well software works in Production should buy and read a copy (there are paper and eBook editions).

Two other reviews might be useful too: my colleague Anant East (Head of Architecture and Infrastructure, thetrainline.com) wrote up a detailed review of Patterns for Performance and Operability on the tech blog at thetrainline.com, and I posted a short review on Amazon.

John Willis (@botchagalupe) on DevOps – “Culture, Culture, It’s Got To Be Culture”

John Willis (@botchagalupe), one of the most respected and knowledgeable people in the DevOps movement, recently gave a talk at the Silicon Valley DevOps meetup group on DevOps Culture. John has been active in DevOps since the beginning (somewhere around 2008, and probably before) and has spoken to thousands of people about DevOps since then. Here’s what he had to say about culture in relation to DevOps:

If you don’t get the C, don’t bother with the A, the M, and the S.

This is a reference to Culture, Automation, Measurement, Sharing (CAMS) which has become the de facto shorthand moniker for DevOps. John is saying that Culture is the foundation of DevOps, and that Automation, Measurement, and Sharing are simply not worth doing if you do not understand that good Culture is essential for DevOps. He continues:

For three or fours years I have been going around saying “Culture, culture, it’s got to be culture”, and people look at you with stare-y eyes going “Shut the hell up” or “Yeah, we get it John. Our culture, absolutely, yeah. NOW CAN WE GET THAT CHEF RECIPE RUN?”. People think [culture] is a ‘kittens and puppy dogs’ thing which no-one really wants to deal with because it’s HARD.

He then goes on to characterise several different approaches to DevOps culture: organisations which try to IMPOSE culture, command-and-control style (doomed to failure); organisations which believe that culture is IMPOSSIBLE to change (also a failure); and organisations (the successful ones) which try to WORK WITH the existing culture and shape it gradually.

(Start from 09’00” in to hear the quotations above)

Jez Humble advocates ‘cultivating culture’ instead of hiring DevOps experts

In a recent talk at PuppetConf 2013, co-author of Continuous Delivery and DevOps champion Jez Humble advocated passionately for not hiring in DevOps ‘experts’ but for cultivating a culture of collaboration and learning (slides 5-7)

This approach of nurturing a DevOps culture within your own organisation is what you will take from attending one of the Experience DevOps workshops; see http://experiencedevops.org/ for forthcoming workshop dates and locations.

Continuous Delivery Workshop with Neal Ford (@neal4d) – a Retrospective

I attended a workshop at DevWeek 2012 led by Neal Ford (@neal4d) on Continuous Delivery (CD). The day was excellent – Neal is a really engaging presenter – and I took copious notes, even though I’d already read most of the CD book. Fifteen months later, I thought it would be interesting to see how my notes from Neal’s workshop compared with my experience of Continuous Delivery, both within my job at thetrainline.com, and also in conversations with other people, particularly the good folks in the London Continuous Delivery meetup group.

The tl;dr version: go attend one of Neal’s excellent CD workshops, but be prepared for the challenges with Continuous Delivery to be much more social/organisational than technical.

Continue reading Continuous Delivery Workshop with Neal Ford (@neal4d) – a Retrospective

Chef on Windows – detecting and fixing WMI problems which prevent chef-client runs

This post covers some issues we had recently with chef-client on Windows due to missing WMI classes, and how we diagnosed, fixed, and mitigated the problem.

Matthew Skelton (@matthewskelton)'s avatar

At thetrainline.com we use Opscode Chef for managing our build infrastructure. Like many other tools running on Windows, the chef-clientohai framework relies on WMI for extracting information about the server machine on which scripts are being run. We found that Windows WMI repository corruption can cause chef-client runs to fail due to missing WMI classes, which causes the node to remain out of policy. The WMI repo can be repaired using winmgmt /salvagerepository, and the WMI errors can be monitored using the WMIDiag script to alert on WMI repository corruption before future chef-client runs. This post details how we detected and fixed the problem, and how to monitor for WMI repository corruption.

View original post 1,131 more words