Laatste vrijdag van juli is Dag van de Systeembeheerder

Vraag het maar aan CrowdStrike: je deployt niet op vrijdag. Vrijdag is voor documentatie en achterstallig onderhoud, want iedere systeembeheerder wil om 17.00 lekker het weekend in. Dat is zeker vandaag zo, want het is vandaag de Internationale Dag van de Systeembeheerder.

Oude serversDe Dag van de Systeembeheerder vindt jaarlijks plaats op de laatste vrijdag van de maand. Op vrijdag ja, omdat dat meestal de rustigste dag van de week is en in juli hopelijk ook de rustigste dag van het jaar. De Dag van de Systeembeheerder, ook wel Sysadmin Day of BOFH Day genoemd, is bedoeld als een ode aan de beroepsgroep die je doorgaans alleen ziet als alles in de soep loopt, maar die er juist voor moet zorgen dat die momenten tot een minimum beperkt worden.

De dag stamt uit het begin van deze eeuw. In 2000 riep een systeembeheerder bij HP op om systeembeheerders eens een hele dag in het zonnetje te zetten, vergelijkbaar met hoe dat ook gaat op bijvoorbeeld Secretaressedag in april. Sindsdien wordt de dag wereldwijd her en der gevierd, al zijn er weinig officiële evenementen of vieringen rondom de herdenking.

Aanvankelijk ontstond de dag omdat de oprichter een advertentie zag waarop een systeembeheerder te zien was die een printer installeerde en daarvoor bossen bloemen en fruitmanden kreeg als dank. Dat is hoe we de dag nu nog steeds kunnen vieren, al zullen de meeste systeembeheerders al blij zijn met een Slack-bericht en een welgemeend bedankje. Dus denk vooral aan ze, de volgende keer dat het printen feilloos verloopt en het netwerk een hele dag naar behoren heeft gefunctioneerd. Dat gaat namelijk niet zomaar. Vraag het maar aan Tweakers-sysadmin Kees, die we in 2021 nog aan de tand voelden voor deze dag.

Door Tijs Hofmans

Nieuwscoördinator

26-07-2024 • 17:08

52

Submitter: Portenge

Reacties (52)

52
52
21
1
0
28
Wijzig sortering
🌷 voor Kees? 😉😘👍
Vraag het maar aan CrowdStrike: je deployed niet op vrijdag.
Volgens mij kan het tegenwoordig prima. Zeker wanneer een boel ook getest is (denk dan ook aan automated tests zoals unittests en ui tests) en dergelijken, zie ik niet waarom je niet op een vrijdag zou kunnen deployen. Het kan geen reden zijn omdat 'het misschien fout kan gaan' dat je dan niet deployed. Dat kan op elke andere dag immers ook gebeuren, ook dan kan het als het tegenzit nachtwerk worden wanneer een en ander fout gaat, maar dan is er ook niet goed getest bijvoorbeeld en zijn er andere zaken niet goed waardoor het fout gaat.

IMO is 'je deployt niet op vrijdag' echt iets van het verleden. Tegenwoordig met alle mogelijkheden in termen als load balancing, scalability etc, zou je eigenlijk niets moeten merken als er een machine even uit is voor een update. In een tijd waar alles snel moet en liefst ook 24/7 beschikbaar moet zijn (want de gehele wereld komt in de webshop bijvoorbeeld) is er eigenlijk nooit een goed moment om op te deployen. In dat licht maakt het (imo) totaal niet meer uit wanneer je deployed.

Hou je je vervolgens wel vast aan het stramien om niet op een vrijdag te deployen, dan kan dat natuurlijk, maar dan betekend dat wel dat je de omgeving en de applicatie(s) niet vertrouwd. Waarom zou je dat dan alleen op een vrijdag opeens niet vertrouwen? Dan is "Ik wil om 17:00 weekend vieren zonder gebeld te worden dat iets niet meer werkt" natuurlijk geen geldig excuus. Op een andere dag kan dat zoals gezegd dus net zo goed gebeuren.

[Reactie gewijzigd door CH4OS op 26 juli 2024 17:27]

Omdat het na vrijdag weekend is en er dan niemand beschikbaar is om eventuele problemen op te lossen?
Omdat het na vrijdag weekend is en er dan niemand beschikbaar is om eventuele problemen op te lossen?
Ik denk niet dat een werkgever dat waarderen kan om dan iets niet op te lossen. Of dat nu op een vrijdag is of op een Dinsdag bijvoorbeeld. Dat maakt echt 0 verschil. Systemen of (grote) webwinkels gaan praktisch nooit meer uit of dicht anno 2024, die enkele webshop die op Zondag sluit zijn ook haast uitgestorven (ja ze hebben echt bestaan...), in die zin wordt er in de tegenwoordige tijd echt wel totaal anders verwacht. Niet alleen door werkgevers, maar ook door consumenten die op zondag tijd hebben om iets te kopen via een website, wat bij voorkeur dan (en als het even kan) op Maandag al geleverd moet worden.

Dat doet mijn werkgever overigens ook, ik heb een nooddienst telefoon, zodat ik indien nodig daarop gebeld kan worden in het holst van de nacht, maar ook in het weekend. Ook "het is weekend" is een oude mentaliteit wat mij betreft, natuurlijk heeft iedereen altijd op een bepaald moment in de week minimaal 2 dagen in de week vrij om bij te komen e.d, maar dat hoeft niet per se meer na de vrijdag te zijn.

Er zijn genoeg mensen die een onregelmatigheidstoeslag krijgen, waardoor ze wisselend werken en soms ook gewoon in het weekend, omdat de fabriek een specialistisch product maakt bijvoorbeeld en 24/7 moet blijven draaien, waarbij stoppen geen optie is. Je kunt dan dus ook niet (meer) komen aanzetten als ITer "maar ik heb weekend" als er iets gebeurd en een en ander stil ligt.

[Reactie gewijzigd door CH4OS op 26 juli 2024 17:43]

Ik denk dat je veel te serieus reageert op iets wat als grap bedoeld is ;-) Tijd voor weekend?
Het is ook een stuk risico-afweging, wanneer is de impact van een deployment het kleinst, wanneer is die het makkelijkst te herstellen als er iets fout gaat en is daar personeel voor beschikbaar? En is een systeem kritisch voor de primaire processen, of is het alleen maar ondersteunend? En hoe lonend is het voor al die systemen om load balancing en scalability in te richten, en is een organisatie daar al ver genoeg voor? Dat zijn allemaal afwegingen die meespelen in het bepalen wanneer bepaalde zaken gedaan worden, en dan kan "op vrijdag niet deployen" best wel eens een prima uitgangspunt zijn voor een deel van de organisatie.

Ik heb voor applicaties waar ik aan gewerkt heb bij verschillende werkgevers de discussie langs horen komen, ook over bereikbaarheidsdiensten en 24/7 beschikbaarheid, maar die keutel wordt tot nu toe iedere keer weer ingetrokken omdat de applicaties toch niet zo kritisch zijn dat 24/7 up-time nodig is en de meeste problemen toch vooral buiten onze invloedssfeer liggen. Dan gaat het op een gegeven moment ook over het kostenplaatje en personeelsbezetting in het team en dan blijft de discussie weer een paar maanden stil.
Hey, stop eens met projecteren kerel! Vervelend voor jou, maar dit betekend niet dat dit dan ook voor iedereen dient te gelden. Weekend is weekend.
Ik projecteer toch ook niets? Ik zeg alleen dat voor iedereen het moment van weekend anders kan zijn, dat betekend ook dat iemand niet twee dagen achter elkaar vrij heeft… Geen idee hoe dat projecteren is… 🤷‍♂️
Liever een storing op maandagmiddag dan vrijdagavond. Ik zit er niets mee in om gewoon door te werken tot een kritiek probleem is opgelost, en heb dat ook al mogen doen, maar als ik de keuze heb, liever niet in het weekend.

Uiteraard zijn er dingen die je continue laat updaten, zoals beveiligingsfixes. Maar grote aanpassingen in je eigen infra doe je over het algemeen niet op vrijdagnamiddag wanneer die infra kritiek is voor je onderneming. Nuja, als ze kritiek is plan je het sowieso buiten kantooruren natuurlijk.

En nee, wij hebben geen nooddienst bij ons, ook geen wachtvergoeding, maar als het in het weekend toch misloopt, wees maar zeker dat men begint rond te bellen. Krijg je ineens 1 van onze beheerders aan de lijn op zaterdagavond met al enkele glazen achterover. Maar hopen dat dat goed gaat.

En wanneer je bedrijf gewoon kantooruren hanteert, dan heb je gewoon weekend op zaterdag en zondag. En natuurlijk zijn er enorm veel bedrijven waarbij dat niet zo is, maar het aandeel diensten dat wel degelijk gewoon 9-to-5 draait op werkdagen is volgens mij nog altijd een heel stuk groter.
En dat is waar het fout gaat, alles moet maar 24/7 door. Wat is er mis met even een paar dagen wachten op je bestelling?
Uiteraard zijn systemen van een webshop 7x24 uur beschikbaar. Het gaat er echter om wanneer downtime het minste impact heeft. Het gaat erom wanneer recovery time het grootst is.

En in beide gevallen zal "vrijdag (na werktijd)" niet het beste resultaat opleveren. Noch zal een 'we hebben maatregelingen getroffen" (Scalability, load balancing) enig invloed hebben. Voor load balancing maakt het echt niets uit of het onderuit gaat op maandag, dinsdag of whatever-dag. Hetzelfde geldt voor het aantal servers waarop het draait. Maakt niets uit of het 10/20 of 1 server is. Down is down. Uiteraard maakt het aantal servers wel uit of een applicatie down is of niet, maar het heeft geen enkele invloed op de dag / deployment

[Reactie gewijzigd door Het.Draakje op 26 juli 2024 18:47]

Helemaal mee eens!
Had in het verleden een klant, productie draaide 24x7, +/- 20 personen op kantoor. Bij onze eerste grote update daar werd vanwege kantoor gekeken naar vrijdag-avond cq zaterdag om dit te doen.
Niks daarvan zei de eigenaar, maandag ochtend 9u00 beginnen. Eerst vraagtekens aan onze kant want kantoor plat, maar dezelfde redenatie als hier boven: De andere (software) leveranciers gaven in het weekend niet thuis, dus bij problemen kom je dan toch weer op maandag ochtend uit.
Uiteraard is het een kwestie van geld.

De baas wil niet betalen voor 24 uur support, dan heeft een deployment in het weekend weinig zin. Is het belangrijk dat de software wel gedurende de normale kantooruren beschikbaar is dan zal hij de geldbuidel moeten trekken. E.e.a. heeft (uiteraard) geen enkel invloed over wel/niet op vrijdag deployen.
Niet dat de baas niet wou betalen, maar leveranciers die dat gewoon niet aanbieden. (Ook de concurenten niet.)
Neen.

We accepteren dat geen enkel programma foutloos is. De stap naar 'iedere deployment kan problemen veroorzaken' is niet bepaald groot.

Met andere woorden: vertrouw geen enkele deployment ongeacht tijdstip.

Load balancing doet geen ******** tegen een slechte deployment. Het heeft alleen een voordeel als je de deployment terug moet draaien. Voor scalability heb ik maar een woord: WTF? (heeft dat te maken met een recovery van een slechte deployment).

De vrijdag (iedere werknemer ligt op intensive care na de werkweek) is de meest slechtste dag om te deployen.

De meest ideale dag is zondag. (Zaterdag lekker uitslapen). Minimaal 24 uur resolve time. En ja, liefst zo vroeg mogelijk. Want de halve wereld (of de hele wereld afhankelijk van je applicatie) ligt lekker te slapen op zondag morgen 06:00. Ook bij een 24/7 economy..

Ik heb een aantal jaren on-line banking " mogen"ondersteunen en mijn standpunt is heel duidelijk. Wil je een andere deployment dan op zondag dan wordt je vriendelijk verzocht om even wijdbeens te gaan staan. Ja, iets wijder.

Om vervolgens lekker uit te halen met een flink eind hout. Liefst tropisch hardhout.

Om even terug te gaan naar het onderwerp: systeembeheer is iets meer dan het vertrouwen op de blauwe ogen van een ontwikkelaar dat het wel goed zit.

Edit: wellicht hier en daar een smiley toevoegen.

[Reactie gewijzigd door Het.Draakje op 26 juli 2024 18:13]

Ben minder hardlijnig dan jij, en zou grappig genoeg het weekend vermijden.

Maar denk dat jij vooral dingen met betalingsverkeer doet en daar zit je al snel aan de nacht van zaterdag op zondag vast :-( (heb ik ook ruime ervaring mee)

Vanwege beschikbaarheid personeel, is mijn voorkeursmoment tegenwoordig dinsdag of donderdag 10:00, direct na de stand-upjes, zeg maar :-)

Iedereen koffie gehad, intussen hebben we de boel qua techniek wel zo dat technische onbeschikbaarheid minimaal
is, en dan is beschikbaarheid en frisheid van mensen juist maximaal.

Gaat het mis, dan kan je razendsnel opschalen, met de grootste beschikbaarheid van de meest gekwalificeerde mensen. (Met als bijkomend voordeel: in zo’n geval
krijgen juniors vaak ook nog eens iets mee van een verstoring, anders dan alleen maar in de nabespreking. Praktijk is toch echt de beste leerschool)

[Reactie gewijzigd door Keypunchie op 28 juli 2024 07:42]

Heb ook ervaring met betalingsverkeer. Zit daar echter al lang niet meer.

Als je een duizenden eindgebruikers hebt (web-site bezoekers) dan is deployen tijdens kantooruren geen optie. Die loadbalancer staat er niet voor niets, die instances zijn nodig want anders is de performance te laag. Dan moet je naar een tijdstip waar het gros van de klanten lekker ligt te slapen. Zoiets staat er dan ook wel in de SLA.

Juniors draaien gewoon mee. Ze doen de acceptatie deployment, met een senior aan de zijlijn. Kijken een paar keer mee met productie deployments en daarna een paar keer de gewone run (doe je acceptatie, dan doe je ook productie) met een senior op het vinkentouw. Na vier / vijf productie deployments moeten ze het toch wel zelfstandig kunnen. Komt wel voor dat het niet lukt, maar zo iemand werk je met (niet zo) zachte hand richting de uitgang.

Opschakelen bij problemen daar heb je, in een professionele organisatie, geen problemen mee. Er was altijd een manager on duty.

Uiteraard werk ik liever niet in het weekend. Maar het is niet te vermijden. Zeker niet als je 3 / 4 deployments per maand mag doen. (En dan heb je ook nog de OS- en Hardware patches, etc.)
Als je een duizenden eindgebruikers hebt (web-site bezoekers) dan is deployen tijdens kantooruren geen optie. Die loadbalancer staat er niet voor niets, die instances zijn nodig want anders is de performance te laag. Dan moet je naar een tijdstip waar het gros van de klanten lekker ligt te slapen. Zoiets staat er dan ook wel in de SLA.
Dit vind ik dan wel echt de zegen van "cloud-native" (denk aan Kubernetes). Maakt nauwelijks uit, want capaciteit schaal je gewoon standaard al dynamisch bij en af. Dus het enige risico dat je over houdt is dat of een operator iets grondig verprutst (maar goeie voorbereiding en dat gebeurt praktisch nooit), of dat er iets mis is met de change zelf, bvb. software-bug en je moet terugrollen.

Maar ook dat laatste kan dus met cloud-native benaderingen mooi gemitigeerd worden met blue-green deployments benadering. Wat dat betreft vind ik de flexibiliteit van containerisatie, stateless services, etc, echt een feestje als beheerder.

[Reactie gewijzigd door Keypunchie op 28 juli 2024 11:27]

Tja, die regelgeving. Cloud base is helaas geen optie. Gewoon je eigen datacentra. (Produktie en acceptatie/uitwijk).
Oops, vandaag al 4 deploys op tweakers gedaan ;)
In theorie wel, in de praktijk...

Het begint erop te lijken dat het 'Crowdstrike' fiasco heeft kunnen gebeuren omdat ze enkel geautomatiseerde tests in de CI/CD pipeline hadden opgezet en er geen deployment test op een daadwerkelijk systeem gedaan werd (Ars Technica en andere sites hebben hier wat over geschreven).
Dit kan natuurlijk ook geautomatiseerd worden, en dan had deze bug daarmee wel boven water gekomen omdat alle systemen knalden maar wat 'fuzzy' testen door een mens voegt nog altijd wat toe (IMO).

Wel denk ik dat dit soort updates niet per se kunnen wachten maar daar moet dan de organisatie op ingericht worden (mensen die zaterdag/ zondag beschikbaar zijn, etc)
IMO is 'je deployt niet op vrijdag' echt iets van het verleden
Het changemanagement maakt een risico analyse, daarbij wordt er zeer zeker wel het tijdstip van uitvoeren van de change in meegenomen. Sommige bedrijven hebben freeze periodes waarin zelfs zo min mogelijk changes doorgevoerd worden.

[Reactie gewijzigd door nullbyte op 27 juli 2024 21:24]

IMO is 'je deployt niet op vrijdag' echt iets van het verleden
Wat mij betreft voor de meeste organisaties niet. Ook met al je CI/CD en automatische testen.

Je plant dit niet voor de situaties waarin het goed gaat, maar waarin het *fout* gaat.

Als het fout gaat, dan is op vrijdag domweg bij de meeste organisaties een gebrek aan “key personnel”, zowel bij de techniek als bij de business om snel te schakelen.

En met pech gaat je verstoring ook het weekend in. (Ook een kleine)

Doordeweeks heb je de makkelijke optie om de volgende ochtend de koppen bij elkaar te trekken, plannetje te maken en de boel vlot te trekken.

Scheelt een hele hoop overhead, frustraties en gedoe.

Dus, doe lekker je ding uiteraard en het is geen verplichting, maar als het niet hoeft, dan vermijd ik de vrijdag voor gepland onderhoud.
Helemaal gemist, mijn werkgever gelukkig ook ;)
de redactie blijkbaar ook, want de werkdag zit er voor velen al op. Nobody cares, zoals gewoonlijk.
Read-only Friday - ik hou mij daar al jaaaaaaren aan.
Wat zo laat nog een post maken over Dag van de sys admin. Volgens mij waren jullie dat zelf vergeten, volgend jaar maar op donderdag (24/07/2025) een post maken
Of op Donderdag al klaarzetten om de sysadmins in de bloemetjes te zetten wanneer ze op kantoor toekomen en Tweakers openen.
Beste medeTweakers,

Gefeliciteerd en dank weer voor al jullie harde werk👊
haha niet releasen op vrijdag...dat is echt een ding ja. Doen wij ook nooit. Uiterlijk donderdag!
Ik wil mijn 2 sysadmins vandaag wel bedanken, maar ze hebben allebij vrij. :+
Ik was in ieder geval blij dat voor de eerste keer in 25 jaar mij een patatje ter ere van sysadminday aangeboden werd 😏
dan heb je meer gekregen dan ik, want ik ben nog nooit beloond in de 24 jaar dat ik als sysadmin werk.
Happy late sysadmin day everyone !!

Op dit item kan niet meer gereageerd worden.