Dlaczego DevOpsi?

W branży IT termin DevOps przewija się w dyskusjach od kilku lat:

„Zatrudnimy DevOps Engineer’a”

„Wprowadzamy w naszej firmie kulturę DevOps”

„Dzięki wprowadzeniu DevOps w naszej firmie o x procent zmniejszyliśmy koszty operacyjne”

Dyskusje, dyskusjami, ale czym tak naprawdę jest DevOps?

Historia pewnego spotkania

Aby odpowiedzieć sobie na to pytanie musimy się cofnąć w czasie do roku 2008 i konferencji Agile w Toronto.

Andrew Clay Shafer, obecny Vice President Transformation w Red Hat zaproponował, aby jedną z jej sesji nazwać „Agile Infrastructure”. Nie do końca jednak uczestnicy tego zacnego zgromadzenia zrozumieli wtedy jego intencje ponieważ… sesja nie odbyła się z powodu braku zainteresowania. Na szczęście konferencję w Toronto odwiedził również niezależny konsultant IT Patrick Debois, nazywany dzisiaj Ojcem Chrzestnym ruchu DevOps.

Rozmowa z konsekwencjami

Andrew i Patrick spotkali się, aby podzielić się swoimi spostrzeżeniami oraz doświadczeniami. Patrick w tym czasie realizował migrację Data Center dla belgijskiego rządu. W ramach tego projektu z jednej strony współpracował ze zwinnymi zespołami developerskimi, z drugiej zaś z nieobliczalnymi zespołami operacyjnymi. Bezsprzecznie stał pomiędzy młotem a kowadłem. Tematów do dyskusji z Andrew nie mogło mu zabraknąć. Okazała się ona być niezwykle owocna, ponieważ w jej efekcie powstała grupa Agile System Administration (nawiasem mówiąc grupa wciąż działa, organizuje wiele ciekawych spotkań na temat nie tylko technikaliów, ale również o tym jak wprowadzać DevOps do organizacji).

Narodziny DevOpsDays

To właśnie Agile System Administration stał się czynnikiem sprawczym pierwszej w branży IT konferencji DevOpsDays. Odbyła się ona w Belgii w dniach 30-31 października 2009 roku. Wywołała ogromne zainteresowanie wśród programistów, administratorów i managerów. Konferencja stała się motorem napędowym dla wielu inicjatyw i osób – na jej fali powstały projekty, bez których dzisiaj trudno byłoby sobie wyobrazić świat programistów: Vagrant, Puppet czy Chef.

DevOpsi_team
Głównym zadaniem DevOps jest współpraca pomiędzy zespołami developerskimi i operacyjnymi.

Czym w takim razie jest DevOps?

DevOps jest metodologią. Czerpie bardzo dużo z takich metodyk jak Agile, Lean czy Kaizen. Jej głównym zadaniem jest burzenie murów i nawiązywanie współpracę między zespołami developerskimi i operacyjnymi. Dzięki temu proces dostarczenia oprogramowania do Klienta zostaje w sposób znaczny usprawniony. Oprogramowanie to też jest obarczone mniejszą ilością błędów i bardziej odpowiada potrzebom Klienta. Tak naprawdę główną ideą powstania DevOps było zatem stworzenie interdyscyplinarnych i rozmawiających ze sobą zespołów – Dev(development) i Op(operations), czyli DevOps.

Metodologia DevOps w firmie – korzyści

Korzyści wprowadzenia w firmie metodologii DevOps nie brakuje. Wymieńmy te najważniejsze:

Redukcja czasu dostarczania oprogramowania

– DevOps zakłada, że oprogramowanie powinno być dostarczane w mniejszych, ale częstych „porcjach”. Klient powinien dodatkowo uczestniczyć zarówno na etapie planowania prac (Planning, Refirement), jak i na etapie odbiorów małych części (Demo) – dzięki czemu widzi postępy i jest w stanie szybko udzielić informacji zwrotnej na temat danego przyrostu, jak i całości rozwiązania.

Odporność na zmiany

– dobrze wdrożona metodyka DevOps nie boi się zmian – ba! ona lubi zmiany. Nie boi się kryzysów.

Autonomiczne zespoły

– to o czym pisałem wcześniej. Moją ulubioną korzyścią, którą niesie za sobą wprowadzenie DevOps do organizacji to postawienie przed zespołem celu – „dowiezienie” produktu/zmiany. Metoda dojścia do tego schodzi całkowicie na drugi plan – zespół sam się organizuje, wybiera technologię, podejście do testów itd. Dzięki tej pozornie prostej zmianie w łatwy sposób można uniknąć tzw. mikrozarządzania.

Zburzenie muru odpowiedzialności

– druga moja ulubiona korzyść. Jak to wyglądało kiedyś? Manager szedł od działu do działu i pytał kto poprawi pilny błąd na produkcji. Kolejne zespoły mówiły: to nie mój problem – idź dalej. Frustrujące, prawda? Jak to wygląda w DevOps? Zespół jest odpowiedzialny za tworzenie, rozwój i utrzymanie rozwiązania, czyli problem jest rozwiązywany natychmiast.

Polepszenie bezpieczeństwa

– dość oczywiste, jednak często pomijane. Powtarzające się testy, release’y małych porcji oprogramowania, pozwalają na wykrycie dużej ilości błędów i ich naprawę przed wydaniem. Takie błędy wykryte już na produkcji mogą się okazać trudne i drogie do usunięcia chociażby przez to, że często samo poprawienie procesu jest niewystarczające. Musi ono dotyczyć także danych, co często okazuje się skomplikowanym zadaniem.

Transparentność

– trzecia moja ulubiona korzyść. Każda osoba w zespole/firmie jest świadoma tego co się dzieje w samej firmie czy projekcie, nad którym pracuje. Dzięki temu mamy przepływ wiedzy zarówno między działami jak i osobami. Budujemy Zaufanie. A jak twierdzi Michał Szafrański, ekspert finansowy i znany bloger – Zaufanie jest Walutą Przyszłości.

DevOpsi_team_on_DevOps_project
Autonomiczne zespoły DevOps same się organizują, wybierają technologię, podejście do testów.

Pryncypia

Aby móc nazywać się organizacją, która wdrożyła DevOps – Organizacją DevOps – należy dążyć do spełnienia 6 pryncypiów, którymi są:

  1. Działania zorientowane na Klienta.
  2. Wytwarzanie z wizją końca.
  3. Odpowiedzialność od początku do końca -> Zrobiłeś, więc Utrzymuj.
  4. Interdyscyplinarne zespoły.
  5. Continous Improvement.
  6. Automatyzacja. Wszystkiego. Nawet jako sztuka dla sztuki.

Po spełnieniu tych 6 punktów firma może śmiało mówić, że jest DevOps. Wiadomo, że spełnienie to jedno, ale trzeba te Pryncypia ciągle rozwijać i pielęgnować.

Dlaczego więc DevOpsi?

Od wielu lat starałem się budować właśnie takie interdyscyplinarne zespoły – spełniające Pryncypia DevOps. Gdy podjąłem decyzję o rozpoczęciu budowania własnej organizacji, nawet przez chwilę nie zastanawiałem się nad jej nazwą – odrazu wiedziałem, że DevOpsi idealnie odwzoruje to co reprezentujemy. Naszą Misję, Wizję i Wartości którymi się kierujemy…