Op 7 december vond de derde conferentie plaats , georganiseerd door de Moskouse DevOps-gemeenschap met de steun van Mail.ru Cloud Solutions. Naast presentaties van vooraanstaande DevOps-beoefenaars konden deelnemers korte motiverende Lightning Talks en workshops bijwonen en communiceren in open ruimtes.
Uit zes toespraken hebben we belangrijke inzichten verzameld en interviews afgenomen met diverse sprekers om te achterhalen wat er achter de rapporten is achtergebleven.
Binnen:
- Baruch Sadogursky, JFrog: “Laat de software als een vloeistof van leverancier naar gebruiker stromen”
- Pavel Selivanov, Southbridge: “Dev en Ops hebben één gemeenschappelijke taak: een product maken dat werkt”
- Vladimir Utratenko, X5 Retail Group: “DevOps in Enterprise is ontwikkeling zonder pijn en vuur”
- Sergey Puzyrev, Facebook: “Production Engineer geeft om de service als geheel: zodat zowel gebruikers als ontwikkelaars plezier hebben”
- Mikhail Chinkov, AMBOSS: “Eén afdeling kan het DevOps-pad niet volgen, het hele bedrijf moet het volgen”
- DevOps-enthousiastelingen van Rosbank: “1000 dagen om DevOps te implementeren in een bloedige onderneming”
1. Baruch Sadogursky, JFrog: “Laat de software als een vloeistof van leverancier naar gebruiker stromen”
Mislukte software-updates komen elk uur voor en voor iedereen. Hier is slechts één horrorverhaal uit de toespraak: Knight Capital verloor binnen een uur $440 miljoen na een mislukte update.
Baruch sprak over DevOps-patronen van continue updates die fouten en gebruikershaat helpen voorkomen:
Lokaal terugdraaien — bewaar de vorige versie van de software op uw apparaat om terug te draaien als er iets gebeurt. Dit zal je beschermen als de zaken zo erg worden dat je geen patch meer door de lucht kunt sturen.
Over-the-air-updates - beter continu. Anders zal het net als bij de Jaguar-ontwikkelaars zijn: vanwege een bug in het remsysteem, die niet via de ether kon worden bijgewerkt, moesten de auto's uit de verkoop worden teruggeroepen. Het was pijnlijk en duur.
Continue updates — обновляйте софт непрерывно, как только готова новая фича. При редких обновлениях фичи группируются, критическое обновление может ждать некритические. Как в Тесла — обновление, которое должно было пофиксить случайное торможение, ждало обновления игры в шахматы.
Geautomatiseerde implementatie - vervang mensen door machines, omdat mensen slecht zijn in het uitvoeren van routinematige handelingen.
астые обновления - je helpen een gewoonte te ontwikkelen en angst weg te nemen. Zeldzame updates veranderen in noodgebeurtenissen.
De staat van het apparaat kennen - updates testen, niet helemaal opnieuw installeren. Dit is belangrijk omdat updates zich anders kunnen gedragen, afhankelijk van de status van het apparaat.
Kanarie releases — updates uitrollen naar een klein aantal gebruikers en observeren. Hierdoor wordt de schade beperkt als er iets misgaat.
Updates zonder onbeschikbaarheid — zorg ervoor dat klanten alleen nieuwe functies opmerken en dat ze niet enkele weken zonder service blijven zitten terwijl u een update uitrolt.
We spraken met Baruch Sadogursky over hoe de visie op DevOps verschilt in Russische en westerse IT, of Cloud straks alles voor ons gaat doen en of alle softwarediensten in het aaS-schema zullen glijden - bekijk het interview:
2. Pavel Selivanov, Southbridge: “Dev en Ops hebben één gemeenschappelijke taak: een product maken dat werkt”
Het implementeren van Kubernetes zal niet bijdragen aan het realiseren van DevOps, en integendeel, het kan alles kapot maken. Pavel legde uit waarom technologie (zelfs de coolste) niet al je problemen kan oplossen:
De complexiteit van het project is verder gegaan dan de code. Voorheen was er een complexe applicatie: interactie binnen het project en complexe ontwikkeling, maar een eenvoudige structuur - de beheerder zette het in, alles werkte. We zijn overgestapt op microservices: elke service is een eenvoudige applicatie, communicatie via standaardprotocollen en snelle ontwikkeling, maar de projectstructuur is complexer geworden. De complexiteit van een project met een microservice-architectuur is niet verdwenen; het is verder gegaan dan de code. Nu is de DevOps-engineer er verantwoordelijk voor.
Ontwikkelaars willen geen veranderingen na de implementatie van DevOps. Als gevolg hiervan blijft de werkstroom met Kubernetes lijken op het over een muur gooien van taken van Dev naar Ops, maar niet metaforisch: Git wordt zo'n muur. De ontwikkelaar plaatst de code daar en werkt als voorheen, en de beheerders hebben Kubernetes, CI/CD en al het andere.
Ontwikkelaars moeten de wijzigingen echter accepteren. De situatie waarin ontwikkelaars niet weten wat beheerders doen, en beheerders niet weten wat er met ontwikkelaars aan de hand is, zorgt voor problemen.
Als er voor de ontwikkelaars niets is veranderd, realiseren ze zich niet dat de werking van de applicatie hun verantwoordelijkheid is - verschillende technische trucs zullen niet werken.
С приходом DevOps и Kubernetes в разработке многое поменяется. Dev должны быть компетентны в Ops, и наоборот. У этих специалистов свои специфические навыки, но они должны быть в курсе работы друг друга. Dev и Ops надо подружить до внедрения Kubernetes, иначе вы поломаете то, что есть.
Pavel Selivanov sprak over wat er over vijf jaar met Kubernetes zal gebeuren en waar een moderne startup een technologiestapel op zou moeten bouwen - bekijk het interview:
3. Vladimir Utratenko, X5 Retail Group: “DevOps in Enterprise is ontwikkeling zonder pijn en vuur”
Bedrijven komen tot DevOps-transformatie als ze beseffen dat de ontwikkeling te traag gaat en niet aansluit bij de realiteit. Ze willen zich beter ontwikkelen en sneller uitrollen.
Vladimir legde uit hoe dit gebeurt en wat de vangst is:
- Сначала компании нанимают DevOps-инженера. Это Senior System Administrator, он занимается развертыванием релиза в производство, стандартизацией окружения разработки, настройкой инфраструктуры, обнаружением и фиксом различных проблем, автоматизацией процессов и другими техническими задачами.
- Dan is één DevOps engineer niet meer genoeg en huurt het bedrijf een DevOps team in. Dit is een competentiecentrum dat de inspanningen van uiteenlopende ingenieurs organiseert en hen in staat stelt zich in één richting te concentreren.
- In feite zijn DevOps-ingenieurs en DevOps-teams anti-patronen van DevOps-transformatie. Omdat DevOps over praktijken en cultuur gaat, zijn er daarnaast implementaties van DevOps bij technologiebedrijven (SRE, Production Engineering).
Wat moeten we doen? Huur een tijdelijk DevOps-team in dat zal helpen bij het implementeren van DevOps-transformatie, het uitvoeren van praktijken, het cultiveren van een ontwikkelingscultuur en een technologische cultuur.
Wanneer een bedrijf een rol gaat spelen en in DevOps investeert, zijn er verschillende scenario’s mogelijk: alles valt bij de start uit elkaar; blijft SRE/Production Engineering of Embedded Ops; zal overstappen naar BizOps, wanneer processen gebaseerd zijn op bedrijfsstatistieken.
Vladimir Utratenko vertelde ons hoe “bloederig” DevOps in een onderneming werkelijk is en hoe praktijken worden geïmplementeerd binnen de grote detailhandel - bekijk het interview:
4. Sergey Puzyrev, Facebook: “Production Engineer geeft om de service als geheel: zodat zowel gebruikers als ontwikkelaars plezier hebben”
Facebook is een enorm bedrijf, met een groot aantal componenten, servers, mensen en datacenters. Ondanks zijn enorme omvang is het erg snel: ontwikkelaars kunnen diensten vele malen per dag uitrollen. Bovendien groeit Facebook snel, en niet alleen het aantal gebruikers en servers groeit, ook het aantal ontwikkelaars neemt toe, wat de processen complexer maakt.
Sergey vertelde op Facebook wat een Production Engineer doet:
- Een Production Engineer codeert veel, hij moet systeemkennis hebben: besturingssystemen, bestandssystemen, databases, netwerken en dergelijke. Moet ervaring hebben met het werken met gedistribueerde systemen en Reliability Engineering, dat wil zeggen het ondersteunen van de productbetrouwbaarheid. Hij moet op afroep beschikbaar zijn, dat wil zeggen dat hij op elk moment bereikbaar is.
- Production Engineer verschilt van Software Engineer doordat hij over geavanceerde vaardigheden beschikt, maar is in feite een ondersoort van Software Engineer. Software-ingenieurs coderen meer; ze hebben mogelijk extra vaardigheden die bijvoorbeeld verband houden met gegevensverwerking. Op Facebook moeten dergelijke specialisten ook oproepbaar zijn, wat voor velen een onaangename verrassing is.
- De piramide van behoeften van een productie-ingenieur in een bedrijf begint met het monitoren van servers en hun levenscyclus, dat wil zeggen het verkrijgen van nieuwe hardware, het opzetten en in gebruik nemen ervan. Het volgende niveau is hetzelfde op serviceniveau: monitoringdiensten en hun levenscyclus. Dan komt naadloze schaling en geavanceerde monitoring. Ze schakelen over op automatisch schalen nadat de servicelevenscyclus is geautomatiseerd. En uiteindelijk is het nodig om aanpassingen te doen, zodat de schaalvergroting effectief is en het bedrijf geld en middelen bespaart.
5. Mikhail Chinkov, AMBOSS: “Eén afdeling kan het DevOps-pad niet volgen, het hele bedrijf moet het volgen”
Mikhail gelooft dat DevOps een voortdurende ontwikkeling is. Je kunt niet een aantal instrumenten introduceren en daar stoppen. Welke problemen weerhouden bedrijven ervan om DevOps te worden en hoe kunnen ze deze praktijken implementeren?
Verschil in het begrijpen van DevOps. Canonieke devops, zoals evangelisten het zien, berust op 5 pijlers:
- cultuur - focus op mensen en samenwerking;
- automatisering - delegatie van routine naar workflow;
- lean – nadruk op het leveren van waarde aan de gebruiker;
- delen - continue uitwisseling van kennis;
- meetgegevens en het ontvangen van feedback op basis daarvan.
Bedrijven richten zich doorgaans alleen op automatisering en het leveren van waarde aan de gebruiker. Maar cultuur, kennisdeling en DevOps-statistieken om de ontwikkeling te volgen verdwijnen naar de achtergrond.
DevOps-standaardisatie-uitdagingen. Productdoelen zijn voor alle bedrijven verschillend en kunnen niet worden gestandaardiseerd. De staat van DevOps in een bedrijf hangt af van het bedrijf zelf, maar velen begrijpen dit niet en zijn van mening dat het voldoende is om een DevOps-ingenieur in te huren.
Waarom zijn we nog geen DevOps? Er zijn twee belangrijke problemen. In Enterprise is er een langzame ontwikkeling van de organisatie, problemen met het veranderen van de vector in de hoofden van duizenden werknemers. Bij startups is er een gebrek aan kennisbronnen en is er een probleem met het toewijzen van middelen voor transformatie.
Stadia van DevOps-ontwikkeling in een bedrijf:
- de eerste is de infrastructuur in de cloud, maar niemand weet hoe deze werkt, behalve een of twee beheerders;
- ten tweede is de infrastructuur transparant en begrijpelijk voor alle ingenieurs, maar zijn de processen niet gestroomlijnd;
- ten derde - ingenieurs lanceren en repareren onafhankelijk live-services;
- ten vierde - ingenieurs zullen optioneel bijdragen aan de kerninfrastructuur, transparante code in de cloud, implementatie per knop.
Идеальная схема — все имеют одинаковый доступ к инфраструктуре, все инженеры получают доступ к проду и понимают, что они делают.
Закрыв все культурные и технические гештальты, DevOps-трансформация компании будет учитывать обратную связь от бизнес-метрик и метрик платформы.
6. DevOps-enthousiastelingen van Rosbank: “1000 dagen om DevOps te implementeren in een bloedige onderneming”
Yuri Bulich, Dina Maltseva en Evgeny Pankov van Rosbank vertelden hoe ze in drie jaar tijd bij DevOps terechtkwamen. Er waren twee doelen: het oplossen van specifieke problemen in specifieke teams en het implementeren van gecentraliseerde tools.
Hier zijn de behaalde resultaten:
Resultaten voor productteams: 30 keer snellere montage, 6 keer snellere installatie, tot 30% besparing op de volledige cyclus. We hebben nu de mogelijkheid om met een druk op de knop naar productiviteit te gaan
Результаты для платформенных команд: 10 keer snellere montage en installatie, 87% groter aantal installaties, 46% autotestdekking. Het integratieteam is niet langer een knelpunt
Dus, hoe implementeer je DevOps-praktijken in een bloedige onderneming?
Voer eerst een proefproject uit: Selecteer teams, bepaal hoe de architectuur wordt geïmplementeerd en selecteer tools. We kozen voor tools met een open licentie, met installatie in de bank en expertise in het werken ermee. Rosbank implementeerde tegelijkertijd een private cloud samen met het DevOps-platform, en dit hielp in het begin. In de cloud was het mogelijk om met één druk op de knop binnen 15 minuten over de benodigde resources te beschikken; voorheen duurde zo'n proces een week.
Bij banken en andere ondernemingen is het noodzakelijk om de beperkingen vooraf met het informatiebeveiligingsteam uit te werken en een oplossing te vinden waarmee de wijzigingen kunnen worden geïmplementeerd.
Na de pilot moet een succesvolle oplossing worden opgeschaald.
- Het is belangrijk om de pijplijn zoveel mogelijk ‘recht te trekken’, onnodige verbindingen eruit te elimineren, waardeverschaffers onder de aandacht te brengen en de resterende componenten te verwijderen. Tussenproducten zijn antipatronen. Bij Rosbank ontwikkelde een aantal teams bijvoorbeeld geen interne ontwikkeling, waardoor er alleen externe ontwikkeling overbleef. Dit leidde tot de opkomst van een toegewijd DevOps-team, dat zorgde voor de overdracht van code van externe naar interne ontwikkelaars. Het probleem werd opgelost door externe ontwikkeling te integreren in CI/CD, zodat zij de code niet alleen van henzelf naar de bank zouden overdragen, maar ook verantwoordelijk zouden zijn voor het succes ervan.
- Het volwassenheidsmodel omvatte elementen van DevOps-praktijken, somde tools op en hield rekening met de kenmerken van het werken met externe leveranciers - in de toekomst hielp dit om de achterstand in taken snel weg te werken bij de implementatie ervan in nieuwe teams.
- We hebben governance nodig in de vorm van zachte controle en aanbevelingen. Een DevOps-handboek dat goed werkt, is een reeks organisatorische en toolkenmerken die teams helpen het platform correct te gebruiken.
- Je moet meteen aandacht besteden aan cultuur, dan zullen veel veranderingen sneller en gemakkelijker plaatsvinden. Laat uw interne gemeenschap groeien, organiseer meetups, technische workshops, trainingen en leuke activiteiten. Dat werpt zijn vruchten af: mensen delen praktijken, kijken wie wat heeft gedaan, weten waar ze terecht kunnen, er is sprake van een hype en gezonde concurrentie binnen het bedrijf.
- Het heeft geen zin om te werken met degenen die niet bij het proces betrokken zijn, met teams die nog niet volwassen zijn; het is beter om te investeren in geïnteresseerde teams en loyale mensen.
- De gekozen oplossing moet handig zijn voor de ingenieurs die er gebruik van maken.
- Externe ontwikkeling is geen blokker; praktijken kunnen daar ook worden geïmplementeerd, het belangrijkste is dat het team zelf de wens heeft.
Еще чуть-чуть пользы
Lijst met boeken die het lezen waard zijn voor mensen in DevOps, van Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Wil en zelfbeheersing."
- Daniel Kahneman "Denken, snel en langzaam".
- Barbara Oakley "Een geest voor cijfers".
- Maxim Dorofeev "Jedi-technieken".
- Viktor Frankl ‘De zoektocht van de mens naar betekenis’.
Blijf kijken
Wij houden ook van DevOps. Volg de aankondigingen van de serie en @Kubernetes, evenals andere Mail.ru Cloud Solutions-evenementen, in ons Telegram-kanaal:
Bron: www.habr.com