On Sun, 12 Apr 2009, Bob Apthorpe wrote:
> There are certain classes of work that can only be performed by a
> licensed professional engineer, generally those relating to the health,
> safety, and well-being of the public. The software industry has been
> lucky thus far that so few people have died because of bad coding but as
> software & firmware works its way into areas formerly dominated by
> mechanical and analog controls,
but is this a sysadmin issue or a programmer issue?
most of the examples that people produce of systems becoming 'health,
safety, and well-being of the public' may have a little bit of system
administration in them, but mostly they are more tightly related to
programming('software engineering' if you drink that particular kool-aid
;-)
> there will be greater emphasis placed on
> quality assurance, compliance, and liability; it may not happen in my
> lifetime but I firmly believe UCITA's days are numbered. History is on
> my side.
>
> Professional licensure and engineering standards were driven by the
> insurance industry back when any ol' jackass could sell a steam boiler
> or install petroleum piping. I won't bore you with the details of
> history suffice to say that insurers were tired of paying out for
> exploding buildings and boats and the resulting widows and orphans. They
> basically ratcheted Congress into regulating who could do what after
> decades of industrial whining and hand-wringing about the cost and
> "stifling innovation" (where have I heard that before...?)
>
> And yes, that meant that a bunch of people who called themselves
> engineers were driven out of the marketplace; on the other hand, the
> number of exploding boilers dropped, and the death and morbidity toll
> went way down.
and when a system gets breached, how much of the responsibility is on the
various parties involved
1. the line sysadmin working on the machine
2. his manager, who allocates the sysadmin's time to creating new
systems instead of patching an existng system
3. the in-house programmers who wrote portions of the systems
4. the various vendor programmers who wrote portions of the systems
5. the senior sysadmins who wrote scripts and other tools to keep the
systems running (far more of these than management realized in many cases)
6. the company security department who runs network based protection (IDS,
firewalls, etc)
7. the company audit department who are so clueless that they don't
understand what they are looking at
8. the outside pen-test vendor who misses for 8 years of quarterly tests
that sendmail wasn't being upgraded
9. the corporate senior management/risk management group that lets this
all happen
until you can point the blame at the right place you won't be able to
'fix' the problem. SOX attempts to make a start at this by saying that the
people at the top who sign things really are liable, but until you start
seeing CEOs going to jail for problems it's a paper tiger.
also, if whatever standard is created would mean that a large portion of
the senior people in the field are not 'qualified' (and for most
proposals, would never have become qualified), that standard starts off in
a _very_ bad position.
> So what to do?
>
>
> In the short term, we need to serve our community; in the long term we
> need to guide sysadmin education in a way that serves the public, our
> community, and the academy.
>
> Here's a strawman:
>
> 1) Answer the question: "What are accredited schools teaching?" Put
> together a working group to review the state of the art in sysadmin
> education, specifically the ABET-accredited programs and the
> accreditation process. My guess: between 5 and 12 LOPSA members with a
> variety of backgrounds (or whatever has worked for others that have
> served on working groups before.) Set a 3-6 month charter with the goal
> of describing a general sysadmin curriculum. It may be that ABET already
> has such a document and all we have to do is pony up the cash to get a
> copy. Or ask nicely.
>
> If we create this as original work, summarize it in a white paper and
> issue a press release and offer the full report for $$$ a la Gartner.
>
> 2) Of the subjects taught, determine:
> 2.1) which are specific enough that they are covered by vendor certification
> 2.2) which are general enough that they are covered under a bachelors or
> an associates degree program
> 2.3) which subjects or skill are suitable for decomposition into
> day-tracks for a "Sysadmin Days"-style educational conference
>
> 3) Develop and teach a number of "training tracks" based on the skills
> identified in 2.3.
> 3.1) Develop LOPSA-standard curriculum, perhaps with join IP agreements
> with people who may already teach similar courses at conferences.
> 3.2) LOPSA offers these standardized training tracks at conferences
> ("Sysadmin Days", SCALE, OLF?, etc.) & companies
> 3.3) Revise the curricula based on participant and instructor feedback
>
> This most probably would benefit from corporate or university
> sponsorship and a major promotion effort.
in spite of being strongly against the licensing of sysadmins (and as
someone who has been in the field 'officially' for over a decade and puts
zero certifications on my resume), I do see a lot of value in the approach
described above.
the key thing is to try and teach why you need a tool like X rather than
teaching tool X. over the last 5 years, how many 'ultimate' config
management tools have been written that were the rage and the best thing
ever for a while, only to be overshadowed by a new tool. the critical
thing isn't learning cfengine, or puppet, or whatever the flavor of the
day is, it's understanding the concepts and approaches that these tools
have to choose from. if you have a good handle on that you can not only
pick up any of the big tools as needed, you can use/create home-grown
tools that are either already in place in your company, or that you can
gradually grow without needing to do a super-disruptive change to the
company to implement the new tool
I see this as the key differentiation between 2.1, 2.2, and 2.3 above.
there is a place for learning a particular tool, so I'm not saying that
there is no place for a 'learn cfengine' class, I'm just saying that it
needs to be _named_ 'learn cfengine', 'learn puppet', etc not 'learn
config mangement' (whil only covering one tool)
when I go to confrances, the classes that annoy me the most are the ones
that from the title and summary sound like they are a broad coverage of
the field, but end up being 95% about one tool, barely mentioning other
tools.
> 4) Long-term: work with ABET, universities, and other related
> organizations to formalize a standard curriculum.
> 4.1) Use experience gained in 3.3 to guide curriculum formation
> 4.2) Work to publish and maintain the Weighty Tome of Sysadminnery to
> guide the development of additional accredited programs.
changes in the field need to slow down before the WToS can be written, and
what I am seeing is that far from slowing down, it's speeding up with more
new things and options each year than the year before. not to mention that
the combinations of different pieces can interact in ways that nobody
thinks of (until someone does, and creates a substantial company around
it). how many people look at various Internet businesses and not only say
'how did they think of that', but also say 'how in the world do they
actually make money doing that' (and getting a windfall from VCs _is_
making money, for the founders at least)
David Lang
_______________________________________________
Discuss mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
