2008/6/17 Rick Welykochy <[EMAIL PROTECTED]>:
> Jamie Wilkinson wrote:
>
>> 2008/6/12 Jeff Waugh <[EMAIL PROTECTED]>:
>>
>>> <quote who="Rick Welykochy">
>>>
>>>> I've always pondered where to draw the line between sys admin and
>>>> programmer /analyst.
>>>
>>> Wherever you draw it, draw if very firmly. Sysadmins should not write
>>> code,
>>
>>
>> Bollocks.
>
> I've yet to meet a sysadmin who does not write code.
> But I classify it as "scripting".
>
> Leave programming in the large to analysts.

I still have to disagree with you.  This industry needs more sysadmins
who are competent software engineers.  We need sysadmins who are
analysts.  Systems administrators without those skills are not
administrators, they are janitors and night watchmen -- they change
tapes and run other people's programs, without understanding what
happens under the hood.  We need systems administrators who get in
under the hood and experiment; who not only can read code, but
actively participate to the code of the systems they run, to find and
fix bugs, improving stability and keeping their own peace of mind.

It is essential to a business that the sysadmin understand software
development and get involved with that process so as to make it easier
to steer the design to one that allows essential features, such as
logging, whitebox and blackbox monitoring, configuration management,
versioning and rollback, healthchecking, and so on.  (The corollary to
that is that it is also essential to business that the software
developer understands the production environment that their code will
run in, how it behaves, how the sysadmin is going to manage and
sustain the deployment.)

I have worked in environments where the operations and engineering
were separate and did not communicate, where operations and
engineering were done by the same people, and where ops and eng were
done by two communicating groups with a shared subset skillsets.  I
have to say I vastly prefer the latter, where employee productivity
and morale goes up along with system reliability.

But to the point at hand, that a sysadmin should not write code -- who
else will?  How do you prevent boredom or insanity on your part by
automating processes?  How do you implement self-service tools so your
users can get what they need without involving you?  Who's going to
write all this stuff for you?  None of this stuff is "scripting;" once
you are writing something user facing, or a tool to assist your
production services, you are going to be doing real software
engineering or you are going to relearn the mistakes of software
engineers past the hard way as you deal with the consequences of
hacking away, without design, without bug tracking, without version
control, without regression testing.

There are many excellent tools written by systems administrators.
These tools are not "one off hacks", but fully fledged programs to be
configured, deployed, managed.  "Scripting" languages are not just for
your quick, hack, either.  Many large production systems are written
in perl, python, ruby using real software engineering practice, by
real systems administrators.

There is puppet, an excellent configuration management tool.  Not a
script, but a complex piece of software developed using software
engineering practices, and written by a systems administrator by
trade, Luke Kanies.

(Despite the two weeks I've had to think of more examples, I can only
think of one in the public eye.  I do not consider that to weaken my
argument though -- if anything, just one example shows that it is both
possible and likely that more examples of excellent sysadmin-written
software exists.)

Consequences of the programmer-sysadmin is not just the ability to
write your tools yourself.  How deep do you go when your servers have
problems?  Correlate a log message against the manpage?  Google for
the answer?  When your production apache server segfaults at 3am, what
do you do - restart it and hope it doesn't happen again, or load up
the core into gdb and step through the code to find the crash,
determine that the crash is happening in glibc's nss layer, and
isolate a stack smash in nscd, send a patch upstream, and get your
name immortalised in CVS?

It's a very blurry distinction between a sysadmin and an "analyst."  I
know of many sysadmins who write code, and I do not classify most of
what I see as just "scripting."
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to