Live data from Hacker News

Inside the longest Atlassian outage

newsletter.pragmaticengineer.com

461–470 of 772 posts

Re: Inside the longest Atlassian outage

#461

Earlier quoted context omitted.

I am biased but I can tell you what works best for mid-large companies: having a solution provider. Basically a partner that hosts and maintains the instance and has enough Atlassian certified people to help you with any question so that you will never have to hire people to just maintain the beasts or tell you about features, tricks or plugins that could solve problem X. Experienced people hosting and tuning Atlassi…

It seems like if you are going to pay for a bunch of SaaS seats AND a team of technicians/engineers for make it work, you might as well just do the latter and roll your own solutions... A lot of these SaaS are just glorified Rails apps with a patina of professional "security" and "reliability", and loads of extra junk that your co will never use.

Trust me, if someone could clone Jira and its functionality they would have done so already. Truth is that if you build one product for 20 years you have a giant lead in features. If all it took was having a Kanban board then Jira would have died years ago.

Re: Inside the longest Atlassian outage

#462
post #460

Atlassian about to dip over the next few years as firms around the world slowly remove themselves from their ecosystem of products.

Right. Feels similar in a way to an ongoing conflict elsewhere... There is what happens now, and what happens over the next decade because people have lost fundamental trust in you.

Re: Inside the longest Atlassian outage

#463

Earlier quoted context omitted.

>"Nobody uses more than 5% of its features, but every company uses a different 5%." >The saying is apocryphal and unlikely to be accurate Well its mathematically impossible to be accurate as soon as you have > 20 users.

> Well its mathematically impossible to be accurate as soon as you have > 20 users. It's probably in the semantics. Text input and editing is clearly a part of functionality that's probably used by everyone (or at least most users), so it's not possible for "different 5%" to mean what you're alluding to, maybe the phrasing needs work. In any given 5% there might be 1-4% of overlap with what others are using and the r…

And the greater the degree of overlap the weaker the implicit argument.

If it's a uniform distribution of discrete features then each feature is equally "important" and worth equal resources and dev time. If 81/100 companies use the exact same 5% of features and the remaining 19 cover the remaining 95%, then all else equal you can probably drop 95% of your features and still do well.

Re: Inside the longest Atlassian outage

#464
post #322
post #258

Earlier quoted context omitted.

Is there a source on this number?

From the article: > Atlassian claims the customers impacted were “only” 0.18% of its customer base at 400 companies. From https://jira-software.status.atlassian.com/ : > The team is continuing the restoration process for the ~400 impacted customers.

> The team is continuing the restoration process for the ~400 impacted customers. We have restored functionality for 45% of impacted users.

If this is truthful it implies implies more than 400 impacted customers.

Re: Inside the longest Atlassian outage

#465
post #408

Earlier quoted context omitted.

I think that depends on what you mean by compliance. Some regulations require you to irreversibly destroy data when they prescribe the destruction of that data. That can mean as much as "you have to encrypt everything with a separate key, so that you can destroy the key for the given (say, personally identifiable) dataset making its retrieval irrecoverable" I'm not saying that's the particular compliance reason they…

"permanently delete" strongly suggests to me that it was the "medical and financial data" kind of compliance. If data can be restored, it's not permanently deleted. But this was a statement from the CEO, so words can have arbitrary meaning :)

"permanently delete" does not mean the same thing as "immediately delete". deleting from the live database is the first step of a permanent deletion, as long as the data exists somewhere the deletion process is still in-progress.

there's a whole lot of people in here who are way too quick to assume that just because one part of a permanent deletion process was inadvertently triggered and then caught while they still had backups, their whole permanent deletion process is a lie.

Re: Inside the longest Atlassian outage

#467

Earlier quoted context omitted.

In these cases the best thing to do is just give every customer the full month refund; don't make them ask for it.

Not every business can afford to go one month without income. What's the best thing for customers? Have the business go bankrupt and irremediably lose access to the service?

It's 400 clients, not all their user base. They can handle the lost income from a small slice of their customers for one month.

And if they can't sustain that, then it's even more imperative that those customers migrate away.

Re: Inside the longest Atlassian outage

#468

What's a good Jira replacement? Redmine? Phabricator? OpenProject? Just leaving the jira server alone and hoping there's no new and exciting zero-days? One thing is clear, these guys are a bunch of cowboys who can't be trusted with any amount of data.

We switched from JIRA to Shortcut https://shortcut.com/ (formerly Clubhouse), and I'd highly recommend them. It's much better than JIRA ever was, both from a UX perspective and an implementation/performance perspective.

Re: Inside the longest Atlassian outage

#469
post #123

Earlier quoted context omitted.

that's an interesting question, i've given a little thought to this multi tenant saas stuff... not sure if the right way forward is some sort of innovation in operating system and software design where people write and run apps that feel like single tenant apps attached to dedicated per tenant datastores where os and framework magic handle per tenant encryption and segmentation (tenant id as an os level concept) or..…

Yeah, soft delete is the way to go in 99.99% of the cases, with a system setup to eventually hard delete on some schedule (preferably don't hard delete until X number of backups have caught the soft deleted data safely, for example).

Hi, this is Mike from Atlassian Engineering. Strongly agree with this. I'd say that if you can afford it, don't do the hard deletes on a schedule though. You never know when there's a system out there referring to soft deleted data that fails once the data is hard deleted. Hard deletes should feel frightening because they are frightening.

Re: Inside the longest Atlassian outage

#470
post #460

Atlassian about to dip over the next few years as firms around the world slowly remove themselves from their ecosystem of products.

Their core customers are unfortunately just as dysfunctional and slow-learning. Think Boeing, etc. Witness:

https://jobs.boeing.com/job/annapolis-junction/jira-administ...

Post reply on HN