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

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?

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.

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.

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.

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.

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.

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.

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.

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ą.