In ons vorige Devops-artikel deden verschillende bedrijven al uit de doeken hoe zij de mist in gingen met Devops. En ook vandaag hebben wij weer twee prachtige voorbeelden van hoe het vooral niet moet. Wat kunnen we ervan leren?

Onvoldoende devops-dekking

Soms zit het met het devops-team wel snor, maar gaat het toch mis omdat ze verkeerd worden ingezet. Een bedrijf dat zich bezighoudt met autoleases voor een grote groep bedrijven in Amerika kwam daar op de harde manier achter.

Als een klant een auto wilde leasen moest de informatie van die personen, samen met het verzoek, worden ingediend en verwerkt in een zelfgebouwde applicatie. Een groot deel van deze informatie moet worden gecontroleerd door externe instanties. Aangezien het om een financiële transactie gaat is het van essentieel belang dat deze controle goed gebeurt om te voorkomen dat financiële bedrijven met een slechte lease blijven en hun geld kwijt zijn.

"De devops die zich bezighielden met dit project hielden zich vooral bezig met de serverkant. Het opsplitsen voor verschillende verzoeken in combinatie met deployment statistieken, responstijd en geautomatiseerde processen. Een paar weken geleden hadden wij een probleem waardoor het hele systeem plat ging. Dat kwam door een zogenoemd monitoring-gat. Een belangrijke 3rd-party validation-service had netwerkproblemen en legde onze eigen infrastructuur plat. Dat zou geen probleem moeten zijn maar door de slechte constructie van de software (welke was uitbesteed naar het buitenland voor een mooie prijs) waren alle leaseaanvragen gekoppeld aan deze dienst die er nu dus uit lag," aldus Nathaniel Rowe, softwareconsultant bij het leasebedrijf (waarvan hij de naam liever niet noemt).

Het probleem was te wijten aan een incomplete devops-dekking. Mensen hielden zich vooral bezig met metriek en interne processen en naar de externe processen werd nauwelijks gekeken. Er is lang op deze manier gewerkt omdat de meeste problemen zich vooral voordeden in de interne code. Externe problemen kwamen amper voor dus werd er nauwelijks na gekeken, legde Rowe uit.

Toen het probleem eenmaal bekend was zat het ontwikkelteam er direct bovenop en ontkoppelde het de validatiecode. Er werden procedures toegepast om de gewraakte service te omzeilen. Hierdoor konden partnerbedrijven de ingevoerde informatie alsnog opslaan.

"Wij kwamen achter het probleem door contact op te nemen met de service provider. Om te voorkomen dat dit probleem zich in de toekomst weer voordoet hebben we een globale instelling toegevoegd die ervoor zorgt dat het indien-proces wordt doorgestuurd naar een ander proces en dat partners daarvan op de hoogte worden gebracht.

Een groot voordeel van deze fout is dat er nu tijd en geld is gereserveerd voor het patchen en monitoren van dit soort problemen," aldus Rowe.

Mensen en processen vergeten

Brian Dawson, devops-evangelist bij CloudBees, werkte voorheen als een proces-consultant voor een leverancier voor de Amerikaanse overheid. Zijn eerste devops-ervaringen bij dat bedrijf waren geen goede, maar hij heeft er wel veel van geleerd.

Het bedrijf was bezig met een belangrijk project om een web-applicatie te bouwen. "De leverancier was verantwoordelijk voor het ALM (Application Lifecycle Management) en was bezig met het opzetten van tooling processen en de bijbehorende planning. Daarnaast werkte het ook aan code (en commits) het bouwen en uitrollen van de applicatie. Dit zou allemaal gedaan worden op een (open source-achtige) manier waarbij iedereen samenwerkte," aldus Dawson.

"Het uitrollen en configureren van de ondersteunende devops-tooling was een succes maar jammer genoeg kunnen devops niet uitgerold worden op basis van tools. Het moet net zoveel aandacht worden besteed aan de mensen en culturen achter de processen en tools," zegt Dawson.

Het project bestond uit verschillende teams en had een zeer strakke deadline. Management wilde dat op een snelle, simpele manier oplossen en focuste zich alleen maar op de tools. " We konden een platform bouwen dat mooie agile planning tools, een modern SCM (Software Configuration Management) en Jenkins voor continue integratie. Allemaal uitgerold op een ietwat elastisch, schaalbaar platform."

Het bedrijf had echter geen rekening gehouden met de mensen zelf en de devops-processen en kon niet de juiste mensen aantrekken om goede devops-strategie te maken en toe te passen.

We hadden dus een prachtig, hypermodern devops-platform staan maar de mensen die ermee werkten deden dat op de oude "legacy" manier. Ontwikkelaars deden niet aan commits, merges en integratie. Automatische QA (Quality Assurance) en releases werden niet geïmplementeerd en kapotte builds werden niet gezien als iets ernstigs. Bovendien werden productie-loads in productie-omgevingen niet getest."

Toen de klant de webapplicatie in gebruik nam ging het meteen goed mis. De boel ging keihard onderuit. Niet zo heel gek aangezien de applicatie nooit behoorlijk was getest in een echte productie-omgeving met echte gebruikers. Daar kwam nog eens bij dat het ons meerdere weken en ontwikkelcycli kostte om de boel te repareren en de site weer te laten draaien. De trage responstijden hielpen daar ook niet echt bij.

De technische issues waren binnen een paar maanden gerepareerd. Maar het oplossen van het achterliggende probleem, duurde vele maanden langer.

Pas toen de juiste mensen gevonden waren konden deze problemen getackled worden. Devops kunnen het ontwikkelproces flink versnellen, maar alleen als jij en je team je daar goed mee aan de slag gaan en kunnen werken in een goede devops-cultuur.