Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside the longest Atlassian outage

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

61–70 of 772 posts

Re: Inside the longest Atlassian outage

#61

Post by chrsig »

bborud wrote: post #42
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.

It's more "this is our contractual obligation, if we're down more than this, then we might not charge you"

Re: Inside the longest Atlassian outage

#62

Post by dxf »

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.

>Are SLAs even real?

SLI: Some metric you use to measure a thing (e.g. uptime, latency, etc.)

SLO: Some objective you try to hit, as measured by the SLI (e.g. "99.99% of requests are processed within 3 seconds)

SLA: A promise to a customer that they will meet some SLO, and consequences if they don't. If there aren't consequences for not meeting the SLO, then measuring and tracking the metrics is a pointless exercise.

The SLA is "real" to the extent Atlassian is adhering to any listed consequences.

Re: Inside the longest Atlassian outage

#64

Post by dylan604 »

chrsig wrote: post #61
bborud wrote: post #42

Earlier quoted context omitted.

Think of SLAs as "this is how hard we'll scramble when shit hits the fan". Except...I don't even believe that.

It's more "this is our contractual obligation, if we're down more than this, then we might not charge you"

Lawyers are involved, so I'd assume some text about "excluding acts of god, sabotage,etc" to weasel their way out of things. They might even be able to get away with "acts of incompetence" how ever a lawyer might phrase that to allow their client to weasel.

Re: Inside the longest Atlassian outage

#65

Post by macintux »

dangus wrote: post #58
throwaway894345 wrote: post #36

Earlier quoted context omitted.

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…

The answer is medium to large companies. Jira is a tool that can satisfy hundreds of different teams’ work management needs without having to buy dozens of different products. The fact that it’s so feature packed and customizable is the point. I think the complainers are not really investing the time in to change project settings to fit their needs. My only complaint about the Atlassian suite is the performance of Ji…

How do you change the markup language to be consistent between Jira and Confluence?

How do you eliminate all non-task ticket types in a Jira board and allow any ticket to be a child of any other ticket?

It’s hard to configure away complexity from a product if it’s designed to be complicated.

Re: Inside the longest Atlassian outage

#66

Post by leeoniya »

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.

> Atlassian's SLA page says, Premium Cloud Products 99.9%

> That's 43 minutes of downtime per month.

we need a better default way to communicate SLOs than "number of 9s", which are more human. how the status quo has stayed this way can only be attributed to intentional dark patterns, imho.

Re: Inside the longest Atlassian outage

#68

Post by codingdave »

radicaldreamer wrote: post #40
dabeeeenster wrote: post #33

Earlier quoted context omitted.

How else do you run a multitenancy platform?

Sorry, I'm not actually sure... maybe someone who's experienced in backend db can elucidate here. Is it not a good idea to spin up separate db instances for each client/company?

It is like any other architectural choice - there are pros and cons both directions. If you have separate db instances, you have to scale up the operations to manage each one - migrations, scripts, etc need to be either run against them all, or you need good tooling in place to automate it. A single instance avoids all that, but is more complex in the actual software and definitely more complex for security. A single DB also would let you share data amongst organizations fairly easily, but whether that is good or bad depends on your product. I've created and run products both ways, and I like separate DBs at small scales, single DBs at medium scale, but separate DBs again at huge scale if you also put management tooling in place.

Re: Inside the longest Atlassian outage

#70

Post by notdang »

mkl95 wrote: post #23
pgwhalen wrote: post #14

Earlier quoted context omitted.

> The fact it's been so long and they still haven't revealed and explained the root cause of the outage They did last night: https://www.atlassian.com/engineering/april-2022-outage-upda...

> Communication gap. First, there was a communication gap between the team that requested the deactivation and the team that ran the deactivation. Instead of providing the IDs of the intended app being marked for deactivation, the team provided the IDs of the entire cloud site where the apps were to be deactivated. So what they are saying is that they are not testing scripts at some staging server before running them…

it seems that it worked as intended, thus they have a QA process. The problem was in the wrong IDs provided and I doubt that at their scale they have a staging environment that duplicates the customer data.
Post reply on HN