GNU/Linux >> Znalost Linux >  >> Linux

Primární odpovědnosti inženýra DevOps

V této sérii článků o DevOps jsem zahájil diskusi znovuzavedením DevOps s novým pohledem. Ve druhé části jsem udělal totéž, ale se zaměřením na životní cyklus vydání softwaru.

Ve třetí části jsem bodově a tabulkově rozlišil role softwarového inženýra a inženýra DevOps:

V této čtvrté části se chci znovu zaměřit zejména na roli DevOps Engineer a podrobně rozvést jejich primární povinnosti.

Než začnu, navrhuji, abyste se rychle podívali na naše nové modely, zejména na životní cyklus vývoje systému a schémata životního cyklu vydání softwaru, která byla uvedena dříve.

Zkoumání základních povinností inženýra DevOps

Povinnosti softwarového inženýra jsou již poměrně dobře známy. Je však nutné prozkoumat, jak se scénáře mění v případě DevOps Engineer:

Plánování nasazení softwaru

Na rozdíl od plánování návrhu softwaru, jak to dělají softwaroví inženýři, plánování jeho nasazení může být úplně jiná odpovědnost. Na základě předběžného konceptu softwaru navrhli vývojáři plán založený na tom, jak bude nasazen. Ve skutečnosti však plánování jeho nasazení na různé platformy může hrát významnou roli pro kteréhokoli inženýra DevOps, který se velmi pečlivě stará o to, aby to dopadlo.

Správa kódu

Správa kódu je důležitým aspektem pro jakýkoli software běžící v produkci. Pravidelné auditování kódu nesmírně pomáhá při minimalizaci chyb, které by se mohly vyskytnout v produkčním prostředí. Inženýři DevOps se starají o doladění již existujícího kódu vytvořeného od počátku softwaru na úrovni alfa a také o postprodukci.

Dokumentace postupu nasazení

Ani vynikající software by nebyl dobrý, kdyby neměl jasnou a stručnou dokumentaci. Softwaroví inženýři dokumentují, jak vytvořit software a jak jej nasadit. Ale DevOps Engineers se zaměřují výhradně na dokumentaci postupu nasazení.

Čím je software starší díky svému produkčnímu využití, tím důležitější je důsledně kontrolovat proces jeho nasazení. Proto je dokumentace neustálým úsilím a je stejně důležitá jako revize kódu. Lepší dokumentace =Menší chyby. Věděli jste:

Testování dokumentace je nefunkční typ testování softwaru.

Testování pouze stabilních verzí softwaru

Na rozdíl od softwarových inženýrů jsou role DevOps zaměřeny pouze na stabilní verze, protože pouze tyto verze jsou významné pro prostředí na produkční úrovni pro nasazení. Software, který dokončil svůj první ADLC (Application Development Life Cycle), musí být důkladně otestován z hlediska jeho potenciálu jako stabilní produkční verze a o to se stará specializovaný inženýr DevOps.

Hlášení chyb s kritickými opravami (je-li potřeba)

Tato část je kombinací dokumentování a opravy chyb. Když běží stabilní verze ve výrobě, všechny chyby, které se během tohoto procesu vyskytnou, musí být pečlivě opraveny pro příští stabilní vydání softwaru.

Obecně platí, že za opravu chyb odpovídají vývojáři. Ale v případě potřeby mohou inženýři DevOps také zasáhnout a spolupracovat na řešení oprav chyb, které jsou ve své podstatě kritické. Opravy chyb na kritické úrovni lze proto tímto způsobem opatrně urychlit.

Také zdokumentování prevence nebo dočasných řešení (dokud nebudou opravena) chyb může být mimořádně přínosné pro efektivitu a spolehlivost softwaru. To má přímý dopad na funkčnost, použitelnost a bezpečnost.

Nasazení stabilních vydání v produkčním prostředí

Jakmile se na základě důkladného testování, jak je uvedeno výše, potvrdí, že software je spolehlivý a účinný, je nakonec nasazen do výroby pomocí pokynů krok za krokem, které dříve zdokumentoval DevOps Engineer. Význam dokumentace je nejlépe pochopen pouze tehdy, když nasadíte software do výroby.

Údržba a monitorování nasazení

Software běžící ve výrobě vyžaduje nepřetržitou údržbu a monitorování. Inženýr DevOps zajišťuje, že software je aktuální a také platformy, na kterých jsou nasazeny. Zejména během této fáze lze zaznamenat chování na úrovni výroby pro zlepšení budoucí použitelnosti. To zahrnuje chyby na produkční úrovni, nutnost nových funkcí a také vylepšení uživatelského rozhraní a zabezpečení.

Přeplánování návrhů na základě chování na úrovni výroby

Plánování nasazení softwaru je nepřetržitý proces, který začíná předběžným plánem a koncepcí nasazení nástroje, aby splnil svůj cíl. Jakmile vyjde první stabilní vydání, tento plán prochází přísnými revizemi po každém novém stabilním vydání. Revize v postupu nasazení softwaru jsou založeny na zpětné vazbě získané z každé z fází životního cyklu vývoje aplikací a životního cyklu vývoje systému.

Toto byl přehled o pochopení významu role DevOps Engineer. Jejich různorodé odpovědnosti je jasně dávají vyniknout a zdůrazňují jejich potřebu zajistit nepřetržité vylepšování softwaru, dokud a dokud nedosáhne konce životnosti. Velké poděkování všem oddaným technikům DevOps!

Doufám, že vám tento článek byl užitečný. Pokud máte další nápady, které byste mohli sdílet jako zpětnou vazbu nebo návrhy, udělejte to prosím v sekci komentářů níže.


Linux
  1. Evoluce správců balíčků

  2. Primární versus logický oddíl?

  3. Základy YAML musí znát každý inženýr DevOps

  1. RR - Softwarový debugger pro nahrávání a přehrávání

  2. Jaké jsou odpovědnosti jednotlivých komponent pseudoterminálu (pty) (software, hlavní strana, vedlejší strana)?

  3. Porovnání nástrojů Ansible vs Jenkins:DevOps

  1. Ansible vs Concourse:Porovnání nástrojů DevOps

  2. Top 10 Helpdesk Support Ticket Software

  3. Steganografický software