Tentamens op Rijksuniversiteit Groningen zijn uitgesteld vanwege ict-storing

Online tentamens voor duizenden studenten van de Rijksuniversiteit Groningen zijn uitgesteld vanwege ict-problemen. Het online examensysteem Nestor liep vast door overbelasting. Inmiddels zou het systeem weer werken, maar nog steeds klagen sommige studenten over problemen.

In totaal moesten tien tentamens worden uitgesteld, schrijft RTV Noord. Daardoor konden duizenden studenten geen tentamens maken. Het probleem zit in Nestor, de online leeromgeving van de RUG. Op maandagavond ontstonden er al problemen met het systeem. Dat zou overbelast zijn geraakt. Hoewel het probleem binnen een uur zou zijn opgelost, lijken er ook dinsdagmiddag weer veel studenten niet in te kunnen loggen.

De universiteit zegt naar 'de onderliggende problemen' te kijken. "Een oorzaak hebben we nog niet kunnen vinden. We hopen natuurlijk van ganser harte dat het niet weer gebeurt", zegt een woordvoerder tegen RTV Noord. Waarschijnlijk is het systeem overbelast, omdat het overgrote merendeel van de studenten de tentamens online moet maken.

De Groninger Studentenbond GSV is boos op de universiteit. "'Eerder hadden we ook tentamens, maar daar deed een klein groepje aan mee. Door corona is het nu tachtig procent van de studenten die er mee werkt. Na meer dan zeven maanden is het nog steeds niet in orde. Dit is de basis van online onderwijs en zelfs dat gaat niet goed", zeg een woordvoerder van de bond.

Het is niet de eerste keer dat onderwijsinstellingen te maken hebben met storingen in de tentamenomgeving. Vorige maand werden duizenden tentamens voor studenten van de Universiteit van Amsterdam stilgelegd vanwege een grote storing.

Door Tijs Hofmans

Nieuwscoördinator

03-11-2020 • 11:43

76

Submitter: Webgnome

Reacties (76)

Sorteer op:

Weergave:

snap niet wat nu het probleem is,. opschalen van capaciteit mag toch niet het probleem zijn.
Aan opschalen (dikkere server) zijn grenzen en niet elke software kan om met uitschalen (meer servers). daarnaast kan de software bvb wachten op de database om iets weg te schrijven maar dezelfde software houd een tabel gelocked in de database (voor bvb een andere student) waardoor de database niets kan wegschrijven.

Een andere klassieker is round trip tussen de client en de database. Als die applicatie ontworpen is om op een LAN te draaien en die moet dan opeens over het internet dan wordt dat weer belangrijk...

Ik laat het simpel overkomen, maar in werkelijkheid is performance echt wel een lastig iets, wat meestal enkel fundamenteel op te lossen is in de code.

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

Je hebt helemaal gelijk en je wijst terecht mogelijke bottlenecks aan, maar er is in mijn ogen geen excuus voor een incident als dit.

Want alles wat jij hier terecht aandraagt zijn risico's waar we al 25 jaar bekend mee zijn.

Ik krijg sterk de indruk dat er nooit een degelijke, representatieve load test heeft plaatsgevonden op het systeem.

Maar ik laat me graag van het tegendeel overtuigen. Ik zou het wel interessant vinden om te begrijpen waar het mis ging.

Edit: het feit dat het zo snel was opgelost klinkt meer als een mensen fout dan een structureel probleem in de omgeving. Maar de beste stuurlui...... ;)

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

We zijn nog niet 25 jaar bekend met het feit dat iedereen thuis zit. Maar goed, jij zult waarschijnlijk al jaren terug je systemen zo hebben gebouwd dat het met alle mogelijke (tot voor kort onvoorspelbare) situaties om kan gaan zonder enige user impact. Kan je misschien al vast met ons delen hoe we de boel moeten configureren voor iets wat over 5 jaar gaat gebeuren?
Het thuis zitten is nieuw, maar het gevolg van dat thuiszitten, dat is al zo oud als het internet. :D

Ken je het slashdot effect nog? :)

De bottlenecks zoals beschreven door Yalopa zijn al 25 jaar bekend en je moet er dus mee rekening houden en vooral testen.

p.s. ik heb zelf de indruk dat het niet bepaald onvoorspelbaar was dat rond deze periode duizenden studenten tegelijk tentamens zouden moeten maken, dus je zou in de zomer even wat load tests uitgevoerd kunnen hebben.

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

Het thuis zitten is nieuw, maar het gevolg van dat thuiszitten, dat is al zo oud als het internet. :D

Ken je het slashdot effect nog? :)

De bottlenecks zoals beschreven door Yalopa zijn al 25 jaar bekend en je moet er dus mee rekening houden en vooral testen.
Daar zit natuurlijk wel een prijskaartje aan. Bij het bouwen van zo'n systeem moet je een schatting maken van de verwachte belasting. Een jaar geleden had niemand kunnen voorzien dat we zo snel zouden overstappen naar online-only.
Dynamisch schalende oplossingen (zoals populair in de "cloud") bieden een uitkomst, maar dat heeft ook zo z'n prijs en uitdagingen en niet alle software is er geschikt voor.
p.s. ik heb zelf de indruk dat het niet bepaald onvoorspelbaar was dat rond deze periode duizenden studenten tegelijk tentamens zouden moeten maken, dus je zou in de zomer even wat load tests uitgevoerd kunnen hebben.
Makkelijker gezegd dan gedaan. De hele IT-wereld rent al maanden lang de benen uit het lijf omdat iedereen opeens alles online moet doen. Er is op grote schaal software uitgerold vanuit een crisis-sfeer: er moet /nu/ een oplossing komen, doet er niet toe hoe, anders lopen tienduizenden studenten studievertraging op. Zorg maar dat het werkt!

Alles is daarvoor moeten schuiven, geld, tijd en mensen. Daardoor is er wel een enorme achterstand ontstaan in ander werk en heel veel nieuwe "technical debt" door het overhaast uitrollen van software zonder goed plan en het budget voor dit jaar is ook al lang en breed op.

De hele IT-wereld heeft dit soort problemen aan zien komen. Lang voor Covid was het al een chaotisch wereldje dat op de rand van de afgrond balanceerde tussen budget en bugs.
Het issue was met een uurtje opgelost. De schade was natuurlijk al geleden. Maar dat wijst eerder op een mensen fout dan een design/infrastructuur fout. Ik ben erg sceptisch, maar ik was er niet bij :D
Daar zit natuurlijk wel een prijskaartje aan. Bij het bouwen van zo'n systeem moet je een schatting maken van de verwachte belasting. Een jaar geleden had niemand kunnen voorzien dat we zo snel zouden overstappen naar online-only.
Dynamisch schalende oplossingen (zoals populair in de "cloud") bieden een uitkomst, maar dat heeft ook zo z'n prijs en uitdagingen en niet alle software is er geschikt voor.
Ik kijk daar wat anders tegen aan: ik bedoel het allemaal simpeler.

Doe eerst maar eens een test en kijk bij welke belasting het stuk gaat. Dan weet je tenminste überhaupt waar de grens ligt. En dan weet je wat de vervolg stappen zouden kunnen zijn.

Ik weiger te teneur te accepteren dat dit incident alleen met heel veel moeite te voorkomen zou zijn geweest.
Makkelijker gezegd dan gedaan. De hele IT-wereld rent al maanden lang de benen uit het lijf omdat iedereen opeens alles online moet doen. Er is op grote schaal software uitgerold vanuit een crisis-sfeer: er moet /nu/ een oplossing komen, doet er niet toe hoe, anders lopen tienduizenden studenten studievertraging op. Zorg maar dat het werkt!
Tja, ik was er niet bij. Het voelt allemaal als excuses. Zeker omdat het zo was opgelost. Juist onder druk weet je van te voren dat je niet in de valkuil moet trappen van paniek voetbal, waarbij alle stappen/processen die kwaliteit moeten waarborgen als eerste het raam uit vliegen onder het mom van geen tijd. Haast.

Dan creëer je geen Technical Debt, dan maak je er gewoon een potje van.

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

Het issue was met een uurtje opgelost. De schade was natuurlijk al geleden. Maar dat wijst eerder op een mensen fout dan een design/infrastructuur fout. Ik ben erg sceptisch, maar ik was er niet bij :D
Klopt, maar dan heeft het hele verhaal over bottlenecks en loadtests ook geen zin.
Ik kijk daar wat anders tegen aan: ik bedoel het allemaal simpeler.

Doe eerst maar eens een test en kijk bij welke belasting het stuk gaat. Dan weet je tenminste überhaupt waar de grens ligt. En dan weet je wat de vervolg stappen zouden kunnen zijn.
Makkelijker gezegd dan gedaan. Zoek maar even 1000 studenten die mee willen werken. Natuurlijk kun je dat ook simuleren maar iemand zal dat moeten bouwen.
Ik weiger te teneur te accepteren dat dit incident alleen met heel veel moeite te voorkomen zou zijn geweest.
Ik ook. IT-problemen zijn vaak van het "death by a thousand papercuts"-soort. Voor al die kleine probleempjes is een eenvoudig oplossing die met een klein beetje tijd en moeite uitgevoerd kan worden. Maar duizend van die kleine probleempjes samen kosten wel veel tijd en moeite.
Juist onder druk weet je van te voren dat je niet in de valkuil moet trappen van paniek voetbal, waarbij alle stappen/processen die kwaliteit moeten waarborgen als eerste het raam uit vliegen onder het mom van geen tijd. Haast.
Daar kan ik het natuurlijk niet mee oneens zijn, maar het is makkelijker gezegd dan gedaan. In dit soort crisis situaties zul je altijd harde en pijnlijke keuzes moeten maken. Je kan niet iedereen tegelijk helpen en je kan niet altijd de tijd nemen die nodig is om het goed te doen. Als de brandweer een slang met een gat heeft dan gaan ze niet terug naar huis om een nieuwe slang te bestellen. Er moet nu geblust worden want ieder uur dat je wacht brandt er meer af dat je nooit meer terug krijgt.
Studenten hebben tegenwoordig een enorm straks schema met weinig ruimte voor vertraging. Als je een jaar niet haalt dan kost dat als snel heel veel geld, of dat nu je eigen schuld is of niet. Je kan een tentamen misschien een paar dagen uitstellen, maar geen maanden.
Dan creëer je geen Technical Debt, dan maak je er gewoon een potje van.
Technical debt is net als iedere ander vorm van schuld: ongewenst. Niemand wil schulden. Toch heeft de halve wereld een hypotheek (een schuld dus) en de meeste jongeren een studieschuld.
Bepaalde risico's en schulden moeten we in het leven accepteren om verder te komen. Als je pas in een auto stapt als je 100% zeker weet dat je er levend uit komt dan zou de ontwikkeling 100 jaar geleden zijn bleven steken.
Klopt, maar dan heeft het hele verhaal over bottlenecks en loadtests ook geen zin.
Helemaal waar, dit was een ander scenario.
Makkelijker gezegd dan gedaan. Zoek maar even 1000 studenten die mee willen werken. Natuurlijk kun je dat ook simuleren maar iemand zal dat moeten bouwen.
Zoals je aangeeft: dat ga je simuleren. Maar mijn mening: dat zou bijna verplicht moeten zijn als onderdeel van je release proces / CI/CD: dat je systeem geload test is voordat het in productie gaat.

Het is 2020!
Studenten hebben tegenwoordig een enorm straks schema met weinig ruimte voor vertraging. Als je een jaar niet haalt dan kost dat als snel heel veel geld, of dat nu je eigen schuld is of niet. Je kan een tentamen misschien een paar dagen uitstellen, maar geen maanden.
Tja, de stakes are high. Dus als die stakes zo high zijn, dan mogen de voorbereidingen en maatregelen ook wel equivalent zijn. Had dit issue van te voren geidentificeerd kunnen worden?
Technical debt is net als iedere ander vorm van schuld: ongewenst. Niemand wil schulden.
Ik vrees dat jij ook een onjuiste definitie van Technical Debt hanteert, zoals ik zelf dat ook deed. Ik ga in het gelinkte artikel in op wat jij als TD beschrijft. Maar dat is erg OT ;)
Maar mijn mening: dat zou bijna verplicht moeten zijn als onderdeel van je release proces / CI/CD: dat je systeem geload test is voordat het in productie gaat.
Je hebt helemaal gelijk. Dat is hoe het zou moeten zijn. In praktijk gaat het helaas niet altijd zoals het zou moeten. Mensen moeten voortdurend kiezen tussen dingen die zouden moeten.
Uiteindelijk is het allemaal een kwestie van geld. Onderwijs heeft vrijwel permanent te maken met bezuinigingen en schuivende geldstromen. Dan krijg je niet de hoogste kwalitiet maar een budget oplossing. Testen is vaak het eerste wat er bij inschiet.

Ik heb wel een beetje met dit soort situaties te maken en je mag inderdaad zeggen dat het een rommeltje is, maar dat is het industriebreed. Kwaltiteit is onbetaalbaar. Je moet altijd forse compromissen sluiten. De meeste klanten kijken alleen naar features en niet naar veiligheid, betrouwbaarheid of kwaliteit. Dat is waar IT-bedrijven voor bouwen. De eenzame gek die wel om "onzichtbare" aspecten geeft komt in de situatie dat er gewoon geen software te krijgen is die wel echt goed is. Als je eisen stelt krijg je te maken met enorme meerprijzen. ("Sorry meneer, daar vragen onze andere klanten noooit om, dat kunnen we echt niet alleen voor u gaan doen hoor").

Van de ene kant betoog ik altijd dat IT veel te veel doet en dat we de verwachtingen moeten halveren en de prijzen verdubbelen. IT heeft nog altijd het imago van handig whizkids die voor een zak chips een digitale eifeltoren knutselen, terwijl het in praktijk meer lijkt op het bouwen van de pyramides.

Van de andere kant zie ik wat voor ellendige oplossingen mensen gebruiken als ze geen software hebben. Ik zie te veel administratieve types die als ware monniken urenlang op hun computer zitten te zwoegen terwijl een paar regels code het probleem in 3 minuten oplost. Het doet er niet toe hoe brak die code is, alles is beter dan niks.

Ergens in het midden ligt het afschuwelijke compromis waar we nu mee zitten.

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

Bedankt hoor dat je deze informatie met mij deelt, ik vind het interessant om te lezen. Ik wil ook niet andermans werk zomaar van tafel vegen. Daar heb ik geen enkel recht toe, ik ben er niet bij betrokken.

Mijn eigen ervaring is dat mensen altijd mij vertellen dat dingen moeilijk zijn en niet kunnen.

Maar als ik dan met de betrokken mensen om tafel ga zitten praten, dan blijkt altijd dat we er met elkaar uit komen en dat wat we willen wel kan. Soms moet dat stapsgewijs en kan dat niet in één keer gerealiseerd worden, dat is dan een compromis.

Veel van die zaken als stabiliteit, veiligheid en kwaliteit, dat zijn vaak te abstracte begrippen. Het heeft dus ook enorm veel met (dat vage woord) communicatie te maken. Ik heb in een ver verleden vanuit mijn werk (security) veel bedrijven van binnen gezien en de kwaliteit was wisselend, maar ook soms gewoon prima/goed.

Ik vind het dus lastig, maar ik begrijp wel je ervaringen en hoe je kijkt naar een incident als dit.
Je doet een paar aannames, gaat ervan uit dat je daarmee het probleem beschreven hebt en begint vervolgens te blazen dat dit allemaal 25 jaar bekend is, en een paar load tests of simulaties uitvoeren in de zomer, aannemende dat dat niet gedaan is.
Het klinkt mij in de oren als "tjee een file, belachelijk, effe de weg verbreden, hoe moeilijk kan het zijn"".
Je hebt denk ik geen idee waar het over gaat, en ook niet hoe universiteiten in elkaar zitten, met wat voor randvoorwaarden ze te maken hebben bij het afnemen van tentamens. Zoek even proctoring op. Je zegt het zelf:"ik heb de indruk dat ...". helaas, die indruk is fout.
helaas, die indruk is fout.
Op basis waarvan zeg jij dit?
terechte vraag. ik werk, met een hoop anderen al sinds mei op de Utwente met verschillende teams aan proctoring, aantallen, prognoses, regelgeving etc etc
Helder, zover ik het bericht begrijp en wat ik in de comments hier lees was dit probleem niet gerelateerd aan proctoring. Het was puur het systeem zelf (inloggen?) dat niet goed werkte.
We zijn nog niet 25 jaar bekend met het feit dat iedereen thuis zit. Maar goed, jij zult waarschijnlijk al jaren terug je systemen zo hebben gebouwd dat het met alle mogelijke (tot voor kort onvoorspelbare) situaties om kan gaan zonder enige user impact. Kan je misschien al vast met ons delen hoe we de boel moeten configureren voor iets wat over 5 jaar gaat gebeuren?
Sorry, maar dat is toch echt veel te makkelijk gesteld.

Massaal moeten thuiswerken door een pandemie is een volledig voorspelbaar iets. Pandemieën zijn namelijk voorspelbaar (als in: om de zoveel jaar is er gemiddeld een pandemie). Dit is niet de eerste pandemie en ook zeker niet de laatste die we zullen kennen.

En dat nog even los van het feit dat thuiswerken 10 jaar geleden al de norm had kunnen zijn. Zelfs zonder pandemie. Zelfs tijdens de pandemie, zelfs wanneer de overheid vraagt om meer thuiswerken staan bedrijven (90% van mijn klanten, allemaal zelfverklaarde "high-tech" bedrijven), scholen en universiteiten er op dat mensen naar een kantoor/klas komen om de hele dag achter een bureau/PC te komen zitten. Diep triest IMO. En nee: geen ICT capaciteit is anno 2020 echt geen goed excuus.

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

Interessant, als dit op te lossen is in de code dan zou dat snel geimplementeerd moeten worden. Als dat technisch niet snel kan, dan is is het ontwerp van de software een probleem.

Of er is gewoonweg niet genoeg prio gegeven om dit in de software op te lossen.

Lijkt mij dat Online Leer Omgevingen en de functionaliteit om online examens af te nemen, een functionaliteit is die al langer bestaat en geimplementeerd is door meerdere leveranciers, dus dat betekent dat er wel een Best Practice oplossing is die men dan moet implementeren. Buurtje afkijk :)

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

Zoals ik al zij, het is allemaal niet zo simpel, en achteraf is het heel makkelijk spreken...Soms is code oud, gebaseerd op oude best practices en oude architectuur modellen, dat verander je niet zomaar omdat je niet weet wat er verder zal omvallen.

Er is een wezenlijk verschil tussen wat software functioneel doet en hoe deze gebouwd is. Kijk naar supermarkten, ze doen allemaal hetzelfde, maar toch ga je de Aldi en de Lidl niet zomaar mengen. Ze doen dingen anders, leggen andere accenten. Dat is hun eigenheid, zo hebben ze zich lange tijd weten te onderscheiden. Soms zie je een supermarkt failliet gaan. ze hebben te lang vastgehouden aan het verleden en kunnen nu niet meer veranderen. Zo is het ook met software. Dan moet je afscheid nemen en iets nieuws zoeken.

Ik ben eens zijdelings betrokken geweest in het volledig herschrijven van een core business applicaties. Het origineel was Orcale forms (zeer oude tech, 20 jaar terug een geldige keuze) het nieuwe is gebaseerd op .net en microservices (hetgeen nu een best practice is).

Na 4 jaar ontwikkelen krijg je dus functioneel dezelfde software, alleen is onder de motorkap alles veranderd. Dit lukt enkel maar bij organisaties die geld hebben en die vaststellen dat hun software zo oud is dat ze er niet meer mee kunnen evolueren.. Ga het maar uitleggen aan die directeur dat hij x.000.000 € mag neerleggen om na 3 jaar dezelfde soft te krijgen, maar als hij het niet doet dat hij binnen 6 jaar out of business is (en dan weten we met zn allen dat het 4 jaar wordt en +20% budget)

We hebben het hier over scholen, die hebben meestal niet al te veel geld, "arme" klanten gaan naar "goedkope" leveranciers. Dat soort leveranciers heeft geen geld om continue hun legacy te upgraden. Het werkt nog en wordt verkocht... Uiteindelijk gaan ze er wel uit, maar tot die tijd zit je ermee..

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

Wederom interessant.

De basisfunctionaliteiten blijven grotendeels hetzelfde in het voorbeeld dat je geeft:

Alle supermarkten doen hetzelfde: Producten verkopen.

Echter verandert er wel wat in de dienstverlening zoals online verkoop/bezorging en klanten die zelf kunnen afrekenen. Dan moet je als supermarkt wel meegaan in die dienstverlening of zelf trendsetter zijn met nieuwe functionaliteiten aan te bieden.

Als onderwijsinstelling ben je ook afhankelijk van de leverancier en je eigen IT, maar je zou heden ten dage toch wel mogen verwachten dat een performance probleem binnen 7 maanden wel op te lossen moet zijn..
We weten niet wat er in de contracten staat tussen leverancier en klant. Alles wat wij als buitenstaander verwachten, maar niet in dat contract staat is niet relevant tussen leverancier en klant.

er kan zoveel misgaan...
Heeft de business aan IT of hun leverancier laten weten dat ze hun load maal 100 zouden doen?
Is er tijdig een analyse gestart of waren er ander prioriteiten aan de kant van de business
Kon IT tijdig leveren?
Kon de leverancier tijdig leveren?
Was er budget om dit alles te doen?
Was de timing haalbaar?
Is er terug gecommuniceerd dat de vraag, hoewel valide, onder de bestaande omstandigheden (time / budget) niet gerealiseerd kon worden?

...
We hebben het hier over scholen, die hebben meestal niet al te veel geld, "arme" klanten gaan naar "goedkope" leveranciers. Dat soort leveranciers heeft geen geld om continue hun legacy te upgraden. Het werkt nog en wordt verkocht... Uiteindelijk gaan ze er wel uit, maar tot die tijd zit je ermee..
Scholen hebben inderdaad vaak een beperk budget. Universiteiten hebben vaak alleen nog veel meer inkomsten naast de normale subsidie.

Een deel van het probleem zit hem vaak ook in het verplicht moeten aanbesteden. Ik werk zelf ook op een school en ik kan je vertellen dat zodra je aan moet besteden je meestal met een partij zaken moet gaan doen welke niet altijd de beste keuze is. Wij proberen dan ook zo veel mogelijk onder het bedrag te blijven voor verplichte aanbesteding zodat we zaken degelijk op kunnen pakken.

Daar naast zijn er ook de nodige onderwijsinstellingen / scholen koepels waarbij een groot deel van de voorziening is uitbesteed door gebrek aan interne kennis. Helaas zijn er de nodige partijen welke daar handig misbruik van weten te maken.

Ik ben dan ook dankbaar dat wij de kennis wel in huis hebben en het budget toegewezen krijgen waar dat nodig is. Dat heeft de onderwijsinstelling al veelvuldig geld bespaard. Onze software en onze toetsomgeving draaien gelukkig ook gewoon op recente software.

De corona maatregelen hebben er bijvoorbeeld wel voor gezorgd dat wij 180 extra laptops aan hebben moeten schaffen naast de bestaande systemen zodat er getoetst kan worden met inachtneming van alle maatregelen. Een behoorlijke kostenpost waarmee de studenten zo min mogelijk vertraging ondervinden bij het afnemen van de toetsen/examens
Meestal prutsende coders, hoogvliegers, ik wil niet toegeven types. Dan blijf je maar aanrommelen. Komt meestal solliciteren door de grote hoeveel healthy gratis lunch / gratis fitness / gratis training / dogs friendly / vele vrije dagen etc etc etc. Alles wordt er aangebonden om ze in de watten te leggen.

Ik heb maar al te vaak gezien dat je met wat belletjes naar een paar goede bedrijven het in no time is opgelost en deze nonsense niet nodig is.

Verder is blijkbaar deze weigerende healthy "baardmans" niet te vervangen. Ik ben van mening dat je zonder goed team en zonder dit aan te kunnen kaarten onderling je er niet goed zal uitkomen en het dus ook niet oplost. Vermoeden is dus ook dat er daar een stel nietsnutten werken die geen idee hebben wat ze doen maar wel een goede lunch krijgen. :+
Het probleem hoeft niet persé opschalen te zijn. Het kan ook zijn dat ze software niet ontworpen is om zoveel gebruiken tegelijkertijd aan te kunnen.

Echter weet ik niet waar het probleem is dus daar kan ik ook niks over zeggen.
Tja, als dat het onderliggende issue zou zijn ;)
Soms is opschalen wel een probleem.
Stel je zit aan de grens van de bandbreedte.
Dan moet je extra kabels in de grond gaan graven of andere dingen doen die niet triviaal zijn.

Het hangt af van waar de bottleneck zit of het makkelijk op te lossen is.

Als het lang duurt om ergens te komen omdat er teveel files zijn, of de wegen slecht zijn, dan helpt het niet om een snellere of grotere auto aan te schaffen.
Als het na 7 maanden nog steeds niet op orde is, wat hebben ze dan in de tussentijd gedaan om de situatie te verbeteren? Die 7 maanden zou genoeg tijd daarvoor moeten zijn, zou je denken.
Dat vind ik wel heel kort door de bocht. Ik vind sowieso vaak dat Tweakers storingen zien als 'er wordt niks gedaan' terwijl ik je kan garanderen dat iedere Tweaker die een IT systeem onderhoudt wel eens een storing heeft.
Natuurlijk is het vervelend, maar om meteen zo negatief er in te staan vind ik heel tekenend voor de wereld. Als bedrijf X waar Tweaker Y systeembeheerder is dan hoor je dat niet, omdat het niemand kan schelen of een klein bedrijf een storing heeft. Maar dat wil niet zeggen dat het niet gebeurt. Geen enkel systeem is perfect, daar kan je 7 maanden of 7 decennia mee bezig zijn, perfect gaat het nooit worden.

Ik vind ook dat die studentenbond wel een heel zwart/wit antwoord heeft (maar goed, dat is misschien ook hun taak). Na 7 maanden 'gaat het nog steeds niet goed', ik denk dat die persoon rechten studeert want het is pure shit. Nee, na 7 maanden is er een keer een storing, dat is helemaal niet hetzelfde als 'het is niet op orde'. Jammer dat zulke agressieve mensen de toekomst van bedrijven zijn, het zal je directeur maar zijn. Is er een keer een storing wordt je meteen aangevallen of ontslagen :+

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

Als de belangen zo groot zijn als bij een examen dat door duizenden mensen gemaakt moet worden, mag je wel verwachten dat problemen bij zo'n examensysteem met 5 a 7 maanden opgelost zijn.
Dat snap ik, maar ik snap niet waarom het statement 'na 5 tot 7 maanden' steeds terug komt. Het systeem draait al 7 maanden, en heeft nu een probleem. Als dat probleem er daarvoor niet was, dan kun je niet zeggen 'Oh ja het probleem bestaat al 7 maanden'.
Dat is alsof Tweakers een storing heeft en zegt 'Goh al 20 jaar en nog steeds de basis niet opgelost', je kunt het zeggen maar het slaat niet echt ergens op.
Waarschijnlijk, al weet ik dat niet zeker, is dit de eerste keer (gezien het moment van het jaar) dat zoveel studenten tegelijk tentamens maken.

Als je dan geen degelijke load tests hebt uitgevoerd van te voren, dan kan dit het gevolg zijn. Ik vind het verwijtbaar.
Wat je hier bedoelt te zeggen is dat er waarschijnlijk een ander probleem aan de hand is en daardoor storing. Dat maakt voor de eindgebruiker uiteindelijk niets uit. Als de gebruiker 7 maanden geleden niet goed kon werken met het systeem, en op dit moment op een moment dat het moet werken ook niet dan kan het wel een andere oorzaak hebben maar uiteindelijk onder streep doet het systeem niet wat je er van verwacht.

Op een bepaald moment kom je uit op een punt waarbij de oorzaak niets meer uitmaakt maar dat het een gevoelskwestie is geworden. 'Het systeem ligt er altijd uit' terwijl aantoonbaar kan worden gemaakt dat dat nit zo is. Als een systeem eenmaal een naam heeft gekregen als 'onbetrouwbaar' dan kom je daar heel slecht vanaf.
Eens. Storingen gebeuren, een goede IT-club onderscheid zich niet door het aantal storingen, maar hoe snel ze ze op kunnen lossen...

Maar, in dit geval had een load-test geen kwaad gekund. En als die wel gedaan is, dan is die mogelijk niet representatief geweest.

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

Kort door de bocht is het zeker. Maar Die tijd is wel degelijk een factor. Sinds juni is al bij veel hogescholen en universiteiten bekend dat er geen fysiek onderwijs zou zijn. Dus de mogelijkheid dat er online tentamens gemaakt moeten worden, is groot. Je weet voor eind juli wat het aantal mensen is wat maximaal je systeem gaat gebruiken. Dus moet je daarop roosteren en de capaciteit op incalculeren.

Als jij een bedrijf vraagt om die capaciteit te hosten/aanleveren. Dan mag je er wel vanuit gaan. Na dus 3+ maanden nog niet op een rijtje hebben wat je load zou kunnen zijn is dan wel een slordige zaak. En zeker ook het feit dat dit niet getest is op grotere schaal.

Offtopic(misschien?): De HAN heeft het overgrote deel van zijn tentamens fysiek gedaan omdat ze het niet konden waarborgen naar weten. Veel maatregelen waren er en er zijn nog steeds daar strenge richtlijnen aan. De studieruimtes zijn omgebouwd tot tentamen zalen om mensen kwijt te kunnen. Dus iets fysiek doen is lastig, maar soms onvermijdelijk.
Hangt er een beetje vanaf hoe diepliggend het probleem is natuurlijk. Als het puur een gebrek is aan systeem resources dan kan het afdoende zijn om deze bij te schalen. Als het echter met genoeg theoretische capaciteit qua resources nog steeds fout gaat is er meer aan de hand en moet dat geanalyseerd worden, software of platformen aangepast, etc. Of dat zeven maanden moet duren laat ik even in het midden maar daar gaat sowieso tijd over heen.

Daarnaast is het zo dat het testen van performance en load impact nog best lastig, in ieder geval op een manier dat je ook daadwerkelijk de situatie nabootst zoals het met echte gebruikers ook gebeurt. Het is komt vaker voor dat bij het testen van software men zoveel mogelijk heeft rekening gehouden met de productie situatie en dit ook heeft getracht te emulgeren om er vervolgens toch achter te komen dat bij de echte situatie er bepaalde zaken die je tijdens het testen niet tegen komt of kan reproduceren een dusdanige rol spelen dat in productie je systeem nog steeds niet presteert.

Daar komt nog eens bij dat als het probleem in de software zit en die software heb je niet in eigen beheer ontwikkelt dan ben je dus ook nog eens afhankelijk van een derde partij om het op te lossen.

Nogmaals, ik heb geen inzichten in wat ze wel of niet hebben gedaan en of bovenstaande verhaal op deze situatie van toepassing is. Ik reageer voornamelijk op het gedachte goed dat een x hoeveelheid tijd voldoende moet zijn om iets op te lossen.

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

Nuja, het hangt ook altijd een beetje af van wie een systeem opzet en hoe goed ze hun materie beheersen. Enkele jaren terug hadden we hier een nieuwe applicatie en die draaide voor geen meter. Toch had de VM waar deze in geïnstalleerd was enorm veel resources ter beschikking. 8 CPUs en 32GB geheugen, later zelfs verhoogd tot 128GB. Op een gegeven moment kwam een collega van het team dat de monitoring doet naar mij en vroeg hij of ik iets zinnigs kon vertellen over wat hij zag. 100% CPU belasting op 1 virtuele CPU en voor de rest alles normaal. Wat bleek. 1 van de gebruikte componenten had een limitatie van 1 CPU socket en 4 cores. Door de VM met 8 sockets van 1 core uit te rusten liep die applicatie continue tegen CPU beperkingen aan. Heb men collega dan maar een ticketje naar de verantwoordelijke laten sturen met de melding om het te laten aanpassen. De volgende dag draaide die app netjes op 4 cores met gemiddelde belasting en was de performance er een stuk op vooruit gegaan.
Door de VM met 8 sockets van 1 core
Wow, leuke anekdote hoor. Pijnlijk. Dit is niet conform basic VMware best practices, toch?
Met betrekking tot testen ben ik het helemaal met je eens dat de testsituatie zoveel mogelijk de productie-omgeving nabootst, om er vervolgens achter te komen dat er toch problemen zijn op de Productie omgeving.

Wellicht dat deze situatie nooit eerder is voorgekomen bij deze onderwijsinstelling icm de IT-omgeving en de hoeveelheid gebruikers.

Je kunt dus productieproblemen nooit 100% afvangen. Maar je kunt wel voldoende maatregelen nemen om de (performance)test zo representatief mogelijk te laten zijn voor Productie zodat je de kwaliteit kan vaststellen van de Performance.
Ik ben het met je eens dat je zou verwachten dat zeker nu met corona en digitale lessen/examens de digitale les omgeving in order zou moeten zijn gemaakt.

Alleen is het echter wel zo, dat het ontwikkelen van software tijd kost. Ik weet verder niet hoe daar de infrastructuur is ingericht. Misschien is het op te lossen door extra server er aan toe te voegen. Maar misschien is het wel zo, dat de software niet kan schalen tot zulke grote gebruikers aantallen.

Als de software ontwikkeld is met max 100 gebruikers in gedachten en in een keer zijn het er 5000, dan zullen er delen gaan piepen en kraken. Een klein voorbeeld, als ze een log-in systeem gebruiken dat ontworpen is om op één server te draaien, dan kan je die niet zomaar op 2 or 10 servers draaien. Dan zal het log-in systeem fundamenteel moeten veranderen.

Maar al met al, Ik keur het zeker af dat dit is gebeurd. Als ze wisten, of hadden kunnen weten dat het system het niet aan kon, dan hadden ze naar alternatieve vormen van examens moeten kijken. Ik vind dat dit de studenten niet negatief mag beïnvloedden.

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

Van de 7 maanden, is niet helemaal eerlijk. Er heeft ook nog een zomer vakantie van ruim 2 maanden tussen gezetten. Waardoor je geen besluiten kan nemen en eventuele ontwikkelingen op hun gat liggen.
Bij welke werkgever zit jij?
2 maand vakantie, wow!
*lol* Nee.
Maar zo gaat het toch in de zomer periode. Dat alles zo'n beetje 2 maanden stil ligt? Het is elk jaar weer een verrassing :)
Maar zo gaat het toch in de zomer periode. Dat alles zo'n beetje 2 maanden stil ligt?
Overheid of zuig sector, onderwijs misschien.
Maar 50% van de Nederlanders werken nog bij echte bedrijven. Wij hebben dit jaar geen vakantie gezien.

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

Het artikel gaat ook over de onderwijs sector. En inderdaad daar ligt alles plat. Kan je ook als software leverancier voor het onderwijs ineens een stuk minder ook al heb je zelf geen vakantie.
En los van die maanden vakantie, zaten de ICTers bij de universiteit voor Corona duimen te draaien? Of hadden ze het al heel druk en moet er nu extra werk gedaan worden? Is er extra personeel aangenomen voor het extra werk (waar vind je op dit moment goede ICTers, er is krapte)?
Mijn persoonlijke ervaring met opleidingen en Corona is dat de onderwijsinstellingen in het begin met de armpjes over elkaar en de voetjes op het bureau zijn gaan hangen. Toen het na de bouwvak nog niet over bleek te zijn werd er pas voorzichtig actie ondernomen. (Niet op basis van de RUG, gewoon een mbo opleiding bij het KW1C)
Misschien interessant als toevoeging, de Nestor omgeving van de RUG is niks anders dan Blackboard met hier en daar een eigen layout en enkele eigen extra's. De Tentamens verlopen via standaard blackboard toetsen.
Vindt er wel proctoring plaats?
Nee. Tenminste, het is tot op heden niet de bedoeling dat het gebruikt wordt, maar in het verleden werden er, buiten het college van bestuur, toch proeven gedaan. Neemt niet weg dat de kans aanwezig is dat er in de toekomst wel Proctoring gebruikt gaat worden als je kijkt naar wat de faculteiten van de RUG zeggen over het aantal fraudegevallen.

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

Hoe wordt er dan gecontroleerd op fraude als het via Blackboard gaat?
De examens worden zo aangepast dat het moeilijker is om erop te cheaten.

Internet moet praktisch gezien niet helpen, open boeken zijn totaal toegestaan, en je moet zweren dat je niet met andere studenten praat. Dat laatste is natuurlijk wel een beetje een probleem.

Voor zo ver ik weet gaat het ook niet perfect. Sommige examens worden echt bizar goed gemaakt online in vergelijking met de fysieke versies van eerdere jaren.
De online tentamens zoals deze nu verlopen zijn inderdaad precies hetzelfde als de digitale tentamens, behalve dat je inderdaad moet zweren dat je niet communiceert. Super gemakkelijk natuurlijk om te cheaten en te communiceren mocht je dat willen.

Groter probleem wat ik zelf heb gemerkt is dat een aantal professoren nu besloten heeft om vragen buiten het lesmateriaal om te vragen om voor het 'open boek' en 'gemakkelijk kunnen cheaten' te compenseren. En dan heb ik het niet zozeer over meer in de theorie duikende vragen welke je kunt oplossen met genoeg kennis en het begrijpen van de theorie. Voorbeeld: Wij hadden theorie over bepaalde simulaties waarbij alleen inhibitory responses werden gesimuleerdt en excitatory expliciet niet behandeld worden en 'out of scope' van de course liggen. Dit ivm de complexiteit en problemen die optreden bij het gebruik van excitatory responses. Vervolgens krijg ik op mn tentamen een in-depth vraag over excitatory responses en hoe je dit kan simuleren etc...

Bron: Ben zelf student aan de RUG.
Blackboard heeft een aantal anti fraude maatregelen aan boord.
Ik studeer niet aan de RUG, maar aan de RU. Duidelijk is dat het grootste probleem m.b.t. fraude hem zit in communicatie tussen studenten. Door de maanden heen zijn tentamens steeds meer vragen gaan krijgen, waardoor je bijna nooit meer hetzelfde tentamen krijgt als iemand die je kent. Tentamens worden zoals gezegd zodanig ingericht dat je er alles bij kan houden wat je maar wil - het zal uiteindelijk op inzicht aankomen.
Ik kende de term proctoring niet in deze context (kreeg wel acute sfincterkramp). Nu ik je link las ben ik best verbaasd dat dit niet gebeurt. Mijn kinderen op de middelbare school die online getoetst werden moesten verplicht webcam en microfoon aan hebben staan via MS Teams.(En plechtig verklaren niet te frauderen...)
Proctoringsoftware is nog wel even andere koek dan MS teams aan hebben staan.

Room scans, eye en hand-tracking, monitoren van alle processen op de PC, tracken van al het verkeer over internetverbinding, en als er ook maar iets niet 100% in orde lijkt wordt dit gelijk geflagged als mogelijke fraude. De Stasi zou er jaloers op zijn.
WTF dat gaat toch veel te ver.
En dan nog draai je er gewoon iets op een andere internet verbinding naast.
Behalve dat je hand en oogbewegingen ook meegenomen worden. Dus als het opvalt dat je regelmatig naar links kijkt wordt je al gemarkeerd.
Dat gaat wel "deep"....
Maar tegelijkertijd lijkt dit me een veel te kostbare en daarmee onhaalbare oplossing om overal thuis te plaatsen. Dan zie ik eerder gebeuren dat dit op de campus gebeurt in individuele hokjes die tussen tentamens gereinigd worden.
Proctoringsoftware is al lang en breed ingezet op nagenoeg elke universiteit in Nederland, of Europa voor mijn part. Deze maakt gewoon gebruik van de webcam en microfoon die je als student zelf moet verzorgen, en is meestal te installeren als een plug-in voor je browser. (moet vaak Google Chrome zijn, omdat Mozilla dit soort zooi wel niet toe zal staan).

De universiteit betaald voor deze software, maar kennelijk is deze dus zo geprijsd dat het voor de universiteit wel een aantrekkelijk alternatief op fysiek tentamineren is.
Middelbare scholen waren (en zijn) over het algemeen niet klaar voor toetsen op afstand.
Bij universiteiten is dat anders maar ook die waren niet voorbereid op de schaal waarop er nu op afstand getoetst moet worden.

En "ff" een nieuw pakket kopen betekent vaak een hoop hassle in de vorm van aanbestedingstrajecten en implementatie.
Je kan gerust stellen dat het meer dan enkele extra's zijn. Die omgeving is haast meer RUG dan Blackboard inmiddels.
Interessant, wij hebben BB een aantal jar terug gedag gezegd. Als er veel is aangepast dan neem ik aan dat ze niet naar de SAAS versie zijn overgestapt, klopt die aanname?
Ik durf dit niet zeker te zeggen, maar ik geloof van niet inderdaad.
Capaciteit tijdelijk verhogen door de omgeving te kopiëren? En klassen A-M werken op omgeving 1 N-Z op 2. Misschien te simplistisch gedacht, maar als de omgeving niet (stabiel) kan groeien, maak je er gewoon meer.
Licentietechnisch zullen er wat haken en ogen aan zitten, maar daar valt vast over te onderhandelen. Zeker als het geleverde product eigenlijk niet voldoet.

Gezien de opmerking in het artikel dat de problemen op maandag binnen een uur waren opgelost, lijkt het me meer een kwestie van resources van de omgeving dan software.
Mogelijk werkt dat niet, als de samenstelling van klassen per onderwerp of tentamen verschilt.

Toen ik aan de RuG studeerde deed ik Natuurkunde, maar heb ik ook vakken gevolgd bij Filosofie, Psychologie, Bedrijfskunde, Aardrijkskunde, Wiskunde, Informatica, Scheikunde en Rechten.

Dat soort dingen worden erg lastig als je meerdere gescheiden omgevingen hebt.
Er van uitgaande dat de boel plat gaat omdat er tegelijkertijd verschillende tentamens en veel klassen moeten toetsen, zou je natuurlijk ook de verdeling niet op klas maar op tentamen kunnen maken. Uiteraard is het allemaal lastiger dan één grote stabiele omgeving, maar beter dan het roulettespel waarbij je tentamens opnieuw moet maken (zowel opleiding als student) omdat er halverwege fouten optreden of de helft van de klas wel kan inleveren en de andere helft niet.
Daar heeft een informatice student zijn tentamens niet voorbereid. ;)
Vooral vervelend voor de studenten. Ik hoop dat ze de oorzaak vinden, deze oplossen en vervolgens snel en goed de gehele keten doortesten om eventuele andere knelpunten op te lossen voordat er weer stront aan de knikker is.
Grote aantallen online studenten en meerkeuze tentamens is ook niet duur lijkt me.
Daar heb je helemaal gelijk in! : )

Op dit item kan niet meer gereageerd worden.