Inside the longest Atlassian outage • Hacker News Board

Re: Inside the longest Atlassian outage

#41

Post by spaetzleesser » Wed, Apr 13, 2022, 4:32 PM UTC

h2odragon wrote: post #4

> However, if they [restore backups], while the impacted ~400 companies would get back all their data, everyone else would lose all data committed since that point OK, so you restore backups to a separate system, and selectively copy the stomped accounts data back to production. Simple concepts aren't that simple at their scale, sure, but I suspect this is skimping details on some truly horrendous monolithic architec…

“horrendous monolithic architecture “

I don’t really understand what this has to do with “monolithic” or not.

Atlassian’s software is probably very complex and convoluted but from my experience it’s almost impossible to keep a clean architecture in a software system that has grown over many years and is used and customized by many customers so you have to avoid breaking backwards compatibility.

Re: Inside the longest Atlassian outage

#42

Post by bborud » Wed, Apr 13, 2022, 4:32 PM UTC

politelemon wrote: post #31

> it takes between 4 and 5 elapsed days to hand a site back to a customer. Atlassian's SLA page says, Premium Cloud Products 99.9% That's 43 minutes of downtime per month. That works out to, Atlassian can't have any more downtime for the next 14 years. Are SLAs even real? I'm being slightly facetious. From the page text it's just a threshold after which I think you're entitled to some money back for that month.

Think of SLAs as "this is how hard we'll scramble when shit hits the fan".

Except...I don't even believe that.

Re: Inside the longest Atlassian outage

#43

Post by ocdtrekkie » Wed, Apr 13, 2022, 4:32 PM UTC

farseer wrote: post #15

They have recently killed off on premise offerings, it's cloud only now. And this makes it harder to trust both the security and integrity of your data.

The fact that a single bad script could delete 400 of their customers should be absolute proof they do not have the processes in place to be a steward of your data in the cloud. On-prem or bust.

Re: Inside the longest Atlassian outage

#44

Post by Alex3917 » Wed, Apr 13, 2022, 4:33 PM UTC

A few years ago we didn't renew our subscription on time because we got the email over Christmas break, and iirc they deleted all of our data in less than two weeks. They were eventually able to manually restore it from backups, but they restored it incorrectly so there was a bunch of stuff broken. This whole thing isn't even remotely surprising to me.

Re: Inside the longest Atlassian outage

#45

Post by nemothekid » Wed, Apr 13, 2022, 4:33 PM UTC

>Most of them said they won’t leave the Atlassian stack, as long as they don’t lose data. This is because moving is complex and they don’t see a move would mitigate a risk of a cloud provider going down.

I still don't understand the strangehold JIRA has on some clients. I can't quickly think of another SaaS product that could be down for almost 2 weeks and not have most customers leave.

Re: Inside the longest Atlassian outage

#46

Post by foobiekr » Wed, Apr 13, 2022, 4:34 PM UTC

case0x wrote: post #10

luckydata wrote: post #5

so this is the end of Atlassian as a company right?

Why would it ? On our end everything works fine. If you’re not one of the 400 companies, there's no difference

Severe operational issues don’t give you pause?

Re: Inside the longest Atlassian outage

#47

Post by cdjk » Wed, Apr 13, 2022, 4:34 PM UTC

This isn't the longest outage - last time they couldn't recover and recovered data from email archives.

Re: Inside the longest Atlassian outage

#48

Post by ChrisMarshallNY » Wed, Apr 13, 2022, 4:35 PM UTC

Heh. We have a Confluence account.

That no one uses.

So we didn't notice.

Re: Inside the longest Atlassian outage

#49

Post by throwawayHN378 » Wed, Apr 13, 2022, 4:35 PM UTC

When in doubt I go on LinkedIn and find an engineer that works for the company and message them directly.

Re: Inside the longest Atlassian outage

#50

Post by RandallBrown » Wed, Apr 13, 2022, 4:35 PM UTC

throwaway894345 wrote: post #36

h2odragon wrote: post #4

> However, if they [restore backups], while the impacted ~400 companies would get back all their data, everyone else would lose all data committed since that point OK, so you restore backups to a separate system, and selectively copy the stomped accounts data back to production. Simple concepts aren't that simple at their scale, sure, but I suspect this is skimping details on some truly horrendous monolithic architec…

I would really like to understand who makes the decision to purchase JIRA. It's like the C++ of ticketing software--it does everything because no one wanted to sit down and think critically about the use cases and instead decided it would be easier to say "yes" to every single feature request. It definitely feels like whoever is buying JIRA is not on the team who is using it (maybe IT or finance) because it ticks the…

I think people buy JIRA because you can set it up however you want. I've seen it almost as simple as Trello and much more complicated. It doesn't have to be terrible, it just usually is.

If JIRA didn't allow you to make it terrible, it wouldn't allow for some of the absurd things that people want it for and those companies might not buy it.