Small Mosaic


Categories:

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

Archives:

October 20085
September 20084
August 200812
July 20089
April 20084
March 20081
February 20081
January 200815
August 20072
June 20079
May 20076
April 20078
March 200731
February 20073
January 200721
December 20061
November 20064
October 20066
September 200632
August 200617
July 200614
June 20069
May 200613
March 200611
February 200616
January 200611
December 20051
November 20056
October 200519
September 200525
August 200516
July 200516
June 200513
May 20052
April 200519
March 200531
February 200520
January 200531
December 200421
November 200430
October 200432
September 200418
August 20047
July 200414
June 20045

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 17:41 | /sysadmin | Permanent link to this entry | This entry + 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 17:28 | /sysadmin | Permanent link to this entry | This entry + 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 16:57 | /geekstuff | Permanent link to this entry | This entry + same date


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

Copyright © 2000-2005 Dean Wilson XML feed logo