| ▲ | nazgulsenpai 2 days ago |
| > Current status: We’re investigating an issue impacting multiple Microsoft 365 services and we've determined the affected infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We're restarting and repairing impacted portions of this infrastructure to restore capacity, and reviewing an unexpected increase in a specific type of service traffic to determine whether it's contributing to the elevated load. In parallel, we're evaluating options to redirect traffic to alternate infrastructure to expedite relief. DDOS? |
|
| ▲ | cortesoft 2 days ago | parent | next [-] |
| As someone who worked in infrastructure for a large global CDN, this sort of overload issues happen all the time when trying to bring infrastructure back online after an issue. First, you have every client retrying connections, whether automated or manual retries. This generates extra load over normal. In addition, whichever systems come online first often get a ton of traffic sent to them, which can immediately bring them back down if you don't have ways to prevent it. You will get a wave of systems coming back online, a ton of traffic hitting them, and then falling over again. Now, I am sure Microsoft is used to this and has procedures and systems in place to mitigate the issues (I know we did). However, sometimes if the right combination of services are failing, even the strategies you had to avoid this sort of failure can themselves fail. |
| |
| ▲ | Waterluvian 2 days ago | parent [-] | | I know it’s not actually that easy but don’t they just have some gateway that’s rejecting 100% of requests and they very gently lower that intentional rejection percentage over time? | | |
| ▲ | cortesoft 2 days ago | parent | next [-] | | In many cases, yet it is that simple. However, in other cases it can be more complicated. For example, if the requesters are other internal services, they might not be behind a single gateway (although you should then have other controls you can use). Other times, it is not easy to block the RIGHT requests, because it is hard to distinguish which backend services will end up being hit by a request (a single request can trigger multiple calls to multiple services). There is also the problem of catch up - if a system in a stable state is close to max capacity, it might never have the capacity to recover from a failure even if the entire system is restored. For example, imagine a log processing system that can just barely handle the normal peak load; if you have a failure where your producers locally store logs until they can send them upstream, you will have to clear that backlog, which requires additional capacity beyond a full steady state, which you might not have. | | |
| ▲ | macintux 2 days ago | parent [-] | | And you never really get an opportunity to thoroughly test these failure & recovery modes until something catastrophic happens, at which point capturing detailed metrics and assessing the right sequence to perform the actions are both challenging at best. | | |
| ▲ | cortesoft a day ago | parent [-] | | Yep. There is simply no load testing you can do when you reach certain levels of traffic. Nothing can generate the type of load you get when you have millions of end users making requests from thousands of different networks, on different equipment and network configurations. |
|
| |
| ▲ | fhood 2 days ago | parent | prev [-] | | It is exactly that easy as long as it isn't the gateway that is the problem. |
|
|
|
| ▲ | lossolo 2 days ago | parent | prev | next [-] |
| Probably self inflicted by some code change, as they mention "specific type of service traffic". EDIT: Seems like now they confirmed that: "We've identified that affected servers are failing automated health checks, which is causing them to become unavailable, and this may be related to a recent change to a component involved in processing those checks. We're testing a configuration change on a subset of affected infrastructure to address this and, if successful, will apply it more broadly. In parallel, we've initiated a restart of all affected servers and are validating whether they're successfully returning to service." |
| |
| ▲ | esseph 2 days ago | parent [-] | | Microsoft 365 Status @MSFT365Status 16m We've not identified any recent change correlated with the start of impact; however, our investigation indicates the failed health checks may originate from a specific component that's responsible for processing server health. We've taken steps to prevent additional servers from being impacted while we work to return the affected servers to service. More info under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as status.cloud.microsoft if the admin center is not available to you. | | |
| ▲ | kabdib 2 days ago | parent | next [-] | | Is this a case of "who shall healthcheck the health checker?" | | | |
| ▲ | drillsteps5 2 days ago | parent | prev [-] | | Currently (17:22EST): > Previous status: We're continuing to work through restarting and validating the affected servers to safely return them to service, and we're exploring opportunities to expedite this process. In parallel, we're assessing whether reverting the small number of recent configuration updates we identified could help accelerate recovery. If failures started at some point in time then something must have changed just prior to that. If no changes in traffic were detected (no DDOS) then it must have been a change, be it code or config. Duuuh. | | |
| ▲ | esseph 2 days ago | parent [-] | | > then something must have changed just prior to that Not at all, they could have simply hit an unexpected behavior for their infra they hadn't seen, tested, or expected before. Global scale infra gets very, very complex, and tbh this is Microsoft... they're not very good at it. | | |
| ▲ | drillsteps5 2 days ago | parent [-] | | Unexpected behavior doesn't happen out of the blue, it's not LLM, these are deterministic systems. It's usually config change or code change, not necessarily in the component that's misbehaving, but it is somewhere. More often than not, it's DNS :) | | |
| ▲ | esseph 2 days ago | parent [-] | | > Unexpected behavior doesn't happen out of the blue, it's not LLM, these are deterministic systems. Oh... Oh I have news for you :) | | |
| ▲ | macintux 2 days ago | parent [-] | | No kidding. One computer can behave ~99.999% deterministically. A large network of them? Never. |
|
|
|
|
|
|
|
| ▲ | bitteralmond 2 days ago | parent | prev | next [-] |
| My guess: too many DC resources dedicated to AI, leaving insufficient free capacity to handle traffic spikes |
| |
| ▲ | nazgulsenpai 2 days ago | parent [-] | | I laughed then realized this is plausible | | |
| ▲ | avisser a day ago | parent | next [-] | | Seems unlikely to me. Different hardware requirements. AI workloads aren't running on your standard 2U server. | |
| ▲ | cozzyd 2 days ago | parent | prev [-] | | And then they're probably trying to debug with their AI which isn't helping. |
|
|
|
| ▲ | anvuong 2 days ago | parent | prev | next [-] |
| If Outlook can go down because of DDOS then it's a much worse problem. |
| |
|
| ▲ | gloosx 2 days ago | parent | prev | next [-] |
| isn't Microsoft 365 called Copilot now? |
| |
| ▲ | rawbee1989 2 days ago | parent | next [-] | | no, Copilot and Copilot Premium are products on the M365 platform, copilot is down too | | |
| ▲ | ahartmetz 2 days ago | parent [-] | | Surely you mean Microsoft Copilot Premium for Copilot for M365 for Copilot. For Copilot. | | |
| |
| ▲ | bix6 2 days ago | parent | prev [-] | | It’s actually O365 by Microsoft featuring Copilot by Bill Gates. | | |
|
|
| ▲ | browningstreet 2 days ago | parent | prev | next [-] |
| Nah, just a "Reply-All" chain at NVDA... |
| |
|
| ▲ | bombcar 2 days ago | parent | prev | next [-] |
| >reviewing an unexpected increase in a specific type of service traffic to determine whether it's contributing to the elevated load This seems to be the smoking gnu, now what would it be ... |
| |
| ▲ | BLKNSLVR 2 days ago | parent | next [-] | | I'd like to think that The Smoking Gnu was a competitor publication to The Lone Gunmen. (I've recently been revisiting the X-Files. Can recommend.) | | |
| ▲ | berkeleyjunk 2 days ago | parent | next [-] | | I think you would probably also like the spinoff “The lone gunmen”. Pity it was only one season. | | |
| ▲ | BLKNSLVR 2 days ago | parent [-] | | Yeah, once I'm done with X-Files it'll be next on the list. Seems there are those who love it and those who really don't, and not much in between. |
| |
| ▲ | markus_zhang 2 days ago | parent | prev [-] | | One of my favorite shows! I have two, the other is Yes Minister. | | |
| ▲ | OnlineTux 2 days ago | parent | next [-] | | I see you are a human of culture! | | | |
| ▲ | BLKNSLVR 2 days ago | parent | prev [-] | | Oh man, Yes Minister is almost too good. I was making my way through that series as well, a while back, but I think I got sidetracked by Trump winning the election and Yes Minister just seemed like the actual news. I'll get back into it. Can't recommend it highly enough. | | |
| ▲ | markus_zhang a day ago | parent [-] | | It is really a pity that people don't make those nowadays. It is too politically incorrect and inconvenient to see reality turning into a comedy show. |
|
|
| |
| ▲ | stn8188 2 days ago | parent | prev | next [-] | | At first I thought you meant the traffic increase had something to do with free software :/ | |
| ▲ | reaperducer 2 days ago | parent | prev | next [-] | | This seems to be the smoking gnu, now what would it be ... I saw a frog smoking on The Little Rascals once, but never a gnu. | |
| ▲ | cuu508 2 days ago | parent | prev [-] | | Certainy not Unix! | | |
|
|
| ▲ | MadrasTh0rn 2 days ago | parent | prev | next [-] |
| Reminds me of this https://www.reuters.com/sustainability/boards-policy-regulat... |
|
| ▲ | 2 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | iAMkenough 2 days ago | parent | prev [-] |
| Too many AI agents connecting at once? |
| |
| ▲ | nazgulsenpai 2 days ago | parent | next [-] | | sam altman needs a big headline to shore up AI funding | | | |
| ▲ | FranOntanaya 2 days ago | parent | prev [-] | | Maybe people trying to catch the next Nvidia headline ahead of everyone else, wherever it may be found in (likely someone's inbox.) Edit: Oh, there it is. |
|