Jaka jest różnica między DevOps a automatyzacją?

42

Widzę, że ilekroć ktoś robi DevOps, chodzi głównie o automatyzację takich rzeczy, jak wdrożenie itp.

Ale gdzie kończy się automatyzacja, a zaczyna DevOps?

Różowa Pantera
źródło
Cześć @punkpanther, jeśli ta lub jakakolwiek odpowiedź rozwiązała twoje pytanie, rozważ zaakceptowanie go , klikając znacznik wyboru. Wskazuje to szerszej społeczności, że znalazłeś rozwiązanie i daje pewną reputację zarówno użytkownikowi, jak i odbiorcy. Nie ma takiego obowiązku. Jeśli uważasz, że nie ma odpowiedzi na twoje pytanie, zachęcamy do kontaktu z autorami w komentarzach.
Richard Slater
Być może lepszym pytaniem byłoby, gdzie kończy się DevOps i zaczyna się automatyzacja? Nie wszystko zrobione z DevOps dotyczy automatyzacji; duża część tego, tak, ale nie wszystko ... Można powiedzieć, że DevOps to wszystko oprócz automatyzacji - to sysadmin cultrue, wspólne standardy architektury, wspólne standardy publikowania (powiedzmy GitHub) w określonej dziedzinie technologii ... Gdzie czy automatyzacja w tej konkretnej dziedzinie zaczyna się sama, myślę, że dobre pytanie, myślę ...
JohnDoea,

Odpowiedzi:

45

Duża część DevOps umożliwia bardzo częste wydawanie. Obejmuje to automatyczne budowanie, automatyczne testowanie itp. Można powiedzieć, że aby osiągnąć swoje cele, DevOps musi korzystać z automatyzacji, aby być wydajnym.

Oto jak DevOps i automatyzacja są ze sobą powiązane. DevOps to nie tylko automatyzacja, jest w tym coś więcej. I odwrotnie, automatyzacja nie jest wykorzystywana wyłącznie przez „DevOps people”. Zanim pojawiło się DevOps, w IT działała duża automatyzacja.

DevOps w odniesieniu do automatyzacji

Proszę nie rozważać powyższego schematu do reprezentowania wszystkiego, co jest DevOps, lub wszystko to jest automatyzacja. Ma to pomóc czytelnikowi zobrazować, jak te dwie koncepcje są ze sobą powiązane.

Alexandre
źródło
1
Dokładnie to, co powiedziałem na ten temat :)
Tensibai
Dlaczego „przepływ pracy biletów” w DevOps?
Nakilon
15

Automatyzacja jest kluczowym atrybutem DevOps, ale nie jest to pełna historia. Pytanie jest trochę jak „Jaka jest różnica między boxingiem czasowym a Scrumem?”.

Usłyszysz, jak DevOps nazywa się „kulturą”, „ruchem”, „metodologią” i wszelkimi innymi rzeczami, które nie będą zawierały wystarczającej wiedzy, abyś mógł je zrozumieć, nawet jeśli te opisy są dokładne. W skrócie, DevOps dotyczy zbiegu metodologii Agile, automatyzacji i wirtualizacji, która umożliwia nową pętlę sprzężenia zwrotnego w zarządzaniu / kontroli / sterowaniu projektem oprogramowania.

Dzięki agresywnej automatyzacji rzeczy, które zajmują dużo czasu i są narażone na błędy ludzkie, dzieją się teraz szybko i bez incydentów. W rezultacie robimy to częściej. Podstawowym przykładem tego jest „wdrożenie do produkcji”. Oszczędzaliśmy duże partie pracy i wdrażaliśmy je poza godzinami pracy na wypadek, gdyby „coś poszło nie tak”. Ale teraz możemy wdrażać zmiany kilka razy dziennie, w taki sposób, że szanse na „coś nie tak” są znacznie zmniejszone, a wpływ czegoś nie tak jest znacznie mniejszy, kiedy to nastąpi.

Po wdrożeniu tego powtarzalnego procesu zaczynamy postrzegać go jako „potok”. Wchodzą wymagania, wychodzi kod wdrożony w produkcji. Automatyzujemy wszystko wzdłuż tego potoku - testy, dokumentację, fuzje, wdrożenia i więcej testów itd. Ponieważ ludzie skupiają się na automatyzacji, nie widzą „mentalności potoku”, która ją napędzała. Jest to metodologia zarządzania - uwaga zwrócona na proces - która sprawia, że ​​DevOps to więcej niż automatyzacja.

Kiedy mamy już tę automatyzację, uruchamiają się pętle sprzężenia zwrotnego. Zaczynamy mierzyć takie rzeczy, jak czas cyklu , abyśmy mogli ustalić rzeczy, które wcześniej próbowaliśmy zgadywać z oszacowaniami. Rzeczy na temat architektury, która utrudnia automatyzację / ciągłe dostarczanie, zwykle zastępuje się alternatywnymi wzorami architektonicznymi, które ułatwiają automatyzację / ciągłe dostarczanie (kilka świetnych przykładów tego jest udokumentowanych w książce „Ewolucyjne bazy danych”. Innym przykładem są zielone i niebieskie wdrożenia) ).

Zauważ, że byłem w stanie podać ten opis bez mówienia o Jenkins, Check, Puppet, Ansible, Vagrant, AWS lub jakimkolwiek innym narzędziu, które go obsługuje. To właśnie rozumiemy przez słowa z wyższego poziomu, takie jak „metodologia”. Ostatecznie każdy zestaw narzędzi może zostać zastąpiony ... Pozostaje nam podstawowa zasada zarządzania możliwa dzięki automatyzacji i koncentracji na rurociągu.

David Bock
źródło
1
Przykro mi, ale to brzmi jak manifest Agile bardziej niż przekazuje informacje o kulturze moim uczuciom. Metodologia zwinna / iteracyjna / krótkiego cyklu, nawet jeśli często stosowana, nie jest obowiązkowa dla organizacji deweloperów. Możesz mieć zespoły deweloperów przy projekcie wodospadu i możesz zautomatyzować dostawy oparte na silosie, dlatego wydaje mi się, że te odpowiedzi częściowo odpowiadają na pytanie.
Tensibai
2
@Tensibai Muszę się nieco nie zgodzić - nie automatyzujesz procesu, który nie wykonuje się często. DevOps bez zwinności przypomina automatyzację budowy wielomilionowego supersamochodu.
Dave Swersky
Ta odpowiedź jest niezwykle szczegółowa i trudno jest wyodrębnić różnice lub zalety / wady, które dotyczą OP Q.
Evgeny
@Dave nie rozumiesz, musiałem być niejasny, mam na myśli to, że kultura devops polega na przełamywaniu zespołów silosów, automatyzacja lub krótki cykl nie są ze sobą powiązane, nawet jeśli zwykle, nie widziałem tego ważnego punktu w twojej odpowiedzi
Tensibai
13

DevOps to tak naprawdę zmiana kulturowa - ma ona na celu przełamanie tradycyjnych barier między operacją a rozwojem (a tak naprawdę również z kontrolą jakości i resztą biznesu!). Chodzi o to, że zamiast mieć „silosy” działowe, możesz bezpośrednio współpracować z innymi zespołami, aby szybciej i wydajniej wykonywać zadania.

Chodzi przede wszystkim o usunięcie ograniczeń i usprawnienie procesów. Automatyzacja jest bardzo ważna, ponieważ powtarzalne procesy pomagają usunąć ograniczenia. Na przykład: jeśli ktoś z ops musi wykonać ręczny proces wydania, aby wydostać kod do środowiska, istnieje kilka rzeczy, które mogą temu przeszkodzić - jedną z nich jest to, że musi być ktoś w ops, aby wykonać wdrożenie, a po drugie, proces wydawania jest mniej pewny, ponieważ praca ręczna jest podatna na błędy.

tayworm
źródło
4

DevOps obejmuje automatyzację, ale to tylko jej część. DevOps to zmiana kulturowa polegająca na rozbiciu silosów między różnymi częściami organizacji w celu zapewnienia pełnego strumienia wartości. Zapewniamy kulturę, w której biznes, rozwój, zapewnienie jakości, infrastruktura, bezpieczeństwo, operacje itp. Działają razem, aby zapewnić wartość każdemu, kto jest końcowym użytkownikiem. DevOps nie jest narzędziem, nie możesz go kupić, musisz zmienić swoją kulturę.

Automatyzacja jest kluczową częścią DevOps, ponieważ pozwala na szybkość dostawy z jakością. Automatyzacja procesu wdrażania jest jednym z obszarów, na którym koncentruje się wiele osób, ponieważ jest to jeden z najlepszych sposobów szybkiego uzyskania wartości i zapewnia wysoki zwrot z inwestycji poprzez nie tylko skrócenie czasu wdrożenia, ale także ujednolicenie procesu i usunięcie błędy.

Rosalind Radcliffe
źródło
1

Chciałbym dodać moje 2 centy:
1) Automatyzacja :
     Coś, do czego musimy obecnie zmierzać. Stało się bardziej konieczne, gdy preferowanym sposobem byłoby zautomatyzowanie elementów, jeśli nie cały proces. Takie podejście zapewnia użytkownikom (programistom) elastyczność w stosowaniu stałego kroku oraz możliwość dostosowania w razie potrzeby.
     Zaletą tego podejścia jest to, że możemy zautomatyzować części, które chcemy, a programista może powiązać pojedynczy proces. Im bardziej szczegółowe kroki automatyzacji, tym lepsza kontrola.
     Ponadto istnieje wiele narzędzi do automatyzacji w przestrzeniach, takich jak automatyka robotyczna, automatyzacja SOP (do obsługi przemysłu), automatyzacja raportów (jak Splunk) itp.
2) DevOps:
     Biorąc pod uwagę jakość i terminowość dostaw, jakiej oczekuje się od obecnego świata, istnieje potrzeba rozszerzenia automatyzacji procesu dostarczania oprogramowania. Aby to umożliwić i zapewnić klientowi wartość w najszybszy możliwy sposób, DevOps w dużej mierze polega na narzędziach automatyzacji.
     Zaletą tego podejścia jest to, że poszczególne etapy można zautomatyzować w celu zapewnienia spójności w całym przedsiębiorstwie, a ogólną koordynację można zmodyfikować w celu dostosowania do procesu wymaganego przez ten projekt.
     Poszczególne narzędzia automatyzacji (w pewien sposób), takie jak Chef do wdrożenia, Docker przez Dockerfile, Maven do kompilacji itp. Mogą być powiązane prawdopodobnie za pośrednictwem Jenkins, aby zapewnić wymagane rozwiązanie, jednocześnie zmniejszając czas potrzebny na wdrożenie lub użycie .
Mam nadzieję, że pomoże to wnieść jakąkolwiek wartość do procesu myślowego, który już możesz mieć.

Edycja: Zapomniałem dodać, że mówiłem o Procesie i Narzędziach - 2 z 3 aspektów DevOps. Jak wspomnieli inni, trzecim i równie ważnym aspektem są Ludzie. Jedną z głównych różnic, które zakładam między tym a automatyką, jest to, że ludzie są bardziej podatni na wchłanianie automatyzacji częściej niż przeciwstawiają się DevOps. Wydaje mi się, że wynika to z samej natury DevOps, ponieważ automatyzacja zwykle wiąże się z ułatwieniem im pracy, podczas gdy czują, że DevOps zmienia sposób, w jaki czują się komfortowo.

Karthik Venkatesan
źródło
1

Ruch DevOps składa się z czterech głównych obszarów w skrócie CAMS :

  1. Kultura
  2. Automatyzacja
  3. Pomiary
  4. Dzielenie się

Oto oryginalny post z 2010 roku.

W każdym obszarze znajduje się kilka narzędzi, procesów i praktyk, które są ogólnie akceptowane, chociaż temat nie jest dobrze zdefiniowany w zakresie najlepszych praktyk, w większości przypadków należy przestrzegać kilku dobrych praktyk.

Sama automatyzacja jest nieco szerszym tematem, ale w kontekście DevOps jest tylko podzbiorem tego, co jest omawiane. Zauważ, że prowadzimy z kulturą, chociaż wielu praktyków DevOps, którzy są nowicjuszami w tej dziedzinie, często przeoczają ją na własne ryzyko i przechodzą bezpośrednio do automatyzacji.

Jiri Klouda
źródło
-2

Automatyzacja i DevOps nie są ze sobą powiązane. DevOps przypomina bardziej inżynierię kombinowaną, w której wszyscy programiści witryny lub usługi są operatorami tej witryny lub usługi. Dlaczego ta powieść? Z mojego doświadczenia wynika, że ​​pierwszą rzeczą, którą zespół Ops zrobił, gdy wydarzyło się coś bardziej ekscytującego niż blip sieciowy, było zadzwonić do zespołu deweloperów. Dlaczego to zrobili? Ponieważ wszystko, co zrobił zespół operacyjny, to monitorowanie i utrzymywanie listy numerów telefonów deweloperów, na które można zadzwonić.

Zauważ, że nic nie mówiłem o automatyzacji.

Automatyzacja polega na powtarzaniu sukcesu. Jeśli wykonam kroki a, b i c, a proces X zawsze działa, to kroki a, b i c są dobrymi kandydatami do automatyzacji. Potem mogę wykorzystać czas na proces ręczny, aby zrobić rzeczy, które przynoszą mi więcej pieniędzy. Automatyzacja kończy się powodzeniem, gdy jest prosta. Wdrażanie nowych wersji, przeprowadzanie testów integracyjnych, dokręcanie nakrętki na śrubie, tworzenie kopii zapasowych danych, równoważenie kredytów z debetami itp. Są świetnymi kandydatami do automatyzacji, ponieważ czynności te są powtarzane przez osobę lub robota.

Uwaga : Nowością jest to, że programiści są również operatorami. Nie ma innej grupy. Współpraca w moim przypadku była rzadka. Jeśli w Przewodniku rozwiązywania problemów (aka TSG) nie było nic, masz gwarancję połączenia telefonicznego. Z mojego doświadczenia wynika, że ​​Ops był pierwszym telefonem w przypadku koparko-ładowarki. Problemy między służbami były poza ich sterówką.

Bez zwrotów Bez zwrotów
źródło
Ale wszystko, współpraca zawsze tam była, prawda? Komunikacja między deweloperami a operacjami, czy to coś nowego? co Devops przynosi nowe?
pinkpanther
Nowością jest to, że programiści są również operatorami. Nie ma innej grupy. Współpraca w moim przypadku była rzadka. Jeśli w Przewodniku rozwiązywania problemów (aka TSG) nie było nic, masz gwarancję połączenia telefonicznego. Z mojego doświadczenia wynika, że ​​Ops był pierwszym telefonem w przypadku koparko-ładowarki. Problemy między służbami były poza ich sterówką.
Bez zwrotów Bez zwrotów
3
Automatyzacja i DevOps są „niepowiązane”? Z szacunkiem nie mogłem się nie zgodzić. Ciągła integracja, ciągłe wdrażanie, zautomatyzowane testowanie i wiele innych stanowią integralną część komponentu technologicznego DevOps. Bez automatyzacji DevOps to tylko kultura. Oczywiście kultura jest ważna, ale to tylko jedna noga trzynożnego stołka DevOps (kultura, proces, technologia)
Dave Swersky
@NoRefundsNoReturns Devs są operatorami. W tym sensie, że nie ma potrzeby zespołu devop?
pinkpanther
Możesz się nie zgodzić. Mieliśmy mnóstwo automatyzacji, gdy zarówno zespół „programisty”, jak i zespół „operacyjny”. Dlatego mówię, że nie są ze sobą powiązane. Automatyzacja może mniej dbać o strukturę organizacji. Jeśli twoi programiści są również operatorami, istnieje duże prawdopodobieństwo, że nastąpi automatyzacja, ponieważ większość programistów jest leniwa i będzie miała tendencję do automatyzacji powtarzających się zadań. Jestem zdezorientowany twoją odpowiedzią @pinkpanther
No