Trudno uchwycić sedno mówiąc o DevOps? Zebraliśmy dla Was wyraziste analogie, mocne sformułowania i porady od ekspertów, które pomogą zrozumieć istotę nawet osobom nietechnicznym. Na koniec bonus – własny DevOps pracowników Red Hat.
Termin DevOps pojawił się 10 lat temu i przeszedł drogę od hashtagu na Twitterze do potężnego ruchu kulturowego w świecie IT, prawdziwej filozofii, która zachęca programistów do szybszego osiągania wyników, eksperymentowania i działania metodą iteracyjną. DevOps stał się nierozerwalnie związany z pojęciem transformacji cyfrowej. Ale jak to często bywa w terminologii IT, przez ten czas DevOps zdążył nabrać wielu definicji, interpretacji i nieporozumień.
Dlatego o DevOps często można usłyszeć pytania takie jak: czy to to samo co agile? Czy 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 itd.), dlatego wyodrębnienie kluczowych aspektów może być trudne, szczególnie gdy nie jest się obojętnym na temat. Jednak ta umiejętność jest niezwykle przydatna, niezależnie od tego, czy próbujesz przekazać swoje pomysły przełożonemu, czy po prostu opowiadasz o swojej pracy komuś z rodziny lub znajomych. Dlatego na razie odłożymy na bok terminologiczne niuanse DevOps i skoncentrujemy się na ogólnym obrazie.
Czym jest DevOps: 6 definicji i analogii
Poprosiliśmy specjalistów, aby jak najprościej i najkrócej wyjaśnili istotę DevOps, aby jej wartość stała się zrozumiała dla czytelników o różnym poziomie wiedzy technicznej. Na podstawie tych rozmów wybraliśmy najbardziej wyraziste analogie i mocne sformułowania, które pomogą Wam zbudować swoją opowieść o DevOps.
1. DevOps – to ruch kulturowy
„DevOps – to ruch kulturowy, w ramach którego obie strony (programiści oraz specjaliści od eksploatacji systemów IT) uznają, że oprogramowanie nie przynosi rzeczywistej wartości, dopóki nikt z niego nie korzysta: klienci, użytkownicy, pracownicy – to nieistotne”, uważa Evelina Oehrlich, starszy analityk badawczy w Instytucie DevOps. „Dlatego obie te strony wspólnie zapewniają szybkie i wysokiej jakości dostarczanie oprogramowania”.
2. DevOps – to coś, co daje moc programistom
„DevOps daje programistom władzę nad aplikacjami, ich uruchamianiem oraz zarządzaniem dostawą od początku do końca“
„Zwykle mówi się o DevOps jako o sposobie przyspieszenia dostarczania aplikacji do produkcji dzięki budowaniu i wdrażaniu zautomatyzowanych procesów, mówi Jai Schniepp, dyrektor ds. platform DevOps w firmie ubezpieczeniowej Liberty Mutual. – Ale dla mnie to znacznie bardziej fundamentalna kwestia. DevOps daje programistom władzę nad aplikacjami lub określonymi częściami oprogramowania, ich uruchamianiem oraz zarządzaniem dostawą od początku do końca. DevOps eliminuje chaos związany z odpowiedzialnością i prowadzi wszystkich uczestników procesu do stworzenia zautomatyzowanej i zarządzanej przez programistów infrastruktury.”
3. DevOps to współpraca przy tworzeniu i dostarczaniu aplikacji
„Mówiąc prościej, DevOps to podejście do produkcji i dostarczania oprogramowania, w którym wszyscy współpracują”, zauważa Gur Staf, prezydent i szef działu automatyzacji cyfrowego biznesu w firmie BMC.
4. DevOps to linia produkcyjna
„Linia produkcyjna jest możliwa tylko wtedy, gdy wszystkie części do siebie pasują”.
„Porównałbym DevOps do linii produkcyjnej samochodów, kontynuuje Gur Staf. – Idea polega na tym, aby z góry zaprojektować i wykonać wszystkie części tak, aby później można je było złożyć bez indywidualnego dopasowywania. Linia produkcyjna jest możliwa tylko wtedy, gdy wszystkie części do siebie pasują. Ci, którzy projektują i tworzą silnik, muszą pomyśleć o tym, jak przymocować go do nadwozia lub ramy. Ci, którzy robią hamulce, muszą pomyśleć o kołach, i tak dalej. Tak samo powinno być z oprogramowaniem.”
Programista tworzący logikę biznesową lub interfejs użytkownika musi pomyśleć o bazie danych, która przechowuje informacje o klientach, o środkach bezpieczeństwa chroniących dane użytkowników, a także o tym, jak wszystko to będzie działać, gdy usługa zacznie obsługiwać dużą, być może nawet wielomilionową społeczność użytkowników.”
„Sprawić, aby ludzie współpracowali i myśleli o tych aspektach pracy, które wykonują inni, a nie koncentrowali się wyłącznie na swoich własnych zadaniach – to największa przeszkoda, którą należy pokonać. Jeśli się to uda, będziesz miał doskonałe szanse na cyfrową transformację” – dodaje Gur Staff.
5. DevOps to odpowiednia kombinacja ludzi, procesów i automatyzacji
Jayne Groll, dyrektor wykonawczy Instytutu DevOps, zaproponowała doskonałą analogię do wyjaśnienia DevOps. Jej zdaniem „DevOps jest jak przepis kulinarny, w którym istnieją trzy podstawowe kategorie składników: ludzie, procesy i automatyzacja. Większość tych składników można pozyskać z innych obszarów i źródeł: Lean, Agile, SRE, CI/CD, ITIL, przywództwo, kultura, narzędzia. Sekret DevOps, podobnie jak każdego dobrego przepisu, polega na tym, jak prawidłowo dobrać proporcje i wymieszać te składniki, aby zwiększyć szybkość i efektywność pracy przy tworzeniu oraz wdrażaniu aplikacji.”
6. DevOps to gdy programiści pracują jak zespół Formuły 1
„Wyścig planuje się nie od startu do mety, ale odwrotnie, od mety do startu”.
„Mówiąc o tym, czego oczekiwać od inicjatywy DevOps, posługuję się przykładem zespołu wyścigowego NASCAR lub Formuły 1 – mówi Chris Short, dyrektor marketingu platform chmurowych Red Hat i wydawca newslettera DevOps’ish. – Lider takiego zespołu ma jeden cel: zająć jak najwyższe miejsce w wyścigu, biorąc pod uwagę dostępne zasoby i wyzwania, które stanęły przed zespołem. Przy tym wyścig planuje się nie od startu do mety, ale odwrotnie, od mety do startu. Najpierw stawia się ambitny cel, a następnie określa się sposoby jego osiągnięcia. Po czym dzieli się je na podzadania i deleguje członkom zespołu.”
„Przez cały tydzień przed wyścigiem zespół doskonali swoje pit-stopy. Angażują się w treningi siłowe i kardio, aby być w formie w ten wyczerpujący dzień wyścigu. Ćwiczą współpracę w rozwiązywaniu wszelkich problemów, które mogą wystąpić w trakcie wyścigu. Podobnie zespół deweloperów powinien doskonalić umiejętności częstego wypuszczania nowych wersji. Przy takich umiejętnościach i dopracowanym systemie bezpieczeństwa, uruchamianie nowych wersji w produkcji również zachodzi częściej. W ramach tej perspektywy wzrost prędkości oznacza wzrost bezpieczeństwa” – mówi Short.
„Nie chodzi o to, aby robić «właściwe rzeczy» - dodaje Short - ale o usuwanie jak największej liczby rzeczy, które stoją na drodze do pożądanych rezultatów. Współpracuj i dostosowuj się na podstawie informacji zwrotnej, którą otrzymujesz w czasie rzeczywistym. Bądź gotowy na anomalia i pracuj nad poprawą jakości, aby zminimalizować ich wpływ na dążenie do celu. To właśnie nas czeka w świecie DevOps”.
Jak skalować DevOps: 10 wskazówek od ekspertów
Zwykły DevOps i masowy DevOps to dwie zupełnie różne rzeczy. Opowiemy, jak pokonać przeszkody na drodze od jednego do drugiego.
Dla wielu organizacji droga do DevOps zaczyna się łatwo i przyjemnie. Tworzone są małe zespoły pasjonatów, stare procesy zastępowane są nowymi i pierwsze sukcesy szybko przychodzą.
Niestety, to tylko fałszywy blask, iluzja postępu, jak mówi Ben Grinnell, dyrektor zarządzający i lider w zakresie technologii cyfrowych w firmie konsultingowej North Highland. Wczesne zwycięstwa oczywiście budzą nadzieję, ale nie pomagają osiągnąć ostatecznego celu, jakim jest masowe wdrożenie DevOps w organizacji.
Łatwo dostrzec, że w rezultacie kształtuje się kultura podziału na „my” i „oni”.
Często organizacje uruchamiają takie pionierskie projekty, sądząc, że utorują drogę do masowego DevOps, nie zastanawiając się, czy inni będą chcieli i mogli pójść tą drogą – wyjaśnia Ben Grinnell. – Zazwyczaj zespoły do realizacji takich projektów rekrutują z siebie nawzajem ‘wikingów’, którzy już robili coś podobnego w innych miejscach, ale są nowicjuszami w waszej organizacji. Przy tym są zachęcani do łamania i niszczenia zasad, które wciąż są obowiązkowe dla wszystkich pozostałych. Łatwo zauważyć, że w efekcie powstaje kultura podziału na 'my' i 'oni', która utrudnia przekazywanie wiedzy i umiejętności.
I ten problem kulturowy jest tylko jednym z powodów, dla których DevOps jest trudny do skalowania. Zespoły DevOps stają w obliczu rosnących, czysto technicznych trudności charakterystycznych dla szybko rozwijających się firm, które postawiły na technologie informatyczne – mówi Steve Newman, założyciel i przewodniczący zarządu firmy Scalyr.
W dzisiejszym świecie usługi zmieniają się natychmiast, gdy tylko pojawi się taka potrzeba. Stałe wdrażanie i wprowadzanie nowych funkcji jest oczywiście świetne, ale koordynacja tego procesu i usuwanie pojawiających się problemów to prawdziwy ból głowy – dodaje Steve Newman. – W bardzo szybko rozwijających się organizacjach inżynierowie w składzie zespołów interdyscyplinarnych walczą o zachowanie możliwości śledzenia zmian i wynikających z nich kaskadowych efektów na poziomie zależności. Co więcej, inżynierowie wcale nie cieszą się, gdy pozbawia się ich tej możliwości, a w rezultacie trudniej im zrozumieć istotę pojawiających się problemów.
Jak można przezwyciężyć opisane powyżej trudności i przejść do masowego stosowania DevOps w dużej organizacji? Eksperci nawołują do wykazania się cierpliwością, nawet jeśli waszym finalnym celem jest przyspieszenie cyklu rozwoju oprogramowania i procesów biznesowych.
1. Pamiętaj, że zmiany w kulturze wymagają czasu
Jayne Groll, dyrektor wykonawczy Instytutu DevOps: „Moim zdaniem, rozszerzenie DevOps powinno być tak samo stopniowe i iteracyjne, jak rozwój agile (i w równym stopniu dotykać kultury). W Agile i DevOps skupia się na małych zespołach. Jednak wraz z wzrostem liczby i integracją takich zespołów, mamy coraz więcej osób stosujących nowe metody pracy, co prowadzi do rozwoju kulturowej transformacji na dużą skalę.”
2. Poświęć wystarczająco dużo czasu na planowanie i wybór platformy
Eran Kinsbruner, wiodący techniczny ewangelista firmy 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 rozwijać każdą fazę DevOps i stabilizować ją. Wszystko zaczyna się od starannego planowania historii użytkowników (user story) i strumieni tworzenia wartości (value stream), po czym następuje etap pisania oprogramowania i kontroli wersji z wykorzystaniem trunk-based development lub innych podejść, które najlepiej nadają się do rozgałęziania i scalania kodu.”
„Następnie następuje etap integracji i testowania, gdzie potrzebna jest skalowalna platforma do automatyzacji. W tym miejscu zespoły DevOps muszą wybrać odpowiednią platformę, która odpowiada ich poziomowi umiejętności i celom projektu.
Następna faza to wdrożenie w środowisku produkcyjnym, które musi być w pełni zautomatyzowane z wykorzystaniem narzędzi orkiestracji i kontenerów. Ważne jest również posiadanie wirtualizowanych środowisk na wszystkich etapach DevOps (symulator środowiska produkcyjnego, środowisko kontrolne jakości oraz samo środowisko produkcyjne) i zawsze używanie do testów tylko najnowszych danych, aby uzyskać aktualne wnioski. Analiza musi być inteligentna i zdolna do przetwarzania dużych danych z szybką i skuteczną informacją zwrotną.”
3. Uwolnij odpowiedzialność od poczucia winy
Gordon Haff, ewangelista RedHat: „Tworzenie systemu i atmosfery, która pozwala i zachęca do eksperymentów, umożliwia realizację tzw. udanych porażek w agile’owym procesie tworzenia oprogramowania. To nie oznacza, że nikt nie ponosi odpowiedzialności za błędy. W rzeczywistości ustalenie odpowiedzialności staje się jeszcze prostsze, ponieważ „bycie odpowiedzialnym” nie oznacza już „bycia osobą winą za wypadek”. Oznacza to, że istota odpowiedzialności zmienia się jakościowo. Cztery czynniki stają się przy tym niezwykle ważne: zakres awarii, podejścia, procesy produkcyjne i bodźce.” (Więcej o tych czynnikach można przeczytać w artykule Gordona Haffa „DevOps lessons: 4 aspects of healthy experiments”.)
4. Oczyśćcie drogę do przodu
Ben Grinnell, dyrektor zarządzający i lider obszaru technologii cyfrowych w firmie doradczej North Highland: „Aby osiągnąć skalowalność, zalecam uruchomienie programu „oczyszczania drogi” razem z projektami pionierskimi. Celem tego programu jest usunięcie śmieci pozostawionych przez pionierów DevOps, takich jak nieaktualne zasady i inne podobne rzeczy, aby droga do przodu była wolna.”
„Dajcie ludziom wsparcie organizacyjne i zainicjujcie komunikację, która wykracza daleko poza grupę pionierów, szeroko celebrując sukcesy nowych metod pracy. Szkolcie osoby zaangażowane w następną falę projektów DevOps, które czują się niepewnie, korzystając z DevOps po raz pierwszy. I pamiętajcie, że ci ludzie znacznie różnią się od pionierów.”
5. Uczyńcie narzędzia bardziej demokratycznymi
Steve Newman, założyciel i przewodniczący rady nadzorczej firmy Scalyr: „Narzędzia powinny być dostępne dla ludzi, a ich opanowanie powinno być stosunkowo proste dla każdego, kto jest gotów poświęcić na to czas. Jeśli dostęp do logów ma tylko trzech „certyfikowanych” użytkowników danego narzędzia, zawsze będziecie mieli maksymalnie trzy osoby, które mogą rozwiązać dany problem, nawet jeśli macie bardzo dużą infrastrukturę obliczeniową. Innymi słowy, tworzy to wąskie gardło, które może prowadzić do poważnych skutków (dla biznesu).”
6. Stwórzcie idealne warunki do pracy zespołu
Tom Clark, kierownik obszaru Common Platform w telekomunikacji ITV: „Możesz zrobić wszystko, ale nie wszystko na raz. Dlatego stawiaj duże cele, zaczynaj od małych kroków i idź naprzód szybkim tempem. Z czasem zyskasz reputację zespołu, któremu wszystko wychodzi, więc inni także będą chcieli korzystać z twoich metod. I nie dąż do stworzenia zespołu o wysokiej wydajności. Zamiast tego stwórz ludziom idealne warunki do pracy, a efektywność przyjdzie sama“.
7. Nie zapominaj o prawie Conweya i tablicach kanban
Logan Daigle, dyrektor ds. dostarczania oprogramowania i strategii DevOps w firmie CollabNetVersionOne: „Ważne jest, aby zdać sobie sprawę z konsekwencji prawa Conweya. W mojej swobodnej interpretacji to prawo głosi, że produkty, które tworzymy, oraz procesy, które stosujemy, w tym DevOps, są zorganizowane w taki sposób, jak nasza organizacja“.
„Jeśli w organizacji występuje wysokie rozdzielenie, a podczas planowania, tworzenia i wydawania oprogramowania zarządzanie wielokrotnie przechodzi z rąk do rąk, efekt skalowania będzie zerowy lub krótkotrwały. Jeśli jednak organizacja tworzy zespoły wielofunkcyjne wokół produktów, które są finansowane z nastawieniem na rynek, szanse na sukces drastycznie wzrastają“.
„Kolejnym ważnym aspektem skalowania jest wyświetlanie na tablicach kanban wszystkich prac w toku (WIP, work in progress). Kiedy w organizacji pojawia się miejsce, gdzie ludzie mogą widzieć takie rzeczy, to mocno stymuluje współpracę, co pozytywnie wpływa na skalowanie“.
8. Szukaj starych blizn
Manuel Pais, konsultant ds. DevOps i współautor książki „Team Topologies“: „Wynoszenie praktyk DevOps poza samą Dev i Ops i próba zastosowania ich w innych funkcjach raczej nie można nazwać optymalnym podejściem. Niewątpliwie przyniesie to pewien efekt (na przykład dzięki automatyzacji ręcznego zarządzania), ale można osiągnąć znacznie więcej, jeśli zaczniemy od zrozumienia procesów dostarczania i informacji zwrotnej“.
„Jeśli w systemie IT organizacji są stare blizny – procedury i mechanizmy zarządzania, które zostały wprowadzone w wyniku przeszłych incydentów, ale straciły na znaczeniu (w wyniku zmiany produktów, technologii czy procesów), to zdecydowanie należy je usunąć lub wygładzić, a nie automatyzować nieefektywne lub niepotrzebne procesy“.
9. Nie twórzcie wielu wersji DevOps
Antony Edwards, dyrektor ds. produkcji w firmie Eggplant: „DevOps to bardzo nieostre pojęcie, dlatego każda drużyna ma swoją wersję DevOps. Nic gorszego, niż kiedy w organizacji pojawia się od razu 20 różnych wersji DevOps, które nie bardzo potrafią współżyć razem. Nie może być tak, że każda z trzech drużyn developerskich ma swój własny, szczególny interfejs pomiędzy rozwojem a zarządzaniem produktem. Tak samo nie może być tak, że produkty mają swoje, unikalne oczekiwania dotyczące obsługi informacji zwrotnej przy przenoszeniu do symulatora środowiska produkcyjnego. W przeciwnym razie nigdy nie uda się wam skalować DevOps“.
10. Propagujcie wartość DevOps dla biznesu
Steve Newman, założyciel i przewodniczący rady nadzorczej firmy Scalyr: „Pracujcie nad uznaniem wartości DevOps. Uczcie się i nie bójcie się opowiadać o korzyściach płynących z tego, co robicie. DevOps niezwykle oszczędza czas i pieniądze (po prostu pomyślcie: mniej przestojów, krótszy średni czas przywracania), a zespoły DevOps powinny nieustannie podkreślać (i propagować) znaczenie tych inicjatyw dla sukcesu biznesu. W ten sposób będziecie mogli rozszerzyć grono zwolenników i zwiększyć wpływ DevOps w organizacji“.
BONUS
Na 13 września przyjedzie nasz własny DevOps – tak, Red Hat, jako producent oprogramowania, ma własne zespoły DevOps i praktyki.
Nasz inżynier Mark Birger, który zajmuje się rozwijaniem usług wewnętrznej automatyzacji dla innych grup w całej organizacji, w czystym rosyjskim języku opowie swoją historię – jak zespół DevOps Red Hat migrował aplikacje z wirtualnych środowisk Hat Virtualization, zarządzanych przez Ansible, do pełnoprawnego formatu kontenerowego na platformie OpenShift.
Ale to jeszcze nie wszystko:
Po przeniesieniu obciążeń roboczych do kontenerów tradycyjne metody monitorowania aplikacji mogą nie działać. W drugim raporcie wyjaśnimy naszą motywację do zmiany podejścia do rejestrowania i pokażemy kontynuację drogi, która doprowadziła nas do nowoczesnych metod logowania i monitorowania.
Źródło: habr.com
