Stats for nerds
1recommend
2mentions
2people
2013years
50% recommend50% neutral
What Hacker News says
- Read The Visible Ops Handbook [1], implement what they talk about, it is an easy read too. On the tools site: puppet [2]. Puppet allows you to bake these controls into your infrastructure and monitor if things change.
p.s. I also read "The Phoenix Project" [3] a couple days ago and it give some good ideas on how to stop in insanity.
[1] http://www.amazon.com/Visible-Ops-Handbook-Implementing-Prac...
[3] http://www.amazon.ca/The-Phoenix-Project-Business-ebook/dp/B...
- Google for blogs written by Google's Site Reliability Engineers - SREs. The Visible Ops Handbook is where devops as a movement, seems to have begun. But Devops is really about taking things like ITIL standards more seriously. It is unfortunate that too many people aim for buzzword compliance with any published standard, without looking for the essential meaning of the standard and adapting that to their own environment. Therefore a lot of stuff on the net about ITIL is crap, but the essential principles and practices that ITIL documents, are necessary for any serious Internet service company. And part of that is that software developers have to be involved in engineering how their apps are deployed and operated and CHANGED. No more silos between ops/sysadmins and developers. In the ideal end game of devops, there would be no more ops/sysadmin roles, just software developers, some of whom specialize in maintaining/improving site reliability. If you are in ops then you need to learn professional software development practices (Bob Martin's book Clean Code comes to mind) and if you are a developer, it means that you need to learn more about managed processes (human processes) and about the architecture of the things that run your code. You have heard of cores, but what about L1 cache and false sharing? How much time does your app spend waiting on locks? Why don't you know the answer to that last question? How do you measure/monitor your apps? If you answered Nagios, go back to school. Uptime is irrelevant, it is application health that matters, resource utilization and so on. Send data to Graphite to build up a historical view of your app behavior. If there is too much data being generated then use statsd or metricsd to only send a random sample of the data, because "too much" is a code for "a random sample would be statistically significant therefore I don't need all the data points".
