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

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?

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.

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.

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 potok „ CICD ” koordynowany 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 ...

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

DevOps Toolchain

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.

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

• Pamięć definiowana programowo (SDS) to termin marketingowy dotyczący oprogramowania do przechowywania danych w celu zapewnienia opartego na zasadach udostępniania i zarządzania przechowywaniem danych niezależnie od sprzętu. Pamięć zdefiniowana programowo

• EMC ogłosiło swój pierwszy w historii produkt open source: Project CoprHD. CoprHD to kontroler automatyzacji i zarządzania pamięcią masową zdefiniowaną programowo, a ostatnia decyzja EMC o otwarciu źródła jest u podstaw naszej strategii zapewniania większej wartości globalnym firmom, gdy wkraczamy w obszar wzrostu i skrajnych zmian. Jako światowy lider w dziedzinie pamięci masowej i zarządzania informacjami firma EMC jest liderem w dziedzinie pamięci masowej definiowanej programowo (SDS) .

• CoprHD to zdefiniowany programowo kontroler pamięci i platforma API. Umożliwia oparte na zasadach zarządzanie i automatyzację w chmurze zasobów pamięci masowej dla dostawców bloków, obiektów i plików CoprHD