DevOps is de afgelopen jaren een zeer populair onderwerp geworden. Veel mensen dromen ervan om hieraan deel te nemen, maar zoals de praktijk laat zien, vaak alleen vanwege het niveau van de salarissen.
Sommige mensen vermelden DevOps op hun cv, hoewel ze de essentie van de term niet altijd kennen of begrijpen. Sommige mensen denken dat je na het bestuderen van Ansible, GitLab, Jenkins, Terraform en dergelijke (de lijst kan naar eigen smaak worden voortgezet) onmiddellijk een “devopsist” wordt. Dit is natuurlijk niet waar.
De afgelopen jaren ben ik vooral betrokken geweest bij de implementatie van DevOps bij diverse bedrijven. Daarvoor werkte hij ruim twintig jaar in functies variërend van systeembeheerder tot IT-directeur. Momenteel DevOps Lead Engineer bij Playgendary.
Wie is DevOps
Het idee om een artikel te schrijven ontstond na een andere vraag: “wie is DevOps?” Er is nog steeds geen vaste term voor wat of wie het is. Een deel van de antwoorden staat hier al in . Eerst zal ik de belangrijkste punten eruit belichten, en daarna zal ik mijn observaties en gedachten delen.
DevOps is geen specialist die kan worden ingehuurd, geen set hulpprogramma's, en geen afdeling ontwikkelaars met ingenieurs.
DevOps is een filosofie en methodologie.
Met andere woorden, het is een reeks praktijken die ontwikkelaars helpt actief te communiceren met systeembeheerders. Dat wil zeggen: werkprocessen met elkaar verbinden en integreren.
Met de komst van DevOps zijn de structuur en rollen van specialisten hetzelfde gebleven (er zijn ontwikkelaars, er zijn engineers), maar de regels van interactie zijn veranderd. De grenzen tussen afdelingen zijn vervaagd.
De doelstellingen van DevOps kunnen in drie punten worden beschreven:
- De software moet regelmatig worden bijgewerkt.
- Software moet snel gebeuren.
- De software moet gemakkelijk en in korte tijd worden geïmplementeerd.
Er bestaat niet één tool voor DevOps. Het configureren, leveren en bestuderen van meerdere producten betekent niet dat DevOps in het bedrijf is verschenen. Er zijn veel tools en ze worden allemaal in verschillende fasen gebruikt, maar dienen één gemeenschappelijk doel.
En dit is slechts een deel van de DevOps-tools
Ik interview nu al meer dan twee jaar mensen voor de functie van DevOps-ingenieur en ik ben tot het besef gekomen hoe belangrijk het is om de essentie van de term duidelijk te begrijpen. Ik heb specifieke ervaringen, observaties en gedachten verzameld die ik wil delen.
Uit interviewervaring zie ik het volgende beeld: specialisten die DevOps als een functie beschouwen, hebben doorgaans misverstanden met collega’s.
Er was een sprekend voorbeeld. Een jonge man kwam naar een sollicitatiegesprek met veel slimme woorden op zijn cv. Bij zijn laatste drie banen had hij 5-6 maanden ervaring. Ik heb twee startups verlaten omdat ze ‘niet van de grond kwamen’. Maar over het derde bedrijf zei hij dat niemand hem daar begrijpt: de ontwikkelaars schrijven code op Windows, en de directeur dwingt deze code te 'verpakken' in gewone Docker en in te bouwen in de CI/CD-pijplijn. De man zei veel negatieve dingen over zijn huidige werkplek en zijn collega's - ik wilde alleen maar antwoorden: "Je verkoopt dus geen olifant."
Toen stelde ik hem een vraag die bij iedere kandidaat hoog op mijn lijstje staat.
— Wat betekent DevOps voor jou persoonlijk?
- In het algemeen of hoe neem ik het waar?
Ik was geïnteresseerd in zijn persoonlijke mening. Hij kende de theorie en de oorsprong van de term, maar was het er absoluut niet mee eens. Hij geloofde dat DevOps een functietitel was. Dit is waar de wortel van zijn problemen ligt. Evenals andere specialisten met dezelfde mening.
Werkgevers, die veel hebben gehoord over de “magie van DevOps”, willen iemand vinden die deze “magie” komt creëren. En sollicitanten uit de categorie ‘DevOps is een baan’ begrijpen niet dat ze met deze aanpak niet aan de verwachtingen zullen kunnen voldoen. En over het algemeen schreven ze DevOps op hun cv omdat het een trend is en ze er veel voor betalen.
DevOps-methodologie en -filosofie
De methodologie kan theoretisch en praktisch zijn. In ons geval is het de tweede. Zoals ik hierboven al zei, is DevOps een reeks praktijken en strategieën die worden gebruikt om gestelde doelen te bereiken. En in elk geval kan dit, afhankelijk van de bedrijfsprocessen van het bedrijf, aanzienlijk verschillen. Wat het niet beter of slechter maakt.
De DevOps-methodiek is slechts een middel om doelen te bereiken.
Nu wat de DevOps-filosofie is. En dit is waarschijnlijk de moeilijkste vraag.
Het is vrij moeilijk om een kort en bondig antwoord te formuleren, omdat het nog niet is geformaliseerd. En omdat aanhangers van de DevOps-filosofie meer met de praktijk bezig zijn, is er simpelweg geen tijd voor filosoferen. Dit is echter een heel belangrijk proces. Bovendien houdt het rechtstreeks verband met technische activiteiten. Er is zelfs een gespecialiseerd kennisgebied - .
Op mijn universiteit bestond zo'n onderwerp niet, ik moest alles zelf bestuderen met behulp van de materialen die ik in de jaren 90 kon vinden. Het onderwerp is optioneel voor technisch onderwijs, vandaar het gebrek aan formalisering van het antwoord. Maar de mensen die zich serieus verdiepen in DevOps beginnen een zekere ‘geest’ of ‘onbewuste alomvattendheid’ van alle bedrijfsprocessen te voelen.
Gebruikmakend van mijn eigen ervaring probeerde ik enkele van de ‘postulaten’ van deze filosofie te formaliseren. Het resultaat is het volgende:
- DevOps is niet iets op zichzelf staands dat kan worden opgedeeld in een apart kennis- of activiteitsgebied.
- Alle bedrijfsmedewerkers moeten zich bij het plannen van hun activiteiten laten leiden door de DevOps-methodologie.
- DevOps heeft invloed op alle processen binnen een bedrijf.
- DevOps bestaat om de tijdskosten voor alle processen binnen een bedrijf te verminderen om de ontwikkeling van zijn diensten en maximaal klantcomfort te garanderen.
- DevOps is, in moderne taal, de proactieve positie van elke medewerker van het bedrijf, gericht op het verminderen van tijdskosten en het verbeteren van de kwaliteit van de IT-producten om ons heen.
Ik denk dat mijn “postulaten” een apart onderwerp van discussie zijn. Maar nu is er iets om op voort te bouwen.
Wat DevOps doet
Het sleutelwoord hier is communicatie. Er is veel communicatie, waarvan de initiatiefnemer precies diezelfde DevOps-engineer zou moeten zijn. Waarom is dat? Omdat dit filosofie en methodologie is, en pas dan technische kennis.
Ik kan niet met 100% vertrouwen spreken over de westerse arbeidsmarkt. Maar ik weet behoorlijk veel over de DevOps-markt in Rusland. Naast honderden interviews heb ik de afgelopen anderhalf jaar deelgenomen aan honderden technische voorverkoop voor de dienst ‘Implementatie van DevOps’ voor grote Russische bedrijven en banken.
In Rusland is DevOps nog een heel jong, maar nu al trending topic. Voor zover ik weet bedroeg het tekort aan dergelijke specialisten in Moskou alleen al in 2019 meer dan 1000 mensen. En het woord Kubernetes is voor werkgevers bijna een rode lap op een stier. Aanhangers van dit instrument zijn bereid het te gebruiken, zelfs als het niet nodig en economisch winstgevend is. De werkgever begrijpt niet altijd in welke gevallen wat geschikter is om te gebruiken, en met de juiste implementatie kost het onderhouden van een Kubernetes-cluster 2-3 keer meer dan het implementeren van een applicatie met behulp van een conventioneel clusterschema. Gebruik het waar je het echt nodig hebt.
Het implementeren van DevOps is duur in termen van geld. En het is alleen gerechtvaardigd als het economische voordelen oplevert op andere gebieden, en niet op zichzelf.
DevOps-ingenieurs zijn in feite pioniers; zij zijn degenen die als eersten deze methodologie in het bedrijf moeten implementeren en processen moeten bouwen. Om dit succesvol te laten zijn, moet de specialist voortdurend in interactie zijn met medewerkers en collega's op alle niveaus. Zoals ik meestal zeg, moeten alle medewerkers van het bedrijf betrokken worden bij het DevOps-implementatieproces: van de schoonmaakster tot de CEO. En dit is een voorwaarde. Als het jongste lid van het team niet weet en begrijpt wat DevOps is en waarom bepaalde organisatorische acties worden uitgevoerd, zal een succesvolle implementatie niet werken.
Ook moet een DevOps-ingenieur van tijd tot tijd een administratieve hulpbron gebruiken. Bijvoorbeeld om ‘omgevingsweerstand’ te overwinnen – wanneer het team niet klaar is om DevOps-tools en -methodologie te accepteren.
De ontwikkelaar mag alleen code en tests schrijven. Om dit te doen heeft hij geen superkrachtige laptop nodig waarop hij de gehele projectinfrastructuur zal inzetten en lokaal ondersteunen. Een front-end developer bewaart bijvoorbeeld alle elementen van de applicatie op zijn laptop, inclusief de database, S3-emulator (minio), etc. Dat wil zeggen, hij besteedt veel tijd aan het onderhouden van deze lokale infrastructuur en worstelt in zijn eentje met alle problemen van een dergelijke oplossing. In plaats van code voor het front te ontwikkelen. Zulke mensen kunnen zeer resistent zijn tegen elke verandering.
Maar er zijn teams die juist graag nieuwe tools en methoden introduceren en actief aan dit proces deelnemen. Hoewel zelfs in dit geval de communicatie tussen de DevOps-ingenieur en het team niet werd geannuleerd.
Wanneer DevOps niet nodig is
Er zijn situaties waarin DevOps niet nodig is. Dit is een feit: het moet begrepen en geaccepteerd worden.
In de eerste plaats geldt dit voor alle bedrijven (vooral kleine bedrijven), wanneer hun winst niet direct afhankelijk is van de aan- of afwezigheid van IT-producten die informatiediensten aan klanten leveren. En hier hebben we het niet over de website van het bedrijf, of het nu een statisch ‘visitekaartje’ is of met dynamische nieuwsblokken, enz.
DevOps is nodig wanneer de tevredenheid van uw klant en zijn wens om weer bij u terug te keren afhankelijk zijn van de beschikbaarheid van deze informatiediensten voor interactie met de klant, de kwaliteit en doelgerichtheid ervan.
Een treffend voorbeeld is een bekende bank. Het bedrijf beschikt niet over traditionele klantenkantoren, de documentstroom verloopt via post of koeriers en veel medewerkers werken vanuit huis. Het bedrijf is niet langer alleen maar een bank, maar is naar mijn mening veranderd in een IT-bedrijf met ontwikkelde DevOps-technologieën.
Veel andere voorbeelden en lezingen zijn te vinden in de opnames van thematische bijeenkomsten en conferenties. Ik heb een aantal van hen persoonlijk bezocht - dit is een zeer nuttige ervaring voor degenen die zich in deze richting willen ontwikkelen. Hier zijn links naar YouTube-kanalen met goede lezingen en materiaal over DevOps:
Kijk nu eens naar uw bedrijf en denk hierover na: in hoeverre zijn uw bedrijf en zijn winsten afhankelijk van IT-producten om klantinteractie mogelijk te maken?
Als uw bedrijf vis verkoopt in een kleine winkel en het enige IT-product twee 1C: Enterprise-configuraties (Accounting en UNF) is, dan heeft het nauwelijks zin om over DevOps te praten.
Als u bij een grote handels- en productieonderneming werkt (u produceert bijvoorbeeld jachtgeweren), dan moet u erover nadenken. Je kunt het initiatief nemen en de vooruitzichten voor de implementatie van DevOps aan je management overbrengen. Welnu, en tegelijkertijd dit proces leiden. Een proactieve houding is een van de belangrijke uitgangspunten van de DevOps-filosofie.
De omvang en het volume van de jaarlijkse financiële omzet zijn niet het belangrijkste criterium om te bepalen of uw bedrijf DevOps nodig heeft.
Laten we ons een grote industriële onderneming voorstellen die niet rechtstreeks met klanten communiceert. Bijvoorbeeld sommige autofabrikanten en autoproductiebedrijven. Ik weet het nu niet zeker, maar vanuit mijn ervaringen uit het verleden verliep alle klantinteractie jarenlang via e-mail en telefoon.
Hun klanten zijn een beperkte lijst autodealers. En iedereen krijgt een specialist van de fabrikant toegewezen. Alle interne documentstromen verlopen via SAP ERP. Interne medewerkers zijn in essentie klanten van het informatiesysteem. Maar deze IS wordt bestuurd via klassieke manieren om clustersystemen te beheren. Wat de mogelijkheid uitsluit om DevOps-praktijken te gebruiken.
Vandaar de conclusie: voor dergelijke ondernemingen is de implementatie van DevOps niet iets van cruciaal belang, als we ons de doelstellingen van de methodologie uit het begin van het artikel herinneren. Maar ik sluit niet uit dat ze tegenwoordig enkele DevOps-tools gebruiken.
Aan de andere kant zijn er veel kleine bedrijven die software ontwikkelen met behulp van de DevOps-methodologie, -filosofie, -praktijken en -tools. En zij geloven dat de kosten van het implementeren van DevOps de kosten zijn waarmee ze effectief kunnen concurreren op de softwaremarkt. Er zijn voorbeelden van dergelijke bedrijven te zien .
Het belangrijkste criterium om te begrijpen of DevOps nodig is: welke waarde uw IT-producten hebben voor het bedrijf en de klanten.
Als het belangrijkste product van het bedrijf dat winst genereert software is, heb je DevOps nodig. En het is niet zo belangrijk als je echt geld verdient met andere producten. Hieronder vallen ook online winkels of mobiele applicaties met games.
Alle spellen bestaan dankzij financiering: direct of indirect van de spelers. Bij Playgendary ontwikkelen we gratis mobiele games waarbij meer dan 200 mensen direct betrokken zijn bij de creatie ervan. Hoe gebruiken wij DevOps?
Ja, precies hetzelfde als hierboven beschreven. Ik communiceer voortdurend met ontwikkelaars en testers en geef interne trainingen voor medewerkers over de DevOps-methodologie en -tools.
We gebruiken Jenkins nu actief als CI/CD-pijplijntool voor het uitvoeren van alle assemblagepijplijnen met Unity en de daaropvolgende implementatie in de App Store en Play Market. Meer uit de klassieke toolkit:
- Asana - voor projectmanagement. Integratie met Jenkins is geconfigureerd.
- Google Meet - voor videovergaderingen.
- Slack - voor communicatie en verschillende waarschuwingen, inclusief meldingen van Jenkins.
- Atlassian Confluence - voor documentatie en groepswerk.
Onze onmiddellijke plannen omvatten de introductie van statische codeanalyse met SonarQube en het uitvoeren van geautomatiseerde UI-tests met Selenium in de fase van continue integratie.
In plaats Output
Ik wil afsluiten met de volgende gedachte: om een hooggekwalificeerde DevOps-ingenieur te worden, is het essentieel om live met mensen te leren communiceren.
Een DevOps engineer is een teamspeler. En niets anders. Het initiatief in de communicatie met collega's moet van hem komen, en niet onder invloed van bepaalde omstandigheden. Een DevOps specialist moet de beste oplossing voor het team zien en voorstellen.
En ja, de implementatie van welke oplossing dan ook zal veel discussie vergen, en tegen het einde kan het helemaal veranderen. Door zich zelfstandig te ontwikkelen, zijn ideeën voor te stellen en uit te voeren, is zo iemand van toenemende waarde voor zowel het team als de werkgever. Wat uiteindelijk tot uiting komt in de hoogte van zijn maandelijkse beloning of in de vorm van extra bonussen.
Bron: www.habr.com