Er zijn genoeg voorbeelden te vinden waarin devops goed werkt en mooie verbeteringen brengt binnen bedrijven in verschillende industrieën. Maar soms gaat het ook wel eens goed mis. Wij bekeken een paar van deze missers en oplossingen. Wat kunnen we ervan leren?

Geen goede visie

IBM begon al met het devops-principe voordat dit hippe woord echt bestond (in 2003). Het werd ingezet als een agile software development initiatief voor een van IBM's nieuwe producten. Het bedrijf investeerde in agile, een set principes voor softwareontwikkeling die het mogelijk maakt snel in te spelen op veranderen en wijzigingen door te voeren. Dat werd gedaan om het aantal software releases op te schroeven voor klanten.

Het was echter niet zo succesvol als men had gehoopt. "Het probleem van agile is dat je er maar zoveel uit kan halen. De ontwikkelkant was supersnel maar de operations-kant reageerde heel langzaam. Het maakte uiteindelijk niets uit aangezien klanten hun producten uiteindelijk niet sneller kregen," aldus Mustafa Kapadia, North American cloud en devops service line leader for Global Business services bij IBM.

Het bedrijf besloot uiteindelijk het deployment-proces te automatiseren maar ook dat versnelde het proces niet. IBM probeerde er achter te komen waar het mis ging door een "value chain"-analyse uit te voeren en kwam erachter dat de grootste belemmering niet zozeer agile of het automatiseren van processen was, maar de algehele ontwikkel- en operationele omgeving. Zelfs de vele pogingen om het ontwikkelproces te versnellen zorgden er uiteindelijk voor dat het algehele proces uiteindelijk te veel vertraging opliep.

Hierna: Gebrek aan visie.

Uiteindelijk bleek IBM's devops debacle te komen door een gebrek aan visie bij de mensen die zich bezig hielden met het versnellen van deze processen. "We moesten een paar standaard vragen stellen en bepalen welke problemen wij eigenlijk moeten oplossen, dat is waar wij de mist in zijn gegaan. Als je niet weet hoe het werk uiteindelijk is uitgevoerd, weet je ook niet welke problemen er opgelost moeten worden. Wij hielden ons bezig met [denkbeeldige] problemen die voortkwamen uit leverancier-hypes, niet kijkende naar de problemen die ons wel vertragen," aldus Kapadia.

Pas toen managers beter begrepen hoe de workflows in elkaar zitten en welke processen werden vertraagd, konden er goede wijzigingen worden doorgevoerd waardoor de boel eindelijk op gang kwam.

Te veel toegang, te weinig scholing

In 2006 was professionele content sharing website, SlideShare (nu onderdeel van LinkedIn), een kleine startup met minder dan 20 medewerkers. Het lanceerde een devops model om processen te versnellen en de concurrenten een stap voor te blijven.

"Het ontwikkelteam was opgesplitst tussen San Francisco en New Delhi en de infrastructuur was behoorlijk gecompliceerd," aldus Sylvain Kalache, co-founder van Holberton School, een instituut dat software-engineers traint. Kalache werkte destijds ook voor SlideShare.

Het doel van de devops was om uiteindelijk maximale efficiëntie te behalen binnen het engineering-team en zoveel mogelijk technische kennis te verspreiden. Als er iemand op vakantie zou gaan of het bedrijf zou verlaten zou dat minder impact hebben.

Op de laatste pagina: Het zag er mooier uit, maar werkte niet meer.

"Het werken in een devops-omgeving pushte elke contributor om te werken aan verschillende onderdelen van het product." Dat is superbelangrijk en het zorgt ervoor dat mensen nog nauwer met elkaar samenwerken."

Een van de belangrijkste ideeën achter devops is het hebben van verantwoordelijkheid op bepaalde onderdelen. "Je zal ontwikkelaars toegang moeten geven tot bepaalde onderdelen in de infrastructuur die zij normaalgesproken niet hebben," aldus Kalache. Engineers hadden toegang tot productieservers en productiedatabases.

Een software-engineer werkte aan een database-gerelateerd project en testte een tool die hem de mogelijkheid gaf een MySQL-database op een grafische manier te doorzoeken. "Hij besloot de volgorde van de database 'kolommen' te veranderen zodat het er mooier uit zag in de tool en het beter te begrijpen was voor hem. Wat hij niet wist is dat hij daarmee daadwerkelijk wijzigingen aanbracht in de database waardoor deze niet meer werkte en slideshare.net onderuit haalde."

De persoon die de boel onderuit haalde realiseerde zich niet dat de tool daadwerkelijk wijzigingen uitvoerde op de productiedatabase. Het duurde een kwartier voordat men erachter kwam waar het probleem precies vandaan kwam.

Kalache had daar het volgende over te zeggen: "Wij konden twee dingen leren van deze fout; iedereen had toegang tot elk proces in de keten. De devops pushte dat behoorlijk hard. Terwijl het juist goed is een stap terug te doen en te kijken of het ook daadwerkelijk wat toevoegt als iedereen overal bij kan. In deze specifieke situatie realiseerde wij ons dat het eigenlijk niets toevoegde en zelfs gevaarlijk was.

Daarnaast is het beter om de ontwikkelaars te leren hoe de algehele infrastructuur in elkaar zit. Veel van onze ontwikkelaars waren nooit blootgesteld aan de productie-infrastructuur. Devops is een speciale manier van werken en interactie met andere personen is heel belangrijk. Je kan er niet vanuit dat dat iedereen logischerwijs de 'verborgen regels' kent. Daarom is onboarding tegenwoordig ook verplicht."