Als professioneel techneut moet ik zeggen dat het draaien van honderden servers in een Kubernetes cluster een heel gedoe kan zijn als het gaat om upgrades. En laten we vooral niet de verschillende servers vergeten, van grote enterprise-servers tot kleine twee-dudes die hun banjospel delen, die allemaal individuele aandacht nodig hebben.

Om mogelijke problemen te beperken, upgraden we meestal 's nachts in batches voor onze omgevingen van consumentenformaat. Dit gaat meestal probleemloos, maar zoals met alles wat met techniek te maken heeft, kom je soms onverwachte problemen tegen. Als een Kubernetes node down gaat of als er andere infrastructurele problemen optreden, zal het upgrade script stoppen na het voltooien van de huidige taak. Maar hoewel deze aanpak prima werkt, heb ik geen rekening gehouden met verminderde prestaties die de upgrades kunnen vertragen tot een kruipsnelheid, waardoor sommige van onze klanten worden geconfronteerd met een onbeschikbare omgeving wanneer hun server nog steeds in onderhoudsmodus is voor een langere periode als gevolg van langzame maar gestage upgrades.

Om zulke scenario's in de toekomst te voorkomen, heb ik een tijdcontrolefunctie in het script geïmplementeerd. Het script controleert nu de tijd voordat het elke upgrade uitvoert en als het buiten de aangewezen uren voor upgrades valt, wacht het tot de geplande tijd aanbreekt.

Onze filosofie is om de dingen langzaam maar zeker te doen als het op upgrades aankomt. We springen niet meteen op de nieuwste versie; in plaats daarvan wachten we tot onze infrastructuur soepel draait, de ontwikkelaars een aantal mooie fixes voor de serverrelease hebben uitgebracht en we zeker weten dat er geen grote bugs zitten in de release die we in productie brengen. Daarom lopen we over het algemeen achter met versies. Nextcloud brengt om de paar maanden nieuwe versies uit en hoewel dit geweldig is, zijn ze niet altijd meteen stabiel genoeg voor productiegebruik. Daarom kiezen we, zelfs voor onze consumenten, voorzichtigheid boven haast.

We hebben verzoeken ontvangen voor een meer glijdend releaseschema, wat erg leuk klinkt. Het implementeren van zo'n plan zou echter een aanzienlijke hoeveelheid werk vergen die we op dit moment niet aankunnen vanuit het perspectief van ondersteuning. Zelfs met een zero-support beleid hebben we door ervaring geleerd dat we van nature te aardig zijn om hulpvragen van gebruikers te negeren. Als gevolg daarvan besteden we te veel uren aan het bieden van ondersteuning aan onze gratis gebruikers, terwijl we publiekelijk hebben verklaard dat we dat niet zouden doen.

Onze toewijding om goed te zijn en onze gebruikers te helpen betekent dat we vaak te veel tijd besteden aan het helpen van onze gebruikers, zelfs als hun problemen specifiek voor hen zijn. We raken er langzaam aan gewend om hen eraan te herinneren dat we onze gratis gebruikers geen uitgebreide ondersteuning kunnen bieden als het gaat om algemeen platformgebruik. Hoe graag we dat ook zouden willen, we hebben er de middelen niet voor.

Concluderend: hoewel een wild, rollend, bètatestend upgradespoor als een spannend vooruitzicht klinkt, is het niet iets wat we in de nabije toekomst kunnen bieden. Onze focus blijft liggen op het leveren van een stabiele, betrouwbare service aan onze klanten.