IT-storing legde treinverkeer in en rond Amsterdam plat - update

De verkeersleidingpost van ProRail heeft sinds afgelopen nacht een 'IT-storing' waardoor er geen treinverkeer mogelijk is van en naar Amsterdam en Schiphol. De NS raadt reizigers aan om alternatief vervoer te regelen; een prognose voor wanneer de storing opgelost is, is er niet.

Volgens de NS moesten reizigers afgelopen nacht overnachten op stations, omdat het OV-bedrijf ze niet thuis kon brengen. Afgezien van de term 'IT-storing' geeft de NS geen verdere informatie. ProRail stelt dat 'de systemen zijn gereset en de dienstregeling weer is opgestart', maar dat 'de storing is teruggekeerd'. De eerste post in de liveblog van ProRail is van zondagavond 18.05 uur.

De storingspagina van de NS meldt verder dat tussen Utrecht Centraal en Driebergen-Zeist en tussen Leiden Centraal en Den Haag Centraal respectievelijk minder Sprinters en minder Intercity's rijden. Die twee kwesties krijgen op de statuspagina dezelfde bestempeling als de kwestie in Amsterdam: een 'systeemstoring'.

Update, 09.06 uur: via NU.nl meldt de NS dat de storing is verholpen. Sinds 9 uur moeten de treinen weer rijden, hoewel nog rekening gehouden moet worden met verstoringen. De IT-storing in Amsterdam is nog gaande, maar door deze operaties over te hevelen naar Utrecht, kunnen de treinen wel weer rijden.

Update, 12.44 uur: SpoorPro schrijft dat ProRail door een back-up terug te zetten het systeem weer werkend wist te krijgen. "Normaal gesproken moet dat goed gaan, maar we adviseren reizigers wel om goed te bekijken of ze vandaag écht van of naar Amsterdam moeten reizen. We houden nog even een slag om de arm," meldt een ProRail-woordvoerder aan het medium.

Reacties (371)

[REDSD]

Een trend die ik zie als iemand die in de IT werkt is dat het erg lastig is kennis te houden, en dat de techniek steeds complexer wordt.

Het is financieel gezien totaal niet interessant om bij een bedrijf te blijven voor lange tijd, dat merk ik ook bij mijn bedrijf, wisselen van werkgever loont meer dan blijven bij je huidige, gevolg is een hoog verloop en nog erger veel kennis verlies.

Daarnaast worden IT oplossingen steeds complexer, een trend waar ik mezelf al een tijdje aan erger, steeds uitgebreidere frameworks worden gebruikt (en dus meer afhankelijkheden), steeds complexere systemen zoals AWS, Azure die meer microservices hebben (valt iets om in de keten, is de keten stuk).

Vroeger was ook niet ideaal toen we monolieten van systemen hadden, maar toen bleef kennis in huis en had je alleen kennis nodig van je monoliet. Nu moet je hopen dat je nog kennis in huis hebt van een service die ooit gebouwd is en misschien wel een belangrijkstukje van je infrastructuur is.

[Reactie gewijzigd door REDSD op 22 juli 2024 16:47]

[Yordi-]

De trend die gaande is, gevoed door tekorten en die je niet alleen in de IT ziet, is de enorme groei van (goed betaalde) detachering en/of ZZP. Mensen met weinig verbinding met het bedrijf. Ik snap eerlijk gezegd ook steeds minder goed waarom je met kennis en ervaring überhaupt nog vast in dienst zou gaan. Een uurtarief van 100 euro voor iemand met enige ervaring is helemaal zo gek niet meer en met 1800 uren per jaar is dat toch 180.000 euro per jaar. Al zou je alleen al de helft via een detacheringsclub verdienen (als je ZZP te onzeker vindt) is dat nog steeds vaak veel meer dan je bij veel bedrijven in vaste dienst zou verdienen. Bij organisaties als ProRail, overheden, etc is dit al vaste kost. In plaats van eigen personeel goed betalen voor bakken met geld externen inhuren.

[911GT2]

1800 uur per jaar werken lijkt me al behoorlijk veel, zeker facturabel. Maar voor je voorbeeld wil ik wel de 1800 aanhouden.

Als ik die gegevens invoer op berekenen.nl heb je een netto jaarinkomen van 108.000 euro. Dan heb je nog niets betaald als reiskosten, hardware, verzekeringen, ziektekosten, boekhouder etc etc.

Dus als je een normale auto least van 1000 euro per maand is dat nog maar 96 per jaar.

Dus dan heb je 10K meer per jaar dan ik in dienst van een baas, zonder risico met (duurdere) leaseauto. En moet jij alle overige kosten nog betalen, en dus 1800 uur facturabel zijn.

Ik wens je veel succes met die propositie!

[joker1977]

Ik weet niet precies hoe jij rekent en hoeveel jij verdient, maar als je uitgaat van die 1800 uur / jaar (wat idd. extreem veel is facturabel!) dan heb je idd. een bruto-inkomen van EUR 180.000. Dat is een extreem hoog bruto-inkomen (4,5X modaal). Ik ga er gemakshalve vanuit dat dat (veel) meer is dan 10K / jaar wat jij verdient, gemakshalve ga ik er vanuit dat er niet veel Tweakers boven de Balkende-norm zitten, toch ?

Dus ik denk dat je daar wat zaken door elkaar haalt in je bruto/netto-berekeningen.

Verder, zaken als "normale auto least van 1000 euro / maand": Sorry, maar dat zijn geen normale bedragen voor een auto, lijkt me toch? Je komt ook een heel eind voor de helft van de prijs / maand.

[GrooV]

Vergis je niet, auto's zijn de afgelopen jaren echt duur geworden. Ook helpt het niet mee dat de rente is gestegen (LM's lenen ook gewoon geld voor auto's) wat het weer duurder maakt.

Voor 500 euro per maand zit je in de categorie Skoda Fabia (directlease 25k km/60mnd). Niks mis mee uiteraard maar gemiddeld lease budget gaat toch wel richting 800 euro in de maand.

Verder is 1800 uur per jaar echt wel te doen, gemiddeld zijn er 228 werkdagen per jaar als je feestdagen en vakantie dagen (25) er af haalt. 228 * 8 is 1825 uur.

[zaphod_b]

Alleen is het bedrijfseconomisch niet zo slim om zo te rekenen: je rekent jezelf (te) rijk. In de praktijk ben je nooit 100% billable. Veiligheidshalve reken ik zelf altijd met 1400 uur, dan kan het altijd nog meevallen.

Wat mensen hierboven ook nog vergeten is dat 180k *omzet* niet hetzelfde is als *inkomen*. De leaseauto is al even genoemd, maar er is nog veel meer:

- telefoon
- laptop
- (lease)auto
- pensioenvoorziening (niet goedkoop!)
- het werkgeversdeel van je zorgpremie, ook zo'n 3k, wordt geïnd door de belastingdienst.
- arbeidongeschiktheidsverzekering (achterlijk duur)
- bedrijfsaansprakelijkheidsverzekering
- boekhouder
- thuiskantoor: inrichting etc (indien van toepassing)
- IT-diensten zoals fatsoenlijke offsite backups (als ondernemer moet je alles min 7 jr bewaren, dus zorg voor goede backups)
- representatiekosten zoals een website. Visitekaartjes zijn een beetje voorbij geloof ik, dus die vallen af.
- diverse kosten

Al met al moet je toch wel rekenen op een fors deel aan kosten. Die zijn aftrekbaar voor de belasting in de meeste gevallen.

En vergeet vervolgens de belastingdienst niet. Met zo'n inkomen betaal je fors en val je voor een heel flink deel in de 52%. Houd rekening met een gemiddelde belastingdruk van 40-45%.

Veel mensen denken dat je van zo'n uurtarief van 100 euro per uur lachend binnenloopt. Je kunt er prima van leven en het is een mooi inkomen, maar reken jezelf dus niet te rijk...

Tot slot de allerbelangrijkste: een spaarpot aanleggen voor economisch mindere tijden. Nu op dit moment is er achterlijk veel werk en als je een goeie IT'er bent in een segment dat veel gevraagd wordt, top. Maar dat kan zomaar ineens anders worden. In de jaren 2009-2013 a 14 was het echt geen pretje hoor. Als je goed was was er nog wel werk, maar er zijn er ook heel veel zonder komen te zitten. Bovendien daalden de tarieven of zijn ze uiteindelijk 10 jaar lang niet verhoogd, terwijl de inflatie wel gewoon door gaat.

[hackerhater]

Inderdaad. Grofweg rekenen dat je de helft netto overhoud van de omzet komt in de buurt.
Evengoed nog altijd een leuk bedrag.

[zaphod_b]

Ik zou zeggen dat je netto 30-40% overhoudt. Ik reken op ongeveer 30% kosten, en daarna 45% belastingdruk. Dan houd je 38,5% over, netto.

[NoTechSupport]

Veel hangt af van je keuzes als zelfstandige:
- wat rekent een eventuele tussenpartij aan
- neem je een arbeidongeschiktheidsverzekering of spaar je hiervoor zelf,
- hoe duur is je wagen en hoe duur zou die zijn als je in dienst was,
- hoeveel diverse kosten die je ook als werknemer hebt kan je in de boekhouding van de zaak duwen
- ...

Zelfstandigen rekenen zich wel eens arm/rijk als ze vergeleken worden met werknemers, afhankelijk of ze aan het klagen of opscheppen zijn. Veel hangt er ook vanaf wat je als werknemer verdient. Als je appelen met appelen vergelijkt zal je meestal meer dan €1000 per maand beter af zijn als zelfstandige.

[Left]

@zaphod_b 30% kosten? Dus bij rekenvoorbeeld van 180K zou dat 54K per jaar zijn?
Ik zie niet hoe je aan dat bedrag moet komen. Al helemaal niet aangezien je de meeste kosten kan aftrekken van de belasting.
Dus 54K netto kosten = ca. 100K kosten voor belastingaftrek ..

[Reactie gewijzigd door Left op 22 juli 2024 16:47]

[hackerhater]

30% kosten als IT'er? Dat is heel veel, zelfs met een lease-auto.
15 a 20% is realistischer Buiten de IB zijn je grootste kosten de auto en de AOV.
De rest is tientjes-werk en valt nauwelijks op, op de rekening.

En vergeet niet de MKB-aftrek (-15% belastbaar inkomen), pensioen + AOV als aftrekposten en de zelfstandige aftrek.

[Reactie gewijzigd door hackerhater op 22 juli 2024 16:47]

[zaphod_b]

Het was inderdaad hoog ingeschat, maar ik heb liever dat mensen voorzichtig zijn ipv dat ze zichzelf rijk rekenen. Je kunt beter conservatief begroten en dat het meevalt dan andersom.

[hackerhater]

40% van je omzet aanhouden voor de IB is al heel conservatief inschatten
Dat is in het algemeen al veel te hoog.
Uiteraard moet je die 50% wat je over houd niet over de balk gooien, hou de rest wat je niet nodig hebt in je buffers voor slechte tijden.
Ik ging pas meer geld uit geven toen mijn buffer de ton passeerde.

Die 40% reservering voor de IB gecombineerd met de andere kosten kom je op grofweg 50% voor IT'ers. Uiteraard is het meer als je een auto van 1000+ euro least. Maar laat die kosten 1500 pm zijn. 500 euro meer op een rekening van 13K/maand.......

Uiteraard gaat dit verhaal niet op voor ZZP'ers zoals loodgieters die veel meer bedrijfskosten hebben.
Die houden een stuk minder netto over, daaraantegen moeten ze ook minder IB betalen omdat hun winst lager is.
IT'ers, advocaten, etc zijn de rare uitschieters omdat we weinig vaste kosten hebben voor het beroep.

[Reactie gewijzigd door hackerhater op 22 juli 2024 16:47]

[Hellboy!]

Je vergeet nog een paar zaken:

- opleidingskosten en de bijbehorende uren dat je niet declarabel bent.
- kosten per uur voor de tussenpartijen die raamovereenkomsten hebben bij de bedrijven

[GrooV]

- telefoon
Koop je 1x in de 5 jaar, mag je afschrijven naar 0 en krijg je bij het drempelbedrag investeringsaftrek op. Niet iedereen heeft een iphone 14 pro max nodig
- laptop
Dit is even een investering maar ook weer afhankelijk van je beroep. Misschien voldoet je prive laptop gewoon als het alleen voor de administratie is
- (lease)auto
Kan je zo gek maken als je wil, geldt het zelfde voor in loondienst
- pensioenvoorziening (niet goedkoop!)
Ook dit valt mee, en je kan dit opgeven bij de belasting in box 3. Voordeel is dat je volledig in controle bent. Pensioen betaal je vaak net zo goed in loondienst
- het werkgeversdeel van je zorgpremie, ook zo'n 3k, wordt geïnd door de belastingdienst.
Betaal je ook in loondienst, Zvw bedoel je
- arbeidongeschiktheidsverzekering (achterlijk duur)
Ook dit valt mee als je nog jong bent en in de IT zit, als je een medisch verleden hebt kan je misschien beter in loondienst gaan inderdaad. Verder hoeft de verzekering niet vanaf dag 1 uit te betalen als je een buffer of broodfonds er naast hebt. Dit scheelt heel veel in de kosten. Heel erg afhankelijk van je beroep
- bedrijfsaansprakelijkheidsverzekering
Ook hier afhankelijk van je beroep en sector
- boekhouder
Heb je in principe niet eens nodig, geldt ook voor loondienst waar mensen dit uitbesteden, hoeft niet heel veel duurder te zijn. BTW aangifte is zeer eenvoudig en kan iedereen zelf
- thuiskantoor: inrichting etc (indien van toepassing)
Dit zijn gewoon zakelijke kosten met investeringsaftrek
- IT-diensten zoals fatsoenlijke offsite backups (als ondernemer moet je alles min 7 jr bewaren, dus zorg voor goede backups)
Backups moet je altijd in orde hebben, afhankelijk van je beroep kan dit vrij goedkoop of duur (video editor bijv.)
- representatiekosten zoals een website. Visitekaartjes zijn een beetje voorbij geloof ik, dus die vallen af.
De meeste ZZP'er hebben niet eens een website en mochten ze er een hebben dan hoeft dit echt niet veel te kosten. Er zijn zat template / logo generatoren waar je voor een paar tientjes een leuke website hebt. Hosting hoeft ook niet veel te kosten
- diverse kosten
?

Zeg niet dat het niks kost maar je kan het zo gek maken als je wilt waarbij in mijn ogen alleen een AOV echt een deal breaker kan zijn omdat je hier wel echt afhankelijk bent van een commerciële verzekeraar

[Reactie gewijzigd door GrooV op 22 juli 2024 16:47]

[zaphod_b]

Zo kun je jezelf inderdaad rijk rekenen. Ik heb vooral aan willen geven waar je allemaal over na moet denken, ik heb niet gezegd dat al die kosten hoog zijn of even relevant. Ik wilde vooral ook mensen er bewust van maken dat het niet zo simpel is als alleen een leaseauto en knallen maar.

Ik zie ook in andere reacties mensen bruto en netto door elkaar gooien.... Ik zie jou ook een paar keer reageren op mijn post met, in mijn woorden: lekker boeien die kosten, zijn toch aftrekbaar als kosten. Eh, dat is dus precies wat ik zei . Ze zijn aftrekbaar als kosten voor belasting. Dat betekent echter niet dat dat je inkomen niet drukt.

Overigens, zvw betaal je inderdaad ook in loondienst, maar je werkgever betaalt je werkgeversdeel. Dat is een fors bedrag. Als ZZP'er betaal je zelf dat werkgeversdeel. Dat is dus echt een extra bedrag tov loondienst!
Idem met pensioen, al is dit erg afhankelijk van je CAO / bedrijf. Echter, in veel gevallen betaalt ook hier de werkgever een deel, en jij zelf een (bruto) deel via je loonstrook. Als ZZP'er moet je dit in z'n geheel zelf ophoesten en heb je ook niet het voordeel van een collectieve voorziening. In de praktijk ben je echt duurder uit voor hetzelfde pensioen.

Het ging mij er niet om dat er geen verschillen of nuances zijn, ik wilde vooral duidelijk maken dat je jezelf niet rijk moet rekenen. Teveel mensen beginnen met een veel te rooskleurig aan het ZZP'er bestaan en dan valt het in de praktijk toch wel even tegen. En anderzijds heb ik ook te vaak dit moeten uitleggen aan collega's in loondienst die denken dat je je uurtarief zo ongeveer netto in je zak kan steken. Dat levert scheve gezichten op.

ZZP'er zijn heeft veel voordelen: vrijheid om je eigen opdrachten te kiezen en een hoger inkomen. Maar er zitten ook echt nadelen aan zoals onzekerheid in economisch slechtere tijden. En zoals genoemd, ik hoop vooral dat mensen er realistisch naar kijken.

[GrooV]

Ik bedoel alleen te zeggen dat kosten van een laptop of telefoon in het niets vallen met bijv. een goede loodgieter die een compleet gevulde bus moet aanschaffen incl certificeringen en dergelijke.

4000 euro voor een hele dikke laptop of een bus met duur gereedschap wat je afschrijft als een malle en ook daadwerkelijk slijt scheelt enorm. Dus ja, een laptop zijn maar wat kosten die ook nog eens aftrekbaar zijn. Als een laptop je tegenhoudt om te zzp’en dan moet je het niet doen

[911GT2]

Verder, zaken als "normale auto least van 1000 euro / maand": Sorry, maar dat zijn geen normale bedragen voor een auto, lijkt me toch? Je komt ook een heel eind voor de helft van de prijs / maand.

Een kale ID.4 wat me gewoon een prima middenklasser lijkt heeft een leaseprijs (kaal) van 945 euro per maand bij 48 maanden en 35.000km

Dus zo heel raar vind ik 1000 euro per maand niet hoor.
Om je een idee te geven bij ons zit er ook nog een klasse boven.

[joker1977]

Als je voor jezelf begint, lease je een auto natuurlijk niet tegen dezelfde voorwaardes als wat jij als bijtelling (ga ik vanuit) berekent met een all-in prijs.

Verder iedereen mag bepalen wat hij/zij met zijn geld doet, ik hang er ook geen waarde-oordeel aan, maar ik vind de vergelijking een beetje raar verder. Je gooit netto/bruto doormekaar en vervolgens lijk je een bijtelling/mobiliteits-constructie bij je bedrijf als de norm te zien voor wat een auto (je) kost per maand. Dat lijkt me niet helemaal reëel.

[The Jester]

Als je ZZP'er bent, dan lease je niet: je koopt een youngtimer.

Ik ben zelf ZZP'er en rijdt zakelijk een BMW 540i uit 2007.
Die staat voor €10.000,- op de balans en daar betaal ik 35% bijtelling over (bijtelling bij een youngtimer gaat over de dagwaarde).

Die BMW kost mij aan bijtelling €3.500,- dus dat is netto nog geen €150,- in de maand.
Verder is álles aan die auto zakelijk: de benzine, de wegenbelasting, de verzekering, het ANWB-lidmaatschap en zelf de parkeerbonnetjes en de wasstraat.

Je moet IHMO knettergek zijn om een ID.4 dinky toy te leasen á raison van €965,- in de maand als het ook anders kan. Doe mij maar lekker een V8 op fossiel. Als ZZP'er is dat bijzonder goed te betalen.

[911GT2]

Doe mij maar lekker een V8 op fossiel.

Tja andere organisaties zijn wel bezig met hun MVO beleid.

Dat jij graag in een oude aftandse BMW komt voorrijden bij klanten is een keuze.

Daarnaast zijn de onderhoudskosten van je BMW een veelvoud van die van een ID.4 anders weren ze veel duurder geweest in de lease. Dus fijn dat het voor jou werkt, ik zou alleen op basis van wat je rijdt al een andere ZZP-er huren.

[Reactie gewijzigd door 911GT2 op 22 juli 2024 16:47]

[The Jester]

LOL

Afgeven op fossiel en als username 911GT2 hebben.
Veel hypocrieter wordt het niet

[911GT2]

Voor daily hoef ik geen fossiel te hebben. Voor andere gelegenheden heb ik zelfs twee sportauto's. Jeetje wat hypocriet zeg dat ik probeer mijn CO2 footprint te reduceren door saaie snelweg km's elektrisch te doen. Elektrische auto opgeladen door zonnepanelen, maar dan mag je meteen geen liefhebber meer zijn van (ICE) auto's.

Daar past pas echt een bij.

[supersnathan94]

Dat is een optie inderdaad. Maar wat jij betaald aan brandstof kan ik weer bijtellen in het budget. Is toch weer €250+ in de maand erbij.

Daarnaast is onderhoud aan zo’n wagen echt wel veel geld en dat is toch weer iedere keer een aantal uur die je dan voor niks werkt.

[911GT2]

Ik stel voor dat je een opzoekt wat een leaseauto per maand kost, netto, voor 1000 euro heb je echt niet iets bijzonders hoor. Dus ik denk dat je zelf een verkeerd beeld hebt van wat een leaseauto kost.

[Aalard99]

Inderdaad, ook als je een auto koopt en je echt alle kosten op een rijtje zet ben je een hoop geld kwijt. Maak maar eens een berekening op de ANWB autokosten site.

Mensen vergissen zich vaak wat een auto echt kost, dus afschrijving, onderhoud, verzekering, brandstof, belasting, etc. Vaak hoor je, de auto is toch al betaald maar dat is ook geld wat is uitgegeven en je zal een potje moeten maken voor het vervangen van de auto.

Zeker als je veel gaat rijden, tot 10.000km is het nog te doen maar ga je 30.000km rijden wordt het al een heel ander verhaal.

[supersnathan94]

Verder iedereen mag bepalen wat hij/zij met zijn geld doet, ik hang er ook geen waarde-oordeel aan, maar ik vind de vergelijking een beetje raar verder. Je gooit netto/bruto doormekaar en vervolgens lijk je een bijtelling/mobiliteits-constructie bij je bedrijf als de norm te zien voor wat een auto (je) kost per maand. Dat lijkt me niet helemaal reëel.

Valt vies tegen hoor. Een normale middenklasse auto rekent men gemiddeld €0,49/km. Met 35K kilometers is dat aan kosten ongeveer €17.500 per jaar. Een kleine €1500 per maand all in. En daar komt dan dus ook nog inkomsten belasting bij.

€1000 die je als privaat persoon uitgeeft is bruto veel meer. Dat is namelijk €1585 bruto. Zakelijk gezien kun je dus 58% meer geld uitgeven alleen al door het verschil voor inkomstenbelasting en dan komt daar BTW voordeel nog een keer bovenop als je voldoende omzet hebt.

[Urk]

Ik begrijp nooit zo goed waarom bedrijven operational lease gebruiken. Zeker niet als je meerdere auto's least als bedrijf. Je betaald een fortuin om alleen de auto te "lenen" en spekt daarmee flink de lease maatschappij. Na looptijd mag je hem gewoon weer lekker inleveren. Waarom geen financial lease? Ben je aan 't eind van de financiering vaak ook nog (grotendeels) eigenaar. Ik zie het bij mijn klanten ook veranderen dat ze auto's gaan kopen en aan het einde van de looptijd veel voordeliger uit zijn.

[indigo79]

Omdat financial lease als schulden op je balans staat en operational lease gewoon in de kosten zit.

[supersnathan94]

Naast dat financial lease een lening is (en dus een schuld waar je niet zomaar vanaf komt) omvat operational lease alle kosten in een vast bedrag. Veel makkelijker om rekening mee te houden als je meerdere wagens beheert.

Als jij een vloot van 30 wagens hebt die allemaal aan de beurt zijn voor een grote beurt dan is dat een enorme kostenpost die je cashflow in gevaar kan brengen.

[Urk]

Ja snap ik. Maar met een operational lease contract zit je daar ook vaak bijv 3 jaar aan vast. Afkopen is duur en vaak een groot deel van de totale termijn...

Een grote beurt valt vast niet allemaal gelijk. De reden die je geeft is met Financial lease toch vergelijkbaar. Dat zijn ook maandelijkse kosten. Alleen betaal je onderhoud en banden zelf... Benzine etc betaal je toch zelf..

[supersnathan94]

Dat ligt er heel erg aan. Ik zie bij best veel bedrijven die hard groeien met eigen wagens vaak een hoop opeenvolgende kentekens. Die zijn dus veelal op dezelfde dag de sjaak mbt APK bijvoorbeeld. Dat valt pas na een paar jaar, maar afhankelijk van hoelang je ze in de vloot houd tikt het wel aan in bepaalde maanden.

Maar met een operational lease contract zit je daar ook vaak bijv 3 jaar aan vast. Afkopen is duur en vaak een groot deel van de totale termijn...

Maar het is wel een kostenpost en geen lening. Dat is wel een groot verschil.

Brandstof betaal je uiteindelijk natuurlijk zelf, maar in operational lease wordt dat vaak verrekend met een voorschot.

Overigens denk ik dat het voor elektrische wagens echt veel slimmer is om financial lease te doen dan full operational. De overige kosten zijn praktisch nul.

[SimonMc]

Wat is "de Balkende-norm"?

[Andros]

Je profiel geeft aan dat je in Sint-Niklaas woont en ik kan me voorstellen dat deze term in België minder bekend is. In de jaren 2000 was ene Jan-Peter Balkenende minister-president van Nederland, de voorloper van Mark Rutte. Deze man heeft vier kabinetten met veel politieke chaos geleid maar een van zijn verwezenlijkheden betreft de zogenaamde Balkenende-norm, zijn jaarsalaris als plafond voor iedereen die in de publieke sector werkt. Destijds betrof dat 180.000 euro per jaar oid, het is goed mogelijk dat het intussen meer is maar de term wordt nogal eens gebruikt als er iemand in de politiek of een publieke functie werkzaam is met een hoger salaris dan de minister-president van het land .

https://nl.wikipedia.org/wiki/Balkenendenorm

[Reactie gewijzigd door Andros op 22 juli 2024 16:47]

[SimonMc]

Oh ok, Balkenende-norm dus en niet Balkende-norm.

[TheVivaldi]

Reiskosten, auto, etc., eens. Maar hardware? We hebben het hier niet over servers van 10.000 euro, dus die hardwarekosten zijn eenmalig en misschien eens in de 5 jaar opnieuw. Boekhouden hangt er vanaf of je dat zelf doet.

Maar dan nog zou 96K een lekker bedrag zijn. Ik verdien nu krap aan 20K per jaar (wel een hele andere branche, maar toch), dus 96K klinkt voor mij alsof ik eindelijk rijk word.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 16:47]

[911GT2]

Maar hardware? We hebben het hier niet over servers van 10.000 euro, dus die hardwarekosten zijn eenmalig en misschien eens in de 5 jaar opnieuw. Boekhouden hangt er vanaf of je dat zelf doet.

Stel je bent een ZZP-er en je koopt een Mac-book pro.
Dan begin je bij 2500 euro, iPhone er bij, 1000 euro. Minus wat BTW die je terugkrijt. Als je ze beiden afschrijft in 5 jaar (wat lang is voor de telefoon, maar goed).

3500 euro in 5 jaar is 700 euro per jaar of wel 60 euro per maand. Dan heb je alleen een laptop en een telefoon. Ik vind dat een kostenpost die je niet kan verwaarlozen.

En dan heb je nog niets thuis voor je WiFi, backup en beveiliging.

[Reactie gewijzigd door 911GT2 op 22 juli 2024 16:47]

[supersnathan94]

Een kostenpost die je kunt afstrepen tegen je winst (dus btw vrij) en bruto kunt aanschaffen.

Als ZZP-er ben je voor de belastingdienst gewoon een bedrijf. Iedere euro die binnenkomt is een zakelijke euro en dus onderhevig aan inkomstenbelasting als je hem naar jezelf uitkeert om iets van te kopen.

Dus leuk dat die laptop en telefoon €3500 euro kosten ex btw, maar de grote winst zit hem in het feit dat je geen inkomstenbelasting hoeft te betalen.


Als jij privé zo’n combi koopt van 3500 ex dan komt daar BTW bij (€4235) en heb je al inkomstenbelasting betaald. Hiermee komt het totaal (met de huidige 36.93%) op €6715 uit.

Leuk dus die kostenpost van €60, maar privé was dat dus het dubbele geweest.

[Game_overrr]

Wat je hier vergeet is dat je die afschrijvingslasten als kosten mag opnemen, wat dus de belasting op je winst verlaagd. Je betaald als ZZPer dus minder als je zakelijk spullen aankoopt.

[ApexAlpha]

Als jij echt 86.000 netto per jaar pakt dan heb je ook wel een hele goede baan.

[supersnathan94]

Als ik die gegevens invoer op berekenen.nl heb je een netto jaarinkomen van 108.000 euro. Dan heb je nog niets betaald als reiskosten, hardware, verzekeringen, ziektekosten, boekhouder etc etc.

Maar zo mag je niet rekenen. Reiskosten, verzekeringen, hardware en boekhouder zijn allemaal kosten die je bruto betaald niet netto. Dat trek je dus af van bruto omzet en daarna pas belasting. Scheelt enkele tientallen procenten.

[GrooV]

Volgens mij haal je het eea door elkaar, als je in loondienst 108.000 per jaar netto wil verdienen zit je op 208.000 bruto.

[Guyon]

Als je 150k bruto verdient bij een werkgever kan je waarschijnlijk ook veel meer dan die 100eu/uur vragen uit het voorbeeld (mits je meerwaarde voor het bedrijf natuurlijk grotendeels op relevante, aantoonbare skills en ervaring gebaseerd is, niet bedrijfsspecifieke kennis).

Opdrachtgevers betalen zo 90 a 100eu/uur voor een goede developer met 5-10 jaar ervaring die in vaste dienst ~70k op jaarbasis zou verdienen.

Het werkt misschien in de praktijk niet precies zo, maar als je dat op basis van het salaris in vaste dienst zou extrapoleren kom je op ruim 200eu/uur uit.

[YopY]

Ik las laatst dat de gezondheidszorg daar ook last van heeft - veel medisch personeel neemt ontslag en gaat verder als ZZPer, maar dan tegen 2x zoveel geld. En ze worden daartoe aangemoedigd door detacheringsbedrijven en tussenpersonen, want die romen ook een deel af. Soms zelfs dat ze ontslag nemen bij bijv. een ziekenhuis, om vervolgens als ZZPer bij datzelfde ziekenhuis aangenomen te worden. linkje

[Zoop]

Ik heb dat in de IT ook meerdere keren gezien. Kerel verlaat bedrijf, afscheidsborrel en alles. En vervolgens zit die gast nog steeds op dezelfde plek, maar nu als ZZP'er. Dan heb je het volgens mij wel goed voor elkaar.

Motivatie vanuit bedrijf was dat ze dan niet met vaste kosten zitten, als er geen werk voor de kerel is, hoeven ze hem ook niet te betalen. Maar daar tegenover vangt hij wel zo'n 4x meer voor exact hetzelfde werk. Kan mij niet voorstellen dat dit minder kost ... Maarja, gaat om kostenposten en afschrijvingen. Al die uren die die kerel erin steekt kan je doorberekenen naar de klant.
De uren dat hij stil zit is pure verlies ...

[Andros]

Werkgever bespaart ook op premies volksverzekeringen, pensioenafdracht, doorbetaling bij ziekte en is ook van die ZZP'er af als het werk op is. Vaak zijn die "zelfstandigen" ook gewoon een manier om onder normale arbeidsrechten uit te komen, werkgevers vragen het soms zelf of een personeelslid zelfstandige wil worden met de belofte dat er meer te verdienen is. Dat de werknemer in de problemen komt bij ziekte of "ontslag" vertellen ze er nooit bij.

[Zoop]

Dat is waar, in dienst kan zo'n werknemer zo een halfjaar met ziekteverlof als hij iets ernstigs oploopt.
Is leuk als je als ZZP'er 4x meer verdient, maar 4x0 is nog steeds 0.

[REDSD]

Maar als je 4x zoveel verdient heb je na 3 maanden werken ruimte om 9 maanden ziek te zijn. Als je 20 jaar zzp hebt gewerkt kan je dus 60 jaar verlof nemen en heb je het zelfde verdiend.

Een vaste baan geeft je geen garantie op inkomen, als je twee jaar ziek bent wordt je ook ontslagen.
Als je je baan verliest krijg je ook maximaal maar 2 jaar een uitkering en daarvoor moet je door veel hoepels springen voor het UWV.

Dus ja als Zzp loop je risico, maar als je veel meer verdient kan je dat beter afdekken dan wanneer je van de staat en je werkgever afhankelijk bent.
(ps ben geen zzper, maar ik heb genoeg mee gemaakt om te weten dat in vaste dienst je vooral meer schijnveiligheid geeft)

[Andros]

Probleem is ook dat mensen die als ZZP'er veel meer verdienen er ook naar gaan leven. Dure luxe auto, groot huis, verre vakanties etc. Tegen de tijd dat ze wel eens ziek worden of met pensioen gaan komen ze bij de staat aankloppen voor bijstand omdat ze aan de grond zitten. Niet iedereen kan goed rekenen, dat is nou net de reden dat we met al die volksverzekeringen ooit zijn begonnen.

[Glashelder]

Het leeuwendeel van de ZZPers die ik ken zijn niet zo.

Maar als je het wel doet kan het ook gewoon een keus zijn. Waarom wachten met lekker leven tot je oud en bejaard bent? Je kan ook nu je geld uitgeven en dan accepteren dat je het wat minder breed hebt tegen de tijd dat je oud en bejaard bent. Dan heb je tenminste een leven gehad

[DhuumDhuum]

Maar diezelfde mensen zullen dan bij de staat aankloppen voor extra geld.

Terwijl de mensen die er voor gewerkt hebben (of aan het werk zijn) en netjes iets opzij hebben gezet dan de sjaak zijn. Want die betalen allen extra omdat diegene die alles hebben uitgegeven nooit het geld op zij hebben gezet voor hun oude dag.

Dus hoe is dat eerlijk voor de anderen?

[Glashelder]

Waarvoor kunnen ze aankloppen dan? Het enige waar je AFAIK voor kan aankloppen is iets als bijstand, en daar heeft iedereen recht op in die situatie.

[DhuumDhuum]

Als je bijstand nodig hebt hoor je het te krijgen ja en dat is een belangrijk vangnet.

Maar in de situatie die jij schetst waar mensen tegen gezond verstand in teveel geld opmaken op jongere leeftijd want "ik krijg toch wel bijstand" is niet waarvoor een vangnet bedoeld is. Dan is het gewoonweg -opzettelijk- onverantwoord financieel gedrag wat niet beloond zou moeten worden.

[Glashelder]

De huidige situatie is dat 90% van Nederland zijn hele leven voor een pensioen werkt, en best een deel daarvan haalt de pensioengerechtigde leeftijd niet eens. Als je dan geen partner hebt, dan vervalt zo'n pensioen gewoon aan het pensioenfonds. Erfgenamen hebben daar geen recht op (minderjarige kinderen uitgezonderd). Is dat eerlijk?

Verder heb ik heb het niet over *teveel geld* opmaken, ik zeg alleen *leven* wanneer je als mens op je best bent. Jij interpreteert dat als zijnde dat je dan *al* je geld opmaakt. Ik had het weliswaar over 'je geld uitgeven', maar dat hoeft niet te betekenen dat je *al* je geld opmaakt.

Moraal van het verhaal: het leven is niet altijd eerlijk, en je moet niet altijd willen proberen om het maar eerlijk te maken. Zo ontstaan nieuwe kindertoeslagenaffaires En buiten dat, al die controles kosten echt bakken met geld.

[FONfanatic]

Er zijn nog steeds heel wat mensen die weinig of geen aanvullend pensioen hebben opgebouwd en niets verbrast hebben. Dat was en is ook 'niet eerlijk'.

Dat 'aankloppen bij de staat' is een beroep doen op de AOW. Dat bouwt een ieder op die hier te lande legaal verblijft. Maar dat deed menigeen niet ...

Hoe 'eerlijk' is het overigens je als graaiende ZZP‐er te gaan gedragen met als excuus dat je je onderbetaald vindt? Loononderhandelingen kun je als beroepsgroep collectief laten doen door een beroepsvereniging of vakbond. Dan kun je misschien de verleidingen weerstaan om je verantwoordelijkheidsgevoel over drainbrain in te ruilen voor je hedonisme.

[Kevinp]

Het beleid hier is dat een ZZP'er/detacheerder maar (ik dacht 2 jaar) in diest mag zijn. Dit om kennis in huis te houden en het echt als project te zien.

Uitzonderignen zijn er altijd, maar toen ik hier begon waren er mensen die hun jubileium van 12.5 jaar bijna hier vierde, maar ingehuurd zaten.

[leuk_he]

Ik ken ook een bank, waar het budget aan het eind van het jaar (oktober/november) op is en dan verdwijnen er een boel exterenen... en vreemd genoeg zijn die niet allemaal in januari weer beschikbaar.

Opvallend is ook dat die bank regelmatig downtime heeft.

Ik kan niet bewijzen dat er een oorzakelijk verband is, maar het doet je denken.

[Shamalamadindon]

En budgetair uit een ander potje dus op papier kan een manager zeggen dat er minder kosten zijn.

[HuisRocker]

De trend die gaande is... Lang geleden begonnen door directie en management die 2-4 jaar de boel komen kapot bezuinigen 'verbeteren' en daarna vertrekken omdat niets meer functioneerd 'hun taak is volbracht' (en het dus tijd is om ergens anders sprinkhaan te gaan spelen).

[Neocortex-re]

Dit is een heel verleidelijke schets.
- Reken voor 'body shopping' met een facturabel percentage van 80 procent.
- Reken voor consultancy op niveau met een facturabel percentage van 60 - 65 procent.
(Ik heb de getallen niet zelf verzonnen.)

[Arfman]

Niet iedereen wil/kan ondernemer zijn. Laat mij maar lekker in vaste dienst zijn, hark nog steeds een prima salaris binnen en alles wordt netjes voor mij geregeld.

[batjes]

Er zijn ook bar weinig bedrijven bereidt te investeren in hun personeel.

Zelf wil ik uit de detachering weg, maar dat is lastig. Het betekend dat ik significant moet inleveren op voorwaarden.

Het voelt ook krom, dus je wilt mij niet direct aannemen of voldoen aan mijn eisen, maar dan rustig 3-4 keer mijn uurloon uitbetalen aan een tussenpartij?

Ik snap wel waarom ik ook steeds meer ZZP-ers en gedetacheerden om me heen zie. De goede bedrijven die direct contracten aanbieden zijn heel erg schaars.

[HuisRocker]

Klopt, ik werk al bijna mijn hele werkende leven op die manier, en alle bedrijven waar ik terecht kom maar klagen dat het zo duur is, maar ja, ze kunnen niemand vinden zonder tussenpartij...
Terwijl, als je er direct zou solliciteren, ze je geen fatsoenlijk salaris en/of voorwaarden bieden!
Gek hé dat mensen dan niet direct voor je willen werken en bij die tussenpartijen terecht komen.

[batjes]

Wat voor mij ook meespeelt, elk bedrijf heeft zijn of haar drama's, ik heb een hekel aan dramas. Als gedetacheerde kan ik me er makkelijker van distantiëren. Kan mij het boeien wat er persoonlijk onderling afspeelt, ik ben daar om te werken.

Ben al een tijdje op mijn gemakje aan het rondkoekeloeren en de arbeidsmarkt valt mij echt vies hard tegen momenteel. Als er een daadwerkelijk tekort aan werknemers zou zijn, dan zouden wij werknemende plebs veel sterker moeten staan aan de onderhandelingstafel.

[dgompie]

En dat gaat vaak samen met extreem slechte (of zelfs geen) documentatie, want niet belangrijk/prioritieit.

[elmuerte]

Documentatie lost complexiteit en weggelopen kennis niet op. Hoe complexer het systeemlandschap hoe meer documentatie. Verder heb je met documentatie altijd de problemen:
1) is de documentatie correct en nog relevant
2) beschrijft de documentatie de complexe interactie tussen de systemen
3) beschrijft de documentatie de details op waar het allemaal mis kan gaan

Documentatie zal niet verbanden kunnen leggen of mogelijke oplossingsrichting kunnen verzinnen die een ervaren ITer met jaren ervaring binnen het bedrijf wel kan. Ook Al zoals die nu ontwikkeld worden zal dat niet kunnen.

[Sluuut]

Toch kan documentatie heel erg handig zijn. Ik heb al vaak meegemaakt dat documentatie je helpt en problemen (veel) sneller zijn opgelost.

1) is de documentatie correct en nog relevant
-> Daar moet de perceelhouder voor zorgen. Als blijkt tijdens periodieke controles dat documentatie achterloopt dan moet de perceelhouder een waarschuwing krijgen en het bijwerken. Is gewoon een stuk opvoeding.

2) beschrijft de documentatie de complexe interactie tussen de systemen
-> Complexe interactie kan alsnog simpel op een visio plaatje op hoofdzaken beschreven worden. Als je op hoofdlijnen weet waar iets mis loopt dan zoom je daarop in en hoef je niet naar de rest te kijken, dat kan al een paar uur troubleshooting schelen.

3) beschrijft de documentatie de details op waar het allemaal mis kan gaan
Nee, en dat zou ook niet moeten. Enkel known issues moeten beschreven zijn.

Wij hebben de volgende documentatie regels
- Documenteer afwijkende configuraties
- Documenteer afspraken en beleidskeuzes
- Documenteer (vaak) terugkerende processen

Ik denk dat ik minder dan 5% van mijn tijd kwijt ben aan documenteren, en ik ben nog diegene die het meeste documenteert van mijn team. De praktijk kan dus echt wel meevallen. Het zit vaker in de techneut die het vergeet en (vaker) er simpelweg geen zin in heeft. Er komen dan vaak smoesjes als geen tijd, andere prioriteiten eerst, en uiteindelijk komt er gewoon geen documentatie.

@REDSD is ben het geheel met je eens dat de IT complexer en complexer word en daardoor de kans op downtime & bugs toeneemt. Ik erger me daar ook aan.

[Reactie gewijzigd door Sluuut op 22 juli 2024 16:47]

[Zoop]

In mijn ervaring wordt dit hele bovenstaande verhaal vaak door 1 enkel persoon beheerd en uitgevoerd. Dus dat is zo goed als die persoon acht dat het is.

Waarschuwingen en opvoeden gaat niet werken als die persoon al weg is bij je bedrijf tegen de tijd dat dit opgemerkt wordt. Zeker als dit ZZP'ers zijn die elk hun eigen eilandje beheren.

[hackerhater]

Nou ik als ZZP'er sta altijd op documentatie.
Bij mijn vorige klant was alles netjes achter gelaten.
De documentatie beschrijft de grote onderdelen van de applicatie en hun onderliggende communicatie.
Elk onderdeel ging nog dieper en beschreef de componenten van het onderdeel en hoe ze samen werkten.

Met een probleem duwde de documentatie je al direct naar 5 a 10 klassen die de oorzaak kunnen zijn. Wat een enorme reductie van zoektijd is.

[Sluuut]

Tsja, daarom moet je ook periodiek (denk bijvoorbeeld aan elke kwartaal) deze controle uitvoeren en de persoon hierover aanspreken. Na 3x lig je er gewoon uit, zo simpel kan het zijn. Zo’n onmogelijke opgave is het niet.

[Zoop]

Het is ook zeker niet zo ingewikkeld. Net als documentatie schrijven, kost je hooguit paar minuutjes per dag.
Maar de praktijk is toch (in mijn ervaring) anders.

Er zullen vast posities zijn waar genoeg management aanwezig is die dat soort controles inplannen en zorgen dat het daadwerkelijk gebeurd.

Maar ik zie zzp'ers het meeste in eenzame posities, een manusje van alles ingehuurd om zijn eiland te beheren. Als die daar een zooitje van maakt kom je daar over het algemeen veel ste laat pas achter.

[cHoc]

Op je punt 1
Terecht, alleen komt de perceelhouder hier wel achter? In dit geval ben jij dat zelf, en pas je het dan aan.
Plus wie update de perceelhouder met de nieuwe informatie? Meestal jijzelf/collega's, alleen dit is niet altijd zo.
In het bedrijf waarin ik werk is de klant verantwoordelijk voor het leveren van nieuwe informatie over nieuwe en bestaande apparatuur, en de perceelhouder is verantwoordelijk voor de documentatie, 1 keer raden waar het fout gaat als het gaat om verouderde informatie in de documentatie, en probeer die maar eens op te voeden.

[mati1983]

Wat je zegt klopt, maar documentatie is absolutut key wat mij betreft.
Ook bij ProRail zal men tegenwoordig wel weer devops/scrum/agile/wat-voor-hippe-variant-dan-ook werken, maar bij al die varianten gaat er "van alles 'over' documentation" en daar ben ik zeer allergisch voor.

Documenteren om het documenteren hoeft niet, maar er moet wel gewoon beschreven staan wat je hebt en doet. Heb je dat niet, dan gaat iets niet naar productie. Simpel. Hoe niet-leuk de gemiddelde ontwikkelaar of beheerder dat ook mag vinden. Zeker gezien het hoge verloop van werknemers vandaag de dag.

Overigens kan dit alles twee oorzaken hebben: óf er is iets kapot (monitoring) of er is iets gewijzigd. Indien kapot is de oorzaak achterhalen niet zo lastig en ook het vervangen, als het goed is, ook niet. Wanneer het een wijziging betreft zou je hopen dat het door een fatsoenlijk stukje change/deploy/release management is gehaald en dat ook een roll-back te doen zou moeten zijn.

Het valt mij sowieso op dat bij bedrijven waar Agile helemaal je-van-het is er in vergelijking met vroeger zeer veel verstoringen zijn. Neem internetbankieren als voorbeeld. 5 jaar geleden was het een zeldzaamheid wanneer de dienst er bij een bank uit lag. Vandaag de dag lijkt zoiets wel 5x per maand te gebeuren.

[elmuerte]

Dat heeft niks met agile te maken. Agile zegt niet dan je niet moet documenteren, het zegt dat werkende software belangrijker is dan uitgebreide documentatie. Dit heeft voornamelijk betrekking om het moment dat je de software nog aan het ontwikkelen bent, en de correcte oplossing nog niet duidelijk is.

[mati1983]

Klopt, alleen is dat niet hoe het in de praktijk bij veel van die zelfsturende teams werkt en dus heeft het álles met Agile te maken!

Dergelijke software is vandaag de dag bijna nooit 'af' trouwens, zeker niet in de mate waarop Agile kleine releases 'forceert'. Het is dus essentieel dat je vandaag de dag weet wat je ex-collega 3 jaar geleden exact gedaan heeft en waarom. Alleen jammer dat hij/zij dat nooit opgeschreven heeft.

Je merkt het al, ik ben een echte agile fan.

[CEx]

Afzetten tegen de norm is ook van alle tijden. De problemen rondom actuele documentatie zijn echter niet verbonden aan Agile.
Dezelfde problematiek had je met Prince 2 (waterval), hoop 'documentatie' vooraf met een planning die niet gehaald werd. Vervolgens werd er onder tijdsdruk ontwikkeld, waarbij hetgeen gebouwd werd na verschillende iteraties aan testen en bugfixing niet meer leek op het oorspronkelijke technisch ontwerp. Want deadline kwam dichterbij, geen tijd om TO's aan te passen of nog erger 'in grote lijnen is het nog hetzelfde' mentaliteit.
De projectleider was alleen maar bezig met exception reports schrijven zodat hij meer tijd en budget kon krijgen. Daarbij was het belangrijk om altijd de schuld ergens anders neer te leggen dan de projectleider zelf. Bij voorkeur bij een IT team, extra bonus als dat IT team al eerder de gebeten hond was, want dan zou het wel waar zijn.

/rant

Het erge is dat ik niet eens overdreven heb.

[Tjidde]

Als je ex-collega duidelijke en zo simpel mogelijke code hebben geschreven is hun documentatie minder belangrijk.

In een methode geen gekke branches die je niet verwacht. Doen wat er op het doosje staat, ga zo maar door.

Want als je dat goed doet, is je code je documentatie. Echter vaak moet het af. Dus is de controle minder, waardoor je slechtere/onduidelijke code in je codebase kan krijgen want er is niet streng genoeg gekeken of het voldoen aan de eisen die jullie als ontwikkelteam gesteld hebben.

Het zit hem uiteindelijk in team- of codemanagement. Als je duidelijke regels met je team afspreekt over de code, hier ook streng op bent naar elkaar. Maakt de werkwijze verder niet uit. Of je nu Agile, waterval of mijn apart met een dartbord je projecten afwerkt.

[himlims_]

De app van ING wordt volgens agile ontwikkeld [..]

[CivLord]

En wat wil je daar mee zeggen?

Ik vind de app behoorlijk goed werken. Wanneer ik er problemen mee heb, komt dat door de achterliggende systemen, waardoor bankieren via de site, iDeal-betalingen en soms zelfs pinnen ook niet werkt.

[Keypunchie]

Het valt mij sowieso op dat bij bedrijven waar Agile helemaal je-van-het is er in vergelijking met vroeger zeer veel verstoringen zijn. Neem internetbankieren als voorbeeld. 5 jaar geleden was het een zeldzaamheid wanneer de dienst er bij een bank uit lag. Vandaag de dag lijkt zoiets wel 5x per maand te gebeuren.

Als iemand die beroepshalve redelijk veel met de missie-kritische financiele IT te maken heeft, herken ik dat absoluut niet.

In de afgelopen 10-15 jaar ofzo is er voor zower ik weet geen enkele noemenswaardige structurele trend opwaarts of neerwaarts in de algemene dienstbeschikbaarheid van internetbankieren (waar ik gemakshalve dan ook "mobiel bankieren" in mee neem, wat in de gebruikersperceptie 1 en hetzelfde is en ook steeds meer convergeert). Individuele banken hebben hun ups&downs gehad in die tijd, maar dat is het dan wel.

Het gebruik en afhankelijkheid van internetbankieren is in die tijd wel allleen maar toegenomen, ook door bankbeleid, waardoor iedere individuele storing wel meer gemerkt wordt. Een individuele storing heeft impact op meer gebruikers dan voorheen.

[mati1983]

Ik plaatste die opmerking met mijn professionele IT pet even af, maar puur vanuit mijn onderbuikgevoel. Heb het niet zitten meten of turven en ik kan het zeker fout hebben, maar iedere week lijk ik wel te lezen dat er 'ergens' problemen zijn.

[PhWolf]

Dat kan ook heel goed, dat het elke week ergens mis is. De nuance van Keypunchie is dus dat dat helemaal niet vaker dan normaal (of 'in vergelijking met vroeger' zoals jij het zei) hoeft te zijn, maar dat het wellicht vaker wordt opgemerkt tegenwoordig omdat we veel meer gebruik zijn gaan maken van internetbankieren en omdat er een algemene verwachting is dat internetdiensten het 100% van de tijd doen.

[Zoop]

Er zijn tegenwoordig niet per se meer autisten, wel kunnen we het beter constateren, dus stijgende cijfers.
Er zijn tegenwoordig meer auto ongelukken dan vroeger, ondanks meer verkeersregels en veiligheidseisen voor auto's.
Haat, fascisme en rascime is van alle tijden, maar laatste tijd lijkt het wel heel erg, erg vocale minderheden die aan het internet een prima platform hebben om vanaf te schreeuwen.

Etc etc.

Dat internetbankieren problemen een stijgende lijn is dus ook niet geheel gek, er wordt meer gebruik van gemaakt. Wellicht gebruik je hetzelf nu ook meer dan vroeger waardoor je er sneller tegenaan loopt.

Dit soort dingen dienen in verhouding te zijn, een acceptabele foutmarge. Of dat zo is met de banken of niet, weet niet (voor mij gevoel is die foutmarge op het moment ook te hoog). Maar die onderbuik gevoelens zeggen niet zo veel over de realiteit.

[Cergorach]

Documentatie zal niet verbanden kunnen leggen of mogelijke oplossingsrichting kunnen verzinnen die een ervaren ITer met jaren ervaring binnen het bedrijf wel kan. Ook Al zoals die nu ontwikkeld worden zal dat niet kunnen.

Nee, maar het zou wel de verbanden met systemen moeten hebben gedocumenteerd. Een ITer met 20 jaar ervaring vervang je door iemand met 20 jaar IT ervaring, maar als wat je zegt waar is, werkt daar in de eerste instantie al geen ITer met 20 jaar IT ervaring binnen dat bedrijf omdat deze alweer snel wegloopt...

Maar 20 jaar IT ervaring zegt niet heel veel, heeft die persoon inzicht en een heel hoog oplossingsvermogen? Dat zijn zaken die je heel wat minder makkelijk in cijfertjes op een CV kan neerzetten.

De drie punten die je aangeeft zijn absoluut belangrijk, zeker punt #1 is een groot issue. Maar wat vaak ook wordt vergeten is de documentatie toegankelijk en begrijpbaar beschreven voor iemand met x niveau IT kennis (dus niet de bedrijfsspecifieke kennis)? Als je de documentatie niet bijhoud en begrijpbaar maakt kan goede documentatie devolven in een periode van een paar maanden. Een (groot) project waarvan de changes niet zijn gedocumenteerd en een significant deel van je documentatie is meteen waardeloos. En laten we wel wezen, een hele hoop ITers staan er bekend om dat het niet de meest vaardige mensen zijn in communicatie, dat maakt ook niet een hele goede documentatie schrijver...

Bij grote en/of complexe organisaties waar veel veranderd/vernieuwd is het gewoon noodzakelijk dat er dedicated mensen bezig zijn met de documentatie bijhouden, begrijpbaar maken/houden, project/change medewerkers achter de vodden aan blijven zitten dat ze changes bijhouden, etc. De meeste organisaties zien daar niet zo de noodzaak van in, totdat ze geconfronteerd worden met het falen van IT door het ontbreken van fatsoenlijke documentatie.

[SunnieNL]

Of een backup/uitwijk mogelijkheid.

Nou is in dit geval een uitwijk gestart gisteravond (volgens de woordvoerder bij rtl nieuws vanochtend), maar die kwam te laat om de boel gisteren al op te starten. Maar zo te lezen heeft dat geholpen. Ze bedienen nu dus Amsterdam vanuit de uitwijk in Utrecht. Kan mij voorstellen dat zo'n uitwijk bij ProRail ook wel een dingetje is en niet zo snel geregeld is. Die uitwijk moet immers alle regio's kunnen opvangen, dus zal her en der wel wat omgezet moeten worden.

Kan mij niet voorstellen dat ze vandaag nog gaan starten vanuit Amsterdam zelf omdat alle mensen nu vanuit Utrecht aan het werk zijn. Mogelijk dat de volgende ploeg het wel vanuit Amsterdam weer kan overnemen als de storing inderdaad boven water is.

[Tjeerd]

Mee eens. Daarnaast persoonlijk ook met best complexe systemen gewerkt en mijn persoonlijke valkuil is dat ik dat hele complexe systeem wil proberen te snappen. Dat lukt mij niet en/of ik word overwelmd. Leermomenten en ik beperk me steeds meer tot een geisoleerd stukje van een systeem om daar iets in aan te passen/uit te breiden. Mentaal kan ik niet alles 'mappen' tot in detail. Grote lijnen wel.

Het gevolg daar van is dat je kennis hebt over maar een klein onderdeel. En ik ben daar niet de enige in. Tel daarbij op dat er soms tien verschillende mensen aan dat stukje hebben gewerkt en ook allemaal weer vertrokken zijn na verloop van tijd.

Gelukkig is de code meestal wel goed getest enz, maar wat ik wil zeggen; niemand overziet bij die steeds complexere systemen alles meer en daardoor is de kans steeds groter dat er toch ergens fouten in sluipen. Software is bij sommige bedrijven echt heel complex geworden, dat ik me wel eens afvraag wat voor generatie ontwikkelaars we nodig gaan hebben.

[gimbal]

De huidige generaties ontwikkelaars kunnen het ook prima aan. Wat nodig is, is een kartrekker. Die mensen zijn echt zeldzaam en bedrijven erkennen niet dat dergelijke mensen bestaan en doen dus ook geen moeite om ze te behouden.

Complexe systemen zijn prima te onderhouden als er een daadwerkelijk team met een team lead achter zit en niet een developer die naar team lead is gepromoveerd om meer salaris te kunnen krijgen.

[poehee]

Precies, een toezichthouder. Een controller.

Iedereen wil dat als zijn of haar huis gebouwd wordt (en zelfs daar gaat echt ook van mis).

Maar voor (cruciale) IT-systemen is daar totaal geen aandacht voor. Iemand die de oplossingen simpel houdt (maar toch schaalbaar), de kikkers in de kruiwagen houdt, zorgt dat testen niet ondergeschikt raakt, releasemanagement en documentatie op orde houdt.
Uiteindelijk heb je capabele mensen nodig, die snel applicaties en datastromen doorzien. Zonder die mensen heb je ook niets aan documentatie. Het is geen of/of...capabele mensen zijn geen pré maar een must.

[SPee]

Met meerdere mensen gewerkt hebben op hetzelfde stuk, gaat ook problemen geven. De eerste heeft het op een bepaalde manier opgezet, die heeft de tweede erover verteld. Maar na verloop is die context weg, waardoor er helemaal niet meer volgens die initiele manier wordt gewerkt en het een zooitje wordt.
En op die manier wordt het vanzelf complex en wordt de kans groter dat er fouten in zitten.

Zeker als het systeem groter wordt en meer complexiteit krijgt, dan zullen tests ook minder helpen; er zijn cases vergeten, teveel unit tests met "verzonnen input", onvoldoende functionele tests, etc.
Dan krijg je dat een collega een aanpassing doet die in service1 een versienr zet, maar in service2 met een ander veld vergelijkt, waardoor dit nooit werkt. Gelukkig zit dit in code die enkel tijdens disaster-recovery wordt aangeroepen, waardoor die op een kritiek moment faalt. En dan krijg je dit soort situaties. En tijdens ontwikkeling en test is dit door geen reviewende collega opgemerkt...

[broit1975]

Je hebt helemaal gelijk. Er komen nieuwe mensen binnen, die willen allemaal weer nieuwe en andere technieken. Er is geen simplicity meer.
Vaak zie ik dat er oplossingen worden bedacht voor problemen die er niet zijn, alleen maar omdat het 'leuk' is. Of er worden complexe oplossingen bedacht terwijl het ook simpeler kon. Waarom makkelijk doen als het moeilijk kan?
En dan ook nog het feit wat je aanhaalt: Als ze klaar zijn met spelen, dan gaan ze naar het volgende bedrijf en komen er weer nieuwe mensen binnen. Alles begint dan weer van voor af aan.

Keep it simple.

[Cartman!]

Dergelijke systemen zijn gewoon niet "simple" dus die simpel bouwen is vaak geen optie.

[Tjidde]

Simpel bouwen is wel een optie.

Je moet in mijn optiek gaan voor de simpelste oplossing. Hoe complex je vraagstuk ook is.
Ga niet voor complexe technieken die nergens voor nodig zijn. Als je een complexe vraagstuk hebt en je lost die op met ook nog eens complexe technieken. Succes om over 2 jaar een aanpassing te doen zonder dat alles instort.

[Cartman!]

We hebben het hier niet over een Wordpress website van de bakker om de hoek. Developen is afwegingen maken. Misschien kun je iets simpel bouwen in een hobby framework zodat het werkt op jouw eigen machine maar is het daarmee ook robuust in te zetten in een omgeving waar stricte SLA's zijn of waar het belangrijk is dat er bijvoorbeeld goede (audit) logging plaatsvindt. Koppelingen met third parties die netjes (async) afgehandeld worden. Verwerken van betalingen of zoals bij de NS; een systeem dat alle sporen en hun statusen/sensoren in de gaten houdt.

[Tjidde]

Je wilt altijd zo simpel mogelijk.

Je hebt inderdaad complexe problemen waar je niet wegkomt met DoeIets(string PleaseWork);

Maar je moet altijd opzoek gaan naar de simpelste oplossing binnen jouw vraagstuk of dit nu een website is voor de bakker of de NS maakt niet uit.

De vraagstuk is inderdaad complex. Waarbij je naast functionele eisen ook eisen die vanuit wetgeving of wat dan ook komen. Maar omdat het juist zo complex is moet je code zelf niet nog eens extra complex zijn omdat het gaaf is. Het moet werken en zo simpel mogelijk. Je gaat niet allerlei hippe trucjes/frameworks gebruiken die mogelijk over een jaar of twee heel anders werken of niet meer ondersteund worden.

[Cartman!]

Maar jij hebt blijkbaar inside information dat deze situatie ook van toepassing is op de NS?

[YopY]

En het (dwz nieuwe technieken) wordt zelfs aangemoedigd, want dan kunnen ze beter (en betere) mensen vinden. Je krijgt een heel andere groep mensen in je inbox als je bijv. "blockchain & AI solutions in Rust" in je vacature hebt staan dan "Java developer voor ERP software".

Ik heb ook wel gehoord dat ze met opzet consultants inhuren die coole hippe dingen doen om het bestaande, interne & vastgeroeste personeel een opkikker te geven. Daar zit je dan terwijl iemand die 3-4x kost wat jij verdient leuke dingen doet, het naar jou over de schutting gooit en weer oprot.

[StarZ]

Vaak zijn die complexe systemen ook antwoorden op complexe problemen. Gebruikers willen alles met 1 inlog kunnen, alle gegevens gekoppeld hebben en de klant moet alles zelf via een website kunnen doen.
Dit los je echt niet op met een simpel systeem. Vaak zitten er ook allemaal leveranciers achter de systemen die ook aangesproken moeten worden.
Het probleem zit hem denk echter meer dat men tegenwoordig steeds meer verwacht van de developers en deze inderdaad na een paar jaar met alle kennis vertrekken omdat men niet genoeg betaald. Ook komen dingen als reliability en bugs op een lager pitje staan dan features, want features leveren direct geld op en risico management niet perse.

[IStealYourGun]

Als je infrastructuur afhankelijk is van de loyaliteit van je werknemers, dan is dat eerder een bijkomend risico.

Ik ken genoeg bedrijven waar enkele engineers met veel anciënniteit plots vertrokken waren op korte tijd en hun bus factor gekelderd was met alle nodige gevolgen.

[coolkil]

IT oplossingen worden complexer gemaakt door onduidelijke en onnodige requirements. Daarnaast zijn er veel IT ers die erg domein specifiek denken en moeite hebben met het grote plaatje

[Anoniem: 1322]

Een trend die ik zie als iemand die in de IT werkt is dat het erg lastig is kennis te houden, en dat de techniek steeds complexer wordt.
Yep, dat is het probleem / voordeel (vanaf welke kant je kijkt) van schaarste op de markt. Persoonlijk vind ik dat techniek niet enorm veel complexer wordt, we worden verwacht steeds 'breder' kennis te hebben. Maar dat is niet een hele nieuwe trend. Vroeger (als in 2000) werd dit ook verwacht, we hadden toen geen aparte netwerk / storage / infra IT medewerkers. Joep de systeembeheerder deed het allemaal zelf. Daarna kreeg je veel meer specialisme (tot de dag van vandaag) en moet je een specialist inhuren voor je Juniper netwerk om de juiste instellingen te weten. Tegenwoordig vervalt dat specialisme weer met cloud. De specialistische kennis is nog wel vereist voor sommige leveranciers maar de mensen komen er wel uit.

Daarnaast worden IT oplossingen steeds complexer, een trend waar ik mezelf al een tijdje aan erger, steeds uitgebreidere frameworks worden gebruikt (en dus meer afhankelijkheden), steeds complexere systemen zoals AWS, Azure die meer microservices hebben.
Uiteindelijk hangt dit allemaal af van de architect. En als het een goede is kiest hij vrijwel altijd voor de KISS principe (tenzij het echt niet anders kan en dan staat dit beschreven in een architectuur bestand. Onthoudt dat microservices hier niet zoveel mee van doen hebben, die zouden juist je architectuur simpeler moeten maken door scheiding van taken. 1 taak onderuit betekent dan niet direct een probleem en schaling van die taken is eenvoudiger (als je het goed doet).

(valt iets om in de keten, is de keten stuk)
Tja, als dit het geval is kan je niemand anders de schuld geven dan de architect. Dat moet natuurlijk nooit of hij heeft het aangemerkt en het is een management keuze geweest. Een interessante oplossing voor dit probleem is bijvoorbeeld Chaos engineering. Als je dit onderwerp interessant vindt zie ook de Netflix blog over hoe zij dit hebben aangepakt: https://netflixtechblog.c...-simian-army-16e57fbab116

Nu moet je hopen dat je nog kennis in huis hebt van een service die ooit gebouwd is en misschien wel een belangrijkstukje van je infrastructuur is.
Geloof mij, je wilt echt niet terug naar de monolitische systemen. Backups was je nummer 1 lifesaver in die dagen... Iets dat tegenwoordig vrijwel niet meer voorkomt.
Mijn grootste probleem is dat men een draak van een oplossing heeft gebouwd maar niemand durft het nog aan te raken. Men heeft een (veel) te complex systeem maar ze durfen er niets aan te doen. Tot het in elkaar stort.

[wiseger]

Het probleem ligt niet zozeer bij de architect maar eerder bij het continue veranderende landschap. Een goede bedrijf applicatie gaat rustig 10 jaar mee. Bij de overheid zien we zelfs uitschieters naar 20 jaar of langer.

Zolang iets goed werkt wordt het niet zomaar vervangen omwille van de voortschrijdende inzichten van de architecten en het veranderende IT landschap.

Dus zitten we heden ten dage bij grote organisaties met een hele mix aan systemen. Van applicaties die geleverd worden door een leverancier, zelf gebouwde applicaties van verschillende leeftijden op verschillende architecturen en alles is aan elkaar geknoopt met interfaces. Van CSV bestanden die via SFTP lopen, tot queue interfaces of zelf real time interfaces. Als je het landschap plaatje bekijkt dan val je echt vaak van je stoel, zo complex is het geworden.

Als er ergens in die brij een cruciaal onderdeeltje omvalt, zie dan de root cause maar eens te vinden. Daarom heeft Prorail het zo moeilijk, daarom heeft de belastingdienst het zo moeilijk.

[Tassadar32]

Hier ervaring met IT bij de overheid. Er is totale onwil om mee te komen met moderne technieken en de engineers die in dienst zijn worden als ze een beetje goed zijn snel weggekaapt. Wat je overhoud zijn externen, onbekwame medewerkers die nooit ontslagen worden en vooral heel veel niet-ITers die beslissingen maken die ze nooit hadden gemaakt als ze daadwerkelijk ervaring met IT hadden.

[Anoniem: 1322]

Het probleem ligt niet zozeer bij de architect maar eerder bij het continue veranderende landschap.
Zolang iets goed werkt wordt het niet zomaar vervangen omwille van de voortschrijdende inzichten van de architecten en het veranderende IT landschap.
Dat is een goed punt en inderdaad een groot probleem. Maar we moeten hier niet doen alsof dit een nieuw probleem is. Life-cycle management is een essentieel kernpunt van ieder project en is onderdeel van ITIL. Zeker in IT is het geen verassing dat een systeem maar een beperkte levensduur heeft.

Als er ergens in die brij een cruciaal onderdeeltje omvalt, zie dan de root cause maar eens te vinden.
Oké, dus omdat het complex is (gemaakt) moeten we het dan maar accepteren? Of zouden we dan eigenlijk eens moeten gaan werken aan een oplossing?

Daarom heeft Prorail het zo moeilijk, daarom heeft de belastingdienst het zo moeilijk.
De grap is dat de regels voor overheden heel duidelijk zijn. Als ze zich aan die regels houden dan voert men veel standaardisaties toe die zullen leiden tot veel minder complexiteit. Het probleem is hier vooral politiek (scope-creep) en daarna beleid (gebrek aan toezicht).

[paradoxdesign]

Zo waar wat je nu zegt. De techniek overstijgt een beetje het kunnen. Alles wordt zo achterlijk complex. Alleen om een licentiemodel van Microsoft te doorgronden moet je tegenwoordig al bijna ingenieur zijn.
IT is ook al lange tijd geen hulpmiddel meer maar een enorm geldverslindend doel.
Het lijkt er een beetje op dat alles ondergeschikt is aan de IT. Het eindproduct of service lijkt een bijzaak geworden.
Wordt hoog tijd eens een beetje gas terug te nemen.

[FreezeXJ]

Doe het maar eens zonder Dat kost je meer mensen, die je niet kunt vinden, en levert veel minder auditability op (in elk geval op papier). Vergeet niet dat elke scheet nu minimaal 4x gelogged moet worden, en door 6 verschillende instanties gecontroleerd moet (kunnen) worden voordat ie gelaten mag worden. Daarnaast is er normering voor de normering, auditing voor de (automagische) auditing, en natuurlijk moet alles in een of ander groot snelsnel-naar-productie-framework gebakken worden want dat doet 3 van die 6 controles al voor je (tot er 1 z'n standaarden omgooit en je op jezelf aangewezen bent).

Het is niet de IT, het is de eis tot inzichtelijkheid die alles zo onoverzichtelijk maakt. Mede mogelijk gemaakt door de IT.
En as always, gas terugnemen gaat niet zo relaxed, dat moet gewoon komen doordat de wal het schip keert. Te weinig personeel om basis-taken uit te voeren, waardoor je overbodige taken een voor een moet elimineren, ondanks dat andermans baantje daar weer van afhankelijk is. Misschien... zou je zelfs wel eens moeten vertrouwen op je medewerkers, zonder dat je precies kunt nagaan of ze wel de optimale keuze maken. En die arme medewerkers moeten dan ook niet schrikken als er eens naar ze geluisterd wordt, want dat kon wel eens normaler worden.

[rl3]

Bij de overheid is het wel goed om voor lange tijd te blijven. En dus lang verhaal kort; weer een argument dat de NS nooit geprivatiseerd had moeten worden.

[Djordjo]

De storing is niet bij de NS maar bij niet-geprivatiseerd ProRail.

[skatebiker]

NS en Prorail zijn geen van beide geprivatiseerd.
NS is alleen verzelfstandigd, maar de aandelen zijn nog steeds 100% van de staat.

[Hatsjoe]

Daarnaast worden IT oplossingen steeds complexer, een trend waar ik mezelf al een tijdje aan erger, steeds uitgebreidere frameworks worden gebruikt (en dus meer afhankelijkheden), steeds complexere systemen zoals AWS, Azure die meer microservices hebben (valt iets om in de keten, is de keten stuk).

Ja, IT omgevingen worden steeds uitgebreider, maar wanneer juist opgezet, niet complexer. Helaas vinden wij ITers het vaak niet leuk om documentatie schrijven en bij te houden. Ook vinden we nieuwe glimmende dingen erg leuk waardoor er een wildgroei aan tools en frameworks ontstaat. Dit is echter een probleem dat opgelost kan worden met strakkere afspraken en standaarden. Daarnaast, juist opgezette microservices architectuur is vele malen betrouwbaarder dan een monoliet. Wanneer 1 microservice omvalt hoort dit niet de rest offline te trekken. Wanneer de "spoor onderhoudsschema" microservice offline is hoort dit bijvoorbeeld niet de gehele "dienstregeling" microservice offline te trekken (fictieve microservices).

Vroeger was ook niet ideaal toen we monolieten van systemen hadden, maar toen bleef kennis in huis en had je alleen kennis nodig van je monoliet. Nu moet je hopen dat je nog kennis in huis hebt van een service die ooit gebouwd is en misschien wel een belangrijkstukje van je infrastructuur is.

Ik durf te wedden dat monolieten vele malen meer inefficiënt was. Toen moest je de GEHELE codebase kennen om de gehele monoliet te snappen. Met microservices maar een heel klein specifiek stuk waar jouw team voor verantwoordelijk is. Bij bedrijven die microservices op de juiste manier doen heb je altijd een functional en technical owner van iedere microservice die zorg moeten dragen voor de ontwikkeling en onderhoud van deze service(s). Daar horen storingen oplossen ook bij. Bij een storing weet je dan meteen welke service het probleem is, welk team daar verantwoordelijk voor is en heb je meteen de juiste experts te pakken. Bij een monoliet mocht je eerst logs en stacktraces doorspitten om überhaupt te weten wat er stuk is. En dan maar hopen dat er nog iemand in het bedrijf is die weet wat die regels code doen die al in 10 jaar niet aangeraakt zijn.

TLDR: wanneer je microservices op de juiste manier toepast, en je een goede bedrijfscultuur hebt met goede werkafspraken en standaarden, zijn microservices in (bijna?) ieder opzicht beter dan monolieten. Je hoeft binnen een microservice architectuur niet ieder component te kennen, enkel die waarvoor jij zelf verantwoordelijk bent (en wat basiscomponenten zoals networking/ingress/egress).

[Reactie gewijzigd door Hatsjoe op 22 juli 2024 16:47]

[wiseger]

Ik ben het niet net je eens. Juist door het gebruik van talloze microservices is het voor veel IT-ers steeds lastiger het overzicht te bewaren. Als er een serieus probleem is dan blijkt het erg lastig uit te vinden waar het zit, juist doordat je dan ineens met veel verschillende support groepen te maken hebt die allemaal hun eigen service grenzen hebben.
Dan zie de het ticket letterlijk van queue naar queue gaan zonder dat het problem opgelost wordt.

[Hatsjoe]

Ik ben het niet net je eens. Juist door het gebruik van talloze microservices is het voor veel IT-ers steeds lastiger het overzicht te bewaren.

Welk overzicht? Als applicatieteam hoef je enkel het overzicht te hebben van jouw eigen applicatie/microservice en alle daarbij horende dependencies zoals andere microservices of externe API's. Met API contracts weet iedereen precies hoe ze jouw API moeten gebruiken, en weet jij hoe je alle andere API's moet gebruiken.

Als er een serieus probleem is dan blijkt het erg lastig uit te vinden waar het zit, juist doordat je dan ineens met veel verschillende support groepen te maken hebt die allemaal hun eigen service grenzen hebben.

Als je binnen een microservice architectuur niet weet waar het probleem zit tijdens een storing, dan heb je je monitoring, alterting en insights niet goed op orde. Juist omdat alles zo los getrokken is van elkaar maakt het het kinderlijk eenvoudig om te zien welke endpoint/microservice de veroorzaker is van storingen of verhoogde latency. Vaak zelfs in 1 enkel overzicht, zoals bijvoorbeeld in dit plaatje: https://www.appdynamics.c...img.png/1615318321990.png

Dan zie de het ticket letterlijk van queue naar queue gaan zonder dat het problem opgelost wordt.

Dat klinkt als het klassieke probleem van geen "ownership" of door een gebrek aan monitoring/insights. Dat is geen probleem inherent aan microservices, maar een organisatorisch en bedrijfsbreed probleem.


Ik heb bij veel bedrijven rondgekeken, zowel die succesvol zijn met een monoliet, succesvol zijn met microservices, en die keihard falen met microservices. En overal zie ik dat wanneer een microservices architectuur goed toegepast wordt, dit altijd beter is dan monolieten, en dit positief uitpakt voor zo'n beetje alle KPI's.

Puur uit nieuwsgierigheid, wat voor soort functie beoefen jij momenteel binnen wat voor soort bedrijf?

[wiseger]

Ik ben applicatie eigenaar van diverse applicaties bij een internationale financiele instelling.
Ik heb te maken met een zeer complex IT landschap waar alles gebruikt wordt, van eigen ontwikkelde microservices, monolitische applicaties tot of the shell applicaties van leveranciers.
Hosting is zowel intern als extern.

[jpsch]

Zal je zien dat de down-time gewoon binnen de SLA valt.

[wiseger]

De spijker op zijn kop. Hoe vaak zien we niet dat een bedrijf zijn productie support uitbesteed?
Documentatie, jarenlange opgebouwde knowledge base, kennisoverdracht sessies, noem maar op moeten zorgen dat alle kennis overgedragen wordt.

Maar wat zien we bij de outsource partner, veelal gevestigd in India, ze hebben hele grote teams met heel veel verloop.

Binnen een paar jaar is alle diepgaande kennis weg en nemen de oplostijden behoorlijk toe.

[cHoc]

En vergeet ook niet de langere oplostijd en outsourcen.
Ik zie dat bij het bedrijf waar ik werk. Storingen worden nog wel redelijk snel opgelost.
Maar als het gaat om zaken als autorisatie en andere niet storingsgerelateerde zaken, dan wordt dat pas uitgevoerd als de SLA bijna is afgelopen, en niet eerder, zelfs al is er tijd voor om het eerder te doen.

[wiseger]

Dat is iets wat ik helaas ook regelmatig zie. Ik begrijp het ook wel, in de onderhandelingen wordt de prijs op basis van de SLA bepaald. De onderhandelingen zijn vaak prijs gestuurd, het moet zo goedkoop mogelijk.

Dan zie je vaak dat de outsource partner later ook de tijden van de SLA aan houdt en vaak geen snellere service biedt. Ben bang dat het beleid is, dat ze de toekomstige onderhandelingen in het achterhoofd hebben, zodat ze een beter contract kunnen afsluiten indien een snellere service gevraagd wordt.

[Over Revy]

Dr Evil.

[richard1074]

Inderdaad worden sommige zaken gewoon te ingewikkeld. Dat zie je overal. Men wil steeds meer toeters en bellen in de software hebben waardoor je steeds meer afhankelijkheden maakt.
Soms wordt het zo ingewikkeld dat men gewoon niet meer weet waar het moet zoeken.
Ik verwacht dat dit steeds erger wordt en we richting een algehele blackout gaan ergens in de komende jaren.

[theduke1989]

Maar ja is ook wel logisch.

Als jij bij je huidige werkgever meer geld wilt verdienen. Moet je dus een gesprek aangaan. Aantonen waarom jij meer zou moeten verdienen. Wat heb je al die tijd gedaan dat je meer geld zou moeten verdienen etc.

Het is daarom dan ook veel makkelijker voor iemand om ergens anders voor het zelfde werk meer te vragen tijdens de job interview.
Zonder dat ze al die vragen stellen aan je.

[schrikbeeld]

@REDSD Je noemt een paar moderne IT-systemen als AWS, Azure. Grote kans dat deze niet de oorzaak van deze storingen zijn.
Er werken bij ons nog wel eens ingehuurde die ook bij NS/Prorail hebben gewerkt en die weten vrijwel zonder uitzondering te zeggen dat daar nog heel veel systemen op oude OS-en en oude db's draaien. Gaat er dan een keer wat mis dan heb je inderdaad vaak de backups nodig want kennis ontbreekt vaak van oude systemen. Mogelijk is dit ook de reden dat er geen verdere uitleg wordt gegeven want welk bedrijf wil nu nog in het nieuws komen met storingen in Oracle 7 of Windows 2003?

[Brent]

IT is core in elke org waar vernetwerkte computers essentieel zijn. Expertise moet je dus in house hebben en houden, anders krijg je die momenten dat iedereen ziet dat je je eigen broek niet kunt ophouden vaker en vaker.

[carbidsjitter]

Je ziet het niet alleen met werk, maar bv. ook met abbonementen, verzekeringen etc: maar trouw zijn of een trouwe klant zijn kost jezelf geld, eigenlijk zou dat beloond moeten worden in de 'ideale' wereld. Zo nu en dan switchen bespaart je veel geld of verdien je meer geld.

[[NUT]]

Volgens de directeur van ProRail hebben ze pas om 3 uur vannacht besloten te gaan uitwijken, van Amsterdam (hoofdlocatie) naar Utrecht (backuplocatie). Ik denk dat ze nog wel eens mogen gaan kijken naar die uitwijk procedure. Ze testen de backup elke 3 maanden aldus meneer de directeur, dat wil dus zeggen dat ze met enige zekerheid weten dat die draait, werkt en bruikbaar is.

Ik snap dat je liever op de hoofdlocatie blijft om zo veel redenen maar waarom moet er dan bijna 8 uur gewacht worden voor besloten word om feitelijk uit te wijken naar Utrecht? Waarom word de uitwijk na een uurtje troubleshooten (en dat vind ik dus al aan de lange kant) niet gewoon alvast online gebracht en met een minimale bezetting bemand? Dan kan je veel sneller overstappen en heb je minder druk op de reparatie poging van de hoofdlocatie, alles rijd immers gewoon door in de tussentijd, zo nodig met minder treinen voor de werkdruk van de backup maar alles blijft dan in grote lijnen gewoon in beweging...

Je hebt de backup locatie... waarom dan dus pas zo laat inzetten?

( bron van de uitspraken van de directeur )

[Reactie gewijzigd door [NUT] op 22 juli 2024 16:47]

[Boneshock]

Die uitwijk locatie is normaal de opleidingslocatie voor nieuwe treinverkeersleiders. Het ombouwen van simulator naar een echte werkplek vergt wat tijd en je neemt capaciteit weg van de opleidingen. Op het moment dat de storing zich voordeed was het waarschijnlijk al niet meer mogelijk om de uitwijklocatie draaiende te hebben vóór einde treindienst. Dan is het leuk als je om 01:00 up en running bent, maar als de NS dan zegt "wij rijden nu geen treinen meer" dan heeft het weinig nut gehad om meteen tot uitwijken over te gaan.

[[NUT]]

Ik zie daar een vreemde reden. Een opleiding kan niet voor gaan op het draaiende houden van een dienst met een samenleving ontwrichtende storing. Daarnaast, op zondag lijkt me dat er geen opleiding actief is?

Maar goed, okay, het is een simulatie omgeving, moet omgebouwd worden. Waarom niet daar dan al mee beginnen na 30 minuten volle downtime voor de hoofdlocatie? Ik bedoel, ja je doet het misschien voor niets maar serieus... dat is echt veel minder pijnlijk dan 8 uur lang een volledige verstoring in en om Amsterdam en op de langere termijn dus ook in de ochtendspits de volgende dag, naast materieel wat nu nog steeds niet staat waar het volgens de planning had moeten zijn. Het kan zo veel minder heftig door sneller te acteren op de storing. Ja joh, je kan ook wel eens te snel zijn met overstappen en had het misschien niet nodig geweest... jammer dan? Dat lijkt me toch echt wel goedkoper dan de schade die het nu heeft gedaan...

[Jordy141]

De back-up locatie zal ook niet actief in gebruik zijn geweest voor de opleiding toen de storing zich voor deed. Dat neemt echter niet weg dat het tijd kost om de locatie klaar te maken om een andere regio in het land te besturen, en om treinverkeersleiders op die locatie te krijgen die bevoegd zijn om de infrastructuur rondom Amsterdam te mogen besturen. Het spoor is namelijk opgedeelt in allerlei kleine "stukjes" of werkplekken, en voor elke werkplek moet bevoegdheid behaald worden om die te mogen bedienen. Voor het spoor rond Amsterdam heb je afhankelijk van de drukte al snel 4 tot 8 treinverkeersleiders nodig die de verschillende stukken spoor kunnen bedienen. Dat alleen al organiseren en naar de verkeersleidingspost brengen kost tijd.

Daar komt dan ook nog bij, dat vanwege de opzet van de systemen, het overdragen van die controle van de één naar de andere verkeersleidingspost en het operationeel maken van de back-up locatie tijd kost. Zo uit m'n hoofd al gauw 2 a 3 uur. En gedurende die tijd kan geen van beide verkeersleidingsposten het spoor bedienen. Daarom wordt ook niet snel tot overschakelen naar de back-up locatie overgegaan, want als de IT-afdeling bij ProRail denkt de verstoring in 1 a 2 uur op te kunnen lossen, dan wil je juist niet overschakelen. Dat kost alleen maar tijd.

[kodak]

Een backuplocatie is niet bedoeld om voor andere zaken te gebruik en daarmee gebruik van de backupvoorzieningen zelf te belemmeren.

Ook is vandaag nogmaals duidelijk geworden waarom je niet te lang moet wachten: de storing zal er niet zomaar korter door duren. Ze schijnen het omschakelen al 10 jaar meerdere keren per jaar te oefenen. Dan mag wel verwacht worden dat ze in staat zijn dat alvast op te starten als de officiele post nog probeert op te starten.

[FONfanatic]

Volgens diezelfde directeur van ProRail kost het opstarten van die backup locatie vier uur en had men dan in de tussentijd treinen die nog op hun trajecten stonden niet naar hun eindhalte kunnen laten rijden.

[koenieee]

Er staat al veel klaar, het is niet de software die moeilijk te verplaatsen valt. Dat is een paar klikjes.
Het is alle configuratie (netwerk, firewalls etc) eromheen om van de ene verkeersleiding post naar een andere post over te stappen. Daarnaast heb je een heleboel procedures en failovers, wat ook weer extra risico met zich meebrengt dan kijken of je de problemen terplekke kan oplossen.
Én alle treindienstleiders moeten ook verplaatst worden van Amsterdam naar Utrecht.
Al met al wel mooi dat er een uitwijkpost en functionaliteit beschikbaar is en dat alles uiteindelijk met veel inzet van allen betrokkenen weer up en running is
Eventueel voor de volgende keer wat eerder besluiten, maar al niet met al niet slecht!

[erwinwernars]

Wat ik wel erg vindt is dat wanneer dus amsterdam plat ligt, ook de treinen op andere trajecten volledig niet rijden. Je zou ze ook tot aan de randstad kunnen laten rijden en dan weer terug als het een storing in amsterdam betreft.

[wildhagen]

Dat hangt van veel zaken af. Dan moet er op het tijdelijke eindpunt wel voldoende ruimte zijn om al die treinen op te stellen. Dat is lang niet overal het geval namelijk.

Daarnaast staat veel materieel én personeel natuurlijk vast in Amsterdam, waardoor er misschien weer te weinig materieel/personeel aanwezig is voor die extra treinen.

Daarnaast zit je met het punt dat die treinen dan op afwijkende tijden gaan rijden (ze hebben immers een kortere route). Daar moet wel ruimte voor zijn op het spoor, dat toch al vrij drukbezet is. En dat is dan nog los van eventuele werkzaamheden, die ook vaak in een weekend plaatsvinden.

En als laatste heb je dan personeel wat hun standplaats mogelijk niet kan bereiken (die hebben immers zelf óók last van de storing!), wat de inzetbaarheid van datzelfde personeel nog verder beperkt.

Het is niet zo makkelijk als het klinkt om "even" een alternatieve dienstregeling in elkaar te sleutelen. Er wordt niet voor niets ruim een jaar aan een dienstregeling gewerkt en gepland etc. En in een weekend is dat, door de lagere bezetting, nóg lastiger.

[Reactie gewijzigd door wildhagen op 22 juli 2024 16:47]

[MrE]

Dit is niet de eerste keer dat er zo'n storing plaatsvind. De NS had dit soort punten natuurlijk al veel eerder kunnen bouwen.
De grap vind ik dat ik, als ik naar de verhalen van een oude spoorwachter luister, de NS dit vroeger wel had. Maar na de privatisering en de daarmee gepaard gaande opsplitsing is ten gevolge van lean and mean denken teveel aan de kant geschoven of onduidelijk gebleven wie waarvoor verantwoordelijk was.
Daardoor zijn zaken die goed geregeld waren in het slob geraakt en afgedankt.

[wildhagen]

Dit is niet de eerste keer dat er zo'n storing plaatsvind. De NS had dit soort punten natuurlijk al veel eerder kunnen bouwen.

Helaas, maar nee. De NS kan dit niet, omdat zij alleen een vervoerder zijn, zij beheren de infra niet. De infra is in beheer, en eigendom, van Prorail. Denk aan de sporen, overwegen, wissels, bovenleidingen, seinen en delen van de stations, de verkeersleiding, en nog wat andere zaken.

Dus als Prorail daar niet in wil investeren houdt het op en kan de NS dus niks meer doen.

Zeker in de randstad is grond ook nog eens gruwelijk schaars en duur, dus dit zijn hele duren grappen om opstelplekken te gaan maken die zeer zelden nodig zijn, maar wel enorm veel ruimte kosten. Daar is simpelweg geen geld en ruimte voor.

[CivLord]

Dat. En je wil alle passagiers van een volgepakte intercity niet uit laten stappen op klein stationnetje waar normaal gesproken enkel een boemeltje stopt, ook al is er op papier een goede busverbinding naar het centrum van Amsterdam.

[Maurits van Baerle]

Inderdaad, het laatste uur van de dag (vaak na het einde van de publieke dienstregeling) is extreem belangrijk om al het materieel op de plek te krijgen waar het de volgende ochtend weer moet beginnen. Daarom is het niet ongebruikelijk dat je soms de volgende ochtend nog last hebt van een storing die de vorige dag al verholpen was.

[Cergorach]

30 jaar treinreiziger: Als Amsterdam plat ligt, heeft dat impact op een aantal trajecten in de rest van Nederland. Als Utrecht plat ligt, ligt over het algemeen heel Nederland plat. Er zijn bepaalde punten waar extreem veel treinverkeer overheen gaat, als daar geen treinen vertrekken, dan zijn die treinen uren later niet beschikbaar aan de andere kant van Nederland en kunnen dan dus niet worden ingezet op andere trajecten. Het is echter niet alleen de treinen, maar ook het personeel. Dat is een puzzeltje welke je in roostert en je kan wat uitval faciliteren, maar niet de algehele uitval van grote regio's, niet op korte termijn en zeker niet in het weekend.

En leuk als ze kunnen rijden tot station X, Weesp is zo een gevalletje. Sta je in Weesp, en wat dan? Je staat daar met heel wat andere mensen, regulier busverkeer trekt een dergelijke influx van passagiers niet, net als de taxis. Zelfs voor personenvervoer die dan mensen komen ophalen/droppen is het opeens een filepark (heel wat keren gestrand op Weesp de afgelopen 16 jaar omdat er net even voorbij Weesp heel wat storingen optraden).

[glennoo]

Toch wel frappant dat een dergelijk grote partij op zo’n cruciale locatie gewoon doodleuk zegt “regel zelf maar wat” ipv mee te werken aan een tijdelijk oplossing. Ik denk dat dit ze nog een flink kostenplaatje mee kan brengen, al helemaal met het concert gisteren.

[n4m3l355]

Ik vind dat eigenlijk nog het raarste in het geheel. Het is niet alsof dit nooit voorkomt en vervolgens weet men voor treinreizers geen vervoer te regelen? Hier slaat de NS en Nederland richting de veelal touristen die hier gebruik van maken toch wel een gigantische flater.

Wat ik niet snap en het is anecdotisch, maar hoevaak specifiek Schiphol problemen heeft met de trein. Ik maak wel geteld 2-3 keer per jaar vanuit Schiphol gebruik van NS en dan heb ik toch met enige regelmaat op Schiphol zelf of op de weg naar het Zuiden problemen met de trein. Dit staat in geen verhoduing met de statistieken die de NS zelf vrij geeft maar neemt niet weg dat ikzelf toch vaak wel pech met ze heb.

[Gizz]

Ik vind dat eigenlijk nog het raarste in het geheel. Het is niet alsof dit nooit voorkomt en vervolgens weet men voor treinreizers geen vervoer te regelen?

Maar hoe dan precies? Dit gaat niet over een paar treinen die uitvallen, je hebt het eerder over 100.000 reizigers (als het al niet veel meer is) waarmee je 1500 touringcars kunt vullen.

Treinen zijn goed in gigantische hoeveelheden mensen transporteren. Daarom hebben we die dingen. Voor 1 intercity heb je 7 bussen nodig voor alleen de zitplaatsen (413 mensen), terwijl in de spits natuurlijk veel meer mensen in een trein aanwezig zijn dan het aantal beschikbare zitplaatsen. Voor treinuitval op deze schaal bestaat daarom niet direct een eenvoudig centraal organiseerbaar alternatief, denk ik

[Reactie gewijzigd door Gizz op 22 juli 2024 16:47]

[glennoo]

Ik begrijp je punt. Maar bij mij komt het niet helemaal lekker binnen. Een woordvoerder van de NS gaf ook aan “het zijn zulke grote hoeveelheden dus we zetten gewoon niks in” maar je kunt toch op zijn minst de meest drukke trajecten wat verlichtten? Zou lekker zijn als er een flinke ramp in Amsterdam gebeurd waardoor een veel gewonden zijn en de ziekenhuizen zeggen “ja het zijn zoveel gewonden dus we doen gewoon helemaal niks”. Of dat we maar besluiten om de zorgtoeslag te stoppen want “niet alles is ermee opgelost”. Iets van een steuntje zou helpen maar nu laat de NS even mooi zien dat het OV enorm onbetrouwbaar is.

[Andros]

Je vergelijking gaat wat mank aangezien gestrande reizigers niet direct in levensgevaar zijn. Bij te grote verstoringen ga je niet direct vervangend vervoer kunnen regelen. Zoals iemand hier al aanhaalde heb je grote aantallen bussen nodig om uberhaupt 1 intercity te kunnen vervangen. Stel dat je 7 touringcars laat voorrijden voor een enkele rit van Amsterdam naar Utrecht waar normaal pakweg 400 man op die trein zou zitten. De storing duurt al enige tijd dus je gaat al rustig 1000 man voor je neus hebben staan bij die touringcars aangezien er al meerdere ritten zijn uitgevallen. Een andere groep van nog eens 1000 man die richting Rotterdam wil ziet die touringcars komen en gaat kijken waar ze heen gaan. Sommigen denken verder en willen ook mee naar Utrecht in de hoop daar weer een trein naar Rotterdam te kunnen halen.

Een dergelijke mensenmassa gaat op een gegeven moment gewoon gevaarlijk worden. Die mensen zijn al niet blij, sommige gefrustreerd en je gaat nooit genoeg vervangend vervoer kunnen regelen om al die mensen normaal weg te krijgen. Je kunt zoiets opvangen bij geplande werkzaamheden of als er onverwacht een enkel traject uitvalt. Een groot knooppunt als Amsterdam-Centraal of zelfs een landelijke storing zoals al een paar keer is gebeurd los je niet op met bussen te laten komen, dan slaat de vlam gewoon in de pan bij de achterblijvers. Daarvoor is het aantal gedupeerden simpelweg te groot en is het veiliger om zoals nu veldbedjes en andere zaken te regelen.

[dcm360]

'De druk iets verlichten' klinkt als concept wel prima, maar sneuvelt als je gaat nadenken over de praktijk. Als er 500 mensen staan te wachten, en er komt 1 bus, dan krijg je absolute chaos. De NS heeft in het verleden genoeg nare ervaringen opgedaan met veel te weinig bussen inzetten dat in situaties als deze geen bussen inzetten ruim beter is voor de algemene orde en veiligheid voor zowel het personeel als de reizigers.

[hellred666]

Ik heb wel eens knockpartijen gezien tussen mensen omdat zij graag het laatste plekje in de bus wilden hebben en niet nog eens 10 minuten wilden wachten. Dit was dan op een moment dat het niet heel druk was. Ik kan mij inbeelden dat dit op grote schaal met mensen die gehaast zijn om bij een concert te komen dit snel kan escaleren. Denk dat de NS hier de juiste keuze heeft gemaakt, en ja dat is heel vervelend voor een hele grote groep mensen maar we moeten niet doen als of dit een gigantische ramp is oid.

[Cergorach]

Ik begrijp je punt. Maar bij mij komt het niet helemaal lekker binnen. Een woordvoerder van de NS gaf ook aan “het zijn zulke grote hoeveelheden dus we zetten gewoon niks in” maar je kunt toch op zijn minst de meest drukke trajecten wat verlichtten?

Heb je wel eens in zo een massa gestaan? Een bepaalde groep mensen zijn al snel niet vriendelijk en absoluut aso als de volgende lege bus aan komt rijden en schermutselingen zijn niet ondenkbaar. Helemaal als er niet voldoende bussen zijn. En dat zijn mijn ervaringen op uitval op een enkel traject. Moet je nu voorstellen dat alle trajecten in en uit Amsterdam plat liggen, daar gaat men NOOIT genoeg bussen voor hebben, zeker niet op zondagavond/maandagochtend.

En laten we wel wezen, als er wordt gezegd dat er geen vervanging is, zullen veel meer mensen thuisblijven op maandagochtend dan dat als ze een stille hoop hebben een stuk met de bus te kunnen... Ik hoop althans dat dit vanochtend vroeg al op de 9292 app stond.

[SunnieNL]

Onmogelijk gisteravond. Er waren 2 concerten in de Bijlmer Arena omgeving. Die bezoekersstromen kun je onmogelijk met bussen regelen. Dan heb je een busfile van utrecht naar amsterdam om al die concertbezoekers daar af te zetten en 's avonds weer met ophalen. Waar laat je daarnaast al die bussen en hoe krijg je die mensen er fatsoenlijk in.

Bij een ramp in amsterdam komen de ambulances vanuit alle regio's in NL en worden de wegen afgezet. Dat is in het geval van treinen die uitvallen wel ff anders. (anders komen de concertgangers met de auto weer in de problemen)

[Reactie gewijzigd door SunnieNL op 22 juli 2024 16:47]

[michelr]

Ietwat kort door de bocht geredeneerd vanachter je toetsenbord.

[segil]

Alleen zullen die 100.000 reizers niet allemaal de hele nacht gestrand zijn, toch? Een groot deel kan wel z'n eigen weg vervolgen met bussen, taxi, vrienden die komen halen, lopend, whatever. En dat blijft er een kleiner deel over dat nog vervoer nodig heeft.

Wederom niet de beste kant van de NS die we te zien krijgen.

[Horatius]

Oke dus wanneer ga je die bussen laten rijden? 3 uur snachts? Dan zullen de meeste mensen zelf wel iets geregeld hebben dus zou NS misschien iets kunnen doen.

Hoeveel onvrede zorgt het ervoor als ze pas om 3 uur snachts tourbussen laten rijden? Gigantisch.

[StefanJanssen]

Er is de mogelijkheid om 30km/h te rijden zonder communicatie met de spoorleiding. Dit werd in het verleden wel eens geopperd door machinisten, maar is volgens mij nooit bij een dergelijke storing gebeurd.
Als je vanaf centraal, elk kwartier een trein laat vertrekken kun je dit erg veilig voor elkaar krijgen zonder enige systemen nodig te hebben bij de spoorleiding.

[IJzerlijm]

Klinkt als een goeie manier om de storing langer te laten duren. Want als eenmaal de systemen hersteld zijn staan een hoop treinen opeens ergens anders dan waar ze stonden voor de storing.

[Danos9786]

Tja al staan alle treinen nu ook al op de verkeerde plek als ze weer opstarten. Denk dat dit per saldo niet veel uitmaakt behalve dat je een gedeelte van het gezeur niet hebt.

[IJzerlijm]

Misschien hebben ze bij de NS/Prorail daar beter zicht op. Of misschien hebben we het hier veel beter door dan zij, wie zal het zeggen?

[Danos9786]

Ja geen idee maar ja ze geven het zelf al aan dat nu bij de opstart alles op de verkeerde plek staat.

[SunnieNL]

Dat is natuurlijk afhankelijk van de storing die je hebt.
Als er een seinstoring is, kan dat vast wel... maar op het moment dat je visueel verliest waar alle treinen zijn is zelfs dat onmogelijk. Dat is zoiets als zeggen "als de verkeerstoren van schiphol er uit ligt kunnen die vliegtuigen als ze langzaam vliegen wel gewoon landen en opstijgen"

[CivLord]

En die langzaam rijdende treinen komen dan op enig moment aan in het gebied waar de verkeersleiding nog wel werkt. Die moet er dan tussen geschoven worden terwijl er op dat moment ook andere treinen (uit andere richtingen) rijden. Dan krijg je een chaos waarmee binnen de kortste keren het hele land plat ligt.
En zelfs wanneer het zou werken, doet die trein 4 maal zo lang over het af te leggen traject, waardoor hij maar één keer per uur heen-en-weer kan rijden, terwijl hij het anders elk kwartier had gedaan. Dat doet weinig om de druk op de perrons te verlichten wanneer net twee grote concerten aflopen.

[StefanJanssen]

Als je bedenkt dat het spoor tussen Amsterdam en Den Haag elke 5 minuten een trein heeft rijden, lijkt het me dat het eens per kwartier of half uur niet zo'n groot probleem zou moeten zijn met die snelheden?

Nogmaals, dit is niet mijn idee maar die van machinisten en spoorleiding, ik ga er vanuit dat die wel weten wat wel en niet mogelijk is?

[wildhagen]

Precies. Het is gewoonweg echt de onwillendheid van NS dat dit niet gebeurt.

De storing zit niet bij NS, maar bij Prorail.

Daarnaast las ik gisteren in een nieuwsbericht dat telefonisch contact tussen machinisten, en dan heel langzaam rijden in dit geval geen realistische werkbare optie was ivm de enorme hoeveelheid treinen.

Vergeet niet dat dat ENORM veel telefoontjes betekent, waardoor machinisten afgeleid worden. Dat brengt óók weer veiligheidsrisico's met zich mee. Zelfs met lage snelheid kan er grote schade ontstaan mocht het fout gaan omdat bijvoorbeeld een machinist afgeleid is door een telefoontje.

Het heeft dus niks met onwil te maken, maar met realistische en praktische zaken.

[Reactie gewijzigd door wildhagen op 22 juli 2024 16:47]

[cordonbleu]

en dan heel langzaam rijden in dit geval geen realistische werkbare optie was ivm de enorme hoeveelheid treinen.

Daar kan ik in komen. Maar dan kan het dus wel als ze minder treinen laten rijden? Dat is dan toch denken in oplossingen. Dan kan niet iedereen gelijk mee, maar dat hoeft ook niet. Je kan uiteindelijk wel op bestemming komen. Daar gaat het om.

[Estel]

Het gaat veel verder dan dat. Je zit ook met materieel wat beschikbaar moet zijn op de juiste locatie. Het is nu behoorlijk goed op elkaar afgestemd dat over het algemeen het juiste materieel en de juiste hoeveelheden aanwezig zijn. Als je het op deze manier min of meer op de bonnefooi gaat aanpassen, ben je een halve tot een hele dag daarna nog bezig om dit weer recht te breien.

[Yankovic]

Niemand 's nachts thuis kunnen brengen of een keer wat harder moeten werken om alles weer in de perfecte planning in te passen.
Dan kan je toch beter de volgende dag een paar treinen over het hele land laten uitvallen en een dag later maar weer normaal te rijden lijkt me

[Estel]

Ik snap je reactie, maar dat is echt te kort door de bocht. Heeft niets met harder werken te maken. Dat kost gewoon heel veel tijd om te regelen en uit te voeren. Ook is het aantal machinisten beperkt en moeten die goed uitgerust zijn natuurlijk.

[Yankovic]

Je hebt zo'n 6 uur de tijd en aan uitgeruste machinisten echt geen tekort met het aantal treinen dat is uitgevallen. Je hoeft alleen maar in elke richting 1 hele lange trein te sturen. Dat kost je 1 of 2 machinisten per trein en wat conducteurs voor de service.

Hoeveel treinen gaan er in een normale dienstregeling wel niet van/naar een rangeerterrein om af/aangekoppeld te worden. Als je de puzzel gemaakt hebt en een plan klaar hebt hoeft het toch geen avond te duren om 5-6 lange treinen klaar te hebben staan op Amsterdam CS om op z'n minst 1 of 2 keer heen en weer te pendelen naar een gebied waar wel een werkende treinverkeerspost zit?

Ik snap wel dat ze dit niet doen gezien je eerst nog 4 andere plannen hebt liggen die het verkeer mogelijk wel normaal kunnen opstarten en het dan te laat is om zoiets uit te voeren. Maar ik geloof niet dat het onmogelijk is als je 4 a 6 uur voor het eind van de dag zeker zou weten dat er niks meer zou gaan rijden

[Estel]

Toch wel. Je machinisten moeten ook uitgerust zijn om de dienstregeling weer te hervatten. Daarnaast wordt het spoor, vooral 's nachts, erg veel gebruikt voor goederenvervoer. Ook hierdoor is het behoorlijk lastig in te plannen. Ik zou bijna zeggen, draai eens een dagje mee bij de NS en/of ProRail. Dan zie je dat het soms beter is om helemaal niet meer te rijden. Geloof me, dit kost ze ontzettend veel geld en is geen lichtzinnige beslissing.

Hele lange treinen klinken leuk, maar zijn niet de oplossing. Vergeet ook niet, dat het niet het hele land is wat er last van heeft, maar juist de twee grootste knooppunten.

[StefanJanssen]

Laat dan de helft van de treinen rijden, zet twee machinisten op elke trein en laat 1 de communicatie regelen. Er zijn altijd wel mogelijkheden, maar vaak zijn die mogelijkheden in het nadeel van de NS. Als ze een trein laten rijden is er sprake van een uitval voor de statistieken die invloed hebben op volgende aanbestedingen. Als er niets rijdt valt dit onder een aparte statistiek die geen invloed heeft op de aanbesteding.

[xFeverr]

In hoeverre heeft dit een nadeel voor NS? Deze storing is voor alle vervoerders die die regio bedienen. Lijkt mij niet dat een storing van ProRail nadelig is voor NS, want Arriva, Flixtrain, DB, Connexxion en wieweetnogmeer kunnen dan ook niet rijden.

[StefanJanssen]

Omdat NS in dat geval blijkbaar nog wel kan werken. Dit is wat mij bij eerdere grote storingen door NS personeel tegen mij is gezegd.

[ShadLink]

De storing zit niet bij NS, maar bij Prorail.

Dit is gewoon niet waar. NS is wettelijk verplicht betalende klanten van A naar B te brengen. Als ProFail een probleem is dan moet NS alternatief vervoer leveren. Denk bv aan een Bus.

[wildhagen]

Wat jij zegt is inderdaad niet helemaal waar, dat klopt.

Ten eerste, zit de storing dus wel degelijk bij de verkeersleiding, en die valt onder Prorail. Niet onder de NS.

En over die thuisbrengplicht:

De thuisbrengplicht is enkel toepasselijk als blijkt dat er bij vertrek of aankomst vertraging is. Dit is nu niet van toepassing, omdat de hele rit nog niet eens vertrokken is. We geven nu al aan een alternatief te zoeken. De thuisbrengplicht komt daarmee dan ook te vervallen.

Zie https://community.ns.nl/w...ng-zijn-geannuleerd-74137

(dit is een algemene quote, niet specifiek voor deze storing)

Dat geld dus alleen voor de mensen die al onderweg waren. Mensen die pas incheckten nadat de storing ontstond (en waar de rit dus nog niet vertrokken was), vallen daar dus niet onder. Als men dan iets regelt is het uit coulance, geen verplichting.

In de Algemene Vervoersvoorwaarden van de NS, sectie 6.3 staat ook dit relevante stukje:

Het kan zijn dat NS niet in staat is om vervangend vervoer
aan te bieden. Hiervan is bijvoorbeeld sprake bij massale
uitval van treinen, of wanneer uw eindbestemming
redelijkerwijs niet meer bereikbaar is (zoals bij afgesloten
wegen of als u reist naar een Waddeneiland). In een
dergelijk geval zal NS zich maximaal inspannen om u
kosteloos een slaap- plaats aan te bieden. Als u gebruik
maakt van een papieren Vervoerbewijs, E-ticket of
Eenmalige chipkaart dan kunt u dit omwisselen op de wijze
zoals beschreven in artikel 6.2.

Van een massale uitval is hier wel sprake.

[ShadLink]

Als ik een pakketje bij Bol.com bestel en door een storing bij PostNL kan het pakketje niet geleverd worden. Wie is er dan schuldig? PostNL of bol.com.

Antwoord is heel simpel, ik als klant ga een koopovereenkomst aan met bol.com. ZIJ moeten ervoor zorgen dat ik het pakket ontvang. Dat zij daarvoor PostNL inhuren is niet mijn probleem. Zelfs niet als ze dat in hun algemene voorwaarden zetten!!!

Waarom zou dit hier anders zijn? Betalende klanten dienen gewoon de service te krijgen waarvoor ze een koopovereenkomst zijn aangegaan.

Hier is maar 1 partij schuldig: NS. Zij moeten mensen van A naar B brengen en weer terug. Niet ProRail. Het eeuwige afgeschuif op ProRail moet echt eens stoppen.

[Reactie gewijzigd door ShadLink op 22 juli 2024 16:47]

[StefanJanssen]

Een aantal grote verschillen:
1. Je betaald bij de NS pas bij het uitchecken.
2. De storing stond aangegeven voordat je de overeenkomst aanging.

Voor de mensen die al aan het reizen waren is de NS verplicht om ander vervoer te regelen, voor de mensen die daar hun reis begonnen heeft de NS geen verplichting.

[lenwar]

1500 is allicht wat overdreven. Die 100.000 is niet tegelijk natuurlijk, maar verdeeld over zoveel uur. Maar inderdaad. Al zou je de bussen hebben. Je moet ook nog de poppetjes voor in die bussen hebben.

[StefanJanssen]

Er waren twee concerten, in de ArenA en de AFAS Live (Harry Styles en Ghost respectievelijk). Deze concerten waren goed voor zo'n 70.000 mensen.
Harry Styles was afgelopen om 22:45
Ghost was afgelopen rond 00:15

Dat is nog geen 2 uur tussen de 2 grote stromingen van concertgangers.

[AMD and INTEL]

Same hoor, neem vanaf Limburg vaak de trein en zeker de helft van de tijd kom ik met een halfuur of meer vertraging de randstad aan. Je zou in een land als Nederland toch wel verwachten dat je beter kan vertrouwen op het OV.

[bonzz.netninja]

volgens statistiek niet (https://www.nsjaarverslag...ailnet--hsl/punctualiteit)

Of maw. het is in NL echt wel heel goed geregeld. Moet je eens in duitsland een trein proberen te pakken....

[Andros]

Statistieken houden geen rekening met gemiste overstappen en geschrapte treinen tellen niet als vertraagd. Ook een vertraging die onderweg ingelopen wordt door hogere snelheid of kortere stops zal op tijd op het eindstation aankomen maar reizigers kunnen toch vertraging oplopen. Het is maar net hoe je de cijfers uitlegt.

[EDIT]

Statistieken houden daar gelukkig juist wel rekening mee. Tegenwoordig wordt namelijk de reizigerspunctualiteit als een van de belangrijkste KPIs gebruikt, niet meer de treinpunctualiteit waar jij het over hebt. De reizigerspunctualiteit betreft vertraging van de gehele reis van de reiziger, inclusief overstappen, uitval etc. Als de reiziger binnen 5 minuten van de geplande aankomsttijd op het eindstation aankomt geldt deze als 'op tijd'.

Je kan dit zelf allemaal volgen en vinden op https://kpi.prorail.nl/re...years&lang=nl&spec=hrn05#

[n4m3l355]

Diezelfde website geeft op dit moment AMS Schiphol naar AMS slechts 85% op tijd aan. En dit is op een redelijk recht-toe recht-aan verbinding. Het frappante is als ik kijk naar AMS Schiphol - Maastricht ligt deze slechts op 84%. Dus over zoveel meer verbindingen en overstappen verliest slechts 1%. Ergens klopt dit voor mij gewoon niet qua data.

Ik kan me overigens vergissen maar in geval van uitvalt wordt deze niet meegeteld als vertraging. Het is natuurlijk ook raar dat een semi-publiekelijk bedrijf waarvan de leiders afhankelijk zijn qua bonus van punctualiteit dat zij deze punctualiteit zelf constateren. Het zou veel beter zijn als dat door bijvoorbeeld de ANWB gebeurde.

[EDIT]

Wat ik al zei: uitgevallen treinen tellen gewoon mee bij reizigerspunctualiteit. Je ziet het al aan de naam, reizigerspunctualiteit. Oftewel: hoe stipt is de reiziger. Als een trein uitvalt of een overstap de mist in gaat, dan is die reiziger uiteraard niet meer punctueel.

Schiphol is een van de drukste stations in Nederland qua aantal treinbewegingen en het traject Amsterdam - Schiphol loopt al te piepen en te kraken met de hoeveelheid treinen die er overheen gestuurd wordt, ook omdat je een samenloop hebt van lijnen. Niet alleen bij Amsterdam Centraal zelf, maar ook bij Sloterdijk en vervolgens bij Riekerpolder aansluiting (vanuit de richting Amsterdam Zuid). Het traject is daardoor heel erg kwetsbaar voor vertragingen en dat zie je in de statistieken ook terug. Daarnaast heb je op zo'n korte lijn minder kans om vertragingen in te lopen, wat natuurlijk op een langere afstand veel eenvoudiger gaat.
Overigens verschilt de reizigerspunctualiteit per richting. Van Amsterdam naar Schiphol kwamen de afgelopen 12 maanden ruim 88% van de reizigers met minder dan 5 minuten vertraging aan, en 97,7% met minder dan 15 minuten. De andere kant op inderdaad iets minder, met 84,6% op 5 minuten en 97,4% op 15 minuten.

De data is overigens openbaar. Als je ProRail niet gelooft, dan kan je zelf real-time ook gewoon de reizigerstreinen volgen en zelf de punctualiteit berekenen als je dat wilt. Er zijn genoeg andere partijen die dat ook al doen of hebben gedaan.

[Reactie gewijzigd door EDIT op 22 juli 2024 16:47]

[n4m3l355]

Dit is niet helemaal juist.

Zo wordt er enkel gemeten van 06:30 tot 23:00. Daarnaast wordt er jaarlijks gekeken welke lijnen meetellen en welke niet. De belangrijkste is echter dat de gestelde 5 minuten of 15 minuten tussen instappen en uitstappen wordt berekend. Met andere woorden valt de reis uit, telt die niet mee. Dit zie je overigens onder HRN regelmaat terugkomen. De regels zijn 20 paginas lang en laten heel veel ruimte voor de NS.

[EDIT]

Die beweringen zie ik graag onderbouwd met een bron, want dat gaat namelijk in tegen de uitleg van de KPI reizigerspunctualiteit.
Zoals ook op de eerder genoemde website staat: De reizigerspunctualiteit wordt berekend op basis van de in- en uitcheckgegevens van de OV Chipkaarten, waarbij de afgelegde reis qua in- en uitchecktijden vergeleken wordt met het reisadvies zoals deze twee dagen ervoor in de reisplanner stond.
Valt een trein uit of heeft deze vertraging/lukt een aansluiting niet, dan zal de reiziger dus later uitchecken dan verwacht en is dat dus in de data zichtbaar.

[Reactie gewijzigd door EDIT op 22 juli 2024 16:47]

[n4m3l355]

https://www.google.com/ur...Vaw1n-upvEmJDgUMkxZhjcrox

[EDIT]

Dank je wel voor het bevestigen van wat ik typte
In dat document staat exact wat ik al typte:

Reizigerspunctualiteit 5 minuten HRN
Definitie
Reizigerspunctualiteit 5 minuten HRN geeft een indicatie van het percentage van de reizen dat met minder dan 5 minuten vertraging is verlopen tussen een HRN vertrek- en HRN aankomststation. Dat wil zeggen dat de reiziger bij aankomst op zijn uitcheckstation minder dan 5 minuten vertraging had ten opzichte van de reis die de reiziger vanaf het moment van inchecken volgens de reisplanner had kunnen maken.
Berekeningsmethodiek
Voor iedere reis binnen de scope wordt het verschil tussen de beloofde en de gerealiseerde aankomsttijd bepaald. Als het verschil tussen deze tijden minder dan 5 minuten is (<5 min), beschouwen we de reis als op tijd, anders als te laat. De indicator wordt vervolgens berekend door het aantal reizen dat op tijd was te delen door het totaal aantal reizen. Hieruit volgt een percentage tussen 0 en 100%.
Hierin geldt:
• In scope zijn alle reizen met een in- en uitcheck op een HRN station, met NS als enige vervoerder in het reisadvies en waarbij de combinatie van herkomst (incheckstation) en bestemming (uitcheckstation) in de afgelopen 100 dagen op tenminste 20 verschillende dagen en in totaal tenminste 100 keer voorkwam.
• De beloofde aankomsttijd is de aankomsttijd van de snelste reis die een reiziger volgens het vooraf in de reisplanner gepubliceerde reisadvies op het inchecktijdstip kon maken van het incheckstation naar het uitcheckstation.
• De gerealiseerde aankomsttijd is de aankomsttijd van de laatste trein die in dit beloofde reisadvies voorkwam, mits alle treinen hebben gereden en de eventuele beloofde overstappen haalbaar zijn gerealiseerd.
• Bij treinreizen die niet met de beloofde treinen kunnen zijn verlopen, kan de omvang van de vertraging niet worden bepaald op basis van de realisatietijden van deze treinen. Dit gebeurt als een trein niet rijdt, tenminste 15 minuten vertrekvertraging heeft en/of als een overstap niet gehaald kon worden. In dat geval wordt de aankomstvertraging bepaald op basis van de uitchecktijd. Hierbij wordt een stationspecifieke uitstapmarge in mindering gebracht voor de looptijd tussen de trein en de uitchecklocatie.

Dingen die jij noemde komen wel in dat document voor, maar dat gaat om klantonderzoeken/klantoordeel, niet om de KPI reizigerspunctualiteit.

[Reactie gewijzigd door EDIT op 22 juli 2024 16:47]

[n4m3l355]

Nogmaals, lees precies hoe een te late rit is gedefinieerd, bij in en uitchecken. Met andere woorden als men niet uitchecked, is deze niet te laat. Dit is heel precies gedefinieerd met opzet dat juist de vrijheid bestaat om totaal gemiste ritten buiten de statistieken te houden. Daarnaast zoals ik ook al aangaf in het begin van het jaar maakt men een selectie welke ritten wel en welke niet worden opgenomen in de statistieken. Dus men zou moeilijke trajecten gewoon buiten beschouwing kunnen laten.

[Reactie gewijzigd door n4m3l355 op 22 juli 2024 16:47]

[EDIT]

Probeer je nou je eigen beweringen aan te passen?
Er wordt gewoon gemeten tussen 23:00 uur en 6:30, alle lijnen tellen mee (de enige limitatie is dat er 100 reizen moeten zijn gemaakt over tenminste 20 dagen binnen een tijd van 100 dagen), als een reis uitvalt telt die gewoon mee, omdat de reiziger later uitcheckt.
Alleen als er, door een grote verstoring, helemaal geen treinen meer rijden zal het niet automatisch worden meegenomen als mensen dan op een andere manier naar hun bestemming gebracht moeten worden of reizen, echter zijn daar gelukkig gewoon correctiemodellen voor.

[Reactie gewijzigd door EDIT op 22 juli 2024 16:47]

[michelr]

Dus dat. Duitsland heeft wellicht het beeld dat het prima geregeld is, maar als je wat beter kijkt is het ook daar niet alleen maar hosanna. Bijkomend verschijnsel is dat problemen snel uitvergroot worden en soms leiden tot potje ProRail/NS bashen, maar de 97,3% dat het goed gaat staat niet in de krant.

[nst6ldr]

Het hangt er van af waar je naartoe reist, hieronder werd al een voorbeeld gesteld:

https://www.rijdendetrein...centraal-schiphol-airport

Statistieken voor dit traject zijn berekend over de afgelopen 24 maanden.

Tussen 1 juli 2021 en 30 juni 2023 zijn er 470 storingen gemeld op het traject Amsterdam Centraal–Schiphol Airport. Dit is een gemiddelde van 1 storing per dag.

De gemiddelde storingsduur voor storingen op dit traject is 4 uur, 6 minuten.

Als je het dan toch over statistiek hebt:

Tussen 1 januari 2011 en 5 juni 2023 zijn er 46.769 storingen gemeld. Dit is een gemiddelde van 10 storingen per dag.

Deze treinstoringen duurden bij elkaar 14 jaar, 2 maanden, 28 dagen, 16 uur, 51 minuten. Dit betekent een gemiddelde van 1 dag, 3 uur, 30 minuten aan treinstoringen per dag.

De gemiddelde storingsduur binnen deze periode is 2 uur, 40 minuten.

Er vanuitgaande dat er dus bepaalde hotspots zijn, komt het echt wel vaak voor.

[Reactie gewijzigd door nst6ldr op 22 juli 2024 16:47]

[CivLord]

Er zijn net de afgelopen twee maanden een aantal verstoringen geweest waardoor er op een bepaald traject één of twee weken geen treinen konden rijden, door externe oorzaken. Dat trekt de verstoringsduur enorm naar boven. In deze gevallen was er alternatief vervoer of een alternatieve route beschikbaar.
Hetzelfde heb je wanneer er een spoorbrug aangevaren wordt, dan ligt dat traject ook al snel een paar dagen stil voor inspecties en reparaties. Ook dan zijn er alternatieven.
Wanneer je dit soort verstoringen afzet tegen de gemiddelde storingsduur van 2 uur en 40 minuten, betekent dit dat er enorm veel verstoringen zijn die slechts een paar minuten duren.

[lenwar]

Het probleem is natuurlijk dat we hier niets met Duitsland te maken hebben. Het feit dat het ergens 'nog rotter' is, maakt het niet ineens hier beter.

Echter: Dit gezegd hebbende . Als je wereldwijd kijkt naar treinsystemen heeft Nederland inderdaad één van de beste. Zeker als je het combineert/afzet tegen de drukte van het treinnetwerk. Blijkbaar is het gewoon supercomplex om het heel goed te doen.
We kunnen domweg niet anders stellen, dat de spoorwegen, net zoals vrijwel alle andere infrastructuur in Nederland, gewoon van een zeer hoog niveau zijn.
Als je zoiets suggereert roepen mensen gelijk 'Ja, maar in Japan....'. Dan verwijs ik ze altijd even naar de kaart van die treinsystemen waar ze het over hebben. Dat zijn naar verhouding een handje vol treinen die meer weghebben van de Thalys/HSL dan de reguliere treinen in Nederland.

[hackerhater]

De punctualiteit is doorsnee wel in orde ja. Met een paar negatieve uitschieters.
Wat me wel tegenstaat is de zeer slechte informatie-voorziening als het fout gaat.

Zo heb ik eens een keer buiten Utrecht CS gestaan. We moesten ineens allemaal het station uit en 0 informatie-voorziening.
Lang leven smartphones om op te zoeken wat er aan de hand was en dat wachten geen zin had. (toen met die brand in het controle-centrum)
Een overvolle bus gepakt naar Breda en daar de IC naar Den Bosch. De mensen die braaf bleven wachten, mochten dus overnachten op Utrecht CS.

Die andere keer dat de NS me had laten staan in Utrecht vergeef ik ze. Het weer was toen echt slecht.

[Reactie gewijzigd door hackerhater op 22 juli 2024 16:47]

[koenieee]

Het schijnt toch als je in de VS een kaart laat zien van alle treinbewegingen in Nederland dat ze denken dat het een stad met metro is?
Met 1.3 miljoen reizigers per dag en 7000 km spoor doen we het best wel goed
De complexiteit, moeite, tijd, geld en mensen die daarvoor nodig zijn vergeet je wel eens, omdat als alles goed gaat je er niets van hoort.

[lenwar]

Precies dat. En dit geldt eigenlijk voor alle Nederlandse infrastructuur.

Ga maar de grens over (naar het zuiden of het oosten). Je ziet al snel dat de autowegen structureel van mindere kwaliteit zijn (autosnelwegen gaan wel, maar zodra je provinciaal/binnen de bebouwde kom bent, gaat het heel snel de andere kant op).
In Nederland is vrijwel ieder gebouw aangesloten op het waternet en kan je redelijkerwijs uit iedere waterkraan veilig water drinken. In Nederland zie je vrijwel geen elektriciteitskabels/telefoonkabels boven de grond (hoogspanning uitgezonderd). Breedbandinternet is verreweg de meeste regio's van goede kwaliteit (hier valt overigens nog zeker wel wat te winnen). Ons OV-netwerk is gewoon goed. Het is wel wat beperkt in sommige regio's, maar in de basis wel gewoon goed en robuust.

Dit zijn allemaal zaken die wij allemaal als 'normaal' beschouwen, maar er zijn maar weinig landen op de wereld waar dit gewoon één op één allemaal kloppend is.

Uiteraard hebben we met veel van bovenstaande zaken ook domme mazzel dat we een superzachte grond hebben en alles relatief dicht op elkaar zit; en uiteraard kent iedereen wel een dingetje dat niet helemaal goed is, en waar niks aan lijkt te gebeuren, maar dat zijn wel echt uitzonderingen.

[Pixelmagic]

Pak de auto eens in de spits, hoeveel vertraging heb je dan ?

[CivLord]

Wanneer je die file van 30 minuten incalculeert en 30 minuten eerder van huis vertrekt, kom je voor je gevoel op tijd.
Die collega die 5 minuten vertraging had met zijn trein, komt dan echter, voor je gevoel, 5 minuten te laat.

[Pixelmagic]

Exact dat, het is algemeen geaccepteerd dat je op de weg file kan (en zal) krijgen, terwijl vertraging met het OV van meer dan een minuut wereldnieuws is.

[nst6ldr]

Zo gek is dat toch niet? Het één is een dienst, het ander is eigendom.

Als ik een webservice draai op eigen hardware, dan is het opschalen bij grote drukte mijn verantwoording.

Als ik een webservice draai op bijvoorbeeld AWS, dan is latency en andere zaken de verantwoording van Amazon.

Waarom zou dit in het OV dit anders moeten zijn?

[CivLord]

In jouw voorbeeld is je eigen server zo brak dat je daar zelf rekening mee houdt en extra marge inbouwt. terwijl je meteen begint te piepen wanneer je met je AWS service, die je zonder marge en belofte van 95% uptime hebt ingekocht, een keer met die 5% downtime te maken krijgt.

Niets is 100% gegarandeerd. Waarom zou dat bij het OV wel zo moeten zijn?

[nst6ldr]

5% is overigens heel veel voor een hoster, 99.5% uptime zelfs al aan de lage kant tegenwoordig.

Ik noem overigens nergens dat de server uit het voorbeeld brak is, gewoon ondergedimensioneerd. Dat betekent in dit voorbeeld dat er maatregelen genomen moeten worden om dat in het vervolg te voorkomen, want een tweede of derde keer zou voor veel afnemers betekenen dat ze elders naar dienstverlening gaan zoeken. Bij risicomanagement ga je namelijk verder dan alleen voorbereiden op problemen die voortkomen uit de gebruikelijke bedrijfsprocessen. Het zou de NS sieren als zij dat ook gingen doen, aangezien ze best veel afhankelijkheden hebben. Ik heb namelijk - zoals bij veel commerciële bedrijven - niet het idee dat hun belangen overeenkomen met die van de klant.

[Reactie gewijzigd door nst6ldr op 22 juli 2024 16:47]

[joepP]

Hoe zie je dat "vervoer regelen" voor je? Wie ga je bellen dan? Probeer voor de grap zelf eens een touringcar voor een weekendje weg te regelen: dat is al amper mogelijk wegens personeelstekorten. Laat staan dat je honderden bussen geregeld krijgt binnen een uurtje. Die zijn er gewoon niet. Als de treinen wegens een abrupte storing niet rijden heb je gewoon pech.

[Dennisdn]

Wat moeten ze doen dan? 1000 bussen Amsterdam centrum in sturen?

[vmihai]

Ja, bij voorbeeld. Regel IETS

[CyBeR]

En waar gaan die 1000 bussen vandaan komen dan?

Sommige mensen snappen echt het concept schaalgrootte niet. Op het moment dat er een trein of zelfs een traject uitvalt kun je dat met bussen opvangen. Op het moment dat álle treinen in een hele regio uitvallen dan kán dat gewoon niet. Er zijn niet genoeg bussen, en als die er wel waren, waren er niet genoeg chauffeurs, en als die er waren, is er niet genoeg plek voor (het station is voor treinen, daar is helemaal geen plek voor 1000 extra bussen), etc. etc.

Als er op deze schaal uitval is, dan is er inderdaad gewoon niks wat NS daar aan kan doen wat niet op uitzonderingsbasis is voor individuele gevallen. Het beste wat ze dan kunnen doen is mensen wijzen op alternatieven die wel werken. Zoals men bijvoorbeeld wees op de mogelijkheid om gebruik te maken van de metro voor vervoer binnen de stad en Amstelveen.

Je onderschat ontzettend over hoeveel mensen we het hebben. In één trein naar (of via) Amsterdam kunnen makkelijk meer dan 1000 mensen zitten. Een bus kan er max een stuk of 40 hebben. Maar we hebben het niet over één trein, we hebben het over honderden treinen.

[Reactie gewijzigd door CyBeR op 22 juli 2024 16:47]

[n4m3l355]

Dus? Nogmaals dit komt toch wel vaker voor, het is niet voor het eerst dat reizigers weer de dupe zijn van de NS. Daarnaast heb je geen 1.000 bussen nodig, je hebt 1.000 ritten nodig. Maak er 1.000 ritten desnoods naar Amsterdam van en hok ze maar in een hotel. Ja dat kost veel geld, nogmaals het is de NS die hier faalt en niet eens voor een oplossing zorgt.

Omdat het veel mensen zijn wilt nog niet zeggen dat het niets doen acceptabel is. Ten eerste had de zoveelste Schiphol/A'dam IT probleem niet moeten gebeuren, het komt gewoon veelste vaak voor en juist in een gebied met heel veel reizers. Daarnaast als het voorkomt vindt maar een passende oplossing. Ik verwacht niet dat iedereen thuis komst maar dat mensen maar op het perron moeten slapen dat is toch iets van een derde wereld en totaal onacceptabel. Stop ze lekker in bussen, taxi's, hotels in en rondom Amsterdam/Schiphol. En ja dat gaat heel veel geld kosten, misschien dat de NS er dan ook voor zorgt in de toekomst dat dit soort flaters niet meer voorkomen.

[CyBeR]

Dus? Nogmaals dit komt toch wel vaker voor

Nee? Uitval op deze schaal komt zelden voor.

het is niet voor het eerst dat reizigers weer de dupe zijn van de NS.

Om te beginnen is niemand hier "de dupe van de NS". De NS rijdt treinen. Dat zouden ze graag doen en dat kunnen ze ook, maar de railverkeersleiding, onder beheer van ProRail, is niet in staat om ze dat te laten doen. Het is alsof Rijkswaterstaat de snelweg afgesloten heeft. Dan ben jij ook niet "de dupe van Volkswagen" omdat je je auto niet mag rijden.

Daarnaast heb je geen 1.000 bussen nodig, je hebt 1.000 ritten nodig. Maak er 1.000 ritten desnoods naar Amsterdam van en hok ze maar in een hotel. Ja dat kost veel geld, nogmaals het is de NS die hier faalt en niet eens voor een oplossing zorgt.

1000 ritten? Wat hebben meer dan 100.000 mensen aan "1000 ritten"? Weet je hoeveel mensen er via Amsterdam reizen elke dag? Laat staan Amsterdam en omgeving?

Omdat het veel mensen zijn wilt nog niet zeggen dat het niets doen acceptabel is.

Men doet niet "niets". Jij zit dat lekker thuis achter de computer te typen maar dat is gewoon pertinent onzin. Men doet niet wat jij denkt dat ze moeten doen, omdat wat jij denkt gewoon niet kan. Maar men doet zeker niet "niets".

Ik verwacht niet dat iedereen thuis komst maar dat mensen maar op het perron moeten slapen dat is toch iets van een derde wereld en totaal onacceptabel. Stop ze lekker in bussen, taxi's, hotels in en rondom Amsterdam/Schiphol. En ja dat gaat heel veel geld kosten, misschien dat de NS er dan ook voor zorgt in de toekomst dat dit soort flaters niet meer voorkomen.

Er zijn niet genoeg bussen, niet genoeg taxi's en al zeker niet genoeg hotelkamers (Amsterdam heeft 40.000 hotelkamers, en die zijn voor het grootste deel al volgeboekt) om al die reizigers op te vangen. En al was het dat wel, om dat allemaal binnen een paar uur te organiseren is ook gewoon onmogelijk.

Men doet wat men kan, en men doet niet wat niet kan. Heel simpel.

[Reactie gewijzigd door CyBeR op 22 juli 2024 16:47]

[MennoE]

Ja en dat is de frustratie. Je voelt je aan je lot overgelaten als ze zeggen: vind zelf maar iets anders. Maar feit is dat het zelf regelen van alternatief vervoer in veel opzichten beter en efficiënter werkt dan dat NS iets gaat organiseren. Het enige alternatief is bussen, en er zijn voor dit soort storingen vaak te weinig bussen en buschauffeurs paraat. Dan heb je te weinig bussen, en dan worden de reizigers (terecht) opnieuw boos dat ze geen plek in de bus kunnen bemachtigen. Als er een goed collectief alternatief was dan was dat echt wel georganiseerd.

[Dennisdn]

Al zouden ze zoveel bussen en chauffeurs zouden kunnen vinden, ze passen niet eens in de stad.

[nst6ldr]

Maar dat is gewoon niet logisch, het alternatief zijn namelijk taxi's, hoe ga je daar genoeg van kwijt kunnen?

[Cergorach]

Niet, bij zo een storing zijn er gewoon niet genoeg taxi's, zelfs niet op een enkele traject storing. 100.000 passagiers, 3 passagiers max in een taxi, 33.333 taxi's? Zoveel taxi's hebben we niet eens in heel Nederland! Zelfs al zouden (veel) taxi chauffeurs zich willen wagen in zo een mensen massa...

Bron:
https://www.ilent.nl/onde...-de-taximarkt/taximonitor

[vmihai]

Sorry hoor ik vind dat echt geen excuus. Laat ze maar 50 bussen organiseren voor de mensen die aantoonbaar geen alternatief hebben of een vlucht moeten halen. Zelfs in Roemenië regelen ze bussen bij zo'n storing - heb ik meegemaakt. Kom op zeg.

[Andros]

50 bussen is 1000 man, dan staan er nog een paar duizend te brullen dat ze ook naar huis willen. Wie is er zo gek om met een geel hesje te gaan bepalen wie er wel of niet mee mag? Zie je zo'n medewerker bij elke persoon al vragen "meneer, kunt u niet uw moeder bellen om u te komen halen of mag ik uw boardingpass van uw vlucht zien?". Besef even wat je zegt en in welke maatschappij je tegenwoordig leeft...

[vmihai]

Jahoor, het valt allemaal te regelen - ja het zal chaotisch gaan en er zullen dingen misgaan maar je hebt je best gedaan. Dit is gewoon 3x niets qua aanpak - vooral als je denkt wat voor prijzen NS hanteert. Sorry, ik vind het gewoon NIET uit te leggen.

[MennoE]

Ja 50 bussen is misschien te doen. Maar dan gaan reizigers rekenen op die bussen en zoeken ze geen alternatief (zoals de bussen die sowieso al rijden). Vervolgens gaat er toch iets mis met de NS-bussen. Er komen er minder dan verwacht, of er zijn teveel reizigers etc. Je kunt als reiziger dan niet in de NS-bus, en je hebt je alternatief gemist.

[nst6ldr]

Tussen de 63 en 90 zitplaatsen per bus, dat zijn minimaal 3150 reizigers, dan is het nog het standaard lijnvervoer, de reizigers die gewoon terug naar huis gaan, en die enkele gelukkige die een taxi heeft (en er achter komt dat je dik een maand bezig bent met declareren van je rit van honderden euro's).

Bussen inzetten is dus een prima manier om een flink deel alsnog te vervoeren.

[Andros]

Voor een enkele trein of een enkel traject lukt dat ja. Voor een groot knooppunt met honderden uitgevallen ritten incl reizigers met grote stukken bagage ga je het met die 50 bussen niet redden, laat staan dat je zoveel bussen met chauffeurs kunt regelen en kwijt kunt op het toch al drukbezette Amsterdam-Centraal.

[Orgel]

Ja, bij voorbeeld. Regel IETS

10.000 steppen

[segil]

Alleen gaat het niet om 1000 bussen. Iets van 500-700 mensen konden uiteinderlijk geen alternatief vervoer vinden. Daarvoor moet toch wel wat te regelen zijn?

[Dennisdn]

Omdat alle anderen alternatief vervoer hebben gevonden. Als er bussen rijden komt iedereen alsnog.

[CivLord]

Dat waren de mensen die uiteindelijk overbleven omdat ze geen alternatief vervoer konden regelen.
Wanneer mensen verwachten dat er alternatief vervoer voor hen geregeld wordt, doen ze dat zelf niet en blijven ze wachten. Dan heb je het over een veelvoud van mensen waar je iets voor moet regelen.

Nu hebben ze voor die laatste paar honderd mensen een slaapplaats geregeld. Het is niet alsof ze in de vrieskou op straat zijn achtergelaten.

[Autisme_tech]

Scheelt dat je dan op dat moment ook een taxi kan pakken, maar veel mensen weten dat niet de kosten kan je bij de NS declareren.

[StefanJanssen]

Ik verwacht niet dat er veel taxi's beschikbaar waren op dat moment.

[CivLord]

Een taxichauffeur krijgt heus wel op de één of andere manier mee dat er problemen zijn met de treinen en dat veel mensen naar huis willen. Ze weten ook dat dat over het algemeen ritjes zullen zijn die meer opbrengen dan de standaard ritjes in het centrum.
Ik denk dat er meer taxis af en aan reden dan dat er normaal op een dag in heel Amsterdam rijden.

[StefanJanssen]

Jij denkt dat er voldoende taxis waren voor de 70.000 concert bezoekers die naar Harry Styles en Ghost zijn gegaan?

[CivLord]

Natuurlijk niet. Maar ik denk dat de beschikbaarheid van taxi's op dat moment een flink stuk hoger was dan op een normale zondagavond.

[nst6ldr]

Goed om er bij te noemen dat een taxirit bijzonder duur kan uitvallen en het declareren ervan niet bepaald prettig verloopt, soms kan je er meer dan een maand op wachten.

[lenwar]

Ik denk dat dat in de praktijk betrouwbaarder werkt, dat dat één partij bijvoorbeeld probeert voor vele duizenden mensen bussen probeert te regelen.

Als dan de helft van de mensen dat op in gaat, gaat dat natuurlijk nooit werken. Een trein vervoert een gigantische hoeveelheid mensen tegelijk. Daar is niet tegenop te bussen. Zeker niet ad hoc.

Je kan dan beter hebben dat mensen zelf zich gaan uitspreiden over stadsbussen/streekbussen/trams/auto’s/carpoolen/thuiswerken/enz/enz

Uiteraard is het sentiment niet goed. Want je kan het inderdaad vertalen als. ‘Onze fout, jouw probleem’

Een beetje als vakbonden die Nederland ondersteboven trekken door ov te laten staken, of voedsel laten wegrotten door distributiecentra laten staken.

Die vakbonden lijken ook maling te hebben aan de publieke gevolgen van hun protesten of schuiven de schuld door naar de club die ze hun zijn niet geven.

Één partij handelt (al dan niet) en het publiek heeft er veel last van.

[Mathijs Kok]

"Hallo, ik wil graag 1250 bussen huren."
....
"Uh nee, eigenlijk heb ik ze nu meteen nodig."

[Andros]

NS heeft sowieso oproepcontracten met touringcarmaatschappijen door het hele land. Zowel die busbedrijven als de NS zullen heus wel iets van draaiboeken hebben om problemen op te vangen maar soms is dat gewoon niet toereikend zoals nu.

[Anoniem: 1839988]

Hoe kan iets uitvallen zonder dat iemand eraan zit? Ik bedoel, ze zullen ook wel wat redundantie hebben ingebouwd.

[Blackbird-ce]

Uit de losse pols: automatische updates, hardwarefalen, aantal connecties volgelopen met brakke errorhandling, deadlock, onvoorziene situatie doet zich voor, ...

Er kan genoeg fout gaan zonder dat jij aan de knoppen zit

[Pixelmagic]

Scrap automatische updates maar uit je lijstje, behalve KA (en die bestuurd geen treinen) krijgt niets automatisch een update. Alles gaat vooraf handmatig door de gehele OTAP straat maar helaas gaat het dan nog soms mis.

[Moortu]

Het is vaak iets wat ongerelateerd lijkt of wat onverwachts is.

En er is zeker redundantie, maar misschien niet voor alles.
Er is bijvoorbeeld een applicatie om treinbotsingen te voorkomen, en daarvoor is er een andere applicatie die het ook controleerd op zijn eigen manier. Hierdoor, als de een het mist is de ander er om te waarschuwen.

[Reactie gewijzigd door Moortu op 22 juli 2024 16:47]

[LurkZ]

Met redundantie moet je soms alles alsnog plat leggen.
Als voorbeeld een systeem dat de seinen regelt valt uit. Het backup systeem neemt het over zodat alles veilig blijft. Maar omdat er geen backup systeem is voor het backup systeem, zal alles toch plat gaan omdat volgens de voorschriften er altijd een backupsysteem moet zijn.
In dit voorbeeld kan alles blijven draaien als alles driedubbel of meer is.

[HakanX]

Waarom heb je dan een backup systeem als je het niet mag gebruiken?

[hackerhater]

Om de treinen die al onderweg zijn veilig af te kunnen handelen.

[Xorgye]

Ik denk dat de verwarring in de woorden 'backup' en 'redundant' zit. Een 'redundant' systeem heb je in heel veel manieren met allemaal een iets andere nuance met wat ze garanderen en wanneer ze 'alsnog' falen.

Waar @LurkZ op doelt is dat de REDEN dat er een backup systeem beschikbaar is, voortkomt uit bepaalde regelgeving en/of beleid.
Daardoor kan een redundant systeem op zich nog wel 'werkende' delen hebben, maar tegelijk ook 'gefaald' zijn omdat bepaalde garanties niet meer gegeven kunnen worden.

Als daar bijvoorbeeld staat: om treinen veilig te kunnen rijden, moeten altijd 1 systeem direct beschikbaar staan als backup. Dan betekend dit dat je minimaal 2 'werkende' systemen nodig hebt, 1 die t werk doet en 1 backup. Stel dat nr 1 stuk gaat, dan neemt nummer 2 het over. Maar op dat moment is er geen backup meer voor de backup, om t maar zo te zeggen. In zo'n situatie zal men dan alles gecontroleerd 'tot stoppen brengen', totdat er weer 1 werkend systeem met 1 werkend backup systeem is. Stel dat je dus garantie wilt dat, in t geval van uitvallen van 1 systeem je OOK dan nog door kan blijven werken, dan heb je dus 3 systemen nodig: 1 werkend systeem, 1 werkend backup, en 1 werkend backup van de backup.

[Reactie gewijzigd door Xorgye op 22 juli 2024 16:47]

[Dark Angel 58]

Met redundantie moet je soms alles alsnog plat leggen.
Als voorbeeld een systeem dat de seinen regelt valt uit. Het backup systeem neemt het over zodat alles veilig blijft. Maar omdat er geen backup systeem is voor het backup systeem, zal alles toch plat gaan omdat volgens de voorschriften er altijd een backupsysteem moet zijn.
In dit voorbeeld kan alles blijven draaien als alles driedubbel of meer is.

No way... denk maar aan kernramp van Tsjernobyl, want het kan van alles mis gaan op verkeerde moment. Daarom vind ik echt dat je het eerst in simulatie (in virtueel omgeving natuurlijk) getest moet worden, zodat een echte ramp niet hoeft plaatsvinden!!!

[lenwar]

In z'n algemeen: Soms is het niet helemaal evident dat systeem A bepaalde impact heeft op systeem B. Nou verwacht ik dat het trein-controle-systeem relatief afgebakend is van andere systemen, maar er zullen altijd een paar koppelingen met de buitenkant zijn.

Vergeet ook niet dat zo'n systeem 'omgekeerd beveiligd' zal zijn. Het systeem werkt niet, tenzij alles goed is. Je meet dus altijd omgekeerd. Je meet niet dat de deur dicht is, je meet dat hij niet open is. Dit klinkt een beetje flauw, maar als je het even laat bezinken kan dit natuurlijk best voor gedoe zorgen.


Maar goed. We weten niet precies wat er nou aan de hand was/is, dus er valt niet zoveel te zeggen over hoe en wat. Mogelijk was het telecommunicatie bij een derde partij die stuk was, mogelijk trok iemand de verkeerde stekkers uit het stopcontact om z'n oortjes te snelladen We weten het niet.

[Estel]

Ze hebben juist heel veel redundantie en voor bepaalde cruciale elementen (spoorwegovergangen meldingen/storingen) zijn juist de eisen erg streng. Vroeger was het zo, dat als je ergens iets in het landschap veranderde, je moest kunnen aantonen dat dit geen effect zou hebben op het automatische systeem om storingen van spoorwegovergangen te detecteren en daarop te reageren. Zolang ze niet met informatie naar buiten komen, blijft het gissen. Het is wel apart, dat het zo lang duurt. Het lijkt dus niet iets voor de hand liggends te zijn.

[Moortu]

Het was update-zondag
Is niet goed verlopen, en ze hebben geen rollback functionaliteit

[Homeland]

Het enige wat ik hier niet snap is dat ze dan geen goede opvang regelen. Het is lastig en naar dat treinen niet rijden maar zorg dan in elk geval voor de mensen die ergens stranden. Regel een zaal met bedjes, geef ze wat te eten en te drinken.

Geef ze niet slechts een folie deken en laat ze vervolgens maar voor oud vuil achter in Amsterdam CS, beschamend hoe NS (verantwoordelijk voor de reizigers) dat doet.

[azortje]

Klinkt flauw, maar de reden dat je het niet snapt is waarschijnlijk omdat je geen idee hebt van de impact om iets ogenschijnlijks simpel te regelen.

Waar verwacht jij bijvoorbeeld dat de NS zondagavond na 18:00 nog even een slaapzaal inclusief bedden organiseert? En waar scoort men nog even al het vervoer op dat tijdstip?

[Homeland]

Ik verwacht dat NS hier een plan voor heeft liggen zodat ze relatief makkelijk binnen enkele uren op een locatie zoiets uit de grond kunnen stampen. Dat ze onder andere contracten hebben of zelf een voorraad veldbedden die ze op zeer korte termijn kunnen plaatsen.

Het is niet voor het eerst dat dit (een grootschalige storing) gebeurt dus hoop je toch dat NS daar beter op is voorbereid wat betreft de zorgtaak voor haar klanten.

Als je dit vanuit het niets moet plannen dan is dat lastig, als je hierop voorbereid is dat best te doen.

[FONfanatic]

In Utrecht in de Jaarbeurs, in Amsterdam in de RAI. Dat zijn reguliere opvanglocaties in noodsituaties.

[arie.v]

In de ZIggo was toch een slaapplek voor 500 mensen ingericht? En CS - nu niet de meest beroerde plek om te overnachten. Het vroor niet. he?

[Homeland]

Met 15c is het niet warm en CS is toch vrij belabberd, zeker voor toeristen was de informatie voorziening en hulp blijkbaar zeer minimaal. Daarnaast, waarom vervoeren ze niet iedereen van CS naar een locatie met veldbedden? Nu moesten ze dus op de vloer van CS gaan liggen...

Ziggo Dome was vooral voor mensen van de concerten daar en in de Arena.

[remonkok1990]

Het valt me wel op dat het heel vaak Schiphol is. Dit was het al in 2009-2013 toen ik er dagelijks gebruik van moest maken i.v.m. studie, maar zelfs na 10 jaar is het nog niet veranderd

[wildhagen]

De storing zit niet bij Schiphol zelf, maar in (vrijwel) heel Amsterdam. Daar is Schiphol dus maar één getroffen station van.

Waar jij aan refereert zijn vaak problemen in het verleden met de tunnel bij Schiphol, maar dat is hier geen factor. Het gaat om een IT-storing.

[Reactie gewijzigd door wildhagen op 22 juli 2024 16:47]

[wiseger]

Schiphol is een complexe situatie. Een spoortunnel met beperkte capaciteit, het aantal sporen loopt terug zodra je bij de tunnel komt. Midden in die tunnel is een druk station. Dan gaat het snel mis. Men wil geen risico nemen met treinen die in de tunnel vast komen te staan. Dus leidt een incident in de tunnel al snel tot een verstoring van de dienstregeling.

[aidanl]

Wat mij opvalt, in alle communicatie (en hier in de comments) rept niemand iets m.b.t. malware dan wel gerichte aanval op ProRail infrastructuur. En ik zit hier nu niet met een allu-hoedje op, maar het is de harde waarheid dat er er buitenlandse actoren zijn die er baat bij hebben om onze infra-structuur binnen te dringen, dan wel onderuit te halen.

Nou zal een ProRail ook niet zo snel aangeven wanneer dat het geval is. Zeker in samenwerking met de Nederlandse veiligheidsdiensten. Maar gezien het euvel na een reset weer ontstond, sluit ik een dergelijk scenario niet uit.

[Jordy141]

de systemen die de rail infra besturen (dus wissels, seinen e.d.) zijn niet aangesloten op het internet, ik denk daarom dat het niet heel waarschijnlijk is dat de oorzaak een cyberaanval was.
Gezien de update van Spoorpro dat het probleem verholpen lijkt met het terugzetten van een backup, vermoed ik dat dit een probleem met de interne software was.

Hoop dat ProRail uiteindelijk met een rapportage komt hoe dit precies heeft kunnen gebeuren. En hoe ze herhaling kunnen voorkomen.

[aidanl]

Dat zegt niet alles, zie voorbeeld hieronder genoemd door @Anoniem: 685461.

Daarbij, hoe wordt de rail infra dan aangestuurd? Het zal wellicht niet aan het publieke internet vast zitten, maar dan is er nog steeds een intern netwerk waarmee het communiceert met een centrale meldkamer (exacte terminologie binnen spoor-branch ken ik niet). En daardoor is het in principe net zo vatbaar voor misbruik, al ligt de lat ietsjes hoger.

[Anoniem: 685461]

De geschiedenis leert dat ook systemen die niet aan internet worden aangesloten weldegelijk aangevallen kunnen worden door een cyberaanval. Zo was er in het verleden een worm genaamd 'Stuxnet' in de omloop gebracht. Deze kon zich verspreiden via USB-sticks en computer netwerken. Uiteindelijk kon het een USB-stick de nucleaire installaties in Iran bereiken , waarvoor deze uiteindelijk was bedoeld.

[badbadpresident]

Wat ook wel een realisatie is dat er weinig alternatieven zijn als je afhankelijk bent van het OV. Als je nu van Ams naar Utrecht wilt dan mag je een bus pakken vanaf zuidoost die er ruim 1,5 uur over doet...

[Anoniem: 1839988]

We moeten ook niet overdrijven. Buiten AMS rijden veel treinen wel gewoon volgens dienstregeling.