<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 10, 2021 at 2:52 PM Christopher Morrow <<a href="mailto:morrowc.lists@gmail.com">morrowc.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 10, 2021 at 1:49 PM Matthew Huff <<a href="mailto:mhuff@ox.com" target="_blank">mhuff@ox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Reminds me of something that happened about 25 years ago when an elementary school visited our data center of the insurance company where I worked. One of our operators strategically positioned himself between the kids and the mainframe, leaned back and hit it's EPO button.<br>
<br></blockquote><div><br></div><div>Or when your building engineering team cuts themselves a new key for the 'main breaker' for the facility... and tests it at 2pm on a tuesday.</div><div>Or when that same team cuts a second key (gotta have 2 keys!) and tests that key on the same 'main breaker' ... at 2pm on the following tuesday.</div><div><br></div><div><quadruple face palm></div><div> </div><div>not fakenews, a real story from a large building full of gov't employees and computers and all manner of 'critical infrastructure' for the agency occupying said building. </div></div></div></blockquote><div><br></div><div><br></div><div><div>In the early 2000s a friend of mine worked for a company in NYC that provided stock feeds to large banks and brokerages and similar. They'd ship a (locked) cabinet full of stuff to their customers, complete with an Ethernet cable stickin' out the back. Customer would plug this into their network and, um, do whatever it is stock people do. There was some horrendously expensive SLA attached, and so they outsourced support to one of the managed services companies so that they could provide 24x7x2hour response all over the country.</div></div><div><br></div><div><br></div><div>One day, one of their largest customers, a large bank, also in NYC is down. This means that the brokerage arm is unable to do any trades, and so is, um, annoyed. Support rushes over to the customer and "fix it". My friend doesn't really get a good explanation of how it got fixed, but, meh, it's working, so all good. A few weeks later, same thing - customer devices disappear from monitoring, smart-hands/support rush over and fix it, no useful RFO. This happens a few more times, and everyone is getting increasingly annoyed.<br></div><div><br></div><div>Eventually my friend arranges it so that he gets paged at the same time as the support provider. Pager goes off, friend jumps in a cab to the customer. He arrives at the same time as the smart-hands person, who, oddly, is clutching 1: an Ethernet face-plate and 2: a punch-down tool.  Somewhat mystified, my friend follows the support person to where the cabinet is located. Because it's important and special, but not actually bank owned, it cannot live in their data-center... and so it is located in the corridor, just outside the server room. </div><div><br></div><div>Because of where the Ethernet cable comes out the back of the cabinet, and where the wall jack is, there is basically no slack. When someone goes in or out, especially if they are wheeling a cart or carrying a box of equipment, they bang into the cabinet, which slowly rolls away -- ripping the wall jack off the wall, and the cable out the back of the jack. Support's "solution" to this has been to punch down the cable onto a new wall jack, screw it back onto the wall, wheel the cabinet back into place, and call it fixed.<br></div><div><br></div><div>My friend screwed down the cabinet feet, so it wasn't resting on the wheels any more, replaced the 6ft Ethernet with a 15ft, and the issue never recurred :-P</div><div><br></div><div>W</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Matthew Huff | Director of Technical Operations | OTA Management LLC<br>
<br>
Office: 914-460-4039<br>
<a href="mailto:mhuff@ox.com" target="_blank">mhuff@ox.com</a> | <a href="http://www.ox.com" rel="noreferrer" target="_blank">www.ox.com</a><br>
...........................................................................................................................................<br>
<br>
-----Original Message-----<br>
From: NANOG <nanog-bounces+mhuff=<a href="mailto:ox.com@nanog.org" target="_blank">ox.com@nanog.org</a>> On Behalf Of Sean Donelan<br>
Sent: Friday, September 10, 2021 12:38 PM<br>
To: <a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a><br>
Subject: Never push the Big Red Button (New York City subway failure)<br>
<br>
NEW YORK CITY TRANSIT RAIL CONTROL CENTER POWER<br>
OUTAGE ISSUE ON AUGUST 29, 2021<br>
Key Findings<br>
September 8, 2021<br>
<br>
<br>
<a href="https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf" rel="noreferrer" target="_blank">https://www.governor.ny.gov/sites/default/files/2021-09/WSP_Key_Findings_Summary-for_release.pdf</a><br>
<br>
Key Findings<br>
[...]<br>
<br>
3. Based on the electrical equipment log readings and the manufacturer’s <br>
official assessment, it was determined that the most likely cause of RCC <br>
shutdown was the “Emergency Power Off” button being manually activated.<br>
<br>
Secondary Findings<br>
<br>
1. The “Emergency Power Off” button did not have a protective cover at the <br>
time of the shutdown or the following WSP investigation.<br>
<br>
[...]<br>
Mitigation Steps<br>
<br>
1. Set up the electrical equipment Control and Communication systems <br>
properly to stay active so that personnel can monitor RCC electrical <br>
system operations.<br>
<br>
[...]<br>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">The computing scientist’s main challenge is not to get confused by the<br>complexities of his own making. <br>  -- E. W. Dijkstra</div></div></div>