| Yandex.Taxi, like Uber (in fact, they merged with Uber in Russia), is not really a 'taxi service', they're a marketplace. A real taxi firm would notice and stop taking new calls to the address, but Yandex.Taxi aren't really 'dispatching' taxis, they're just advertising jobs, and letting drivers respond in real time. In fact, I'd imagine that almost none of the orders placed are reviewed in realtime, and the only indicator that anyone would have had for this to begin with would have been a higher than average number on the dashboard for 'trips requested today' - an interesting metric, but not something that I would expect to be monitored closely in real time. I'd imagine there's a 'no show' procedure that doesn't involve human oversight, so the first couple of drivers likely arrived at the address, waited a few minutes, then coded in the no show and moved on to different jobs. This is also likely a metric on a dashboard which would have been the second indicator - booking cancellations/no-shows/driver rejections. But again, it's an analytics metric, rather than realtime actionable business intelligence, so it's the sort of thing that gets put into weekly reports. Maybe someone would have seen it and thought 'huh, that's a bit high', but probably didn't trigger any alarms. Eventually a curious taxi driver would start to question why there are so many taxis outside this address, and would get out of his car and chat to his colleagues. They'd identify that they'd all been asked to the same address, and probably all cancel together and drive off. MAYBE the third indicator here would be a call from one of the drivers to customer support, letting them know about the 'system glitch' that meant multiple taxis were waiting at the same address, but it's equally possible that the drivers just moved onto their next fare without reporting any issue. So potentially, the first time that anyone at YT realised there was a serious issue was already 10-15 minutes after the incident occurred, by which time, it's already late. On top of that, it's unlikely that they have a way to easily and effectively cancel all bookings to a particular address. I don't have any details on the hack itself or YT's infrastructure, so it may have been very difficult to identify and cancel the fraudulent bookings en masse (e.g.: fuzzed addresses, booking times, different users, card details not stored or different card numbers used, etc.). By the time it got escalated to any technical teams, we're already likely 30-40 minutes into the incident itself, at which point they have to analyse what is happening, trace how it happened, and identify a fix. With the immediate nature of taxi booking (I want a taxi NOW, not in 45 minutes), it doesn't surprise me that an incident like this can occur before any technical measures can be put in place to stop or mitigate it. |