Atlassian Jira, Confluence outage persists two days on Atlassian's Jira and Confluence issue tracking and collaboration services have been down for some customers for two days now and the outage remains ongoing. Starting around Tuesday at 0902 UTC, Atlassian's status page reported problems affecting customers using Jira Work Management, Confluence, Jira Service Management, Jira …
To be fair, it doesn't seem to have affected our Jira systems.
At least, it doesn't seem to be any more sluggish or clunky than usual...
Quite why any modern system needs you to manually refresh the entire page to see new comments - or to pick up new values in the search boxes - is completely beyond me!
This is why moving your "stuff" to the cloud is probably not the best option for a lot of people. Centralized target for hackers of all stripes and a central point of failure when someone on staff screws up an update or maintenance activity. This happens way too often with all these big players and the fact that they promise resiliency with their cloud offerings, it just doesn't seem to pan out and customers are down for hours or days. Hopefully their customers in this case, since it looks like they've violated their SLA will be getting some major refunds, but I'm sure the CEO will still get his/her bonus for the year.
> This is why moving your "stuff" to the cloud is probably not the best option for a lot of people.
Statistically, there are likely some affected users who were all but forced into the cloud.
Atlassian axed their on-prem versions (unless you want to pay for a datacentre license) about a year back.
They axed it for new orders, luckily (for me in any case) renewals are still an option until 2024. Though unfortunately we’ll have to start moving next year since maintenance for us end in February 2024.
The price hike in our case : over 30% (at current prices), which in absolute numbers is a LOT more than maintaining the 2 measly VM’s our setup requires. That 30% does not include the cost we’ll have to change internal applications that integrate with their crap, and does not include the price hike we’ll have to pay for some addins that are sold either in a Jira cloud or a Jira on-prem version.
While I knew the situation I had a good laugh anyway. I recently renewed a 10 user server license for confluence that I purchased(?) about 10 years ago(for extremely limited personal use) but had lapsed. The cost to renew was $110, to "true up" the license to current time. That's fine, not a big deal.
Then saw the suggestion hey you can move to data center edition. Again I knew the situation but was curious anyway. To see the $10 price on the left for my existing license(to renew again for another year), vs the lowest cost data center offering of a mere $27,000 I think it was on the right(for 500 users).
But at least the license is still perpetual(for the given version of the product anyway).
I've been using confluence since early 2006, and with the cloud version(inherited from the orgs I worked at) the experience has significantly gone downhill in many aspects. My favorite version of confluence I think was probably version 3(guessing here it was a long time ago, the last version to support editing wiki markup). I have been somewhat relieved that their cloud folks have seemed to have postponed indefinitely their forced migration to the new editor. I had so many issues with it and tickets and phone calls. They kept saying that the new editor will be forced soon and I'd have no choice but to use it. But that was about 2 years ago now and that hasn't happened. Surprising they have not been able to address whatever edge cases the old editor allowed that the new one does not yet. At least they fixed one of my most annoying issues which was keys getting stuck and just printing the same character over and over and over again. Took them weeks to figure it out after trying to blame my computer/browser for the issue.
I use JIRA regularly as well but much less often. I don't use any other Atlassian products.
My regular wiki at home is Xwiki which seems to work quite well, confluence is just for some other stuff that I want to be able to access that I haven't moved(yet).
Confluence has some cool concurrent editing features. Useful even for small teams.
It become a bit of a beast of late and I gave up trying to keep up with new features.
I do wish the wiki syntax actually worked and you could post code and log output without hassle.
New features seem to cause breakage. I haven't found the _insert this text verbatim_ feature.
We moved from on-prem Jira to their cloud version (ours is still working), and the main reason for us was that nobody in the office wanted to be responsible for maintaining it. It worked out easier for us to pay Atlassian to deal with that, so we could concentrate on maintaining things for our customers who pay us money.
Just my luck.... stuff I use and would like to keep using, whenever it's down for a "small number of users", I'm somehow in that small number.
And whenever I'd rather have the excuse that "oh that pile of shit is broken so I'll just work on what I think is most important"... Jira continues to be there with it's horrific interface and tedious ceremonies.
If this was routine, that implies something that is done on a regular basis. In the world of Change Management, I was under the impression that changes should always have a back out plan ready to go or some other Plan B. So a routine task shouldn't take down the whole enchilada. In my case, we use on-prem Jira and when notified of the "You vill all go to the cloud" announcement a search was started for another solution. Bye Bye Atlassian.
https://www.drupal.org/project/burndown - this provides a Kanban or Agile Board ticketing system.
1. Get a digitalocean vps for about 10-20 pounds per month. Or host on a raspberry pi. Rationale for these smallish servers is that if the ticketing system is only used by the business, then a large scale server for a public site is not necessary.
2. Map to a web domain, if hosted on a raspberry pi over a non-static IP, use a registrar with a dynamic dns server, like joker
3. Setup a LAMP stack on the server
4. on the server get and install drupal open source CMS, and add the burndown module, also open source, free
5. setup email to send notifications, perhaps use zoho mail - low cost
6. manage backups yourself and security updates
No affiliation, financial incentive or referall benefits of the above to me. There are likely other similar open source solutions out there. Bugzilla comes to mind but I'm not sure how well it works for most recent processes these days, having not used it for many years.
The above will not suit all. There is always going to be a cost and risk whatever approach and that includes consider self-hosting. With the greater control of self-hosting, comes a requirement to have the knowledge in-house and manage the server which means billable time out of one or more staff, along with a process for absence and when those staff move on, offboarding, onboarding.
Cloud has the benefits to those whose business core competence/reason for existing is not to manage a ticketing system. Which makes the cloud a valid consideration. I've used cloud services includingJIRA in some roles as a developer, as well as trello and pivotaltracker.
Still, having options is healthy and the self-hosting may suit some who already have teams in the business of doing that kind of work already with the related skillset.
At my last job all our changes were peer reviewed and any scripts that were to be run also had to have a peer review by someone with equivalent or greater scripting skill/experience. Production level changes went before a CAB except where they were declared 'routine' - routine being the change was successfully executed 10 separate occasions with no backout required, no incidents attributed to the change. Changes to the script would result in the counter being reset and the change could end up needing to be presented to CAB.
If the script hadn't changed since it was last run the peer review of the script wasn't mandatory but we did have to provide evidence that the script hadn't been changed for Production changes (timestamps, checksum or similar.)
Scripts had to be like for like across environments (Dev, Test, Prod (DR was classed as Production) unless there was a specific reason (different setup in Dev to Prod - client tried to save money with lower specs for some environments.)
At the time I got shoved out the door they were working on 'streamlining' processes and pushing the Agile line to speed things up. I had heard on the grapevine later on that my former offshore colleagues had tried to blame one of my old scripts for a major incident. What eventually transpired they had taken one of my scripts as a base, changed some of it's functionality for what they wanted and in the process removed the parts that backed up existing configurations/settings etc. They had presented it as being 'unchanged' so that they didn't have to go through CAB.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
