

Operations Anti-Patterns - vacipr
http://opsantipatterns.com/

======
jonespen
Heres another anti-pattern: big buttons with only the text being clickable

~~~
bonobo
Especially when they highlight on mouseover

~~~
saurik
(Especially when a many of them don't have link targets, and most of the rest
are to pages that 404. I'm betting the site is simply not finished.)

------
VMG
Great read

> (Editor’s Note: In order to preserve the anonymity of my sources, the
> company in question will be referred to as “Friendly Business”, or “FB.” And
> I will pick a random name for ops engineers, such as “Mark.”)

~~~
cs702
Agree, it's a great read. I also thought the mention of "Plebian Stable" Linux
being "as old as dirt" was insightful (and a great play on words, because
"pleb" means "of the people"). Packages on the stable version of Debian are so
outdated that using it in production typically requires constant back-porting
of more modern packages, introducing all sorts of operational risks that
threaten its stability.

~~~
3amOpsGuy
I think this is a more of a case of wrong tool for the job. For example if i
have a fairly static mail server configuration then it could best served by
stable - I get security updates back ported but I won't have significant
changes in the underlying platform whipping the carpet from under my feet.

Choosing stable for say the website may not be such a good fit though - the
website is permanently in a state of flux due to having money and developer
time invested with a lot more vigor, introducing new technologies to the
stack, I'd be better deploying testing or more likely unstable under that
stack.

For all I love Debian, the naming scheme has cost me many hours explanation to
senior ops management over my younger years!

All that said, there is also the valid ops concern about developers
introducing unproven tech just because it's in fashion even though there is no
business, operational, architectural or even development advantage to be
demonstrated or even hypothesised from it.

Its not fun for anyone when you have A team of developers with their dummy's
out the pram because you wont open any to any routes on the dmz firewall so
they can use some new sexy message queue when any one of the well behaved,
well proven, stable alternatives would offer the same advantages.

~~~
mnutt
_Its not fun for anyone when you have A team of developers with their dummy's
out the pram because you wont open any to any routes on the dmz firewall so
they can use some new sexy message queue when any one of the well behaved,
well proven, stable alternatives would offer the same advantages._

This sounds exactly like the type of infighting caused by having the
developers not responsible for their app in production and having the ops team
not responsible for meeting the needs of the app. Right or wrong, if this
happens enough the developers will eventually get their own budget and go to
Heroku.

~~~
3amOpsGuy
Just so we're all clear, opening any to any rules on the DMZ means no longer
having a DMZ.

That could be a valid move - there are always trade offs to consider and
possibly the trade offs stack up such that you should no longer have a
separate network for public facing services.

However it's part of the ops team's role to mediate all interested parties
requirements and not just allow random changes to make something work right
this second because one party needs it for their requirements. Every other
team might be a bit miffed if we opened that thus breaking our SOX and PCI
requirements and so landing us with a heavy fine, or worse.

I think the point you're trying to make is there are cases where such an
action could be warranted and so the goal should be to make that resolution
process as fast and as painless as possible for all parties.

------
worldimperator
Reads like a constructive version of <http://thedailywtf.com/> , maybe because
of the anonymized stories. But good read :-)

------
johnbellone
Very good read, bookmarking!

