Czym do diabła jest DevOps?

Krótka historia czasu

Aby zrozumieć DevOps, musimy cofnąć się w czasie do dawnych czasów, kiedy nie było tylko programistów.

Jak uczy nas Tao:

Dawni programiści byli tajemniczy i głębocy. Nie możemy zgłębić ich myśli, więc wszystko, co robimy, to opisujemy ich wygląd:

• Świadomy, jak lis przechodzący przez wodę
• Alert, jak generał na polu bitwy
• Miła, jak gospodyni witająca swoich gości
• Proste, jak nieoszlifowane klocki drewna
• Nieprzezroczyste, jak czarne kałuże w zaciemnionych jaskiniach

Programista dał początek językowi maszynowemu. Język maszynowy dał początek asemblerowi. Asembler dał początek kompilatorowi. Teraz są tysiące języków. Każdy język ma swój cel, jakkolwiek skromny. Każdy język wyraża Yin i Yang oprogramowania. Każdy język ma swoje miejsce w oprogramowaniu.

W tamtych czasach biura programistyczne nazywano głównie laboratoriami, a programiści byli naukowcami. Aby stworzyć dobrą aplikację, programiści musieli w pełni zrozumieć problem, który aplikacja rozwiązywała. Musieli wiedzieć, gdzie aplikacja będzie używana i jaki system będzie ją uruchamiał. Zasadniczo programiści wiedzieli wszystko o swojej aplikacji, od specyfikacji, przez rozwój, po wdrażanie i wsparcie.

A potem wkroczyła ludzka natura i zaczęliśmy prosić o więcej. Większa prędkość, więcej funkcji, więcej użytkowników, więcej wszystkiego.

Będąc skromnymi, skromnymi i spokojnymi stworzeniami, programiści mieli bardzo małe szanse na przetrwanie takiej fali potrzebujących użytkowników, którzy zawsze proszą o więcej. Największą szansą na zwycięstwo było rozpoczęcie ewolucji w różnych kierunkach i tworzenie kast. Wkrótce programiści wymarli jako przodkowie nowych ras zwanych programistami, inżynierami oprogramowania, administratorami sieci, programistami baz danych, programistami stron internetowych, architektami systemów, inżynierami QA i wieloma innymi. Szybka ewolucja i dostosowywanie się do wyzwań ze świata zewnętrznego stały się częścią ich DNA. Nowa kasta może ewoluować w ciągu kilku tygodni. Web developerzy stali się back-end developerami, front-end developerami, developerami PHP, Ruby developerami, Angular developerami… wszystko szło do piekła.

Wkrótce wszyscy zapomnieli, że pochodzą od tego samego ojca, programisty. Prosty i spokojny naukowiec, który po prostu chciał uczynić świat lepszym miejscem. Zaczęli ze sobą walczyć, twierdząc, że każdy z nich jest prawdziwym potomkiem „Programisty” i że ich krew jest czystsza od innych.

W miarę upływu czasu ograniczyli interakcję do minimum i rozmawiali ze sobą tylko wtedy, gdy naprawdę musieli. Przestali świętować sukcesy swoich odległych członków rodziny, a nawet przestali co jakiś czas wysyłać pocztówki.

Gdyby tylko przeszukali swoje uczucia, odkryliby, że w ich sercach była iskra Programisty, czekająca, by zabłysnąć i przynieść pokój galaktyce.

W swoim samolubnym i egocentrycznym wyścigu do podboju świata potomkowie programisty zapomnieli o samym celu swojej pracy - rozwiązywaniu problemów swoich klientów. Klienci zaczęli odczuwać ból takich zachowań, ponieważ projekty opóźniały się, były zbyt drogie, a nawet kończyły się niepowodzeniem.

Co jakiś czas świeciła jasna gwiazda i ktoś czerpał inspirację, by spróbować zawrzeć pokój wśród Potomków. Wymyślili Wodospad. To był genialny pomysł, ponieważ wykorzystywał fakt, że różne grupy programistów komunikowały się tylko wtedy, gdy było to konieczne. Kiedy jedna grupa zakończyła swoją część pracy, komunikowała się z następną grupą, aby przekazać pracę przez cały proces i nigdy się na nią nie oglądała.

Działało to przez jakiś czas, ale jak zwykle ludzie (Klienci) znowu chcieli więcej. Chcieli bardziej aktywnie uczestniczyć w całym procesie tworzenia oprogramowania, częściej wyrażać swoje zdanie i prosić o zmiany nawet wtedy, gdy było już za późno.

Projekty oprogramowania stały się tak podatne na niepowodzenie, że zostały zaakceptowane jako standard branżowy. Statystyki pokazały, że ponad 50% projektów kończyło się niepowodzeniem i wydaje się, że nic nie da się z tym zrobić (ZDNet, CNet)

Każde pokolenie miało kilka osób o otwartych umysłach, które wiedziały, że wszystkie te grupy programistów muszą znaleźć sposób na współpracę, komunikację i elastyczność, aby zapewnić swoim klientom najlepsze możliwe rozwiązanie. Są ślady tych prób już w 1957 roku, dokonywane przez kolegów wielkiego Johna von Neumanna. Jednak na rozpoczęcie rewolucji musieliśmy poczekać do początku 2001 roku, kiedy to brudny tuzin stworzył Manifest Agile.

Manifest Agile opiera się na dwunastu zasadach:

1. Zadowolenie klienta dzięki wczesnemu i ciągłemu dostarczaniu wartościowego oprogramowania
2. Witamy zmieniające się wymagania, nawet w późnym rozwoju
3. Działające oprogramowanie jest dostarczane często (tygodnie zamiast miesięcy)
4. Ścisła, codzienna współpraca ludzi biznesu z deweloperami
5. Projekty budowane są wokół zmotywowanych osób, którym należy zaufać
6. Rozmowa twarzą w twarz to najlepsza forma komunikacji (kolokacja)
7. Działające oprogramowanie jest głównym miernikiem postępu
8. Zrównoważony rozwój, zdolny do utrzymania stałego tempa
9. Ciągła dbałość o doskonałość techniczną i dobry design
10. Prostota — sztuka maksymalizacji ilości niewykonanej pracy — jest niezbędna
11. Zespoły samoorganizujące się
12. Regularna adaptacja do zmieniających się okoliczności

Manifest Agile był pierwszym dużym krokiem w zaprowadzaniu pokoju w Galaktyce i przywracaniu równowagi Mocy. Po raz pierwszy od bardzo dawna łączenie wszystkich interesariuszy w procesie tworzenia oprogramowania opierało się zarówno na kulturowym i „ludzkim” sposobie, jak i proceduralnym i zmechanizowanym. Ludzie zaczęli ze sobą rozmawiać, spotykać się regularnie, wymieniać pomysły i komentarze przez cały czas. Zdali sobie sprawę, że łączy ich o wiele więcej, niż im się wydawało, a klienci stali się częścią zespołu, a nie tylko jakimś zewnętrznym czynnikiem, od którego oczekiwano, że prześle pieniądze i nie będzie zadawać pytań.

Pozostało jeszcze kilka przeszkód do pokonania, ale przyszłość wydawała się jaśniejsza niż kiedykolwiek. Bycie zwinny oznacza bycie otwartym i chętnym do dostosowywania się do ciągłych zmian. Jednak przy zbyt wielu zmianach trudno jest skupić się na ostatecznym celu i realizacji. I tak powstał Lean Software Development.

Przywiązani do LSD (gra słów zamierzona) i ryzykujący wygnanie i wygnanie, niektórzy potomkowie szukali rozwiązań poza swoją kastą i branżą oprogramowania. Znaleźli ratunek w pracach dużego producenta samochodów. Toyota Production System był niesamowity w swojej prostocie i było tak oczywiste, że jego odchudzoną produkcję można łatwo zastosować do tworzenia oprogramowania.

Istnieje 7 zasad Lean:

1. Eliminować śmieci
2. Jakość budowy w
3. Twórz wiedzę (wzmacniaj naukę)
4. Odroczenie zobowiązania (podejmij decyzję tak późno, jak to możliwe)
5. Dostarcz tak szybko, jak to możliwe
6. Szanuj ludzi (Wzmocnij zespół)
7. Zoptymalizuj całość

Dodane do Agile zasady Lean wspierały mentalność i koncentrację na robieniu właściwych rzeczy, a jednocześnie były elastyczne podczas całego procesu.

Kiedy Agile i Lean zostały przyjęte przez zespoły programistów, wystarczył jeszcze jeden krok, aby zastosować cały zestaw zasad do IT jako całości – co w końcu doprowadziło nas do DevOps!

Enter DevOps — trzypasmowa autostrada

Stare podejście do zespołów programistycznych obejmowało analityków biznesowych, architektów systemów, programistów front-end, programistów back-end, testerów i tak dalej. Na nich skoncentrowano się głównie na optymalizacji procesu tworzenia oprogramowania, w tym na zasadach zwinnych i szczupłych. Gdy aplikacja była „gotowa do produkcji”, została wysłana do „Operacji”, w tym inżynierów systemów, inżynierów wydań, administratorów baz danych, inżynierów sieci, specjalistów ds. bezpieczeństwa itp. Usunięcie wielkiego muru między programistami a operacjami jest główną siłą napędową DevOps .

DevOps jest wynikiem wdrożenia zasad lean do całego strumienia wartości IT. Strumień wartości IT rozszerza rozwój na produkcję, łącząc wszystkich „odległych krewnych”, którzy wywodzili się od oryginalnego Programisty.

Najlepsze wyjaśnienie rozwiązań DevOps podaje Gene Kim, a jeśli nie czytałeś Projektu Phoenix , sugeruję, abyś poświęcił trochę czasu i to zrobił.

Nie powinieneś zatrudniać inżyniera DevOps, a DevOps nie powinien być nowym działem w twoim IT. DevOps to kultura, sposób myślenia i część IT jako całości. Nie ma narzędzi, które sprawią, że Twój dział IT stanie się organizacją DevOps , a żaden poziom automatyzacji nie umożliwi Twoim zespołom dostarczania maksymalnej wartości Twoim klientom.

DevOps jest zwykle określany jako metoda trzech dróg, ale ja postrzegam je jako trzy pasy tej samej autostrady. Zaczynasz na pierwszym pasie, potem przyspieszasz i przełączasz się na drugi, aż w końcu przejeżdżasz na trzecim pasie.

• Linia pierwsza - Wydajność systemu jako całości jest głównym punktem i jest kładziona na wydajność każdego pojedynczego elementu systemu

• Linia druga – Upewnij się, że w górę jest wysyłana ciągła pętla sprzężenia zwrotnego, a nie ignorowana

• Ścieżka trzecia – Eksperymenty pielęgnacyjne, ciągłe doskonalenie i szybkie porażki

Pas pierwszy – Rozpędzanie się

Zrozumienie znaczenia całego systemu i właściwe ustalenie priorytetów elementów pracy to pierwsza rzecz, której organizacja IT musi się nauczyć podczas przyjmowania zasad DevOps. Nikt w strumieniu wartości IT nie może tworzyć wąskiego gardła i ograniczać przepływu pracy.

Zapewnienie nieprzerwanego przepływu pracy jest ostatecznym celem dla wszystkich zaangażowanych w proces. Bez względu na rolę, jaką pełni osoba lub zespół, konieczne jest, aby starali się osiągnąć dogłębne zrozumienie systemu. Przyjęcie tego sposobu myślenia ma bezpośredni wpływ na jakość, ponieważ defekty nigdy nie są wysyłane w dół strumienia, ponieważ powodowałyby wąskie gardła.

Upewnienie się, że praca nie przeciąga się, nie wystarczy. Wydajna organizacja powinna zawsze dążyć do zwiększenia przepływu. Istnieje wiele metodologii zwiększania przepływu. Rozwiązanie można znaleźć w teorii ograniczeń, Six Sigma, Lean lub Toyota Production System. Wybierz dowolne z nich, wymyśl własne lub połącz je.

Zasady DevOps nie mają znaczenia, do jakiego zespołu należysz, jeśli jesteś architektem systemu, DBA, QA lub administratorem sieci. Wszystkich obowiązują te same zasady i od każdego oczekuje się przestrzegania dwóch prostych zasad:

• Utrzymuj nieprzerwany przepływ systemu
• Zwiększaj i optymalizuj przepływ pracy przez cały czas

Linia druga – podnieś bieg

Nieprzerwany przepływ systemu jest jednokierunkowy i oczekuje się, że będzie przechodził od rozwoju do operacji. W idealnym świecie oznacza to, że oprogramowanie jest tworzone szybko i wysokiej jakości, wdrażane do produkcji i dostarczające wartość klientom.

Jednak DevOps to nie Utopia i gdyby jednokierunkowe dostarczanie było możliwe, wystarczyłaby metoda kaskadowa. Ocena wyników i komunikacja w górę przepływu jest bardzo ważna dla zapewnienia jakości. Pierwszym kanałem komunikacji „upstream”, który należy wdrożyć, jest Ops to Dev.

Przybicie sobie piątki jest łatwe, ale proszenie o opinię i przekazywanie opinii to sposób na zobaczenie prawdziwego obrazu. Konieczne jest, aby po każdym małym kroku w dół następowało natychmiastowe potwierdzenie w górę.

Nie ma znaczenia, jak utworzysz pętlę sprzężenia zwrotnego. Możesz zaprosić programistów do dołączenia do spotkań zespołu wsparcia lub wprowadzić administratora sieci do cotygodniowego planowania sprintów. Tak długo, jak Twoja opinia jest na miejscu, a komentarze są zbierane i obsługiwane, Twoja organizacja pędzi na autostradzie DevOps.

Linia trzecia - Warp 10

Szybka linia DevOps nie jest przeznaczona dla osób o słabych umysłach. Aby szybko przejść na ścieżkę DevOps, Twoja organizacja musi być wystarczająco dojrzała. Chodzi o podejmowanie ryzyka i uczenie się na niepowodzeniach, ciągłe eksperymentowanie i akceptację, że powtarzanie i praktyka są warunkiem wstępnym do mistrzostwa. Dość często słyszysz określenie Kata i nie bez powodu. Ciągły trening i powtarzanie prowadzi do mistrzostwa, ponieważ sprawia, że ​​skomplikowane ruchy stają się rutyną.

Ale zanim zaczniesz łączyć ruchy, konieczne jest, aby najpierw opanować każdy krok.

„To, co jest odpowiednie dla Mistrza, nie jest odpowiednie dla nowicjusza. Musisz zrozumieć Tao, zanim przekroczysz strukturę.”

DevOps Third Way/Fast Lane obejmuje codzienne przydzielanie czasu na ciągłe eksperymentowanie, ciągłe nagradzanie zespołu za podejmowanie ryzyka i wprowadzanie błędów do systemu w celu zwiększenia odporności.

Aby mieć pewność, że Twoja organizacja nie ulegnie implozji podczas wdrażania tego rodzaju środków, musisz tworzyć częste pętle sprzężenia zwrotnego między wszystkimi zespołami, jednocześnie upewniając się, że wszystkie wąskie gardła są jasne, a przepływ systemu jest nieprzerwany.

Wdrożenie tych środków sprawia, że ​​Twoja organizacja jest cały czas czujna i zdolna do szybkiego i skutecznego reagowania na wyzwania.

Podsumowanie — lista kontrolna organizacji DevOps

Oto lista kontrolna, której możesz użyć do sprawdzenia, w jaki sposób DevOps jest włączona w Twojej organizacji IT. Zachęcamy do komentowania artykułu i dodawania własnych punktów.

• Nie ma muru między zespołem programistów a zespołem operacyjnym. Oba są częścią tego samego procesu
• Praca, która jest przesyłana z jednego zespołu do drugiego, jest zawsze weryfikowana i najwyższej jakości
• Nie ma „spiętrzenia” pracy, a wszystkie wąskie gardła są obsługiwane
• Zespół programistów nie wykorzystuje czasu operacyjnego do swoich działań, ponieważ wdrażanie i konserwacja są częścią tego samego przedziału czasowego
• Zespół programistów nie dostarcza kodu do wdrożenia o godzinie 17:00 w piątki, pozostawiając operacje na posprzątanie pracy w weekend
• Środowiska programistyczne są ustandaryzowane, a operacje można łatwo powielać i skalować do produkcji
• Zespół programistów może dostarczać nowe wersje, jeśli uznają to za stosowne, a operacje mogą łatwo wdrożyć je w środowisku produkcyjnym
• Między wszystkimi zespołami istnieją jasne linie komunikacyjne
• Wszyscy członkowie zespołu mają czas na eksperymentowanie i pracę nad doskonaleniem systemu
• Defekty są na bieżąco wprowadzane (lub symulowane) i obsługiwane w systemie. Wnioski wyciągnięte z każdego eksperymentu są dokumentowane i udostępniane wszystkim odpowiednim osobom. Obsługa incydentów jest rutynowa i najczęściej jest obsługiwana w znany sposób

Wniosek

Korzystanie z nowoczesnych narzędzi DevOps , takich jak Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS itp., nie oznacza, że ​​stosujesz zasady DevOps. DevOps to sposób myślenia. Wszyscy jesteśmy częścią tego samego procesu, dzielimy ten sam czas i razem dostarczamy wartość. Każda osoba biorąca udział w procesie dostarczania oprogramowania może przyspieszyć lub spowolnić cały system. Błąd powstały podczas tworzenia oprogramowania może spowodować awarię systemu, a także niewłaściwą konfigurację zapory.

Wszyscy ludzie są częścią DevOps, a gdy Twoja organizacja to zrozumie, w magiczny sposób pojawią się narzędzia i stos technologii, które pomogą Ci nim zarządzać.