Michael,
I don't want to put words into your mouth, but is this the sort of
situation to which you are referring?
Developer: "We need to get this update deployed, today. Oh, and by
the way, it assumes X.Y.Z kernel patch on all systems, because that's
what was on my custom workstation. Can we get this before I have to
make tomorrow's 10AM progress report?"
Sysadmin: "Sure. Let me rummage through the tool cabinet,
downstairs, and see if I can find my magic wand and fairy wings, and
I'll get right on that." (Or at least that's what the Sysadmin might
_want_ to say... ...OK, maybe it's just something _I_ have wanted to
say, on occasion.)
(Obviously, honoring your inclusion of ${us} with ${other_profession},
a similar dialogue could be written with the sysadmin requesting an
update to an application, putting the developer "on the spot" in a
similar manner...and earning a similar response.)
In other words, though it may seem to impede the progress of deploying
new and updated services to the environments, there is a _reason_ for
the many procedures we impose on requests for change, such as
requiring documentation of business cases, pre-deployment testing,
etc. And we as system administrators also need to recognize that our
requests to others also are impeded by their experience-proven
processes for similar reasons.
Does that match what you were describing?
--Aaron
On Sun, Jan 23, 2011 at 16:19, Michael C Tiernan
<[email protected]> wrote:
> ----- Original Message -----
>> From: "Aaron McCaleb" <[email protected]>
>
>> "What do you wish ${other_profession} knew about system
>> administration?"
>
> If asked over a pizza, my response would be this somewhat rambling stream of
> semi-consciousness. I apologize for it being so disjointed, I still haven't
> figured out how to express this correctly.
>
> If you ask five people this question "What would you design differently about
> your car?" you'd get a minimum of five answers. All clever and in some cases,
> well thought out. They'd all tell you how to make the fix too. Now ask them,
> "How would you implement /that/ change on an assembly line that is traveling
> at 2-3 MPH? You'll get blank looks.
>
> "Ok, Michael, what the hell are you trying to say?"
>
> I think too often ${other_profession} as well as ${us}, forget that what we
> do isn't done in a vacuum. What makes us different from the average hobbyist
> is the element of time. Well done SA work includes the element of other
> systems *in production* and the effects of time on the overall process.
>
> Anyone can implement a change across a half dozen machines but to do it
> reliably, repeatedly, and without interfering with the other things going on
> with the system or other systems near it is where the difference lies. The
> time element is the ability to make these changes while the metaphorical
> assembly line continues without stopping.
>
> Another aspect of the "time" element is knowing that you do something a
> specific way, even though there's no obvious reason for it, because *later*,
> in another likely situation, your action will leave you elbow room should a
> subsequent problem arise.
>
> Super simple example. You always use sudo to do your tasks instead of always
> being logged in as root because at some point, you may have another SA
> working with you and this will allow you to smoothly operate together. Using
> 'visudo' is another side of that same example. I used to have a coworker who
> ALWAYS edited the sudoers file by hand with his editor, he never used visudo.
> It got to the point where I used to throw a foam ball (not too soft) at him
> when I caught him doing it.
>
> I've rambled long enough and I know it all sounds pretty foolish but please
> try to "read between the lines" at what I'm trying to say.
>
> Thanks for everyone's time.
>
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
