Meerdere Atlassian-klanten hebben al een week last van storing Jira-clouddienst

De Jira-clouddienst van Atlassian kampt sinds vorige week dinsdag met een storing. Hierdoor kunnen ongeveer 400 gebruikers onder meer niet bij hun Atlassian-omgeving komen. Wanneer de storing helemaal is opgelost, is nog niet duidelijk.

De storing komt door een fout in een script dat tijdens onderhoud werd uitgevoerd, zegt een woordvoerder van Atlassian tegen ZDNet. Het softwarebedrijf sluit een cyberaanval uit en zegt dat er geen ongeautoriseerde toegang is geweest tot klantgegevens. Verder zegt Atlassian dat het 'honderden engineers heeft gemobiliseerd' om de uitval op te lossen.

De storing heeft ongeveer 400 klanten getroffen, zegt Atlassian. Dat is ongeveer 0,18 procent van de 226.000 klanten van het bedrijf. Deze klanten hebben al een week geen toegang meer tot de Jira-clouddiensten. De diensten die door de storing niet of gebrekkig werken zijn onder andere Jira Software, Jira Work Management, Jira Service Management, Confluence, Opsgenie Cloud, Statuspage en Atlassian Access.

Het bedrijf laat maandag in een update weten dat 35 procent van de getroffen klanten weer bij zijn diensten kan. De website zou zijn hersteld en er zou geen data verloren zijn gegaan. Wanneer de storing helemaal is opgelost, is niet duidelijk. Volgens een supportticket van Atlassian die Tweakers heeft ingezien, kan dat nog twee weken duren.

Reacties (67)

[DDX]

Gelukkig pushen ze je naar de cloud, de on premises oplossing (die prima werkt) stoppen ze mee. (end of support volgend jaar en al sinds vorig jaar geen nieuwe features meer)

[Cergorach]

Er zijn drie (verschillende) producten:
Cloud => Waar dit artikel over gaat.
Server => on-premises, waar jij het over hebt.
Datacenter => on-premises, de vervanger van Server.

Server is EOL, het (significant) duurdere Datacenter is voor zover ik weet niet EOL.
Je betaald voor zowel cloud als on-premises naar hoeveel je gebruikt.

Als je on-premises oplossing nooit down is, dan upgrade je ook nooit. Maar meestal is een dergelijk statement gewoon gelogen of geheel ondoordacht gemaakt.

Of je voor Cloud of Datacenter gaat, ligt geheel aan de kosten en de features die je nodig hebt. Bepaalde features zijn gewoon niet beschikbaar in de Cloud versie en (waarschijnlijk) vice versa...

[R0SSI]

De Data Center variant biedt voor Jira Zero Down Time Upgrades (ZDU) bij Feature en Bugfix releases. Dit al een aantal keer gebruikt en de gebruikers merken hier niet veel van (soms een extra F5 om van node te switchen).
Qua features bij Cloud vs Data Center merken wij dat deze vaak eerst in de Cloud beschikbaar komen en later pas in Data Center.

ZDU is ook beschikbaar bij Bitbucket voor Bugfix releases en Confluence voor Feature en Bugfix releases (Feature updates kunnen (nog) geen versie overslaan, bij Jira kan dit wel).

Versie opzet: X.Y.Z
X = Major
Y = Feature
Z = Bugfix

[Cergorach]

Atlassian heeft een tijdje terug de meest populaire integratie voor CMDB overgenomen, die krijg je er nu gratis bij. Echter de Server/Dataserver versie heeft veel meer functionaliteit om hardware automatisch te detecteren. Ik merk dat soort ongein vaker bij SaaS diensten, dat bepaalde zaken niet kunnen op de SaaS oplossing, TOPdesk is/was er nog zo eentje...

[DDX]

Ok klopt ik had het over de server die ze aan het killen zijn. (per 15-2-2024 EOS)
En idd Datacenter is ook nog een optie om naar over te stappen, alleen is dit pas lonend vanaf 500 licenties want dat is de instap.
In principe zelfde product als server, alleen andere licentie file.
Dus ja je zou on premises kunnen blijven draaien, maar stel je hebt 100 users dan gaan je kosten keer 5 en het is al geen goedkoop product.
Zit je op 20 users dan is het verschil nog extremer.

En wat je zegt over nooit upgraden, misschien als je hem volledig achter een firewall hebt zitten maar met enige regelmaat zijn er security updates die je (zelfs al zou je achter een firewall zitten) moet installeren.

[blouweKip]

Datacenter is echter geen vervanging van server voor veel klanten, dus effectief is voor veel bedrijven is on premies effectief dood over een aantal jaar.

Best jammer want het was een prima product maar het past in de treurige trend om alles in abonementsvormen te gieten om nog meer af te kunnen romen.

[Cergorach]

Datacenter is echter geen vervanging van server voor veel klanten

Dat komt dan waarschijnlijk puur door pricing en niets anders.

De oude prijzen van Jira Server:
https://web.archive.org/w...m/licensing/jira-software
De nieuwe prijzen van Jira Datacenter:
https://www.atlassian.com...a/pricing?tab=data-center

De nieuwe Datacenter begint bij $42.000/jaar voor 500 users. Voor de oude server versie betaalde je in 2019 dus nog maar $24,800 voor 500 gebruikers, je kon de software onbeperkt gebruiken en was inclusief een jaar upgrades/support, elk jaar daarop betaalde je $12,400. Als je minder dan 500 gebruikers had, dan is het verschil nog veel groter. De Cloud versie is een significant hoger bedrag, afhankelijk van welke features je precies wilt... En dat is alleen Jira, nog geen ServiceDesk of Confluence...

Dus ja, voor veel kleinere organisaties die dit niet kunnen opbrengen, zal Jira/Confluence zelf hosten niet langer een optie zijn. Dat zal zijn Cloud of naar de concurrentie...

Dit is trouwens wat veel US bedrijven vaak flikken, laag in prijs beginnen en wanneer ze groot zijn en hun klanten behoorlijk gebonden, enorme prijsverhogingen doorvoeren. We hebben het gezien met Logmein, Teamviewer, Egnyte, VMware, etc.

[GeroldM]

Is Atlassian geen Australisch bedrijf?

[Batje4]

Ja, je hebt gelijk, het komt uit Australië.

[Reactie gewijzigd door Batje4 op 25 juli 2024 11:55]

[Cergorach]

Het heeft zowel een hoofdkantoor in Australie als in de VS.

[DragonChaser]

Ook in Polen, probeerde er te solliciteren maar ze nemen echt puur en alleen spartanen aan met 15+ jaar ervaring in een bepaald gebied. Vraag me af of het bedrijf Spartez is overgenomen door Atlassian en nu geen partner meer zijn maar onderdeel van. Want dat bedrijf had ook spartaanse requirements om te joinen. Heb wel een gesprek gehad!, dus maybe in the future.

[DragonChaser]

Neem hierbij het feit dat je wel SSO wilt hebben in je Jira cloud omgeving en ergens in 2019 vragen ze daar nu geld voor. Fijn je krijgt er een reeks security features bij maar je cloud omgeving is verdubbeld in prijs. Hoop dat het naderhand is veranderd qua pricing.

Met jira server/datacenter is je grootste probleem dat je elk jaar je licence moet vernieuwen ivm security patches en mandatory ISO127001 audits.

[JackBol]

on premises oplossing (die prima werkt)

Met het pakket zelf is niets mis, maar dit is weer een production tool die maintained moet worden. En als je minder dan 500 users hebt, heb je zeker niet een dedicated jira admin team, waardoor de kans op fouten alleen maar groter wordt omdat ze meerdere taken hebben.

Al die tools in je pipeline kosten tijd en geld om te maintainen en er is geen enkele zekerheid dat on-prem meer uptime, minder downtime of minder human error garandeert.

[bytemaster460]

Ik vraag me dan wel af welke oplossing over de langere termijn de meeste downtime heeft, lokaal of de cloud. Ik krijg nu al regelmatig meldingen dat het systeem tijdelijk niet beschikbaar is vanwege upgrades of updates. Een lokale storing hebben we ook twee keer gehad binnen een jaar.

[hrigteri]

Over het algemeen heb ik liever de Jira Cloud dan een on-prem oplossing waarbij ik afhankelijk ben van de IT afdeling van een klant en we voor elk kleine verzoekje een week moeten wachten tot die IT persoon eens wat gaat doen.

[mocean]

Als die verplichte cloud/saas diensten zijn ook echt een probleem als ze uitvallen. Lokaal kan je nog even de database in (of zo).

[Globber]

Leuk natuurlijk, maar de gemiddelde gebruiker van een Jira systeem gaat niet 'even de database in' natuurlijk

[Cergorach]

Nee, maar als je dit lokaal draait zal je toch echt wel gekwalificeerde beheerders nodig hebben die dat wel kunnen. Zelfs al heb je die, dan nog zullen die support moeten inschakelen, tenzij ze echt heel veel ervaring hebben met het specifieke pakket. En veel mensen vergeten dat dergelijke mensen beschikbaar hebben ook gewoon (veel) geld kost.

En het is niet alsof zo een fout niet kan gebeuren bij je eigen servers en kennelijk is het voor een berg specialisten alsnog een hele hoop werk om het te herstellen. Zo een berg specialisten heb je echt niet even beschikbaar als je het zelf draait...

[FreezeXJ]

Als je het lokaal draait kun je zelf kiezen wanneer je upgrades doorvoert. Niet tijdens kritieke periodes dus.
Daarnaast kun je zelf best het een en ander troubleshooten, ook als niet-beheerder (been there, done that, got the stack trace). Bij cloud-based software ben je volledig afhankelijk van andermans handjes om het te fiksen, en van de prioriteit die men eraan geeft. Die specialisten hebben vaak ook wel wat anders te doen.
Verder heb ik het idee dat de cloud-versie een stuk gecompliceerder is om te onderhouden dan je lokale servertje, wat voordelen (schaalbaarder, gewoonlijk betrouwbaarder want failover, minder beheer-overhead) heeft, maar ook nadelen.

Als ik dan lees "Deze klanten hebben al een week geen toegang meer tot de Jira-clouddiensten" dan lijkt me dit voor veel bedrijven toch wel een fikse afknapper. Zeg 100 man die door Jira minder productief zijn voor een week, da's niet gratis. Dat compenseer je niet met een maand gratis hosting.

[Erwin1967]

De failover lijkt dus bij Jira niet te werken. Een backup terugzetten gaat blijkbaar dus ook niet. Het is leuk zolang alles blijft werken maar je geeft alles, inclusief alle data, uit handen. Zodra je stopt met betalen dan heb je dus niets meer. Intussen kun je elk jaar een verhoging verwachten van de tarieven of een duurdere licentiestructuur zonder dat je er wat aan kunt doen. Kortom ze hebben je bij de ballen.

[MSalters]

"Gekwalificeerde medewerkers" - meervoud? Berg specialisten ?!

Ik beheerde Jira in m'n eentje. En dat kostte me misschien 2 dagen per jaar. Inmiddels zijn we noodgedwongen over naar de cloud, maar ik verwacht binnen 12 maanden naar Gitlab te migreren.

[equit1986]

daarom houden wij als bedrijf nog steeds zo veel mogelijk on-premise, voor t normale office meuk kan t prima in sharepoint/office365, maar alle productiebedrijven hebben allemaal on-premise applicaties draaien. Niets daarvan mag in de cloud. Wilt de leverancier ons naar de cloud hebben, stappen we over naar eentje die wel on-premise kan bieden.

[kamerplant]

Want on-premise levert nooit storingen op?

[batjes]

We hebben hier een hybrid omgeving. Het 1 en ander in de cloud. Intune, Exchange Online, O365 etc.. Allemaal super handig en beter dan het was.

Onze productie systemen draaien nog steeds allemaal on-prem, enkele uitzonderingen.

Ik kan je wel vertellen, als een on-prem systeem eruit klapt waardoor onze productie stil komt te liggen, dat er dan een handje vol IT-ers, ook midden in de nacht en in het weekend wakker worden of desnoods de auto in springen om het weer aan de praat te krijgen. Het is echt heel erg zelden dat er een systeem langer dan een paar uur uit ligt.

Bij dat cloud spul is het vrij regelmatig raak dat er een systeem een dag uit ligt of soms langer. Gelukkig zijn die cloud applicaties niet zo bedrijfskritisch.

Niet elke aanbieder heeft zelf de capaciteit in huis (of het vertrouwen) dat ze SLA's van 2 of 4 uur weten te halen. Daarnaast zijn zulke contracten vaak dusdanig duur, dat het goedkoper is daar een fulltime IT-er en de benodigde hardware voor in huis te halen.

Hybrid omgevingen zijn vaak toch beter dan puur on-prem of puur cloud.

[Zebby]

"Bij dat cloud spul is het vrij regelmatig raak dat er een systeem een dag uit ligt of soms langer. Gelukkig zijn die cloud applicaties niet zo bedrijfskritisch." dat ligt natuurlijk aan de SLA afspraken, er zijn talloze bedrijven met bedrijfskritische applicaties in de cloud, maar die hebben dan simpelweg duurdere contracten met automatische fallbacks zodat er die 99.99% uptime gegarandeerd kan worden. En dat halen de meeste ook prima, althans, wij wel.

[nst6ldr]

maar die hebben dan simpelweg duurdere contracten met automatische fallbacks zodat er die 99.99% uptime gegarandeerd kan worden. En dat halen de meeste ook prima, althans, wij wel.

Ook dat is slechts een papieren zekerheid, als er echt grote belangen in het spel zijn is het soms lucratiever om contractbreuk te doen dan de SLA afspraken naleven. Helemaal als je met buitenlandse bedrijven werkt, kijk naar Rusland.

[GeroldM]

Een SLA afspraak is niet meer dan dat. Een afspraak. Beide partiojen zullen ook best de bedoeling hebben om dit allemaal na te leven. Maar als er een grote storing is, en jij bent niet de grootste klant in het datacenter, dan ga je met je SLA in de hand toch echt lager in de queue. SLA of niet. Want jouw boete is goedkoper dan de boete van grotere klanten.

Of je het beseft of niet, een datacenter beheerder zorgt ervoor dat er zo min mogelijk personeel rond loopt. En het liefst zo laag mogelijk geschoold. Dus qua hardware hoef je niet op alteveel hulp te rekenen. Software-matig. Dat beheer gaat remote, dat is waar. Maar ook daar word zo min mogelijk personeel ingezet en opschalen naar afdoende hulp van buitenaf, dat is ook enigzins beperkt. Ja, er zal vast wel wat expertise op afroep beschikbaar zijn.

Of dat afdoende is voor het probleem dat op dat moment speelt, dat ligt nogal aan het probleem, maar opnieuw, ben jij niet de grootste klant, dan ben jij zeer zeker niet als eerste aan de beurt.

Dat kan allemaal wel afgevangen worden, maar daar hangt dan wel een prijskaartje aan. Een prijskaartje waar je ook iemand voor in kan huren en van een werkplek kan voorzien. Ook al heb je een beheerder die uitermate geschikt is voor de taak, als deze toegang nodig heeft voor reparatie van je hardware/software in het datacenter, dat is helemaal niet gratis.

Daarnaast moet je ook via een gedegen antecedenten-onderzoek vooraf aantonen aan het datacenter dat deze persoon uberhaupt een datacenter deurknop aan mag raken. Verzekerings-technisch, geheimhoudingsverklaringen er hangen zoveel consequenties aan het toegang verlenen, daar wordt niemand vrolijker van, jij (als bedrijf) niet, de beheerder niet en het datacenter niet. Daar zijn dus ook behoorlijke kosten.

Kortom, je bent dus gebonden aan de expertise die het datacenter bereid is in te huren of kan huren. En deze doen dat echt met zo min mogelijk mensen, want de kosten van het runnen van een datacenter zijn al zo hoog.

Ondertussen heb jij (als bedrijf) 'nee' moeten verkopen aan jouw klanten. En dat heeft consequenties. Misschien niet onmiddelijk, maar je reputatie loopt wel deuken op. Of jouw klanten gaan bij je concurrent hun neus opsteken. En als zij 'ja' kunnen verkopen...

Blind vertrouwen in tekst op papier, dat is een risiko wat door velen word onderschat. Aan elk nivo van risiko hangt voor je bedrijfsvoering een kostenplaatje. En een heleboel personen vergeten dat riskio bij het totale kostenplaatje van alles hosten in de cloud in te calculeren. Want SLA.

On-premise en hybride omgevingen zijn dan veruit te prefereren, ook al lijkt dat initieel veel duurder te zijn en/of ongemakkelijk.

[t_o_c]

Het punt is meer dat je onprem alles in eigen hand hebt dus mocht het een keer fout gaan kan dat een voordeel zijn.

[gimbal]

Maar ook een nadeel als het zonnetje weer ging schijnen en je halve personeelsbestand besloot dat het gras ergens anders een betere tint groen had - iets wat in Nederland vrij gewoon is. Als iets niet mission critical is dan ben ik er persoonlijk wel voor om het als een service af te nemen.

[blouweKip]

Misschien je personeel wat beter behandelen/betalen, dan is dat risico ineens een flink stuk kleiner

Wij zijn juist wat voorzichtiger geworden met het uitbesteden, vaak is uitbesteden flink duurder tegen verminderde functionaliteit en zie je dat basale functionaliteit ineens als "Enterprise" verkocht wordt, verdor lock in in de cloud is nog een pak erger dan on premise.

[Anoniem: 334725]

Je kan automatisch van de "cloud" spul ophalen als je on-premise storing heeft. Niet elk bedrijf heeft dat, maar mogelijkheden zat.

[equit1986]

sowieso zijn wij veel meer in control. en is het ook nog eens een stuk goedkoper. voor t geld dat je moet afdragen voor cloudoplossingen kan je zo 1 tot 2 FTE aannemen. verder ben je niet/minder gebonden aan de welwillendheid van cloudleveranciers. Want een SLA van 2 of 4 uur kost gewoon enorm veel geld en in mijn ervaring worden met grote leveranciers vaker niet dan wel de SLA's gehaald, of hebben ze precies t puntje kunnen pakken waar in het sla staat dat het t niet onder de 2 of 4 uurs sla valt.

[Cergorach]

Natuurlijk levert on-premises storingen op. Maar gebruik de right tool for the job en dit van iemand die primair bezig is met cloud systemen.

@equit1986 is voornamelijk bezig met winkelautomatisering, dat is een heel ander beestje dan kantoorautomatisering waar de meeste van ons primair mee bezig zijn. Je zit absoluut vast aan je locatie als winkel, geen mogelijkheid tot uitwijk. Daarmee heb je niet alleen te maken met storingen on-premises vs cloud, maar ook met internet storingen, stroom storingen, pin storingen, etc. Gezien de hoeveelheid winkelautomatisering is het onzinnig als je weegschaal of kassa niet kan werken als je geen internetverbinding hebt. Voor pinnen heb je vaak dan nog zo een mobiel pinapparaat wat je kan inzetten, maar je IT infra laten lopen over een mobiel abo is naast heel prijzig, ook bijzonder lastig.

Imho is het meest interessante voor dit type situatie een soort van hybride oplossing waarbij een gedeelte on-premises staat en een gedeelte in de cloud. Waarbij on-premises prima kan functioneren zonder een internet verbinding, alleen als je die wel hebt je het hele zootje veel makkelijker kan beheren/updaten. En cloud hoeft niet te zijn bij de leverancier (hoewel dit best wel beter kan zijn, ligt imho aan de leverancier), je kan ook prima zelf servers in de cloud draaien.

[equit1986]

wat je zegt klopt ten delen.
Wij hebben zakelijk glas in elke winkel met een 4G backup, redundante HA firewalls. Vanaf die firewall lopen S2S VPN's naar verschillende aanbieders(alarm, koeling, etc etc).
Zodra de vaste lijn failed, dan schakelt hij automatisch over naar 4G. Dit werkt in principe bijzonder goed, mede omdat ons 4G netwerk in NL prima is. Overal wordt er gebruik gemaakt van een externe antenne welke tegen de buitengevel gericht staat, om zo altijd het beste ontvangst te hebben.
Mocht onverhoopt beide verbindingen er uit liggen om wat voor reden dan ook, dan heeft elke winkel een de-centrale RDS server waar men lokaal alles in de winkel mee kan regelen.
Mobiele pin's liggen ook altijd klaar voor nood.
Er is voor een winkel, en zeker een supermarkt, niets belangrijker dan het kunnen verwerken van betalingen. Cash kan offline bij ons, maar PIN helaas nog niet.
Dit kan btw in Belgie wel !
Daar lopen ze voor qua elektronisch betaalverkeer, en kan je wanneer je pinterminal offline is, gewoon nog steeds pinnen. Zodra de terminal online komt, spuugt ie alsnog alle transacties er door.

Inmiddels kan dit ook in NL ingericht worden, maar daar zijn weer aparte contracten voor nodig(en dus meer geld). En gaat het daarom ook in NL niet op korte termijn een dingetje worden.

[Cergorach]

Zodra de vaste lijn failed, dan schakelt hij automatisch over naar 4G. Dit werkt in principe bijzonder goed, mede omdat ons 4G netwerk in NL prima is.

I stand corrected! ;-) De laatste keer dat ik hier mee heb gewerkt is alweer wat jaartjes geleden, het was toen gewoon erg ruk en je betaalde je scheel.

Ik herinner me van 20-25 jaar geleden dat je bij een (langdurige) pin storing met het handje machtigingen kon uitschrijven. Mag of kan dat niet meer?

[equit1986]

kan en mag niet meer :-)
we zijn nu bezig om te kijken of onze offline kassa's QR codes kunnen uitspuigen om zo middels iDeal/bankapp direct te kunnen afrekenen. Maar das nog heel pril hoor.

[RienBijl]

Het kan inderdaad niet bij de meeste gangbare aanbieders zoals CCV, maar ik had begrepen dat Adyen wel degelijk offline-pinnen ondersteund? Correct me if I'm wrong

[Reactie gewijzigd door RienBijl op 25 juli 2024 11:55]

[equit1986]

wij hebben Worldline, die ondersteund het wel, maar is gewoon duurder en dan zouden we alle transacties via Worldline moeten laten verlopen ipv Interpay.

[himlims_]

dat is met de nieuwe generatie beheerders hier een onpopulaire opinie ik zweer erbij; die afhankelijkheid van externe diensten zo veel mogelijk beperken. want ook die diensten leunen weer op een andere 3rd party. en dan valt ineens als een kaartenhuis in elkaar (zie recentelijk slack/cloudflair etc.)

[MazDaMan1970]

Klopt zo denk ik & mijn huidige werkgever er ook over. Zeker bij zeer bedrijfskritische applicaties, waarbij jezelf de baas wilt blijven over jouw data is een cloudoplossing geen goede keuze.
Bovendien zijn veel cloud-oplossingen prijstechnisch niet interessant, vanwege de hogere kosten.

[geenidee]

Kan ook langer dan 2 a 3 dagen duren volgens deze Reddit thread https://www.reddit.com/r/...estimate_on_our_support/:

"We were unable to confirm a more firm ETA until now due to the complexity of the rebuild process for your site. While we are beginning to bring some customers back online, we estimate the rebuilding effort to last for up to 2 more weeks."

[DDX]

Daar gaat echt iets niet goed met backup/restore procedure.
Alhoewel 0,14% van de klanten. Excuses sorry we hebben de 99% uptime niet gehaald je krijgt deel van je maandkosten terug en nogmaals sorry.

Als ik zoiets doe met een server die ik lokaal host....
Soms wel makkelijk als iets extern staat, ben jij er ook niet verantwoordelijk voor.
Maar je baas staat wel aan je bureau te roepen 2 weken kan echt niet, geef mij een nummer die ik kan bellen etc.
Ook wel leuk als al je documentatie in confluence staat en je daar een paar weken niet bij kan.

[Guus...]

Een baas die tegen het IT personeel staat te roepen is zelden een oplossing voor een technisch probleem. Wat nog beter werkt dan roepen tegen personeel is om de persoon die druk bezig is het probleem op te lossen uit de concentratie te halen door deze op te bellen.

On premise klinkt allemaal mooi maar in plaats van dat een bedrijf de servers runt met hun eigen software en met gespecialiseerd personeel die voor honderden bedrijven leveren laat je het doen door een kleiner team dat waarschijnlijk nog veel andere taken heeft.

Het is vergelijkbaar met elke afweging die bedrijven maken tussen zelf produceren of afnemen van derden. Waarschijnlijk koop je de laptops, bureaus en tekstverwerker gewoon bij een fabrikant, misschien maak je wel een onderdeel of aanpassing voor een machine zelf en als er iets helemaal niet op de markt bestaat maak je een volledig eigen oplossing. Daarin maak je allemaal afwegingen maar er zijn genoeg bedrijven waarbij het zelf hosten geen betere resultaten had opgeleverd.

[RGAT]

In dat geval had jij een jaar geleden al aan het bureau van je baas 2 weken lang moeten staan roepen dat je een budget nodig hebt om het destijds falende IT beleid te fixen
Hoewel, als bij een storing je baas aan je bureau staat te 'roepen' heeft zo'n organisatie wel wat meer nodig dan alleen een groter IT budget....

[DDX]

https://www.atlassian.com/trust/security/data-management
RTO – Recovery Time Objective – services restoration in the event of a disaster :
'<6 hours'

Atlassian realizes that whatever your business does it creates data, and without your data you don’t have a business. In line with our “Don’t #$%! The Customer” value, we care deeply about protecting your data from loss and have an extensive backup program.

- Quarterly tests of actual technical backup/recovery processes are also completed for critical/customer facing services

[Gé Brander]

Die tests zijn dan of niet/nooit succesvol uitgevoerd of ze hebben de data intussen niet meer. Het is ongelofelijk dat het restoren van de omgevingen tot wel drie weken kan duren...

Vierhonderd klanten, honderd specialisten die aan het werk zijn, geteste restore procedures...

It just doesn't add up anymore...

Ik denk dat er data weg is...

[DDX]

Maar als die data weg is, wat doen die honderden mensen.
Klinkt bijna als backup die uitgeprint is en nu overgetypt moet worden ofzo.

[Mattashii]

Hierdoor kunnen ongeveer 400 gebruikers onder meer niet bij hun Atlassian-omgeving komen

De storing heeft ongeveer 400 klanten getroffen, zegt Atlassian

Dat zijn wel heel andere dingen. Een klant is ongeveer een gefactureerde partij, maar een gebruiker is een account. En ik verwacht zo dat een klant meerdere gebruikers (accounts) heeft; dus die 400 gebruikers lijkt me sterk onderschat.

[Wierdo_NL]

Inderdaad... Als het er "maar" 400 mensen zijn valt het mee..
Maar wij werken dus gezellig met Atlassian en kunnen met +/- 150 man er dus nu niet in..
Dus documentatie op Confluence is ook onbereikbaar... Super fijn...

Met de snelheid waarop de restore nu gaat, zou het goed nog een dag of 2 a 3 kunnen duren.

[nightraven79]

bij mijn klant: geen problemen (kleine 200 gebruikers)..
Ben benieuwd waaraan het probleem ligt

[Kees]

Ik gok dat gebruikers en klanten door elkaar word gebruikt. Wij zijn ook klant bij Atlassian, dus wij zijn 1 klant voor Atlassian, maar ons account heeft wel een paar duizend gebruikers.

[bartje]

voor zo'n partij duurt die storing wel heel lang.
Ik begrijp overigens niet waarom de wereld zo lyrisch is over atlassian, mijn persoonlijke ervaring is dat alles net niet werkt.

[Sandor_Clegane]

Dat is niet alleen jouw persoonlijke mening op het moment.....

[Quilt]

Je moet het ook zien in functie van de alternatieven.

Voor mensen die van Mercury / HP / Micro Focus komen is Jira vaak een stap vooruit.

[dehardstyler]

mijn persoonlijke ervaring is dat alles net niet werkt.

Nou inderdaad. Maar niet getreurd! Er is een betaalde plugin die het "oplost".

[johnbetonschaar]

Ik zou er geen doekjes om winden, het is gewoon rommel. Zo traag als dikke stront door een trechter, super ongebruiksvriendelijk, zwaar overgecompliceerd omdat het probeert elke random use case en workflow mogelijk te maken, en daar komt nu dit ook nog eens bij. Ik heb er echt niks positiefs over te zeggen. Als je me echt zou dwingen om iets positiefs te zeggen dan zou het iets worden als 'er zitten veel functies in en alles is een soort van geintegreerd'. De vraag is of dat je dat nodig hebt en of je niet 99% van de functionaliteit en 80% van de integratie kunt bereiken met andere tools die niet zo gaar in elkaar zitten. Vooral Confluence zou kunnen doorgaan voor 'slechtste Wiki systeem ooit', zelfs Sharepoint is beter (en dat wil wel wat zeggen).

/einde Atlassian rant (voor mij is het een vrijwel dagelijkse irritatie)

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 11:55]

[Spoider]

Ik vind het opzich wel mooie software in sommige opzichten (bijvoorbeeld de integratie van Jira met de wiki of Bamboo), maar het is ongelovelijk traag. Of het mist hele random features die mij heel erg essentieel lijken, bijvoorbeeld dat ik niet meerdere issues tegelijk kan 'slepen' naar een andere kolom in Jira, maar dit via hun onoverzichtelijke Bulk-editor moet doen.

[Sebazzz]

De website zou zijn hersteld en er zou geen data verloren zijn gegaan.

Technisch gezien niet, maar afhankelijk van wat er is gebeurd is men wel data recovery aan het doen. Dan is er inderdaad geen data verloren gegaan.

This incident was not the result of a cyberattack and there has been no
unauthorized access to your data. As part of scheduled maintenance on selected
cloud products, our team ran a script to delete legacy data. This data was from
a deprecated service that had been moved into the core datastore of our
products. Instead of deleting the legacy data, the script erroneously deleted
sites, and all associated products for that site including connected products,
users, and third-party applications.

[Reactie gewijzigd door Sebazzz op 25 juli 2024 11:55]

[Sandor_Clegane]

Misschien even ticket inschieten, oh wacht.

[Zakaria89]

Wij hebben hier dus last van. Gelukkig kunnen we nog wel bij bitbucket. Jira en Confluence al meer dan een week onbereikbaar.

[Erwin1985]

Als Confluence en Jira gebruiker ben ik niet tevreden met het nieuwe licensing model. Ik hoop dat in de toekomst weer de stap naar een server model gemaakt kan worden, zonder dat ik 100.000 euro kwijt ben.

[sleiN13]

Wij zijn volledig van Atlassian overgestapt omdat het server model er uit ging. Jira -> Youtrack, Confluence -> Bookstack, Bitbucket -> Gitea, Bamboo -> TeamCity

[onok]

Gekke storing dan, die 0.18% vd klanten treft. Ben blij dat wij er niet tussen zitten

[gimbal]

De software bestaat al heel lang en heeft meerdere transformaties doorgaan, het is niet ondenkbaar dat er een lijmlaag geraakt is waar alleen specifieke (oude?) klanten mee te maken hebben.

[GoGoHaRrY]

Helaas niet alleen "oude" klanten ..... ik ken een bedrijf dat nog geen twee jaar gebruik maakt van de Jira Cloud diensten waar het er ook uit ligt.

In een van de support mailtjes van Atlassian was te lezen.

there may be some limitations when we make it available to you such as 3rd party app functionality.

En nu hopen dat het percentage lijkt te kloppen zaterdag 23%, zondag 31% en vandaag is het 35% .......

Maar met 400 klanten die stuk zijn had het met een legertje zoals ze zelf schrijven in mijn ogen wel sneller moeten gaan dan dat het nu gaat.

This incident is our #1 priority. We have mobilized hundreds of engineers who are working around the clock to recover the remaining sites.

Ow een een support ticket ooen als klant die getroffen is is er niet bij want tickets zijn aan producten gekoppeld en de produkten zijn weg, eigen site is down.