Czy trudno jest uchwycić główny sens rozmowy o DevOps? Zebraliśmy dla Ciebie żywe analogie, uderzające sformułowania i porady ekspertów, które pomogą nawet niespecjalistom dotrzeć do sedna. Na koniec premią jest własny DevOps pracowników Red Hat.
Termin DevOps powstał 10 lat temu i z hashtagu na Twitterze stał się potężnym ruchem kulturowym w świecie IT, prawdziwą filozofią, która zachęca programistów do szybszej realizacji zadań, eksperymentowania i iteracji do przodu. DevOps nierozerwalnie związał się z koncepcją transformacji cyfrowej. Ale jak to często bywa w przypadku terminologii IT, w ciągu ostatnich dziesięciu lat DevOps nabył wiele definicji, interpretacji i błędnych wyobrażeń na swój temat.
Dlatego często można usłyszeć pytania dotyczące DevOps, czy to to samo, co zwinny? A może to jakaś specjalna metodologia? A może to po prostu kolejny synonim słowa „współpraca”?
DevOps obejmuje wiele różnych koncepcji (ciągłe dostarczanie, ciągła integracja, automatyzacja itp.), więc wyodrębnienie tego, co ważne, może być wyzwaniem, szczególnie jeśli pasjonujesz się tym tematem. Jednak ta umiejętność jest bardzo przydatna, niezależnie od tego, czy próbujesz przekazać swoje pomysły przełożonym, czy po prostu opowiadasz o swojej pracy komuś z rodziny lub znajomych. Dlatego odłóżmy na razie na bok niuanse terminologiczne DevOps i skupmy się na szerszym obrazie.
Czym jest DevOps: 6 definicji i analogii
Poprosiliśmy ekspertów o możliwie najprostsze i najkrótsze wyjaśnienie istoty DevOps, aby jego wartość stała się jasna dla czytelników o dowolnym poziomie wiedzy technicznej. Na podstawie wyników tych rozmów wybraliśmy najbardziej uderzające analogie i uderzające sformułowania, które pomogą Ci zbudować Twoją historię o DevOps.
1. DevOps jest ruchem kulturowym
„DevOps to ruch kulturowy, w którym obie strony (twórcy oprogramowania i specjaliści od obsługi systemów IT) uznają, że oprogramowanie nie przynosi realnych korzyści, dopóki ktoś nie zacznie z niego korzystać: klienci, klienci, pracownicy, a nie o to chodzi” – mówi Eveline Oehrlich, starszy specjalista ds. badań analityk w Instytucie DevOps. „Dlatego obie strony wspólnie zapewniają szybką i wysokiej jakości dostawę oprogramowania.”
2. DevOps polega na wzmacnianiu pozycji programistów.
„DevOps umożliwia programistom posiadanie aplikacji, uruchamianie ich i zarządzanie dostarczaniem od początku do końca”.
„Zazwyczaj DevOps jest postrzegany jako sposób na przyspieszenie dostarczania aplikacji na produkcję poprzez budowanie i wdrażanie zautomatyzowanych procesów” – mówi Jai Schniepp, dyrektor platform DevOps w firmie ubezpieczeniowej Liberty Mutual. „Ale dla mnie jest to sprawa o wiele bardziej fundamentalna”. DevOps umożliwia programistom posiadanie aplikacji lub określonych fragmentów oprogramowania, uruchamianie ich i zarządzanie ich dostarczaniem od początku do końca. DevOps eliminuje zamieszanie w zakresie odpowiedzialności i pomaga wszystkim zaangażowanym w tworzenie zautomatyzowanej infrastruktury kierowanej przez programistów.
3. DevOps polega na współpracy przy tworzeniu i dostarczaniu aplikacji.
„W skrócie DevOps to podejście do produkcji i dostarczania oprogramowania, w którym wszyscy pracują razem” – mówi Gur Staf, prezes i szef ds. cyfrowej automatyzacji biznesu w BMC.
4. DevOps to potok
„Montaż przenośnika jest możliwy tylko wtedy, gdy wszystkie części pasują do siebie.”
„Porównałbym DevOps do linii montażowej samochodów” – kontynuuje Gur Staff. – Chodzi o to, aby zaprojektować i wykonać wszystkie części z wyprzedzeniem, tak aby można je było później złożyć bez indywidualnej regulacji. Montaż przenośnika jest możliwy tylko wtedy, gdy wszystkie części pasują do siebie. Ci, którzy projektują i budują silnik, muszą rozważyć, jak zamontować go do nadwozia lub ramy. Ci, którzy wytwarzają hamulce, muszą pomyśleć o kołach i tak dalej. Podobnie powinno być z oprogramowaniem.
Programista tworzący logikę biznesową lub interfejs użytkownika musi pomyśleć o bazie danych przechowującej informacje o klientach, środkach bezpieczeństwa chroniących dane użytkownika i o tym, jak to wszystko będzie działać, gdy usługa zacznie służyć dużej, być może nawet wielomilionowej grupie użytkowników .”
„Największą przeszkodą do pokonania jest nakłonienie ludzi do współpracy i przemyślenia części pracy, którą wykonują inni, zamiast skupiania się wyłącznie na własnych zadaniach. Jeśli ci się to uda, masz doskonałą szansę na cyfrową transformację” – dodaje Gur Staff.
5. DevOps to odpowiednie połączenie ludzi, procesów i automatyzacji
Jayne Groll, dyrektor wykonawcza DevOps Institute, zaproponowała świetną analogię wyjaśniającą DevOps. Według niej „DevOps jest jak przepis składający się z trzech głównych kategorii składników: ludzi, procesów i automatyzacji. Większość tych składników można zaczerpnąć z innych obszarów i źródeł: Lean, Agile, SRE, CI/CD, ITIL, przywództwo, kultura, narzędzia. Sekretem DevOps, jak każdego dobrego przepisu, jest to, jak uzyskać odpowiednie proporcje i wymieszać te składniki, aby zwiększyć szybkość i efektywność tworzenia i wydawania aplikacji.
6. DevOps ma miejsce wtedy, gdy programiści pracują jak zespół Formuły 1
„Wyścig nie jest zaplanowany od początku do końca, ale wręcz przeciwnie, od mety do startu”.
„Kiedy mówię o tym, czego można się spodziewać po inicjatywie DevOps, mam na myśli jako przykład zespół wyścigowy NASCAR lub Formuły 1” – mówi Chris Short, starszy menedżer ds. marketingu platform chmurowych w firmie Red Hat i wydawca biuletynu DevOps. – Lider takiego zespołu ma jeden cel: zająć na koniec wyścigu jak najwyższe miejsce, biorąc pod uwagę zasoby, którymi dysponuje zespół i wyzwania, jakie go spotkały. W tym przypadku wyścig jest zaplanowany nie od początku do końca, ale wręcz przeciwnie, od mety do startu. Najpierw wyznaczany jest ambitny cel, a następnie określane są sposoby jego osiągnięcia. Następnie są one dzielone na podzadania i delegowane członkom zespołu.”
„Zespół spędza cały tydzień przed wyścigiem na doskonaleniu pit stopu. Wykonuje treningi siłowe i cardio, aby utrzymać formę na wyczerpujący dzień wyścigu. Ćwiczy współpracę w celu rozwiązania wszelkich problemów, które mogą pojawić się podczas wyścigu. Podobnie zespół programistów powinien szkolić umiejętność częstego wydawania nowych wersji. Jeśli masz takie umiejętności i dobrze działający system bezpieczeństwa, wprowadzanie nowych wersji do produkcji również zdarza się częściej. W tym światopoglądzie większa prędkość oznacza większe bezpieczeństwo” – mówi Short.
„Nie chodzi o robienie «właściwych rzeczy»” – dodaje Short, „chodzi o wyeliminowanie jak największej liczby rzeczy, które stoją na drodze do osiągnięcia pożądanego rezultatu. Współpracuj i dostosowuj się na podstawie informacji zwrotnych otrzymywanych w czasie rzeczywistym. Bądź przygotowany na anomalie i pracuj nad poprawą jakości, aby zminimalizować ich wpływ na postęp w realizacji celu. To właśnie nas czeka w świecie DevOps.”
Jak skalować DevOps: 10 wskazówek od ekspertów
Tyle, że DevOps i masowy DevOps to zupełnie różne rzeczy. Powiemy Ci, jak pokonać bariery na drodze z pierwszego do drugiego.
Dla wielu organizacji podróż do DevOps zaczyna się łatwo i przyjemnie. Tworzą się małe zespoły z pasją, stare procesy zastępowane są nowymi, a na pierwsze sukcesy nie trzeba długo czekać.
Niestety, to tylko fałszywy blichtr, iluzja postępu, mówi Ben Grinnell, dyrektor zarządzający i szef działu cyfrowego w firmie konsultingowej North Highland. Wczesne zwycięstwa są z pewnością zachęcające, ale nie pomagają osiągnąć ostatecznego celu, jakim jest powszechne przyjęcie DevOps w całej organizacji.
Łatwo zauważyć, że efektem jest kultura podziału na „nas” i „oni”.
„Często organizacje uruchamiają te pionierskie projekty, myśląc, że utorują drogę dla głównego nurtu DevOps, nie zastanawiając się, czy inni będą mogli lub chcą podążać tą ścieżką” – wyjaśnia Ben Grinnell. – Zespoły do realizacji takich projektów rekrutują się zazwyczaj z pewnych siebie „Varangian”, którzy robili już coś podobnego w innych miejscach, ale są nowi w Twojej organizacji. Jednocześnie zachęca się ich do łamania i niszczenia zasad, które pozostają wiążące dla wszystkich innych. Łatwo zauważyć, że efektem jest kultura „nas” i „oni”, która utrudnia transfer wiedzy i umiejętności”.
„A ten problem kulturowy to tylko jeden z powodów, dla których DevOps jest trudny do skalowania. Zespoły DevOps stoją przed coraz większymi wyzwaniami technicznymi, które są typowe dla szybko rozwijających się firm stawiających na IT” – powiedział Steve Newman, założyciel i prezes Scalyr.
„We współczesnym świecie usługi zmieniają się, gdy tylko pojawia się taka potrzeba. Wspaniale jest stale wdrażać i wdrażać nowe funkcje, ale koordynacja tego procesu i eliminowanie pojawiających się problemów to prawdziwy ból głowy – dodaje Steve Newman. – W bardzo szybko rozwijających się organizacjach inżynierowie w zespołach interdyscyplinarnych mają trudności z utrzymaniem widoczności zmian i powodowanych przez nie efektów kaskadowych na poziomie zależności. Co więcej, inżynierowie nie są szczęśliwi, gdy pozbawia się ich tej możliwości, przez co coraz trudniej jest im zrozumieć istotę pojawiających się problemów.”
Jak pokonać opisane powyżej wyzwania i przejść do masowego wdrożenia DevOps w dużej organizacji? Eksperci zalecają cierpliwość, nawet jeśli ostatecznym celem jest przyspieszenie cyklu tworzenia oprogramowania i procesów biznesowych.
1. Pamiętaj, że zmiana kultury wymaga czasu.
Jayne Groll, dyrektor wykonawcza, DevOps Institute: „Moim zdaniem rozwój DevOps powinien być tak samo przyrostowy i iteracyjny, jak rozwój zwinny (i równie dotykający kultury). Agile i DevOps kładą nacisk na małe zespoły. Jednak w miarę zwiększania się liczby i integracji tych zespołów coraz więcej osób przyjmuje nowe sposoby pracy, w wyniku czego następuje masowa transformacja kulturowa”.
2. Poświęć wystarczająco dużo czasu na planowanie i wybór platformy
Eran Kinsbruner, główny ewangelista techniczny w Perfecto: „Aby skalowanie zadziałało, zespoły DevOps muszą najpierw nauczyć się łączyć tradycyjne procesy, narzędzia i umiejętności, a następnie powoli pielęgnować i stabilizować każdą poszczególną fazę DevOps. Wszystko zaczyna się od dokładnego planowania historii użytkowników i strumieni wartości, a następnie pisania oprogramowania i kontroli wersji przy użyciu programowania opartego na magistrali lub innych podejść najlepiej nadających się do rozgałęziania i łączenia kodu.
„Następnie następuje etap integracji i testów, gdzie wymagana jest już skalowalna platforma do automatyzacji. W tym miejscu ważne jest, aby zespoły DevOps wybrały odpowiednią platformę, która odpowiada ich poziomowi umiejętności i końcowym celom projektu.
Kolejną fazą jest wdrożenie na produkcję, które powinno zostać w pełni zautomatyzowane przy użyciu narzędzi i kontenerów do orkiestracji. Ważne jest, aby na wszystkich etapach DevOps (symulator produkcyjny, środowisko QA i rzeczywiste środowisko produkcyjne) dysponować środowiskami zwirtualizowanymi i zawsze wykorzystywać do testów tylko najnowsze dane, aby uzyskać odpowiednie wnioski. Analityka musi być inteligentna i zdolna do przetwarzania dużych zbiorów danych oraz zapewniać szybkie i przydatne informacje zwrotne”.
3. Usuń winę z odpowiedzialności.
Gordon Haff, ewangelista RedHat: „Tworzenie systemu i atmosfery, które umożliwiają eksperymentowanie i zachęcają do niego, pozwalają na tak zwane udane niepowodzenia w zwinnym tworzeniu oprogramowania. Nie oznacza to, że nikt inny nie jest odpowiedzialny za niepowodzenia. W rzeczywistości ustalenie, kto jest odpowiedzialny, staje się jeszcze łatwiejsze, ponieważ „bycie odpowiedzialnym” nie oznacza już „spowodowania wypadku”. Oznacza to, że istota odpowiedzialności zmienia się jakościowo. Cztery czynniki stają się krytyczne: zakres zakłóceń, podejście, procesy produkcyjne i zachęty. (Więcej informacji na temat tych czynników można znaleźć w artykule Gordona Huffa „Lekcje DevOps: 4 aspekty zdrowych eksperymentów”).
4. Oczyść ścieżkę do przodu
Ben Grinnell, dyrektor zarządzający i szef działu cyfrowego w firmie konsultingowej North Highland: „Aby osiągnąć skalę, rekomenduję uruchomienie programu „oczyszczania ścieżek” wraz z pionierskimi projektami. Celem tego programu jest sprzątanie śmieci pozostawionych przez pionierów DevOps, takich jak przestarzałe zasady i tym podobne, tak aby droga naprzód pozostała jasna”.
„Daj ludziom wsparcie organizacyjne i dynamikę poprzez komunikację, która wykracza daleko poza grupę pionierską, szeroko celebrując sukcesy nowych sposobów pracy. Coachuj osoby, które biorą udział w kolejnej fali projektów DevOps i denerwują się pierwszym użyciem DevOps. I pamiętaj, że ci ludzie bardzo różnią się od pionierów”.
5. Demokratyzować narzędzia
Steve Newman, założyciel i prezes Scalyr: „Narzędzi nie należy ukrywać przed ludźmi i każdy, kto chce poświęcić czas, powinien być stosunkowo łatwy do nauczenia się. Jeśli możliwość przeglądania dzienników jest ograniczona do trzech osób „certyfikowanych” do korzystania z narzędzia, zawsze będą dostępne maksymalnie trzy osoby do rozwiązania problemu, nawet jeśli masz bardzo duże środowisko komputerowe. Innymi słowy, istnieje tu wąskie gardło, które może prowadzić do poważnych konsekwencji (biznesowych).
6. Stwórz idealne warunki do pracy zespołowej
Tom Clark, szef Wspólnej Platformy w ITV: „Możesz zrobić wszystko, ale nie wszystko na raz. Wyznaczaj więc duże cele, zaczynaj od małych i idź do przodu w szybkich iteracjach. Z biegiem czasu zyskasz reputację osoby, która potrafi wszystko zrobić, więc inni też będą chcieli korzystać z twoich metod. I nie martw się o zbudowanie wysoce efektywnego zespołu. Zamiast tego zapewnij ludziom idealne warunki pracy, a wydajność wzrośnie”.
7. Nie zapomnij o tablicach z prawem Conwaya i Kanbanem
Logan Daigle, dyrektor ds. dostarczania oprogramowania i strategii DevOps w CollabNetVersionOne: „Ważne jest zrozumienie konsekwencji prawa Conwaya. W mojej luźnej parafrazie prawo to stanowi, że tworzone przez nas produkty i procesy, których w tym celu używamy, w tym DevOps, okazują się mieć taką samą strukturę jak nasza organizacja.
„Jeśli w organizacji jest dużo silosów, a kontrola zmienia ręce wielokrotnie podczas planowania, budowania i wydawania oprogramowania, efekt skalowania będzie zerowy lub krótkotrwały. Jeśli organizacja buduje wielofunkcyjne zespoły wokół produktów finansowanych z myślą o rynku, szanse na sukces dramatycznie rosną”.
„Kolejnym ważnym aspektem skalowania jest wyświetlanie całej pracy w toku (WIP, workinprogress) na tablicach Kanban. Kiedy organizacja ma miejsce, w którym ludzie mogą zobaczyć te rzeczy, bardzo zachęca to do współpracy, co ma pozytywny wpływ na skalowanie”.
8. Poszukaj starych blizn
Manuel Pais, konsultant DevOps i współautor Team Topologies: „Wynoszenie praktyk DevOps poza samo Dev i Ops i próba zastosowania ich do innych funkcji nie jest podejściem optymalnym. Z pewnością będzie to miało pewien wpływ (na przykład poprzez automatyzację ręcznego sterowania), ale można osiągnąć znacznie więcej, jeśli zaczniemy od zrozumienia procesów dostaw i informacji zwrotnych.
„Jeśli w systemie informatycznym organizacji pozostały stare blizny – procedury i mechanizmy zarządzania, które zostały wdrożone w wyniku przeszłych incydentów, ale straciły na aktualności (w wyniku zmian w produktach, technologiach czy procesach) – to z pewnością należy je usunąć lub wygładzone, zamiast automatyzować nieefektywne lub niepotrzebne procesy.
9. Nie rozmnażaj opcji DevOps
Anthony Edwards, dyrektor operacyjny w Eggplant: „DevOps to bardzo niejasne określenie, dlatego każdy zespół otrzymuje własną wersję DevOps. I nie ma nic gorszego, gdy w organizacji nagle pojawia się 20 odmian DevOps, które niezbyt dobrze ze sobą współpracują. Niemożliwe jest, aby każdy z trzech zespołów programistycznych miał swój własny, specjalny interfejs pomiędzy rozwojem a zarządzaniem produktem. Produkty nie powinny mieć także własnych, unikalnych oczekiwań w zakresie obsługi informacji zwrotnych po przeniesieniu ich do symulatora produkcji. W przeciwnym razie nigdy nie będziesz w stanie skalować DevOps.”
10. Głoś wartość biznesową DevOps
Steve Newman, założyciel i prezes Scalyr: „Pracuj nad rozpoznaniem wartości DevOps. Ucz się i nie krępuj mówić o korzyściach płynących z tego, co robisz. DevOps to niesamowita oszczędność czasu i pieniędzy (tylko pomyśl: mniej przestojów, krótszy średni czas powrotu do zdrowia), a zespoły DevOps muszą niestrudzenie podkreślać (i głosić) znaczenie tych inicjatyw dla sukcesu biznesowego. W ten sposób możesz poszerzyć krąg zwolenników i zwiększyć wpływ DevOps w organizacji.”
BONUS
Na Nasz własny DevOps pojawi się 13 września – tak, Red Hat, jako producent oprogramowania, ma własne zespoły i praktyki DevOps.
Nasz inżynier Mark Birger, który rozwija usługi automatyzacji wewnętrznej dla innych grup w całej organizacji, opowie swoją historię w czystym języku rosyjskim - jak zespół Red Hat DevOps przeprowadził migrację aplikacji ze środowisk wirtualnych Hat Virtualization zarządzanych przez Ansible do pełnoprawnego formatu kontenera na platformie OpenShift.
Ale to nie wszystko:
Gdy organizacje przeniosą obciążenia do kontenerów, tradycyjne metody monitorowania aplikacji mogą nie działać. W drugiej prelekcji wyjaśnimy naszą motywację do zmiany sposobu logowania i pokażemy kontynuację drogi, która doprowadziła nas do nowoczesnych metod pozyskiwania drewna i monitorowania.
Źródło: www.habr.com