Small Mosaic


Categories:

/books
/career
/codinghorrors
/events
/geekstuff
/justdont
/languages
/languages/bash
/linkshot
/magazines
/meta
/misctech
/movies
/nottech
/operatingsystems
/operatingsystems/linux
/operatingsystems/linux/debian
/operatingsystems/solaris
/perl
/presentations
/programming
/python
/ruby
/security
/security/apache
/security/tools
/serversmells
/services
/services/dns
/sites
/specifications
/sysadmin
/testing
/tools
/tools/commandline
/tools/firefox
/tools/gui
/tools/network
/tools/online
/tools/online/greasemonkey
/tools/puppet
/unixdaemon

Archives:

August 20101
July 20101
June 20104
May 20102
April 20101
March 20108
February 20101
January 20102
October 20092
September 200910
August 200910
July 20094
June 20091
April 20093
March 20097
February 20094
January 200917
Full Archives

Sat, 21 Apr 2007

Deferring Defects - Autonomics
Autonomics refer to the ability of computer systems to be self-managing. -- autonomics.ca

Here's one that has been bothering me. Suppose you have a recurring problem that your "autonomic solution" can handle every time it occurs without any one knowing. At what point does the fact there is a treatable issue propagate up to a real person?

While an automatic "fix and tell me later" approach helps change your work from fire fighting to planned tasks what classifies a temporary problem as being important enough to warrant you investigating it? It's hard enough to justify preventive maintenance with the current systems, if it fixes itself then you may never get given the time to investigate further.

If a problem fixes itself before any one notices or a sysadmin can look at it is it a problem?

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Posted: 2007/04/21 16:41 | /sysadmin | Permanent link to this entry | This entry and same date


Handling Requests: Three Simple Rules
I'm a sysadmin, half my working life seems to be spent handling other peoples requests (which is why I'm trying to move over to infrastructure work - where I can hopefully concentrate on something for three whole minutes). While chatting with a junior admin at a tech talk in the week the following three tips came up:

Use a ticketing system. This one comes up a lot but it's true, never dropping someones request is well worth the time spent setting it up.

Customers sending requests to individuals is a BAD THING. People go on holiday, they get dragged in to meetings. They work on projects. Which of those do you think someone who's been waiting for a request will accept as an excuse? None of them. And telling them that it's their own fault is a great way of annoying them even more - even if it is true. Training your users to reply to all (so follow ups also get tagged by the ticketing system) and to not send a "Just a quick question" mail so their favourite sysadmin helps you keep an eye on the workload while ensuring that things can't drop between the cracks. Even if it's an often repeated uphill struggle.

There is a caveat to this one. If you've got the resources it's often helpful to assign a sysadmin to a new employee for their first couple of days. Asking those awkward new starter questions is a lot easier face to face than on a mailing list of who knows how many. Any requests can then be added in to the ticketing system while the sysadmin is present, showing the starter how to use it, and that the admins actually pay attention to and process tickets. Nothing beats a good first impression.

Lastly, people have an expectation of how long something should take. If you break this unwritten rule, even for a good reason, then they'll notice and it'll be used against you at some future point. While it's not ideal for concentration quickly completing short tasks like password changes can make a huge difference in how your team is perceived.

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Posted: 2007/04/21 16:28 | /sysadmin | Permanent link to this entry | This entry and same date


Automated Database Provisioning Papers
It's been a week of databases, replication, provisioning and planning for automation. While winding down (it's an on-call weekend) I found some links I'd marked for future reading. If you're interested in database provisioning (especially read only replicated slaves), practical autonomics and how they could potentially be useful in a real environment then these papers make for an interesting ten minutes

It doesn't take a massive leap in imagination to see how a similar approach could be used in to horizontally scale web servers in conjunction with an intelligent monitoring system or load balancer. Mix in some thin provisioning and centralised logging and it's something I should really schedule some time to play with. Now, to the papers!

Database Replication Policies for Dynamic Content Applications(pdf)
Autonomic Provisioning of Backend Databases in Dynamic Content Web Servers(pdf)

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Posted: 2007/04/21 15:57 | /geekstuff | Permanent link to this entry | This entry and same date


books career codinghorrors events geekstuff justdont magazines meta misctech movies nottech operatingsystems/linux operatingsystems/linux/debian operatingsystems/solaris perl programming python ruby security security/apache security/tools serversmells services/dns sites sysadmin testing tools tools/commandline tools/firefox tools/gui tools/network tools/online tools/online/greasemonkey tools/puppet unixdaemon

Copyright © 2000-2010 Dean Wilson XML feed logo