Sunday, 9 March 2008

What's your guiding question?

I know mine's changing again, and just for once, I'm aware of it happening.

Maybe (almost certainly) it's been put better elsewhere, but I made this up all by my own self. Your guiding question is the one you always ask. The one you measure everything you do against. The first question. The last question.

I'll try to explain.

My official job title is 'network and systems manager'. In practice, I'm a significant chunk of a team who make all the technical calls, and do all the fixing. We're generalists, who specialise in whatever's the problem right now. Not an unusual situation.

The pertinent part is where we 'make all the technical calls'. And technical decisions aren't always simple. Interesting technical decisions always aren't simple. Security versus ease of use. Customisability versus maintainability. Everything versus budgets. And the technical decisions I make and influence are affected, I hope strongly, by my guiding question.

The guiding question, for me, has evolved.

  1. What do I need to do to make this machine work?
  2. What do I need to do to make this service work?
  3. What do I need to do to make this service work well for my users?
  4. What do I need to do to make this set of services work together well for my users?
  5. How should these services work together to best support what my users are doing?

And today, it's
  • What service infrastructure should I be providing and supporting to equip my users to do what they do, but better?

What's your guiding question?

I moved from bloglines for the comments

and then I forgot to turn comments on. Whoops. Sorted now.

More monitoring with twitter

Or, the little twitterbot that could.

As I've mentioned before, we've got two identical nagios boxes running, one notifies us of problems via email, one via a special private twitter account that the systems team follow. So if email service or one of the nagios boxes goes down, we'll still get notified.

This is an improvement, and we're already getting to problems quicker. Great smashing super. But sometimes we trip over each other. I'll log in to fix something to find that P is already working on it. This hasn't bit us yet, but rest assured, if we don't deal with it, it will bite us one day. So.

The little protocol we're working with now is as follows: when you take on a problem, you IM the others that you're working on it. But that's n-1 messages before you start working on the fix. A pain and a waste of time.

So I'm working on a little bot. It watches the direct messages feed for the monitoring twitter account ( let's call it skaffen ), and when it gets a new direct message, sends it back as an update to the skaffen account, with the original sender prepended. Like this:

skaffen: WARNING -- stuff is borken
mawhin: d skaffen fixing stuff
... up to a minute, because of twitter rate limiting
skaffen: mawhin is fixing stuff

So to pick up a problem you direct message the monitor. I think that's sweet.

Thursday, 6 March 2008

Planning for networkshop 36

I and a colleague will be attending #networkshop2008 (UKERNA run conference for UK academic network folks).

I'm pretty excited about this one, as most every session is of interest. And already there's a clash. The first set of sessions, we two have three choices - Voice Services, Network Security or Network Engineering - all of which promise to be interesting, and more to the point, relevant to stuff we are doing or intend to be doing or need to be doing.

What to do?

Well, the presentations are usually available online after the event. Sometimes before. I'd like to think that UKERNA will be videoing the sessions and putting them up somewhere. I'm hoping there'll be a number of delegates blogging. I intend to be twittering/blogging. I wonder what else would help?