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

Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

twitter.com

Post reply on HN
Print view View original

71–80 of 260 posts

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#71

Post by yabones »

beachy wrote: post #49
yabones wrote: post #22

We're mere weeks aware from migrating to their could platform after the self-hosted rugpull. This really doesn't give me confidence in their ability to not break my stuff.

Why would you continue with that plan? You couldn't get a clearer warning signal.

To be quite honest, the problem is historical. We have over a decade of project plans, support tickets, change control logs, etc in our Jira instance. There's simply no painless way to export that into another product that will have approximately the same functionality and features. There's a few that come close, but all fall short of a drop-in replacement.

The only options now are the $$$$$ "datacenter" license, migrating to the dangerously unstable cloud, or not doing anything and running unsupported EOL software.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#73

Post by lonelyasacloud »

vbezhenar wrote: post #50
xenadu02 wrote: post #29

Earlier quoted context omitted.

Reminder: never delete data for real as your first step. Always mark it deleted along with a time stamp saying when. Then you can hide deleted itemsfrom everything. When a maintenance script goes haywire you can fix the problem quickly. Have a daily job that really deletes records marked deleted after 30 days. If that is too complicated to retrofit then have any mass cleanup script move the records to a CSV file or t…

What's wrong with restoring from backups? This is one reason they exist after all. I don't think that making a mistake in delete statement is something you would do every week.

Could be that they are restoring from backups - just that that restoring from those backups is very very slow. Atlassian would not be the first where resourcing and testing a speedy disaster recovery strategy wasn't given the highest engineering priority.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#74

Post by polski-g »

rglover wrote: post #72

I love stuff like this happening, not for the schadenfreude but for the "what not to do" lessons. #3,198,191 Don't automate deletion scripts w/o sufficient recovery options.

Bigger lesson is: do not utilize cloud solutions. Your organization's competency floor is set to the least competent employee of the cloud provider.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#75

Post by bartread »

justin_oaks wrote: post #64
xenadu02 wrote: post #29

Earlier quoted context omitted.

Reminder: never delete data for real as your first step. Always mark it deleted along with a time stamp saying when. Then you can hide deleted itemsfrom everything. When a maintenance script goes haywire you can fix the problem quickly. Have a daily job that really deletes records marked deleted after 30 days. If that is too complicated to retrofit then have any mass cleanup script move the records to a CSV file or t…

I agree that data must never be "deleted and forever gone" unless you've already been very sure about it a few time. But I would like to warn people about certain implementations of database "soft deletes" that I'm not a fan of. To be clear, I'm talking about the idea of having a "deleted" and/or a "date_deleted" column and using those columns in the WHERE clause to filter out rows that shouldn't be visible. That pat…

> Accidentally deleting data that needs to be undeleted is usually rare so I don't think people should optimize for it.

That's very use case dependent.

We've made it easy for people to undelete data they've accidentally deleted simply because they used to do it so often and the only people who could get it back were our tech team. We're a devops org so part of our job is of course to support the systems we build, but our time is better spent on building solutions to business problems than to repeatedly providing support for issues that come up all the time. Part of building those systems is of course engineering in solutions that make it hard to screw up, and easy to unscrew when things inevitably do go wrong. No mean feat given our platform dates back over 15 years and still includes a lot of legacy from the time when tech was just a couple of people.

I suppose the object lesson here is that edge cases in one system or company can be part of core business in another so it's best not to make too many assumptions.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#76

Post by TameAntelope »

encryptluks2 wrote: post #14

I'm honestly surprised their stock hasn't plummeted yet. There is no way I could ever invest in a company that was this terrible.

Not sure why an issue affecting a tiny number of clients would crater the stock.

I've been pushing for an exit from Jira for a little while now, but this doesn't really add much ammo to that argument for me. It's like pointing at a plane crash and trying to justify the company no longer fly people places.

Re: Atlassian: We estimate the rebuilding effort to last for up to 2 more weeks

#79

Post by mirntyfirty »

laurent92 wrote: post #42
Nextgrid wrote: post #26

I bet they screwed up royally, deleted some data and are down to either rebuilding it from logs, caches or other side-effects, or using data recovery software on the storage drives (which might involve third-party companies). I can't see many other reasons why this should take 2 weeks.

Let me bet: Rebuilding from Jira email notifications. Yes, the diffs in the notifications.

But are they gonna be able to accomplish anything without Jira guiding their projects?
Post reply on HN