Silos and How They Impede Productivity
Jodie Struthers
Posted on August 13, 2020
Have you ever started a new job and there were tickets waiting for you? I'm talking eight month old issues in the backlog that have multiple comments that increase in frustration, and then end with, "On hold until we hire a SME (Subject Matter Expert) to figure this stupid shit out."
I've walked into a pile of these, but this is one of my favourites. I'd been hired to manage some relationships, work on new initiatives, and do some infrastructure migrations. One particular ticket was for PHP and it throwing a WSOD (White Screen of Death). The engineers couldn't figure it out despite multiple attempts. They're smart folk, but they felt it was outside of their expertise. So this issue sat around and became stagnant.
Until I came along. I looked at the issue and replicated the steps. I got the same WSOD that they had been encountering. I was expecting that. The issue wasn't with PHP though. Given the locked down nature of the box, I could not access all of the logs that I needed to diagnose... but I had a suspicion.
I did the unthinkable: I talked to the folks in DevOps and Infrastructure. I asked them my nagging question, "Those environments you set up... are they also running a newer version of Apache?" (For my newcomers, Apache is a type of web server.)
"Yes."
Bingo bongo.
Access control for Apache changed between version 2.2 and 2.4.
-
Apache 2.2 uses the
authz_host_module
to control access using directives likeDeny
,Allow
, andOrder
. -
Apache 2.4 also uses the
authz_host_module
for access control, but adds theauthz_core_module
, which gave us theRequire
directive.
To summarize the issue: if you're trying to use Apache 2.2 access rules for an Apache 2.4+ server, you might have a bad time.
The solution was editing the .htaccess
file so that it was in 2.4 format instead of 2.2. Multiple projects were stalled for over eight months because of an .htaccess
file and no one thought to bother talking to folks outside of their team. What the hell.
My fix looked a little like this:
A one-liner.
A fucking one-liner.
How much time had been lost because no one bothered to talk to one another? It's great to become a specialist in your chosen domain/language(s), but often the problems you encounter will lead you outside of your comfort zone. It's so easy to shrug it off as "not my problem."
That was one of the most satisfying issues I've ever closed. Not because it was technically complex, but because it was so obvious after one simple conversation. I do have a lot of server administration knowledge, so I don't want to discount that. I knew what to ask. But the thing is: the DevOps team had all of that knowledge. Not to mention that it would have been trivial to get them to look at the error logs.
Ask questions. Share your wealth of knowledge. Add more to your problem solving toolbelt. You might be holding you and your team back.
Posted on August 13, 2020
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.