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

191–200 of 772 posts

Re: Inside the longest Atlassian outage

#191

Post by DocTomoe »

macintux wrote: post #65
dangus wrote: post #58

Earlier quoted context omitted.

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.

> allow any ticket to be a child of any other ticket?

I have no idea why you would want this from a work management point of view, but you can just use issue linking to describe a parent child relationship.

Re: Inside the longest Atlassian outage

#192

Post by nh2 »

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.

> it's just a threshold after which I think you're entitled to some money back for that month

That is exactly what SLAs are.

There are just a lot of people applying the wishful thinking that SLAs are a goal or metric of uptime.

Consider the AWS S3 page on the topic: https://aws.amazon.com/s3/sla/

"Reasonable efforts"; if not met, you get some fraction of the money back.

S3 has worse uptime than my desktop PC over the last years, but affected users got some fraction of their spending back.

Re: Inside the longest Atlassian outage

#193

Post by KptMarchewa »

_dark_matter_ wrote: post #165
closeparen wrote: post #136

Earlier quoted context omitted.

JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that the mass of knowledge workers beneath you are opaque : you have no way of knowing whether they're working or not. Another problem you face is that they're uppity : people who went to college and got used to managing their own time now have all kinds of idiosy…

I feel you here, but I've been at multiple companies that used JIRA and never once had any of those requirements. I've also never seen it come up when deciding which ticketing system to use. Teams have always been free to move tickets at-will.

One very large video game studio has tons of automation for Jira. Imagine someone deciding to add new weapon. The automation creates 100s of tasks for concept artists, 3d artists, animators, sound artists, software developers with complex dependencies better those. Most importantly, automation creates multiple QA steps for each element of completed work.

The same exists for levels, enemies, quests and tons of other elements.

I would not be surprised if a lot of studios had similar workflows.

Re: Inside the longest Atlassian outage

#194

Post by outworlder »

taeric wrote: post #87
ZetaZero wrote: post #81

Earlier quoted context omitted.

This. It would be an impossible nightmare for every account to have their own DB. Hundreds of thousands of accounts and databases....

Wait. Why? This sounds like something that feels hard, if you are used to the giant DBs of old. But you can probably get many many instances of the smaller databases without much trouble. Would still be some maintenance, don't get me wrong. But far from impossible.

It would be a nightmarish scenario if you have thousands of customers. And completely unnecessary. You can create multiple databases and or schemas in a single instance.

Don't do any of the above unless you understand the implications.

Re: Inside the longest Atlassian outage

#196

Post by function_seven »

mrits wrote: post #96
brianwawok wrote: post #25

Earlier quoted context omitted.

Is it? We use JIRA. Not impacted. If this had hit us.. we would just switch to excel or something for a week/month? But maybe we are a very light user of JIRA. Nothing in there can't be replaced. It's "nice" to be able to go look up a 3 year old bug and which client reported it, but not really crucial for day to day ops.

I wonder why you use Jira if a spreadsheet is sufficient for your use case.

Same reason I use oil lamps when the power is out, even though electric bulbs are my normal lighting.

A spreadsheet may be sufficient, but it's not as good as a system designed for development workflows.

(This comment sounds like I have a speck of love for JIRA. I don't! :)

Re: Inside the longest Atlassian outage

#197

Post by outworlder »

brightball wrote: post #98
radicaldreamer wrote: post #40

Earlier quoted context omitted.

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?

There are basically two options for multi-tenancy with their own tradeoffs. 1. An account/tenant_id field for each table 2. A schema for each tenant wrapping all of the tables Option 2 gives you cleaner separation but complicates your deployment process because now you have to run every database change across every schema every time you deploy. This gets more complicated as your code is deploying in case the code its…

Option 2 has many unforeseen consequences.

Business wants to run a query across customers? In most DBs you need either custom code or to create a stored procedure to iterate across schemas.

Every table that you create is multiplied by the number of customers. This has implications for some database systems (like PG's vacuum).

Your migrations will take _forever_ to run.

Etc.

Re: Inside the longest Atlassian outage

#198

Post by vikingerik »

BlargMcLarg wrote: post #51
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…

Trickle down and first mover. JIRA was there first being "decently ok", enough people adapted it and now others do the same. Then couple with that what you write, the people in charge of deciding the software are generally the ones who can justify wasting half their day on it. To this day I still don't know what JIRA does so much better that other products don't which big corps are willing to waste months worth of ma…

Jira's big feature is being widely known. It's the modern version of "nobody ever got fired for buying IBM."

Re: Inside the longest Atlassian outage

#199

Post by originalvichy »

thesh4d0w wrote: post #156
ineedasername wrote: post #152

Something to consider is that Jira can require a great deal of configuration to tailor it to your needs. If you already have a DevOps team of some capacity (not everyone does) then it may only be a small incremental increase to run thinks on prem. I did it myself: I'm ver much not a DevOps person, mostly unfamiliar with optimizing JVM parameters for apps like this, but it still only took me about 5 hours to get thing…

Atlassian has EOL'ed their non-cloud products https://www.atlassian.com/migration/assess/journey-to-cloud

I have had to correct this too many times already. Server is the name of the deployment type of their on-prem. It means single node non-clustered. Data center is their deployment that supports clustering to multiple nodes (and used to support a few extra features). They are retiring the Server deployment type licenses and pushing everyone to data center or cloud. So no, they aren’t EOLing their on-prem.

Re: Inside the longest Atlassian outage

#200

Post by mmcgaha »

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.

I think of SLAs as how do we design this thing. Ask for a system without an SLA and I will give you a system that is well designed and almost never goes down. As soon as you ask for an SLA, I will give you an over engineered system that costs more, takes longer to implement and is slower to iterate but it will almost never go down either.
Post reply on HN