Frustaties in mijn rol als DevOps op werk

[chronoz]

Inmiddels werk ik 4 weken bij een nieuwe werkgever als ZZP'er. Mijn rol is DevOps en ik werk voornamelijk samen met een team van 6 programmeurs, 2 testers en nog 3 andere. Er is niets geregeld qua back-ups, monitoring, veiligheid (matig) en ik zou daar graag iets aan doen. Ik merk aan mezelf dat ik de laatste 2 dagen erg gefrustreerd wordt van het feit dat ik actief aan het coden ben en dat ik om de 10 minuten iets voor hun moet doen of mijn focus moet verleggen, voorbeelden zijn redeployments, git merges, ssh-keys toevoegen en alles moet snel snel snel. Op die manier kom ik niet toe aan mijn eigen dingen.

Samen met de collega links van mij vervang ik de collega die tegenover mij zit. Aan de Git-historie te zien heeft mijn voorganger slechts 3 mini-commits gedaan in 6 weken, dus heeft de kant van DevOps stil gelegen. Inmiddels heb ik al boven de 100 commits gedaan, maar echt productief voel ik me niet. De jongen die links van mij zit werkt met mij samen als DevOps en is 5 weken geleden begonnen, maar doet eigenlijk niets, want hij kent geen Ansible/Jenkins. Hij is al een hele maand bezig met hetzelfde ding, het werkend krijgen van een file transfer client, waarvan het probleem waarschijnlijk gewoon aan een firewall ligt.

We werken volgens het SCRUM systeem, elke dag 2x stand-ups en inmiddels hangen er 20 kaartjes op mijn bordje, waarvan de helft gedaan moet worden, voordat we over 3 weken naar productie gaan.

Ik merk dat ik wel veel leer van het werken met nieuwe technologien als Ansible, Jenkins, ELK-stack, AWS-deployment, maar ik raak een beetje gestressed. Het belangrijkste vooor mij is dat ik me goed blijf voelen en hier goed mee om ga. Ik voel veel ownership voor de infrastructuur/DevOps-kant van het project en het zit me dwars dat ik geen tijd heb dit te verbeteren. Ik heb vanmiddag een e-mail gestuurd naar mijn leidinggevende (DevOps) en de leidinggevende van het programmeerteam, met ook maar beperkt reactie. Er wordt toegegeven dat ik inderdaad de laatste dagen voornamelijk support-werkzaamheden doe, dat mensen om de 10 minuten langs mijn bureau komen voor dit,dit,dat en mijn todo-list zo niet kleiner wordt.

Mijn contract loopt 3 maanden en het is zeker zo erg niet, mensen om me heen zijn enorm vriendelijk, maar ik merk dat ik er gewoon niet goed mee omga, wat gestressed en gefrustreerd raak.

[Verwijderd]

Het simpelweg weigeren van bepaalde zaken is zeker geen optie? Wellicht moeilijk (in het begin), maar uiteindelijk creeert het wel de ruimte voor hetgeen waar je echt mee bezig wil/moet zijn.

[chronoz]

Het werk is meestal altijd blokkerend als ik het niet doe, dus als ik op het laatste moment te horen krijg dat security een nieuwe pen-test moet doen, dan moet ik per direct de ssh-keys toevoegen, ook al heb ik nog maar 60% van de security maatregelen kunnen doorvoeren.

Hetzelfde voor het wijzigen van een simpele omgevingsinstelling als enable_ftpserver=true instellen omgevingsvariable in git, ansible commit, opnieuw Jenkins job draaien. Meestal kunnen de programmeurs zonder niet verder. Ik word vaak gevraagd een service uit te zetten, opnieuw te starten, ook al heb ik ze uitgelegd dat ze dat via sudo zelf kunnen doen. De ergste boosdoener is de tester, die ook vaak om de 15 minuten naar de status vraagt van bijvoorbeeld een redeployment, die hij zelf in Jenkins kan zien. Hij zou zelf het grootste deel van de redeployment kunnen doen, slechts 2 jobs uitvoeren. Ik heb zowel vandaag als gisteren al aangegeven dat ik zo echt niet aan mijn eigen werk toe kom, maar misschien moet ik iets duidelijker zeggen dat ik het storend vind en dat ik geen zin heb om van mijn concentratie gestoord te worden elke 15 minuten voor status-updates.

[Verwijderd]

Begrijpelijk, en lastig natuurlijk. Maar inderdaad, dan maar wat duidelijker zijn en wellicht dat het even moeilijk zal zijn voor je collega om dat te accepteren.

Hier heb ik zelf ook af en toe last van (collega's die continu dingen aan mij vragen, vaak zonder eerst zelf research te doen).

Na een tijdje wennen ze eraan, en de sfeer is er bij mijn in ieder geval niet minder op geworden. Waarom dan wel bij jou?

[Jaymz]

chronoz schreef op dinsdag 03 maart 2015 @ 20:25:
Er is niets geregeld qua back-ups, monitoring, veiligheid (matig) en ik zou daar graag iets aan doen.

Moet je je niet gewoonweg afvragen wie hier daadwerkelijk verantwoordelijk (/afrekenbaar) voor is en het daar op de agenda krijgen ?

Druk maken om dingen waar je weinig tot geen directe invloed op hebt is zeer frustrerend

[3DDude]

Is dit niet gewoon een agenda puntje voor het overleg?
Desnoods schrijf je een korte howto ? Als die tester dat zelf kan uitvoeren? prima toch?
Of geef hem die rechten (al dan niet beperkt).

Dat is een keer even documenteren / uitwerken hoe het werkt.

Daarna zou ik als eerste die collega met die filetransfer even uit de brand helpen zodat die daarna wellicht wel wat kan doen?
Minder op jouw bordje, als hij ook een aantal taken kan overnemen...?

[The Eagle]

Vooraf: toevallig eind vorig jaar mijn scrum master gehaald

Je doet Scrum, dus het hele team is verantwoordelijk voor het op tijd afkrijgen van het werk. Dus niet alleen jij. Er is geen rol van tester, geen functionele rol, helemaal niks: alleen het development team. Uiteraard heeft ieder wel zijn specialiteiten. Voor degenen die scrum niet of nauwelijks kennen: neem de term development niet te letterlijk, het is niet alleen development wat dat team doet. Het is het opleveren van werkende increments.

Scrum vraagt van beide partijen begrip en aanpassing. Juist dit soort dingen zijn de zaken die je in de standup in kunt brengen om te bespreken - als jij telkens gestoord wordt haal je de opgestelde planning niet. En het halen daarvan is een gedeelde verantwoordelijkheid

Voor je collega's zal het wellicht ook nog nieuw zijn en hun weg zoeken. En als er dan een nieuwe collega is die alles kan, dan is dat heel handig. Voor hen welteverstaan, niet voor het gezamenlijke doel.
Ik ga er vanuit dat er ook een scrum master in jullie midden is. Die is er met name om dit soort impediments weg te halen. Spreek hem eens aan

Dat gezegd hebbend: als een bepaalde taak teveel vergt, moet ie worden opgesplitst. Je kunt ook aan je collegas vragen of ze hun verzoeken per mail willen sturen. Kun je ze op gezette tijden oppakken, bijv om 11.00 en om 16.00. Als je dat aan ze duidelijk kunt maken en ze houden zich er aan heb je goed verwachtingsmanagement gehanteerd.

Last: in scrum zou er geen haast moeten zijn, anders is het werk niet goed ingepland

[ Voor 14% gewijzigd door The Eagle op 03-03-2015 21:43 ]

[Ankona]

Het klinkt een beetje als een organisatie die hip wil doen maar niet agile is. Een situatie die je eigenlijk bijna overal tegenkomt.
De kunst is om het team aan het samenwerken te krijgen. Het kan niet zo zijn dat een iemand in zijn eentje al 5 weken tegen een probleem aan zit te hikken, dat is een team verantwoordelijkheid. Probeer met kleine stapjes mensen uit hun vertrouwde eilandjes te krijgen en als een team te opereren. Neem de tijd om elkaar te helpen, ga pair programming toepassen. Het zal zeker weerstand geven, maar als jij het voortouw neemt en begint met hulp te bieden zal je zeker ook kunnen gaan oogsten. Krijg je het team op stoom dan ben jij wel de man! (en zo niet, dan heb je als externe voor jezelf toch het nodige geleerd)

[jip_86]

Zit je tegenover een collega waar je samen moet werken, maar geen flikker doet? Zou je die niet eens kunnen opleiden aan de gang zien te krijgen? De mensen zijn er blijkbaar wel, maar ze verdoen hun tijd met onzin. Als je die op gang krijgt kun je de kutklusjes aan hen uitbesteden

En verder wat The Eagle zegt vaste tijden hanteren, mensen roepen vaak te snel, als ze een uurtje moeten wachten weten ze vaak ineens wel hoe het moet als je dan bij ze komt

[Bob-B190]

Ik zou het planbaar maken. Je weet nu hoeveel tijd je kwijt bent aan onvoorspelbare zaken door de bank genomen. Dus dit reduceert het aantal punten wat je te verbanden hebt gedurende een sprint. Dus men zal dit moeten aanpassen. Daarnaast weet ik niet hoe relevant het in deze is, maar harde deadlines is natuurlijk niet echt in de SCRUM gedachte. Je pakt zaken op naar gelang van prioriteit.

[418O2]

Bob-B190 schreef op woensdag 04 maart 2015 @ 13:17:
Ik zou het planbaar maken. Je weet nu hoeveel tijd je kwijt bent aan onvoorspelbare zaken door de bank genomen. Dus dit reduceert het aantal punten wat je te verbanden hebt gedurende een sprint. Dus men zal dit moeten aanpassen. Daarnaast weet ik niet hoe relevant het in deze is, maar harde deadlines is natuurlijk niet echt in de SCRUM gedachte. Je pakt zaken op naar gelang van prioriteit.

Maar de sprints zijn afgekaderd voor ze beginnen toch?

Overigens vertel ik niemand iets vier keer. Als hij het na 2x niet snapt, schrijft hij het op voor de volgende keer

[t_captain]

Het grote voordeel van een devops engineer boven een systeembeheerder is dat de devops engneer zelf sturing heeft over zijn frustratie. De taken die het vaakst voorkomen, de meeste tijd kosten of de meeste irritatie opleveren, automatiseer je. Het is een beetje een berg om op te klimmen, het gaat zwaarder dan je zou willen, maar gaandeweg kom je toch omhoog.

Ik denk dat je voornaamste probleem is dat je (1) in de initiele fase zit waarin er veel ad-hoc werk jouw kant op komt en (2) je directe collega niet in staat is om zijn helft van het werk aan te pakken.

[The Eagle]

Bob-B190 schreef op woensdag 04 maart 2015 @ 13:17:
Ik zou het planbaar maken. Je weet nu hoeveel tijd je kwijt bent aan onvoorspelbare zaken door de bank genomen. Dus dit reduceert het aantal punten wat je te verbanden hebt gedurende een sprint. Dus men zal dit moeten aanpassen. Daarnaast weet ik niet hoe relevant het in deze is, maar harde deadlines is natuurlijk niet echt in de SCRUM gedachte. Je pakt zaken op naar gelang van prioriteit.

Even nuanceren: het development team (en dus TS en directe collega's) bepalen de prio niet. Dat doet de productowner. Naast de Scrum master zou dat je eerste aanspreekpunt moeten zijn

[justice strike]

The Eagle schreef op woensdag 04 maart 2015 @ 15:30:
[...]

Even nuanceren: het development team (en dus TS en directe collega's) bepalen de prio niet. Dat doet de productowner. Naast de Scrum master zou dat je eerste aanspreekpunt moeten zijn

impediments worden natuurlijk niet door de productowner bepaalt. Dat heeft overigens prio boven alles (want je kunt namelijk niet verder met impediments). Mocht men wel verder kunnen, dan is het geen impediment.

[Verwijderd]

t_captain schreef op woensdag 04 maart 2015 @ 13:29:
Het grote voordeel van een devops engineer boven een systeembeheerder is dat de devops engneer zelf sturing heeft over zijn frustratie. De taken die het vaakst voorkomen, de meeste tijd kosten of de meeste irritatie opleveren, automatiseer je. Het is een beetje een berg om op te klimmen, het gaat zwaarder dan je zou willen, maar gaandeweg kom je toch omhoog.

Ik denk dat je voornaamste probleem is dat je (1) in de initiele fase zit waarin er veel ad-hoc werk jouw kant op komt en (2) je directe collega niet in staat is om zijn helft van het werk aan te pakken.

Misschien iets voor een andere discussie, maar een systeembeheerder dient toch ook te automatiseren? Als je telkens dezelfde taken opnieuw uitvoert als systeembeheerder zonder dit te automatiseren op wat voor manier dan ook, dan ben je (imo) niet helemaal goed bezig.

[Ankona]

Verwijderd schreef op woensdag 04 maart 2015 @ 16:12:
[...]

Misschien iets voor een andere discussie, maar een systeembeheerder dient toch ook te automatiseren? Als je telkens dezelfde taken opnieuw uitvoert als systeembeheerder zonder dit te automatiseren op wat voor manier dan ook, dan ben je (imo) niet helemaal goed bezig.

Hoezo niet? Waarom jezelf overbodig maken als je afhankelijk bent van je baan?


(Heb zelf een vergelijkbare ervaring. Ik ben ooit als extra kracht werkzaam geweest bij een team dat diverse omvangrijke projecten deed. Het team was afhankelijk van een database developer die absurd hard werkte en een stuwmeer aan overuren had staan.... Een slimme en gewaardeerde kracht in het team, maar ook een risico.
Toen ik erbij kwam botste het meteen. Die man was koning op zijn eigen eiland. Hij werkte wel hard, maar vooral doordat hij alles handmatig in de databases aan het friemelen was. Repeterende klussen waar hij een uur of 4 mee bezig was ging ik scripten en kosten ineens nog maar 2 minuten om uit te voeren. Die vent heeft dus alles in het werk gesteld om zo snel mogelijk weer van mij af te komen.)

[Verwijderd]

Ankona schreef op woensdag 04 maart 2015 @ 16:48:
[...]

Hoezo niet? Waarom jezelf overbodig maken als je afhankelijk bent van je baan?


(Heb zelf een vergelijkbare ervaring. Ik ben ooit als extra kracht werkzaam geweest bij een team dat diverse omvangrijke projecten deed. Het team was afhankelijk van een database developer die absurd hard werkte en een stuwmeer aan overuren had staan.... Een slimme en gewaardeerde kracht in het team, maar ook een risico.
Toen ik erbij kwam botste het meteen. Die man was koning op zijn eigen eiland. Hij werkte wel hard, maar vooral doordat hij alles handmatig in de databases aan het friemelen was. Repeterende klussen waar hij een uur of 4 mee bezig was ging ik scripten en kosten ineens nog maar 2 minuten om uit te voeren. Die vent heeft dus alles in het werk gesteld om zo snel mogelijk weer van mij af te komen.)

Je bent toch nog steeds bezig met monitoring, innovatie, etc.? En je kunt niet alles automatiseren natuurlijk. Als je zo werkt dat je hele functie met wat scripts overbodig wordt, dan acht ik de kans groot dat je op een gegeven moment toch wel weg moet bij die firma.

[Asteroid9]

Ankona bedoelt het een tikkeltje cynisch, een kleine was duidelijker geweest!

Heel herkenbaar wat hij schetst, maar veel ICT-ers zijn geen automatiseerders, diegenen die het wel zijn zijn dan ook meestal de echt goede medewerkers!

[justice strike]

Asteroid9 schreef op woensdag 04 maart 2015 @ 17:19:
Ankona bedoelt het een tikkeltje cynisch, een kleine was duidelijker geweest!

Heel herkenbaar wat hij schetst, maar veel ICT-ers zijn geen automatiseerders, diegenen die het wel zijn zijn dan ook meestal de echt goede medewerkers!

De mensen die bovenop automatiseren ook nog eens controle mechanismes hebben zijn de uitmuntende mensen.

als je alles automatiseert dan worden de fouten ook automatisch gemaakt.

[Asteroid9]

Een automatiseringsoplossing waarbij fouten niet opgemerkt worden is niet goed geautomatiseerd!

Ik begrijp wat je bedoelt hoor, zeker op het gebied van controles, monitoring en procesbewaking is in de meeste omgevingen nog heel erg veel winst te behalen. Ondertussen een beetje off-topic, maar wel interessant!

[chronoz]

Ik zou graag als eerst mijn complimenten willen geven aan Gathering of Tweakers als community. Ik woon al een jaar in Londen en ben weleens actief op verschillende Engelse forums. Daarbij kijk ik weleens naar de GoT forumtopics en het valt mij op hoe constructief positief de reacties hier vaak zijn.

Vandaag was een superproductieve dag, ik heb gevraagd of ik een dagje op me zelf kon werken en ook al werden er grappen over gemaakt, voor mij was het echt een fine dag. De collega tegenover mij nam de kleine supporttaken en ik heb enorm veel vooruitgang geboekt en weet nu precies wat er nog gedaan moet worden voor de gang naar productie.

De tester valt mij regelmatig lastig voor status updates terwijl ik code/automatiseer en vraagt wat de status ervan is, vaak om de 15 minuten of zegt dat email niet werkt en dat dat niet werkt. Die onderbrekingen zijn niet weg te automatiseren, wel door beter te communiceren van mijn kant. Ik merk dat onderbroken mij meer stoort dan de meeste andere collega's die ik heb, gezien veel communiceren gedurende de dag best normaal is in een SCRUM/agile development-omgeving. Restarts via sudo is geautomatiseerd en dat kunnen de developers nu zelf. Herbouwen environments zou ik kunnen automatisrren, maar zou wel wat tijd kosten om te zorgen dat ze de hele omgeving via ansible kunnen slopen, het opbouwen via Jenkins/ansible werkt al. Ik heb ze vandaag instructies gestuurd hoe dit te doen, zodat ik alleen nog maar het sloop gedeelte hoef te doen handmatig in AWS. Git merges van bepaalde ansible code voor hun cfg file van hun Java app gaat ook via mij, zij sturen patch file, ik merge in onze repo. Kost steeds even 3min. Ik kan ze geen git write merge rechten geven, dat zou een risico zijn.

Daarbij denk ik ook dat ik meer op me moet nemen wat betreft het instrueren van collega's, wat zij kunnen doen en indien nodig, instructies hoe ze precies bepaalde dingen zelf zouden kunnen doen, bijvoorbeeld het opbouwen van een nieuwe omgeving en het in de gaten houden van de status van een nieuwe build, zodat ze mij daarvoor niet hoeven te vragen.

Ik blijf mijn best doen een goede balans te vinden. Vandaag was in ieder geval een stuk beter dan maandag en dinsdag, al kan ik natuurlijk niet elke dag vragen of mijn DevOps-collega de kleine klusjes kan doen, zodat ik de hele dag ongestoord kan werken.

[The Eagle]

Moet ineens denken aan deze:



Verwoord denk ik wel aardig waar je tegenaan loopt. En is ook een van de funderingen van scrum: learn as you go, pick up pace as you go

[cbr600f4i]

Ik vind het wel knap dat iemand die al 5 weken hetzelfde klusje doet daar gewoon mee weg komt in een stand up zonder dat (iemand uit) het team actie onderneemt.

[noes]

@Chronoz, probeer, zoals je eigenlijk al hebt gedaan met je dag 'alleen werken', iedere dag een ander aan te wijzen voor de support taken. In ons (development) team doen we dit per sprint. Hij/zij pakt alle support op, en in ons geval ook de onderhoudstaken, kleine rewrites, nice-to-haves die anders eeuwig blijven liggen etc. Dit ontlast de rest van het team enorm: niemand wordt gestoord en iedereen kan lekker doorwerken. Enige uitzondering is echte nood door een grote storing oid, dan betrekt de scrum-master er extra personen bij.

[_Arthur]

chronoz schreef op woensdag 04 maart 2015 @ 21:14:
De collega tegenover mij nam de kleine supporttaken en ik heb enorm veel vooruitgang geboekt en weet nu precies wat er nog gedaan moet worden voor de gang naar productie.

Als jullie dat afhandelen van de kleine supporttaken nu gewoon tussen de collega's rouleert; dan is er maar 1 persoon die steeds 'van zijn werk' gehouden wordt en kan de rest gewoon lekker doorwerken. En bv morgen ben jij de pieneut; maar de andere 4 dagen heb je goed door kunnen werken.

[chime]

Nu - normaal kan je je bedenkingen ook onder aandacht brengen in de periodieke review meeting => dus wat ging er goed tijdens deze sprint?, wat niet?, wat doen we eraan?

Git merge kan je normaal ook wel automatiseren => geef elke developer zijn eigen jenkins, laat die gewoon commiten, gaat dat goed => automatische merge poging en dat gaat weer door een jenkins.
Voordeel is dat de development jenkins (de algemene) normaal minder vaak rood zal kleuren - ook automatiseer je zo weer wat werk.

Anderzijds stel ik me ook wel de vraag waarom de tester je lastig valt ... die hoor niet constant achter status-updates te vragen.
Maar eerder te gaan testen als er iets klaar is om te testen.
Is er iets niet klaar => testing zelf verbeteren, code quality bekijken, ...