3 ms·

>Application teams attempting to assign ownership of a bug to a networking team because they didn't account for timeouts. I had to chuckle - everyone (not just

>Application teams attempting to assign ownership of a bug to a networking team because they didn't account for timeouts. I had to chuckle - everyone (not just developers) seems to blame the network first! (including blame the firewall rules)

aNoob7000 5y ago
First blame the network then the database but never the code. :)
- tssva 5y ago
  This just means the network gets blamed twice because inevitably the DBA's will also blame the network once the issue gets to them.
bennyp101 5y ago
I mean, it /is/ always DNS :)
- gfiorav 5y ago
  Or if you work in a big company, it's always the proxy
  - meatmanek 5y ago
    The real question is: _which_ proxy?
- tyingq 5y ago
  I see a fair amount of DNS problems that trace back to "app resolves a DNS name at startup, and never does the lookup again".
Foobar8568 5y ago
I had to escalate to basically a CIO of a fortune 500 company for someone to take a look at the network performance of our system, all teams were blaming applications despite the evidences. It ended up to be a bug in a VMWare driver that was impacting their whole infrastructure.
tyingq 5y ago
I would add reasonable retry logic also. I've seen quite a lot of outages that would not have been noticed if there were decent retry logic with backoff, etc.
johngalt 5y ago
At one point running wireshark and reviewing network traces with developers was a full time job. Guess what percentage of time it was actually a network problem?