Het onderwerp DevOps is de afgelopen jaren zeer populair geworden. Velen dromen ervan hieraan deel te nemen, maar zoals de praktijk aantoont, is dat vaak alleen vanwege het salarisniveau.
Sommigen vermelden DevOps in hun cv, hoewel ze de essentie van de term niet altijd begrijpen. Sommige mensen denken dat als ze Ansible, GitLab, Jenkins, Terraform en dergelijke (de lijst kan naar eigen smaak worden voortgezet) hebben bestudeerd, ze meteen 'DevOps'er' zijn. Dit is natuurlijk niet het geval.
De afgelopen jaren heb ik me voornamelijk beziggehouden met de implementatie van DevOps in verschillende bedrijven. Daarvoor heb ik meer dan 20 jaar gewerkt in posities van systeembeheerder tot IT-directeur. Momenteel ben ik DevOps Lead Engineer bij Playgendary.
Wie is DevOps?
Het idee om een artikel te schrijven kwam voort uit weer een vraag: 'Wie is DevOps?'. Tot nu toe is er geen gevestigde term voor wat of wie dit is. Een deel van de antwoorden is al in dit . Eerst zal ik de belangrijkste punten daaruit Š²ŃŠ“ŠµŠ»ŠøŃŃ en vervolgens mijn observaties en gedachten delen.
DevOps is geen specialist die je kunt inhuren, geen set van tools, en geen afdeling van ontwikkelaars en ingenieurs.
DevOps is een filosofie en methodologie.
Met andere woorden, het is een set van praktijken die helpt om ontwikkelaars actief met systeembeheerders te laten samenwerken. Het gaat erom de werkprocessen met elkaar te verbinden en te integreren.
Met de komst van DevOps zijn de structuren en rollen van specialisten hetzelfde gebleven (er zijn ontwikkelaars, er zijn ingenieurs), maar zijn de regels voor interactie veranderd. De grenzen tussen afdelingen zijn vervaagd.
De doelen van DevOps kunnen in drie punten worden samengevat:
- Software moet regelmatig worden bijgewerkt.
- Software moet snel worden ontwikkeld.
- Software moet gemakkelijk en snel worden uitgerold.
Er is geen enkele tool voor DevOps. Het instellen, implementeren en leren van verschillende producten betekent niet dat er een DevOps in het bedrijf is gekomen. Er zijn vele tools en ze worden op verschillende stadia ingezet, maar dienen Ć©Ć©n gemeenschappelijk doel.
En dit is slechts een deel van de DevOps-tools.
Al meer dan 2 jaar houd ik sollicitatiegesprekken voor de rol van DevOps-engineer, en ik realiseer me hoe belangrijk het is om de essentie van de term duidelijk te begrijpen. Ervaring, observaties en gedachten hebben zich opgehoopt die ik wil delen.
Uit mijn ervaring met sollicitatiegesprekken zie ik het volgende beeld: specialisten die denken dat DevOps een functie is, hebben vaak misverstanden met collega's..
Er was een duidelijk voorbeeld. Een jonge man kwam op het sollicitatiegesprek met een hoop slimme woorden in zijn cv. Bij de laatste drie banen had hij 5-6 maanden ervaring. Van twee startups is hij vertrokken omdat ze "niet succesvol waren". Wat betreft het derde bedrijf zei hij dat niemand hem daar begrijpt: de ontwikkelaars schrijven code voor Windows, en de directeur dwingt hem die code "in te pakken" in gewone Docker en te integreren in de CI/CD-pipeline. De jongen vertelde veel negatiefs over zijn huidige werkplek en zijn collega's ā je wilde bijna antwoorden: "Dus je kunt de olifant niet verkopen."
Daarna stelde ik hem een vraag die Ć©Ć©n van de eerste in mijn lijst voor elke kandidaat is.
ā Wat betekent DevOps voor jou persoonlijk?
ā Gewoonlijk of zoals ik het zie?
Ik was geĆÆnteresseerd in zijn persoonlijke mening. Hij kende de theorie en de oorsprong van de term, maar was daar categorisch mee oneens. Hij dacht dat DevOps een functie was. Hier ligt de kern van zijn problemen, net als bij andere specialisten met dezelfde mening.
Werkgevers, die veel gehoord hebben over de "magie van DevOps", willen iemand vinden die komt en deze "magie" creƫert. En sollicitanten uit de groep "DevOps is een functie" begrijpen niet dat ze met die benadering niet aan de verwachtingen kunnen voldoen. En over het algemeen hebben ze DevOps op hun cv gezet omdat het een trend is en daar veel voor betaald wordt.
DevOps-methodologie en filosofie
De methodologie kan theoretisch of praktisch zijn. In ons geval is het de tweede. Zoals ik eerder zei, is DevOps een set van praktijken en strategieƫn die worden toegepast om de gestelde doelen te bereiken. En in elk geval, afhankelijk van de bedrijfsprocessen van het bedrijf, kan het aanzienlijk verschillen. Dat maakt het niet beter of slechter.
De DevOps-methodologie is slechts een middel om de gestelde doelen te bereiken.
Laten we nu het hebben over wat de filosofie van DevOps is. En dit is waarschijnlijk de moeilijkste vraag.
Het is vrij moeilijk om een korte en duidelijke antwoord te formuleren, omdat het nog niet geformaliseerd is. En omdat de aanhangers van de DevOps-filosofie meer bezig zijn met de praktijk ā is er gewoon geen tijd voor filosoferen. Niettemin is het een zeer belangrijk proces. En het is direct gerelateerd aan de engineering activiteit. Er is zelfs een gespecialiseerde tak van kennis ā .
Aan mijn universiteit was er geen vak over, ik moest alles zelf bestuderen met de materialen die ik in de jaren '90 kon vinden. Het onderwerp is niet verplicht voor een technische opleiding, vandaar het gebrek aan een formeel antwoord. Maar de mensen die zich serieus in DevOps hebben verdiept, beginnen een bepaalde 'geest' of 'onbewuste alomtegenwoordigheid' van alle processen binnen het bedrijf te voelen.
Ik heb geprobeerd om uit mijn eigen ervaring enkele 'postulaten' van deze filosofie te formaliseren. Het resultaat is als volgt:
- DevOps is niets op zichzelf staands, iets dat kan worden onderscheiden als een aparte kennis- of activiteitenrichting.
- Alle medewerkers van het bedrijf moeten de DevOps-methodologie volgen bij het plannen van hun activiteiten.
- DevOps raakt alle processen binnen het bedrijf.
- DevOps bestaat om de tijdskosten van alle processen binnen het bedrijf te verlagen, zodat de diensten kunnen worden ontwikkeld en het comfort van de klant maximaal kan worden gegarandeerd.
- DevOps, in moderne taal, is de proactieve houding van elk medewerker van het bedrijf, gericht op het verlagen van de tijdskosten en het verbeteren van de kwaliteit van de IT-producten om ons heen.
Ik denk dat mijn 'postulaten' een aparte discussie waard zijn. Maar nu is er tenminste een basis om op voort te bouwen.
Wat doet DevOps
Het sleutelwoord hier is communicatie. Er is een overweldigende hoeveelheid communicatie, waarvan de initiator juist die DevOps-engineer moet zijn. Waarom? Omdat het een filosofie en methodologie is, en pas daarna technische kennis.
Over de westerse arbeidsmarkt kan ik geen 100% zekerheid geven. Maar ik weet redelijk veel over de DevOps-markt in Rusland. Naast honderden sollicitatiegesprekken heb ik de afgelopen anderhalf jaar deelgenomen aan honderd technische presales voor de dienst 'Implementatie van DevOps' voor grote Russische bedrijven en banken.
In Nederland is DevOps nog een relatief jonge, maar al trending thema. Voor zover ik weet, was er in 2019 een tekort van meer dan 1000 dergelijke specialisten alleen al in Amsterdam. En het woord Kubernetes is voor werkgevers bijna als een rode lap voor een stier. Voorstanders van deze tool zijn bereid deze zelfs in te zetten waar het niet nodig is en economisch gezien niet voordelig. De werkgever begrijpt niet altijd in welke gevallen het geschikt is om te gebruiken, terwijl de totale kosten voor de implementatie van een Kubernetes-cluster 2-3 keer hoger zijn dan voor de implementatie van een applicatie volgens een normale clusterconfiguratie. Gebruik het waar het echt nodig is.
De implementatie van DevOps vanuit financieel perspectief is kostbaar. Het is alleen gerechtvaardigd waar het economische voordelen oplevert in andere gebieden, niet op zichzelf.
DevOps-engineers zijn feitelijk de pioniers ā zij moeten als eersten deze methodologie in het bedrijf implementeren en processen opzetten. Voor een succesvolle uitvoering moet de specialist voortdurend interactie hebben met medewerkers en collega's op alle niveaus. Zoals ik doorgaans zeg, moeten alle medewerkers van het bedrijf betrokken zijn bij het DevOps-implementatieproces: van de schoonmaker tot de CEO. Dit is een noodzakelijke voorwaarde. Als het jongste teamlid niet weet en begrijpt wat DevOps is en waarom bepaalde organisatorische acties worden ondernomen, zal succesvolle implementatie niet mogelijk zijn.
Daarnaast moet de DevOps-engineer af en toe gebruik maken van administratieve middelen. Bijvoorbeeld om 'verzet van de omgeving' te overwinnen ā wanneer het team niet bereid is de tools en methodologie van DevOps te omarmen.
Een ontwikkelaar moet alleen code en tests schrijven. Hiervoor heeft hij geen superkrachtige laptop nodig waarop hij de hele projectinfrastructuur lokaal draait en onderhoudt. Bijvoorbeeld, de frontendontwikkelaar heeft op zijn laptop alle elementen van de applicatie, inclusief de database, een S3-emulator (minio) en meer. Dat wil zeggen, hij besteedt veel tijd aan het onderhouden van deze lokale infrastructuur en worstelt alleen met alle problemen die deze oplossing met zich meebrengt. In plaats van code voor de frontend te ontwikkelen. Dergelijke mensen kunnen sterk tegen elke verandering zijn.
Maar er zijn teams die juist blij zijn met de implementatie van nieuwe tools en methoden, en actief deelnemen aan dit proces. Ook in dit geval is communicatie tussen de DevOps-engineer en het team van groot belang.
Wanneer is DevOps niet nodig?
Er zijn situaties waarin DevOps niet nodig is. Dit is een feit dat men moet begrijpen en accepteren.
Dit geldt vooral voor bedrijven (met name kleine ondernemingen) waarvan de winst niet direct afhankelijk is van IT-producten die informatievoorziening aan klanten bieden. En hiermee bedoelen we niet de bedrijfswebsite, of die nu een statische 'visitekaartje' is of met dynamische nieuwssecties etc.
DevOps is nodig wanneer de beschikbaarheid van deze informatievoorzieningsservices voor klantinteractie, de kwaliteit ervan en de gerichte aanpak bepalen hoe tevreden uw klant is en zijn bereidheid om weer bij u terug te komen.
Een duidelijk voorbeeld is een bekende bank. Het bedrijf heeft geen traditionele klantkantoren, de documentstroom verloopt via post of koeriers, en veel medewerkers werken vanuit huis. Het bedrijf is geen gewone bank meer, maar naar mijn mening een IT-bedrijf geworden met ontwikkelde DevOps-technologieƫn.
Er zijn veel andere voorbeelden en lezingen te vinden in de verslagen van thematische meetups en conferenties. Een deel daarvan heb ik persoonlijk bijgewoond ā dit is zeer waardevolle ervaring voor degenen die zich in deze richting willen ontwikkelen. Hier zijn links naar YouTube-kanalen met goede lezingen en materialen over DevOps:
Kijk nu eens naar uw bedrijf en denk aan het volgende: hoe sterk hangt uw bedrijf en zijn winst af van IT-producten die klantinteractie mogelijk maken?
Als uw bedrijf vis verkoopt in een kleine winkel en de enige IT-producten twee configuraties van 1C: Enterprise (Boekhouding en UNF) zijn, dan heeft het waarschijnlijk weinig zin om over DevOps te praten.
Maar als u werkt voor een groot handels- en productiebedrijf (bijvoorbeeld dat jachtgeweren produceert), dan is het de moeite waard om erover na te denken. U kunt het initiatief nemen en uw management de mogelijkheden van de implementatie van DevOps uitleggen. En tevens dit proces leiden. Een proactieve houding is een van de belangrijke uitgangspunten van de DevOps-filosofie.
De grootte en het jaarlijkse financiƫle volume zijn geen belangrijke criteria om te bepalen of uw bedrijf DevOps nodig heeft.
Stel je een groot industrieel bedrijf voor dat niet direct met klanten communiceert. Bijvoorbeeld, sommige autofabrikanten en automobielfabrikanten. Ik ben er nu niet zo zeker van, maar uit mijn eerdere ervaring is er jarenlang interactie met klanten via e-mail en telefoon geweest.
Hun klanten zijn een beperkt aantal autodealers. En aan elke dealer is een specialist van de fabrikant toegewezen. Alle interne documentatie verloopt via ERP SAP. Interne medewerkers zijn in feite klanten van het informatiesysteem. Maar het beheer van dit systeem wordt uitgevoerd met klassieke middelen voor clusterbeheer. Dit sluit de mogelijkheid uit om DevOps-praktijken te gebruiken.
Hieruit volgt de conclusie: voor dergelijke bedrijven is de implementatie van DevOps niet essentieel, als we de doelstellingen van de methodologie in het begin van dit artikel herinneren. Maar ik sluit niet uit dat sommige DevOps-tools vandaag de dag door hen worden gebruikt.
Aan de andere kant zijn er veel kleine bedrijven die software ontwikkelen met behulp van de methodologie, filosofie, praktijken en tools van DevOps. En zij beschouwen de kosten voor de implementatie van DevOps als uitgaven die hen in staat stellen om efficiƫnt te concurreren op de softwaremarkt. Voorbeelden van dergelijke bedrijven zien we graag. .
Het belangrijkste criterium om te begrijpen of DevOps nodig is: wat is de waarde van uw IT-producten voor het bedrijf en de klanten.
Als het belangrijkste product van het bedrijf, dat winst genereert, software is - dan heeft u DevOps nodig. En het maakt niet uit of u daadwerkelijk geld verdient met andere producten. Dit omvat ook webshops of mobiele applicaties met spellen.
Alle games bestaan dankzij financiering: direct of indirect door spelers. Bij Playgendary ontwikkelen we gratis mobiele games, waarbij meer dan 200 mensen betrokken zijn bij de directe creatie. Hoe gebruiken we DevOps?
Net zoals hierboven beschreven. Ik communiceer voortdurend met ontwikkelaars en testers, en geef interne trainingen aan medewerkers over de methodologie en tools van DevOps.
Momenteel gebruiken we Jenkins actief als een instrument voor CI/CD-pijplijnen om alle build-pijplijnen met Unity uit te voeren en vervolgens te implementeren in de App Store en Play Store. Verder uit de klassieke set tools:
- Asana ā voor projectmanagement. Integratie met Jenkins is ingesteld.
- Google Meet ā voor het houden van videovergaderingen.
- Slack ā voor communicatie en verschillende meldingen, inclusief notificaties vanuit Jenkins.
- Atlassian Confluence ā voor documentatie en groepswerk.
In de nabije toekomst plannen we om statische code-analyse te implementeren met behulp van SonarQube en geautomatiseerde UI-tests uit te voeren met Selenium tijdens de Continuous Integration-fase.
Ter afsluiting
Ik wil eindigen met de volgende gedachte: om een hooggekwalificeerde DevOps-ingenieur te worden, is het van vitaal belang om effectief te leren communiceren met mensen.
Een DevOps-ingenieur is een teamspeler. En niets anders. Initiatief in de communicatie met collega's moet van hemzelf komen, en niet onder invloed van bepaalde omstandigheden. Een DevOps-specialist moet de beste oplossing voor het team zien en voorstellen.
Ja, de implementatie van elke oplossing vereist veel discussies, en aan het einde kan het geheel veranderen. Door zelfstandig te groeien, ideeĆ«n aan te bieden en deze uit te voeren ā zo'n persoon vertegenwoordigt steeds meer waarde voor zowel het team als de werkgever. Dit weerspiegelt zich uiteindelijk ook in de hoogte van zijn maandelijkse beloning of in de vorm van extra bonussen.
Bron: habr.com
