[nycbug-talk] Hypothetical: the end of the sysadmin/systems engineer/DBA?

swygue swygue at gmail.com
Tue Mar 30 23:11:56 EDT 2010

On Tue, Mar 30, 2010 at 8:25 PM, Marc Spitzer <mspitzer at gmail.com> wrote:
> On Tue, Mar 30, 2010 at 8:03 PM, Matt Juszczak <matt at atopia.net> wrote:
>>> Your are on point, your reference to the tripwire yellow book is
>>> exactly how things are done at my place of employment. One of my
>>> primary roles is to migrate our tomcat application from Windows to
>>> Linux, I'm in between development and the application support teams.
>>> One day, after spending another week troubleshooting an issue that
>>> turned out to be a application configuration problem again. I turned
>>> to my manager and told him we need to adopt a policy of rebuilding
>>> systems rather than troubleshooting. I suggested this because I
>>> realize that its difficult to troubleshoot something you don't have
>>> control over, when you have another team that insist the issue is on
>>> your end and you have to prove them wrong before they take a closer
>>> look at their configs.
>> I agree and disagree with this.  I think anything at this point that isn't
>> standardized should be rebuilt in general into a standardized setup (puppet,
>> openldap, centralized DNS, etc.).  But then, rebuilding is easy - you just
>> install a new instance, launch it, and have puppet configure it.

Definitely, I use puppet, DNS, DHCP and cobbler.

>> Are you saying that if one tiny thing breaks, you rebuild the whole instance
>> anyway?  Or are you saying that if something major breaks, and the box
>> becomes too unmanageable?

No, its simple just to force the application support team to come up
with a methodology to manage the application. They tend to make
changes to productions systems, then after time a problem comes up and
we can't replicate it in QA. That's when the blame game starts, they
blame the network, then the server builds. They don't want to spend
the time reconfiguring the server, so that forces them to standerized
and follow the Dev>QA>Production methodology.

> go read the little yellow book, it explains it.  first troubleshooting
> step is reinstall the box and see if that works.  It is a short book
> that tripwire will send you fro free.
>>> You also mentioned project management and writing, you are absolutely
>>> right about that as well. One thing I've realized since working as a
>>> sysadmin is, you don't come across developers or support personnel who
>>> understands infrastructure or understands something simple as how the
>>> OS you are running boots. My writing skills sucks, and my project
>>> management is improving. The little I know of both has helped me deal
>>> with these two groups of people which lead to us "Solving hard
>>> business oriented problems". I've also noticed some people in IT just
>>> stopped learning, and sadly some of these people are now managers, so
>>> knowing how to articulate something in writing can take you a long
>>> way.
>> The latter is quite sad actually =(
> it makes me money.
> marc
> --
> Freedom is nothing but a chance to be better.
> --Albert Camus
>  The problem with socialism is that eventually you run out
> of other people's money.
> --Margaret Thatcher

swygue neron --->>

More information about the talk mailing list