| ▲ | matt3210 a day ago |
| Sounds like nobody knows how their own systems work anymore. |
|
| ▲ | adamsb6 a day ago | parent | next [-] |
| "Everything went down, trying to bring back a subset of things gets killed by thundering herd" is very common. |
| |
| ▲ | Arbortheus 17 hours ago | parent | next [-] | | This is so true. Not making excuses for Microsoft, but OP’s at this very hard. What would have been a “reboot the server” at small scales becomes a concerted operational nightmare at larger scales. | |
| ▲ | gordonfish 11 hours ago | parent | prev | next [-] | | Why so? I'd have thought that in situations like this, one would limit inbound connections, either to certain IPs, or through rate limiting controls, all of which should be controllable at the router / network infrastructure level. Even more so when dealing with a potential incursion (like servers compromised with botnet software that goes back to work not long after a reboot and slams the server and/or network.) | | |
| ▲ | adamsb6 8 hours ago | parent [-] | | Some form of demand control is generally how you work around these problems, but maybe those parts are falling over too. For really big services it's also hard to exercise these processes on anything approaching actual prod scale. Ideally you can chop the architecture into pieces where you can simulate region failure and ensure everything works as planned, and fix whatever you find that breaks with every simulation. But maybe some bits of the architecture aren't amenable to being regionalized. |
| |
| ▲ | londons_explore 14 hours ago | parent | prev | next [-] | | It's very common, but typically teams test things by having a staging instance which also has staging versions of all dependencies. They then deliberately loadtest it to failure and check it can be bought back under control. | | |
| ▲ | voidfunc 13 hours ago | parent [-] | | The staging pattern doesn't scale for systems this large and complicated. Everything is constantly in flux and changing. Ive worked on systems this large and we had something we called staging but it was a joke. Gradual rollout, pilot regions and monitoring are usually how you avoid broken stuff becoming global incidents. Will be interesting to read what process failed here next week. | | |
| ▲ | londons_explore 9 hours ago | parent [-] | | This type of loadtest I normally only perform ~annually in the companies I have done it. It's normally a ~2 week-long project for an intern to identify failure modes of any client side apps (ie. Retry loops etc), capture a sample of production API requests, create some fake data store either on staging or an instance setup specially for the purpose, adjust the request sample to hit that fake data (reads, writes etc), then replay the sample faster and faster till staging fails due to overload, and practice a recovery procedure with the load still applied. If it goes well, redo it with different types of overload - especially large percentages of failure responses from various dependencies, or 1000ms delays added to dependency responses which tends to be one of the trickier things to recover from. Typical outcomes from the work are patches to make the service more robust, fallbacks to not use dependencies or disable features when overload happens, on-call procedures for what to do or not do in certain common cases etc. |
|
| |
| ▲ | dboreham a day ago | parent | prev [-] | | See also the electrical grid. | | |
| ▲ | quaffcode 15 hours ago | parent [-] | | Betting the electric grid has people around who at least understand how their substation works. | | |
| ▲ | venzaspa 14 hours ago | parent [-] | | It doesn't matter if large portions of the grid go down at once. See the recent Spanish outage - the coordination of bringing it back on line is an art of its own. | | |
|
|
|
|
| ▲ | hn_throwaway_99 a day ago | parent | prev | next [-] |
| While I think it's a bit premature to jump to "AI is at fault", and I will emphasize that I appreciate Microsoft's transparency in their status updates, these updates do have much more of a "we don't know what's going on" feel than any other major outage I can think of. It's been hours, and the status updates still feel like there is an undertone of frantic panic (understood if you can't determine the root cause). When I think of past major outages, they may have been down for hours but usually folks knew what the root cause was relatively early, even if remediation took some time. I wouldn't be surprised if AI coding and release pressure was a primary cause, so I really hope the future post-mortem is made publicly available. |
| |
| ▲ | Root_Denied 18 hours ago | parent | next [-] | | I think this has to do more with their calculating SLAs for uptime than anything else. Once they have a root cause and start deploying a fix they can "stop the clock" on the outage, even if they don't get to your tenant right away. Imagine the amount of money they're losing right now in credits that will have to be applied once this finally gets resolved. | |
| ▲ | ethbr1 12 hours ago | parent | prev | next [-] | | > I wouldn't be surprised if AI coding and release pressure was a primary cause, so I really hope the future post-mortem is made publicly available. If nothing else, increased change volume will mean the number of candidate diffs ballooned, possible to a level where non-AI review is impossible on incident-level timescales. Coupled with each change also being AI-documented and the relevant teams having less hands-on understanding of their own changes, so going to the pushing team and asking "Tell me about _____" isn't an option. | |
| ▲ | Aloha 21 hours ago | parent | prev | next [-] | | AI is at fault for what seem like some of the most vaguely worded outage stuff I have seen. | |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | gred a day ago | parent | prev | next [-] | | The email outage gives me time to order popcorn off Amazon for the inevitable postmortem in a few days. I hope it's a good one! | |
| ▲ | NetMageSCW 7 hours ago | parent | prev | next [-] | | You can be surprised because it (apparently) had nothing to do with AI or release pressure. It was a combination effect of two separate network changes. | |
| ▲ | 14 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | jacquesm 6 hours ago | parent | prev | next [-] |
| Wonder why. |
|
| ▲ | riffic a day ago | parent | prev | next [-] |
| Nobody has ever fully understood how their systems work. Thinking largely about "systems as imagined" and "systems as found." Richard Cook wrote about this years ago, and it's always going to be relevant: https://highscalability.com/designing-for-resiliency-will-be... https://how.complexsystems.fail/ |
| |
| ▲ | 10111001 a day ago | parent [-] | | > Nobody has ever fully understood how their systems work. Thinking largely about "systems as imagined" and "systems as found." But with AI, now we can have systems that no one has understood ever. |
|
|
| ▲ | netsharc a day ago | parent | prev | next [-] |
| E.M. Forster says hello. https://americanliterature.com/author/em-forster/novella/the... |
| |
| ▲ | yes_m_ai_n a day ago | parent [-] | | thanks for this. Just read it for the first time. 1909 hits above its weight! |
|
|
| ▲ | solid_fuel 21 hours ago | parent | prev | next [-] |
| Reading the status updates feels a lot like watching some of the OpenAI models try to debug a thorny issue. Throwing half-baked solutions at the wall, then reacting in surprise when it makes things worse, getting increasingly detached from reality until someone clears the context and makes it start over. |
|
| ▲ | imposter 20 hours ago | parent | prev | next [-] |
| [dead] |
|
| ▲ | ajdude a day ago | parent | prev [-] |
| [flagged] |