Close

ITSM voor razendsnelle teams

IT-support op de DevOps-manier

Het is bewezen dat DevOps-principes in je IT-service- en engineeringteams de servicekwaliteit, de moraal van het team, de probleemoplossing en bedrijfsproductiviteit drastisch verbeteren. Bedrijven die DevOps-principes toepassen, melden zelfs gemiddeld 45% hogere klanttevredenheid, 43% hogere productiviteit van werknemers, 41% verbetering ten opzichte van storingspercentages en 38% minder IT-gerelateerde kosten.

Met dergelijke statistieken heeft het integreren van DevOps-principes in IT-servicebeheer enorme voordelen voor bedrijven. Maar het kan ook een ingewikkelde verandering betekenen voor teams. Het goede nieuws? Het is niet zo ingewikkeld als het lijkt. De sleutel tot beter presterende services is zo simpel dat het je misschien verrast.

Wat is DevOps?

Dus wat is DevOps precies? Het is een aantal procedures die twee vaak afzonderlijk werkende teams samenbrengen die elkaar al vaker tegenwerken, namelijk development en operations. Het doel is samenwerking, open communicatie en manieren te vinden voor beide afdelingen om hun respectievelijke doelen te bereiken.

Zoals onze experts zeggen: “DevOps is een aantal werkwijzen om de processen tussen softwareontwikkeling en IT-teams te automatiseren, zodat ze software sneller en betrouwbaarder kunnen bouwen, testen en releasen. Het concept van DevOps is gebaseerd op het ontwikkelen van een cultuur van samenwerking tussen teams die historisch gezien totaal apart werkten. De bijbehorende voordelen zijn meer vertrouwen, snellere softwarereleases, het vermogen om kritieke problemen snel op te lossen en beter beheer van ongepland werk.”

Waarom DevOps voor IT-support?

Vanuit zakelijk oogpunt spreken de cijfers voor zich. 45% betere klanttevredenheid. 43% meer productiviteit van werknemers. 38% besparing op IT-gerelateerde kosten. De DevOps-beweging heeft de bedrijfsresultaten op een belangrijke manier geholpen. Daarom zeggen 4 van de 5 bedrijven waarschijnlijk dat ze in ieder geval een paar DevOps-principes gebruiken.

Even aantrekkelijk voor teams zelf, als DevOps goed wordt uitgevoerd, verbetert DevOps de tevredenheid, samenwerking en erkenning van werknemers en teams. Het vereenvoudigt ingewikkelde processen, versnelt taken en verwijdert een laag bureaucratie die al lang spanningen heeft veroorzaakt bij IT, development en andere onderling verbonden teams.

Waar Ops-teams gefrustreerd raakten door nieuwe releases waar ze niets van wisten en ze niet wilden ondersteunen (en, die volgens Gartner 85 - 87% van de incidenten veroorzaken), opent DevOps de communicatielijnen en bereidt IT operations voor op wat er gaat komen. Waar ontwikkelingsteams gefrustreerd waren door de push-back van operations die lanceringen vertraagde, kunnen teams nu samenwerken aan snellere lanceringen die SLA-beloften en SLO-doelen niet in gevaar brengen.

DevOps voor IT-service: best practices

Geef prioriteit aan cultuurveranderingen

De grootste uitdaging van DevOps-integratie is de cultuurverandering.

Traditionele IT-organisaties werken vaak in silo's, waarbij het ontwikkelingsteam binnen een eigen afzonderlijke ecosysteem werkt en Ops het vervolgens overneemt—vaak met weinig tot geen waarschuwing voor systeemveranderingen voordat ze plaatsvinden—zodra een verandering is doorgevoerd.

DevOps-organisaties leggen daarentegen de nadruk op samenwerking en communicatie tussen teams (door middel van procedures en tools zoals hackathons, stand-upmeetings en chatrooms).

Het omarmen van deze verandering betekent het omarmen van nieuwe tools, nieuwe processen en een nieuw cultureel perspectief waarin communicatie tussen teams en gedeeld succes wordt benadrukt.

Automatiseer waar je kunt

De productiviteitswinst van DevOps is, althans gedeeltelijk, te danken aan een filosofie die prioriteit geeft aan automatisering. DevOps omarmen betekent teams stimuleren om constant te vragen: waar kunnen we automatiseren?

Kunnen we de beoordeling van codes automatiseren voor veelvoorkomende fouten? Kunnen we systemen automatiseren om problemen, incidenten en aanvragen te koppelen aan de wijzigingen of releases die deze mogelijk hebben veroorzaakt? Kunnen we controles automatiseren die ons ervan weerhouden code vrij te geven die niet voldoet aan beveiligings- of wettelijke vereisten? Kunnen we systemen automatiseren om nieuwe releases te blokkeren als we gevaarlijk dicht bij onze SLO-doelen zijn?

Er zijn veel manieren om DevOps-statistieken te automatiseren en te verbeteren. De drie meest voorkomende zijn:

  • Workflow (bijvoorbeeld: support tickets sneller via de servicedesk verwerken)
  • Kennis (als er een incident binnenkomt, moet jouw servicemanagementtool automatisch met relevante kennis en documentatie komen)
  • Escalatie (als er maar twee mensen in je organisatie zijn die een probleem kunnen oplossen, moet een slim systeem het rechtstreeks naar ze doorsturen in plaats van strenge, lineaire escalatieprocedures te volgen)

Houd belangrijke statistieken bij

Bij samenwerking tussen development en IT operations, moeten ze ook bijhouden hoe het gaat.

Veelvoorkomende belangrijke prestatie-indicatoren (KPI's) voor DevOps zijn onder andere MTBF (gemiddelde tijd tussen storingen), MTTR (gemiddelde tijd tot herstel, reparatie, reactie of oplossen), MTTF (gemiddelde tijd tot storing) en MTTA (gemiddelde tijd tot erkenning). Veel bedrijven vertrouwen ook op cijfers zoals het aantal waarschuwingen of aanvragen dat binnen een bepaald tijdsbestek wordt gegenereerd, de kosten van downtime per minuut of de kosten van support per oproep/aanvraag.

De statistieken die je teams moeten volgen zijn afhankelijk van de teams zelf, de beloftes die aan klanten zijn gedaan in je SLA-overeenkomsten, de SLO-doelen die je met de organisatie hebt afgesproken en eventuele specifieke punten waarop je je richt. Het is ook belangrijk om te beseffen dat er moeilijk vat te krijgen is op statistieken. Naarmate er dingen binnen het bedrijf veranderen - van de producten die IT ondersteunt tot de behoeften van belanghebbenden aan externe wettelijke of veiligheidsverplichtingen - moeten de statistieken die je bijhoudt en de manier waarop misschien ook veranderen.

Geef prioriteit aan delen

DevOps gaat over het overbruggen van de kloof tussen creatie en onderhoud, makers en ondersteuners. Het gaat over het creëren van dezelfde opvattingen, doelen, processen en vocabulaire. Het gaat over het delen van kennis en communicatie. Het gaat over gedeelde toolsets, resources en codebases. En misschien nog wel het belangrijkste, het gaat om gedeeld eigendom, wat neerkomt op gedeelde verantwoordelijkheid en gedeelde successen.

Voor veel traditionele organisaties betekent de overstap naar DevOps opnieuw nadenken over hoe je die gedeelde verantwoordelijkheden en successen definieert, beloont en volgt. Staan de doelen van de development- en operations-teams op gespannen voet? Betekent succes voor het ene team dat succes voor het andere team lastiger wordt?

Bijvoorbeeld: als het development-team de taak heeft om zo snel mogelijk nieuwe functies te lanceren en het IT operations-team de taak heeft de uptime te behouden, kunnen deze twee doelen een negatieve invloed op elkaar hebben. Operations wil ontwikkelaars misschien vertragen om de uptime-doelen te overtreffen en development kan kwaad zijn op operations, omdat door hen de lanceringsdoelen niet werden gehaald.

De oplossing voor veel DevOps-teams is een SRE-benadering, waarbij development-teams, zolang de uptime binnen SLO-doelen valt, zoveel kunnen lanceren als ze willen. En wanneer uptime daalt tot onaanvaardbare niveaus, worden alle lanceringen geblokkeerd totdat teams samenwerken om de uptime weer op niveau te krijgen.

ITIL versus DevOps

Als je ITIL volgt, vraag je je misschien af waar DevOps om de hoek komt kijken. Voor veel bedrijven kunnen ITIL- en DevOps-procedures prima samengaan. Sterker nog, hier bij Atlassian zien we veel bedrijven de voordelen en sterke punten van beide omarmen.

Zoals in dit verhaal over DevOps en ITIL wordt uitgelegd: “We hebben beide nodig. We hebben het over complementaire, niet competitieve kaders. We moeten slimmer en sneller kunnen werken, maar we hebben ook nog steeds processen en controles nodig. Moderne, goed presterende teams en organisaties beginnen dit te realiseren en gebruiken elementen van beide – ze hoeven er dus niet meer tussen te kiezen.”

ITIL adresseert best practices voor operations, support, governance en andere belangrijke zakelijke functies. DevOps zorgt voor zaken als een continue levering, een onberispelijke cultuur, samenwerkingstools en agile-procedures die de reeds in de ITIL-richtlijnen verwerkte procedures verbeteren en erop voortbouwen.

Tools voor DevOps-georiënteerde organisaties

Het omarmen van een DevOps-benadering kan ook betekenen dat nieuwe tools worden omarmd—voor communicatie, automatisering en samenwerking tussen teams.

Als er nieuwe tools worden beoordeeld, is het belangrijk om de volgende vragen te stellen:

  • Werkt deze tool in onze omgeving en integreert deze met bestaande tools?
  • Voldoet de tool aan onze behoeften?
  • Werken alle nieuwe tools samen in een uitgebreide, samenhangende toolset?

We zijn misschien bevooroordeeld, maar bij Atlassian gebruiken we Jira Service Management voor IT-servicebeheer, Jira Software voor softwareontwikkeling en Bitbucket voor onze coderepository.

Een van de redenen waarom deze tools zo goed werken, is dat ze goed samenwerken. En wanneer je de silo's binnen je teamstructuren doorbreekt, wil je ook silo's doorbreken in de tools waar je voor kiest.