Jaka jest różnica między Sysadmin a DevOps Engineer?

40

Podczas ubiegania się o pracę zwykle można znaleźć dwa rodzaje podobnych zadań: Inżynier Sysadmin i Inżynier DevOps .

Oba dotyczą konfiguracji serwera i zapewniają niezawodne działanie systemów komputerowych. Różnica między nimi może być trudna. Jakie są główne różnice między nimi?

kenorb
źródło
3
Powiązane: Jaka jest różnica między SRE a DevOps?
Sathyajith Bhat
2
Możliwy duplikat Jaka jest różnica między SRE a DevOps?
Woodland Hunter
Warunki SRE i sysadmin są różne.
kenorb
2
Proponuję dołączyć definicję sysadmin i pozwolić na odpowiedzi, którzy mogą porównać to do roli DevOps. Osobiście uważam, że DevOps nie jest nawet rolą ... więc chciałbym coś powiedzieć w tej sprawie.
Evgeny
1
@Evgeny Powiedz to agencjom rekrutacyjnym.
kenorb

Odpowiedzi:

54

Głównie DevOps nie jest rolą (gdy jest używany jako taki, jest bardziej modnym hasłem niż prawdziwą rolą).

DevOps to z grubsza wzór organizacyjny mający na celu przełamanie silosu między deweloperami a administratorami.
Głównym celem jest budowanie zespołów z programistami i administratorami (zwykle wraz z testerami) odpowiedzialnych za produkt (aplikację) od jego definicji, od decyzji dotyczących architektury, aż po utrzymanie w działaniu tego produktu.
Każdy członek zespołu będzie częścią decyzji dotyczącej całego cyklu życia produktu, programista wykona niektóre zadania sysadmin w produkcji, a sysadmin będzie uczestniczył w fazie projektowania produktu, aby uniknąć zastrzeżeń z punktu widzenia infrastruktury na przykład.

W idealnym przypadku sysadmin byłby również częścią zespołu programistów produktu, w rzeczywistości sysadmin koduje bardziej konfigurację wokół produktu i rozwiązań monitorujących, ale będąc w stanie wyrazić obawy innym członkom zespołu, uniknąć wielu nieporozumień w procesie wdrażania.

Tensibai
źródło
9
Tyle, że ... DevOps nie jest rolą. Administrację systemu wykonujesz w inny sposób jako „część” kultury DevOps.
Ken Mugrage,
2
Niektóre organizacje, w których pracowałem (bardziej przypadkowo niż projektowo) doprowadziły to do skrajności: nie mieliśmy dedykowanych sysadminów, a całą pracę sysadminów wykonali „zwykli” programiści. (W tej konkretnej organizacji wielu programistów było bardzo doświadczonymi administratorami systemów, więc nigdy nie czuliśmy potrzeby zatrudniania kogoś, kto się w tym specjalizuje.)
Curt J. Sampson,
„DevOps to z grubsza wzór organizacyjny”, tym bardziej oświecający fragment, który przeczytałem do tej pory.
Webwoman
Możesz wyjaśnić, że DevOps! = NoOps
sgargel
20

Krótka wersja

DevOps łączy kulturę organizacyjną, metody pracy Agile / Lean i automatyzację oprogramowania, które po zastosowaniu do Administracji i Operacji Systemów pozwalają tym funkcjom działać na tym samym poziomie Agility, co Agile lub Lean Development Teams.

Długa wersja

Pomysły DevOps zrodziły się ze społeczności Administracji Systemów, Operacji i Agile, w szczególności Patrick Debois wygłosił prezentację na Agile2008 zatytułowaną „Agile Infrastructure”, gdzie podkreślił różnicę między sposobem działania trzech funkcji w organizacji:

  1. Zwinne zespoły programistyczne - zwinne zespoły piszące kod.
  2. Zespoły administracji systemów - budowanie infrastruktury do uruchamiania oprogramowania.
  3. Zespoły operacyjne - wspieranie aplikacji i infrastruktury w produkcji / na żywo.

Propozycja Debois polegała na ujednoliceniu trzech sposobów współpracy, w szczególności przeniesieniu zespołów administracji systemów i zespołów operacyjnych z modelu wodospadu do modelu zwinnego. W tym celu Debois skonfigurował DevOpsDays 2009 w Gandawie w Belgii, nieumyślnie tworząc frazę DevOps .

Idea DevOps rozbrzmiewała wraz z autorami serii książek VisibleOps: Gene Kim, George Spafford i Kevin Behr; który napisał dalej The Phoenix Project i The DevOps Handbook . Obie książki pokazują, w jaki sposób Agile i Lean mogą pozytywnie wpłynąć na zespoły administracji systemów i operacji.

Richard Slater
źródło
1
Doskonałe podsumowanie! Najlepsze, jakie widziałem w historii tej filozofii i stylu inżynierii.
Jesse Adelman
9

Jako inżynier DevOps pochodzący ze środowiska Operations, przeszedłeś od ręcznego budowania i wdrażania serwerów i oprogramowania do skryptowania instalacji oprogramowania na swoich serwerach, takich jak BASH, PowerShell, Python itp. Po chwili zdasz sobie sprawę, jak fajne skrypty są i zacznij odkrywać bardziej wyrafinowane sposoby automatyzacji wdrażania .

Ostatecznie zdecydowałbyś się na Chef, Puppet, Ansible lub inne narzędzie do zarządzania konfiguracją , aby pomóc zarządzać stanem swojej floty systemów. W miarę dojrzewania twoich umiejętności w zakresie automatyzacji wdrażania aplikacji i zarządzania systemem, wraz z narzędziami, niedawno przeniosłeś się do dziedziny „ Infrastruktura jako kod ” i używasz jej nie tylko do automatyzacji wdrażania oprogramowania, ale także wymaganej infrastruktury i środowisk do kierowania oprogramowaniem podczas przejścia firmy na chmurę.

Teraz gotujesz na gazie. Z czasem poznałeś zalety korzystania z narzędzi programistycznych, takich jak kontrola źródła, do zarządzania modułami, przepisami i szablonami, które tworzą arsenał narzędzi do wdrażania i zarządzania.

Kiedy przeszedłeś do zespołu DevOps , byłeś narażony na cykl życia oprogramowania i koncepcję ciągłej integracji . Chłopcy, ci programiści szybko wprowadzali zmiany i aby nadążyć, znalazłeś się bliżej z twórcami! Doświadczyłeś pilnej potrzeby zespołu programistów, by zmieniać rzeczy przez cały czas, co jest sprzeczne ze starym paradygmatem operacyjnym: „ jeśli to nie jest zepsute, nie naprawiaj go ”. Nigdy więcej chwalenia się przestojem systemu, jesteś w infrastrukturze jednorazowego użytku .

Zauważyłeś, że przejście na DevOps było czymś więcej niż pracą z deweloperami lub użyciem nowych narzędzi i technik , ale w zespole nastąpiła wyraźna zmiana kulturowa , która przeniknęła całą organizację. Pracowałeś jako zgrany zespół o wspólnych obowiązkach , wspólnym oprzyrządowaniu i wspólnych celach .

Wykorzystałeś swoje umiejętności w zakresie automatycznego wdrażania i wmasowałeś je w potokCICDkoordynowany przez „ serwer ciągłej integracji ”, taki jak Jenkins , Bamboo lub Code Pipeline . Teraz, gdy programiści wprowadzają nowy kod, twoje skrypty, narzędzia i szablony stawiają nowe środowiska na żądanie, uruchamiają ramy testowe, aby wykonać swoje zadania i niszczą środowiska przedprodukcyjne po zapaleniu zielonych świateł w wydaniu, zgodnie z pomysły „ ciągłej dostawy ”.

Gdy nowy kod przechodzi przez etapy CICD, Ty, programiści i biznes zyskujesz pewność, że aktualizacja nie ulegnie awarii po wydaniu do produkcji. Jest jeszcze jedna droga, zanim zespół przejdzie do „ ciągłego wdrażania ”, nadal musisz zadecydować o drobniejszych punktach automatyzacji możliwości niebieskiego / zielonego wdrażania, a decyzja jest w większości biznesowa. Na razie jesteś zadowolony, że liczba połączeń o 3 nad ranem zmniejszyła się, a liczba sev-1 i sev-2 maleje.

Nawet jeśli dostaniesz sev-1, nie będziesz już ciągnął przez całą noc, a menedżerowie oddychają ci plecami - możesz łatwo wydać poprzednią wersję za pośrednictwem rurociągu CICD i ponownie uruchomić system w krótkim czasie. Firma zauważyła, że stabilność systemów informatycznych poprawiła się pomimo szybkości zmian .

Dziwisz się sposobem zarządzania zasobami potrzebnymi do napędzania oprogramowania w Twojej firmie, zwłaszcza gdy myślisz o tym, jak to było kiedyś i ile krwi pozostawiłeś na szynach w centrum danych ...

rdp-cloud
źródło
6

Sysadmin vs. DevOps (widok osobisty)

Niektóre firmy mówią o programistach, operacjach i testach. Jeśli coś wymaga przetestowania, mówią: „Test powinien to zrobić”. Jeśli coś trzeba opracować, Dev to zrobi, a jeśli konieczne będzie wdrożenie oprogramowania, Ops to zrobi.

Moim zdaniem, i czego doświadczyłem w kilku firmach, jest to, że skutkuje to postawą „przerzucenia przez mur”, która powoduje tarcie między ludźmi i zespołami. Osobiście czasami czuję, że ludzie pracują indywidualnie i mówią, że to właśnie zrobiłem. Nie mam nic do roboty zamiast pracować jako zespół.

Według mnie DevOps oznacza, że ​​wszyscy w zespole są odpowiedzialni i zajęci rozwojem, testowaniem i działaniami. W zespole nie ma mnie ani osobnych działów. Każdy powinien zwolnić. Oczywiście są specjalności, ale moim zdaniem każdy powinien być w stanie wykonać co najmniej 25% niektórych prac w każdej dziedzinie. Np. Jeśli ktoś był programistą w tamtych czasach, należy zmienić kod zarządzania konfiguracją, np. Szefa kuchni i wdrożyć oprogramowanie.

Referencje

Sysadmin

Według Wikipedii :

Administrator systemu lub sysadmin to osoba odpowiedzialna za utrzymanie, konfigurację i niezawodne działanie systemów komputerowych; szczególnie komputery z wieloma użytkownikami, takie jak serwery.

Administrator systemu dąży do tego, aby czas działania, wydajność, zasoby i bezpieczeństwo komputerów, którymi zarządza, odpowiadał potrzebom użytkowników, nie przekraczając budżetu.

Aby spełnić te potrzeby, administrator systemu może nabywać, instalować lub aktualizować komponenty i oprogramowanie komputerowe; zapewnia rutynową automatyzację; utrzymywać polityki bezpieczeństwa; rozwiązywać problemy; szkolić lub nadzorować personel; lub zaoferować wsparcie techniczne dla projektów.

DevOps

Według Wikipedii :

DevOps (skrótowy związek „rozwoju” i „operacji”) to proces opracowywania i dostarczania oprogramowania, który kładzie nacisk na komunikację i współpracę między zarządzaniem produktem, tworzeniem oprogramowania i specjalistami operacyjnymi. Wspiera to poprzez automatyzację i monitorowanie procesu integracji oprogramowania, testowania, wdrażania i zmian infrastruktury poprzez ustanowienie kultury i środowiska, w którym tworzenie, testowanie i wydawanie oprogramowania może się odbywać szybko, często i bardziej niezawodnie.

DevOps

wprowadź opis zdjęcia tutaj

DevOps Toolchain

wprowadź opis zdjęcia tutaj

030
źródło
1
Tylko jeden mały komentarz: IMHO tak długo, jak cały zespół ma dobre relacje z każdym aspektem obszarów deweloperskich / operacyjnych / testowych i ma dobrą komunikację, nie jest absolutnie konieczne, aby każda osoba w zespole obejmowała również każdy taki obszar. Oczywiście, jeśli tak się stanie, dobrze, ale wymaganie może być w niektórych przypadkach niepotrzebnie drogie.
Dan Cornilescu
2

Administrator systemu jest odpowiedzialny za utrzymanie i konfigurację serwerów, a jego zadaniem jest zapewnienie użytkownikowi wydajności, czasu pracy i bezpieczeństwa, którego szukają. Zdefiniowanie roli inżyniera DevOps jest nieco trudniejsze, ponieważ nie ma formalnej ścieżki kariery, a samo DevOps może mieć wiele form.

Inżynier DevOps może być na przykład deweloperem zainteresowanym operacjami sieci i wdrażania lub administratorem systemu, który ma pasję do kodowania i skryptowania. Przejście od administratora systemu do inżyniera DevOps nie jest bardzo trudne, w rzeczywistości ten artykuł bardzo dobrze opisuje ten proces.

Wiele osób twierdziło nawet, że przejście od administratora systemu do inżyniera DevOps jest niezbędne, ponieważ stanowisko administratora systemu stanie się w przyszłości przestarzałe. Mimo że istnieje wiele starszych serwerów, które wymagają konserwacji, a administratorzy systemu dysponują dużą „wiedzą plemienną”, pozycja sysadmin w przyszłości będzie coraz mniejsza.

DevOps Jedi
źródło
-1

Będą serwery, których nie słyszysz, działające w centrach danych. Wszystko będzie oprogramowaniem. Pamięć masowa, sieć, systemy, bezpieczeństwo, centra danych; SDN, zapory ogniowe, NFV, pamięć masowa, serwery itp. Sysadmini bez doświadczenia programistycznego, doświadczenie SDLC (nie mam nawet na myśli skryptów Perl, Powershell itp.) Prawdopodobnie znikną. Rozproszone, skalowalne i zwirtualizowane środowiska, w większości chmurowe, rosną poziomo, a nie pionowo.


Odważę się powiedzieć, że Sysadminowie rosną w pionie, DevOps (lub OpsDev) rosną w poziomie. Możesz zobaczyć ten sam wzorzec ewolucji mikrousług z monolitów. Wolę wybrać inżyniera DevOps z zespołu oprogramowania, a nie zespołu operacyjnego / systemowego.

Ponieważ zespół operacji / systemu po prostu uruchamia to, co buduje zespół oprogramowania.

  • Administratorzy systemów nie budują / kompilują jądra Linux / FreeBSD / Windows itp., Podobnie jak inżynierowie oprogramowania budują / kompilują aplikacje.
  • Administratorzy systemów nie przechodzą cyklu życia oprogramowania (SDLC).
  • Administratorzy systemów nie są częścią procesu produkcyjnego (proces CI / CD).
  • Sysadmin zaczyna działać po zakończeniu CI / Continuous Delivery / Deployment.

    A jeśli złamiesz i przypisasz wdrożenie / dostawę, może to być zepsuty potok
    , zespół oprogramowania jest systemem twórców / zespół operacyjny to głównie biegacze / opiekunowie.

Wygląda na to, że nie ma serwera / systemu do administrowania, nie jest potrzebne sysadmin.

Przetwarzanie bezserwerowe to model wykonawczy przetwarzania w chmurze, w którym dostawca chmury działa jako serwer, dynamicznie zarządzając alokacją zasobów maszynowych. Wycena oparta jest na faktycznej ilości zasobów zużywanych przez aplikację, a nie na wcześniej zakupionych jednostkach mocy obliczeniowej Bez serwera

Ktoś z zespołu programistycznego już wie, jak budować, a nawet utrzymywać kodowanie (SRE vs DevOps / OpsDev).


Zastanawiam się, dlaczego nazywa się DevOps, ale nie OpsDev? czy jest to związane z kierunkiem między nimi?

* W szczerym polu nie zacząłem pisać o pamięci zdefiniowanej programowo, jest to reakcja na usunięty komentarz na ten temat *

Informacje o pamięci zdefiniowanej programowo

hakkican
źródło
1
Nie dodawaj nazwisk w odpowiedzi, trzymaj je zgodnie z pytaniem, ponownie polecam przeczytać Poradę odpowiedzi .
Tensibai