Monthly Archives: June 2012

Apply Solarized color scheme to Graphite graphs

I spend at least part of every work day looking at graphs.  It’s standard operating procedure for those on the Ops side of things.

I really like using Graphite for exploring my data. It’s such a useful tool.

Recently I’ve been thinking about color schemes. It started off when I heard about the Solarized project from Ethan Schoonover on The Changelog podcast.  Ethan knows more about the effective use of color than anyone I’ve come across. It really expanded my mind to hear about Solarized and it’s choice of colors to “to ensure perceptual uniformity in terms of lightness”.

The default graph colors from Graphite are, well, quite highly contrasting to my uneducated eye. Here’s an example graph using the Solarized color scheme. How do they look to you? Easier on the eye or not?


You can specify the colors to use for a graph by using this in the URL to render the graph. &colorList=6c71c4,859900,d33682,b58900,cb4b16,268bd2,2aa198,dc322f

Leave a comment

Filed under Uncategorized

Tips for Ops to work better with Devs

Recently I re-read Evan Bottcher’s presentation and blog post DevOps – Ten tips for loveless developers.  It’s good advice.

This is a response to Evan’s blog post with some advice for Operations people and teams.

* Earn their trust. If you can form good working relationships with your developers, friendships even, rather than client/patron (or master/slave), they’ll treat you with respect. Try to build equality in the relationship. Help them out, and you may find you can even ask for help when the time comes that you need it.

* Educate them in the mysterious ways of operations. Developers are generally intelligent and curious people. They may not know as much about operating systems and networking protocols as you do. That’s ok. Teach them something!  A less known unix command or how to copy files more quickly, something interesting or useful, or  about what your challenges and constraints are and they’ll understand you better. They will think twice about bothering you about a broken printer during Sev1 incident-in-progress, for example.

* Get an understandng about the motivations and challenges of developers. They may have time constraints and other pressures you’re not aware of. Sometimes it may be ok to bend the “no deploys on a Friday afternoon” rule to meet a deadline.

* Enable them to do their job better. Be proactive about meeting their needs. Whether it be provisioning servers, or upgrading their laptops. If you’re not meeting their needs they’ll find ways around you and it’ll end badly for all. Remember Operations is a service department (that’s a fact of life, it’s not a negative thing). The developers are our customers.

* Learn about their tools and language. Become at least a bit familiar with continuous integration, testing frameworks, Agile software development methodologies. Ask to pair program for a day on a typical development task. Ops often have latent programming skills too! Definitely understand source control and use it.

* Share the metrics with them. Enable easy access to metrics. Preferably without requiring authentication. Teach them what the graphs mean. Celebrate with them when they go in the right direction. Work with them when they go in the wrong direction. Get developers excited about how they can do their jobs better by better integrating their code with Operations’ metrics and monitoring.

* Security is a means to an end. Not the main goal. (Unless that is your main business). It is tempting to lock systems down so well that it prevents people from doing their job. Use appropriate levels of security keeping mindful of the big picture.

* Configuration management is cross team communication piazza. Open up and provide full access to the config management code repository. The more you try and hide what you’re doing from the devs the more they’ll mistrust you.

* As Operations we live by the principle of least privilege. Developers may not understand this concept as well. It’s our job to educate just as much to enforce.

* Invite yourself along to their meetings, standups, kickoffs, retros etc. Be actively involved in the development process from as early as possible. This will help prevent surprises and operations bottlenecks. You may even be invited to their launch parties.

* Don’t resist change. Developers are employed to make changes. These changes to the code presumably will make money. If the organization is more efficient at making money Operations may get new toys to play with, and you may even get paid every week/month. This is a good thing. Enable change.

* Make them aware of the pain of operations. If you’ve been up all night keeping the site alive let everyone know about it. Especially if it’s a code related problem. If you’ve earned their trust they will make it a high priority to fix the root cause. Outages cause loss of confidence in the business, and therefore money. Availability is a shared responsibility.

* The best way of making developers responsible for the code they produce is to allow them to deploy to production. Are you still deploying code manually? Deployment is work for bots (or devs). Building systems to enable this to happen safely is far more interesting work for humans.

And to reiterate Evan’s final comment, use common courtesy.  Say pleasethankyou, and when you’ve screwed up say sorry!

Leave a comment

Filed under Uncategorized