Live data from Hacker News

Full technical details on Asana's worst outage

blog.asana.com

11–20 of 70 posts

Re: Full technical details on Asana's worst outage

#11
post #9

Was this incident really recorded minute by minute or is that made up? I've noticed a lot of companies that give this kind of detail like to give a minute by minute report, I just don't understand how they get that accuracy?

It's from details gathered from tickets and chat history, customer reports and server logs. My team is developing a set of tools to manage our incidents, and automating the gathering of details like this are central to the reporting element.

Re: Full technical details on Asana's worst outage

#12
post #9

Was this incident really recorded minute by minute or is that made up? I've noticed a lot of companies that give this kind of detail like to give a minute by minute report, I just don't understand how they get that accuracy?

Often one person will be in charge of taking notes while the rest diagnose (using things like server logs or email timestamps to get these times as precise as possible). Not just for the post mortem, it can be very helpful in figuring out what happened, making sure the timing of events plausibly lines up with your hypothesis, extrapolating based on the length of a particular part of the incident to decide what to do next, etc.

Re: Full technical details on Asana's worst outage

#13
post #9

Was this incident really recorded minute by minute or is that made up? I've noticed a lot of companies that give this kind of detail like to give a minute by minute report, I just don't understand how they get that accuracy?

Oh, man. Most definitely that's real.

If you're working in Slack or chat, you've got a minimum of half a dozen people typing and putting out suggestions and offering to investigate something. That's all time stamped. And even if you're not doing that real-time, you may be using something like a GitHub issue to discuss the problem via comments, which are also time-stamped.

No one at the moment of the incident is probably going "Ah, it's 8:01, better write down that I identified the problem." It's most likely "hay I think I got it one sec" and then that works. Or doesn't. But hopefully it does.

Re: Full technical details on Asana's worst outage

#14
post #9

Was this incident really recorded minute by minute or is that made up? I've noticed a lot of companies that give this kind of detail like to give a minute by minute report, I just don't understand how they get that accuracy?

We reconstruct history from timestamps in Slack and our logging and monitoring systems.

Re: Full technical details on Asana's worst outage

#15
post #4
post #3

Earlier quoted context omitted.

This was the first time we had this class of outage. Many things were in a very bad state, and many of these symptoms were more familiar to us. So we spent time ruling them out before realising webserver CPU was closer to the root cause than the other symptoms. We roll back by reverting to a previous release on the load balancers, which is usually pretty instant. The previous releases were bad and themselves rolled b…

What I don't get is why you didn't see the relatively low cpu usage on the database server and the super high ones on the webserver immediately in a nagios (or similar) dashboard.

And apparently there were no alarms in place for these kind of things

Re: Full technical details on Asana's worst outage

#16
post #9

Was this incident really recorded minute by minute or is that made up? I've noticed a lot of companies that give this kind of detail like to give a minute by minute report, I just don't understand how they get that accuracy?

they probably just look at the chat history and wrote a timestamped summary narrative.

judging from the number of 'sorry's in the text, seems like post mortems have been slowly adapted into a very specialized form of semi-fictional stage drama in which the audience is pandered to excessively through the use of hyperbolic apology.

Re: Full technical details on Asana's worst outage

#19
post #15
post #4

Earlier quoted context omitted.

What I don't get is why you didn't see the relatively low cpu usage on the database server and the super high ones on the webserver immediately in a nagios (or similar) dashboard.

And apparently there were no alarms in place for these kind of things

Apparently a lot of parts of the system were on alarm.

Re: Full technical details on Asana's worst outage

#20
post #18

> Initially the on-call engineers didn’t understand the severity of the problem Every outage I read, something like that happened. At least asana didn't blamed the technology their were using.

For me that was the great part of the post mortem, they identified the response process itself as the root cause.
Post reply on HN