{"id":55735,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/eshhe-raz-o-devops-i-sre"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"eshhe-raz-o-devops-i-sre","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","title":{"rendered":"Nogmaals over DevOps en SRE","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Naar aanleiding van de discussie in de chat AWS Minsk Community<\/a><\/noindex><\/p>\n

De laatste tijd vinden er ware strijdtonelen plaats over de definitie van DevOps en SRE.
\nOndanks dat de discussies over dit onderwerp voor velen al lang niet meer nieuw zijn, heb ik besloten om mijn visie aan de Habr-gemeenschap voor te leggen. Voor degenen die ge\u00efnteresseerd zijn, welkom onder de cat. En laten we opnieuw beginnen!
\n<\/a><\/noindex><\/p>\n

Achtergrond<\/h4>\n

\nDus, in oude tijden bestonden er afzonderlijke teams van softwareontwikkelaars en serverbeheerders. De eersten schreven succesvol code, terwijl de laatsten, met allerlei warme en liefdevolle woorden richting de eersten, de servers instelden en af en toe naar de ontwikkelaars gingen, waarbij ze als antwoord kregen: \"Het werkt op mijn machine.\" Het bedrijf wachtte op de software, alles stond stil, er waren regelmatig storingen, iedereen was nerveus. Vooral degene die voor dit hele rompslomp moest betalen. De mooie lampenperiode. Maar jullie weten wel waar de wortels van DevOps liggen. <\/p>\n

De geboorte van DevOps-praktijken<\/h4>\n

\nToen kwamen er serieuze heren en zeiden: dit is geen industrie, zo kan je niet werken. En ze brachten levenscyclusmodellen mee. Bekijk bijvoorbeeld het V-model.<\/p>\n

\"Nogmaals
\nDus, wat zien we? Het bedrijf komt met een concept, architecten ontwerpen oplossingen, ontwikkelaars schrijven code, en dan komt de klap. Iemand test het product, iemand anders levert het aan de eindgebruiker en ergens aan het einde van dit wonderlijke model zit een eenzame zakelijke opdrachtgever te wachten op de beloofde verbetering. Men kwam tot de conclusie: we hebben methoden nodig die dit proces kunnen optimaliseren. En men besloot praktijken te cre\u00ebren die dit zouden realiseren.<\/p>\n

Een lyrische uitweiding over wat een praktijk is<\/b>
\nMet een praktijk bedoel ik een combinatie van technologie en discipline. Bijvoorbeeld: de praktijk van het beschrijven van infrastructuur als code met Terraform. Discipline is hoe je infrastructuur als code beschrijft, dat zit in het hoofd van de ontwikkelaar, en technologie is wat daadwerkelijk Terraform is.<\/p>\n

En besloten ze om deze DevOps-praktijken te noemen \u2014 ik denk dat ze het hadden over van Development naar Operations. Ze verzonnen verschillende ingewikkelde dingen \u2014 CI\/CD-praktijken, praktijken gebaseerd op het principe van IaC, duizenden ervan. En het ging van start, ontwikkelaars schrijven code, DevOps-engineers transformeren de systeemomschrijving in de vorm van code naar werkende systemen (ja, code is helaas slechts een beschrijving, maar geen belichaming van het systeem), de levering draait, en zo verder. Gisteren's beheerders, die de nieuwe praktijken onder de knie hadden gekregen, herkwalificeerden zich trots tot DevOps-engineers, en het ging allemaal van start. En het was avond, en het was ochtend\u2026 excuses, niet daarvandaan.<\/p>\n

Alles weer niet te geloven<\/h4>\n

\nNet als alles tot rust was gekomen, begonnen verschillende slimme 'methodologen' dikke boeken over DevOps-praktijken te schrijven, en er ontstonden stille discussies over wie nu precies de beruchte DevOps-engineer is en dat DevOps \u2014 een productie cultuur is, wat weer ongenoegen opriep. Plotseling ontdekte men dat softwarelevering \u2014 een absoluut niet triviale opgave is. Elke ontwikkelinfrastructuur heeft zijn eigen stack, ergens moet je bouwen, ergens moet je de omgeving opzetten, hier is tomcat nodig, daar is weer een ingewikkelde manier van starten nodig \u2014 kortom, het hoofd knalt uit elkaar. En het probleem, vreemd genoeg, bleek in de eerste plaats te liggen in de organisatie van processen \u2014 deze functie van levering, als een bottleneck, begon de processen te blokkeren. Bovendien werd de exploitatie (Operations) niet afgeschaft. Die is in het V-model niet zichtbaar, terwijl daar nog de hele levenscyclus aan de rechterkant is. Uiteindelijk moet je de infrastructuur ook onderhoud geven, en naar monitoring kijken, en incidenten oplossen, en daarnaast ook nog de levering uitvoeren. Dat wil zeggen, je moet met \u00e9\u00e9n voet zowel in ontwikkeling als in exploitatie staan \u2014 en plotseling ontstond zo een Development & Operations. En toen kwam er ook nog een grote hype rondom microservices. En met hen begon de ontwikkeling van lokale machines naar de cloud te verschuiven \u2014 probeer maar iets lokaal te debuggen, als er tientallen en honderden microservices zijn, hier wordt continue levering een manier van overleven. Voor een 'klein bescheiden bedrijf' is het nog wel te doen, maar toch? En Google?<\/p>\n

SRE van Google<\/h4>\n

\nGoogle kwam binnen, at de grootste cactussen op en besloot: dit is niet wat we willen, we hebben betrouwbaarheid nodig. En betrouwbaarheid moet beheerd worden. Daarom besloot hij dat we specialisten nodig hebben die de betrouwbaarheid gaan beheren. Hij noemde ze SR-engineers en zei: hier heb je alles, doe het zoals gewoonlijk goed. Hier heb je SLI, hier heb je SLO, hier heb je monitoring. En hij wees naar operations. En noemde zijn \"betrouwbare DevOps\" SRE. Het lijkt goed te zijn, maar er is een smerige hack die Google zich kon veroorloven: op de positie van SR-engineers mensen aannemen die de kwalificaties van ontwikkelaars hadden en ook nog een beetje ervaring hadden met hoe werkende systemen functioneren. En Google heeft zelf problemen met het aannemen van zulke mensen, vooral omdat hij ook tegen zichzelf concurreert; iemand moet immers ook de businesslogica beschrijven. De levering legde hij in de handen van release-engineers, SR-engineers beheren de betrouwbaarheid (natuurlijk niet rechtstreeks, maar door invloed uit te oefenen op de infrastructuur, architectuur te veranderen, wijzigingen en indicatoren bij te houden, en incidenten op te lossen). Mooi, kan. boeken schrijf<\/a><\/noindex>. Maar wat te doen als je niet Google bent, maar betrouwbaarheid je toch enigszins bezighoudt?<\/p>\n

De ontwikkeling van DevOps-idee\u00ebn<\/h4>\n

\nHier kwam Docker net op tijd, gegroeid uit lxc, en daarna verschillende orkestratiesystemen zoals Docker Swarm en Kubernetes, en DevOps-engineers haalden opgelucht adem \u2014 de uniformiteit van praktijken vereenvoudigde de levering. Het vereenvoudigde het zozeer dat het zelfs mogelijk werd om de levering aan ontwikkelaars over te dragen \u2014 wat is er moeilijk aan deployment.yaml? Containerisatie lost het probleem op. En de volwassenheid van CI\/CD-systemen is al zo ver gevorderd dat je gewoon \u00e9\u00e9n bestand schrijft en het gaat vanzelf \u2014 ontwikkelaars kunnen het zelf aan. En hier beginnen we te praten over hoe we onze eigen SRE kunnen maken, met... nou, met wie dan ook. <\/p>\n

SRE niet bij Google<\/h4>\n

\nNou goed, we hebben de levering geregeld, schijnt dat we weer kunnen ademhalen, terug naar de goede oude tijden, toen beheerders de CPU-belasting in de gaten hielden, systemen afstelden en in stilte iets onbekends uit mokken dronken, in rust en stilte\u2026 Stop. We hebben het niet voor dit alles gedaan (wat jammer!). Plots blijkt dat we de uitstekende praktijken van Google kunnen overnemen \u2014 niet de CPU-belasting is belangrijk, en niet hoe vaak we de schijven daar vervangen, of hoe we de kosten in de cloud optimaliseren, maar de zakelijke metriek \u2014 diezelfde beruchte SLx. En het beheer van de infrastructuur is daar niet van verdwenen, incidenten moeten opgelost worden, en je moet af en toe dienstdoen, en in het algemeen op de hoogte blijven van de bedrijfsprocessen. En jongens, begin al een beetje op een goed niveau te programmeren, Google wacht al op jullie.<\/p>\n

Samenvattend. Plotseling, maar je bent al moe van het lezen en je kunt niet wachten om de auteur een reactie onder het artikel te sturen. DevOps als leveringspraktijken was, is en zal blijven bestaan. En zal nergens naartoe gaan. SRE als een verzameling exploitatiepraktijken maakt deze levering succesvol.
\n
Bron: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u0447\u0430\u0442\u0435 AWS Minsk Community \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u0440\u0430\u0437\u0433\u043e\u0440\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0431\u0438\u0442\u0432\u044b \u043d\u0430 \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043d\u044f\u0442\u0438\u044f DevOps \u0438 SRE. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0443\u0436\u0435 \u0432\u043e \u043c\u043d\u043e\u0433\u043e\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443 \u0443\u0436\u0435 \u043d\u0430\u0431\u0438\u043b\u0438 \u043e\u0441\u043a\u043e\u043c\u0438\u043d\u0443, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u0438 \u043c\u043d\u0435, \u0440\u0435\u0448\u0438\u043b \u0432\u044b\u043d\u0435\u0441\u0442\u0438 \u043d\u0430 \u0441\u0443\u0434 \u0445\u0430\u0431\u0440\u0430-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0430 \u0438 \u0441\u0432\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443. \u0422\u0435\u043c, \u043a\u043e\u043c\u0443 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e, \u0434\u043e\u0431\u0440\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":55736,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Weer over DevOps en SRE | ProHoster","description":"Naar aanleiding van de discussie in de chat van de AWS Minsk Community. De laatste tijd zijn er echte gevechten ontstaan over de definitie van het begrip.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0415\u0449\u0435 \u0440\u0430\u0437 \u043e DevOps \u0438 SRE | ProHoster","og:description":"\u041f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0434\u0438\u0441\u043a\u0443\u0441\u0441\u0438\u0438 \u0432 \u0447\u0430\u0442\u0435 AWS Minsk Community \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u0440\u0430\u0437\u0433\u043e\u0440\u0430\u044e\u0442\u0441\u044f \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0431\u0438\u0442\u0432\u044b \u043d\u0430 \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043d\u044f\u0442\u0438\u044f.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/eshhe-raz-o-devops-i-sre","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-10-05 06:23:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/55735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=55735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/55735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/55736"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=55735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=55735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=55735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}