Czym jest DevOps? 5 reguł, które musisz znać

W ostatnich latach określenie DevOps stało się bardzo popularne. Firmy coraz chętniej wykorzystują je w rekrutacji inżynierów lub promowania swoich technologii. Czym właściwie jest DevOps? Czy stanowi klucz do sukcesu biznesu sieciowego? A jeżeli tak, to dlaczego?

W 2009 roku serwis Flickr stanął przed poważnym wyzwaniem. Dynamiczny rozwój aplikacji przynosił coraz większe zapotrzebowanie technologiczne. Równocześnie użytkownicy chcieli, by serwis był nowoczesny i zawsze na czasie. Było to zgodne z założeniami twórców Flickra. Jednak problem stanowiło sprostanie tym zadaniom w taki sposób, by po osiągnięciu sieciowego sukcesu pozostać na fali i rozwijać się nie tracąc dotychczasowych klientów.

Twórcy aplikacji zdecydowali, że będą wdrażać zmiany częściej, niż miało to miejsce do tej pory. Znacznie częściej, bo aż 10 razy dziennie miał się odbywać deploy nowej wersji na produkcję. Aby tego dokonać, konieczne było zupełnie inne podejście do rozwoju produktu oraz narzędzia, które wspierałyby szybkie dostarczanie oprogramowania bez konieczności przerw w dostępie do usługi dla użytkowników.

Pracownicy Flickr zauważyli, że aby wydajnie wdrażać często nowe wersje serwisu, potrzeba innej organizacji pracy nie tylko na poziomie Developmentu, ale także Operations. Ich doświadczenia zbiegły się z potrzebami innych firm na świecie. Dlatego jeszcze w tym samym roku w Gandawie (Belgia) odbyła się pierwsza konferencja DevOps Days poświęcona problemom dynamicznego wdrażania oprogramowania przy udziale pracowników technicznych, jak i operacyjnych członków zespołu. To właśnie tam Patric Debois ukuł hasło DevOps, tak bardzo popularne dzisiaj wśród firm IT całego globu.

W ciągu kolejnych lat wypracowano szereg dobrych praktyk i podstawowych postulatów, których należy się trzymać. Dotychczas biznes nie znosił porażek (ang. failures), co powodowało silne skupienie na wszystkich aspektach oprogramowania i prowadziło do dłuższych prac nad kodem. DevOps staje w opozycji i mówi, że należy robić małe kroki i nie bać się potknięć (ang. fail early). Im mniejszy krok, tym mniejsze błędy, które można naprawiać szybko. Jest to możliwe dzięki stosowaniu częstych wdrożeń. Tak samo, małe sukcesy łatwiej jest wykorzystać, by przekuć je w jeszcze większe powodzenie.

Praktycy DevOps zauważyli, że w ten sposób użytkownicy mają szansę wyrazić swoją opinię (przez zebranie opinii ankietowej lub badanie zachowań w usłudze) i szybko można porzucić złe pomysły lub rozwijać te dobre.

DevOps zakłada ciągłe zmiany, stąd nie posiada manifestu. Mimo to istnieje pięć zasad, które leżą u jego podstaw. W pierwszej kolejności ważne jest (1) usprawnienie komunikacji w zespołach projektowych. Należy obalić tzw. silosy pomiędzy programistami a pracownikami operacyjnymi (managerami, marketingiem i handlowcami).

(2) Aplikacje powinny być tworzone metodologiami zwinnymi. Co jednak istotne, nie tylko od strony rozwoju kodu, ale także biznesowego spojrzenia na produkt. Programiści od dłuższego czasu stosują zwinne metody wytwarzania oprogramowania, jednak pracownicy operacyjni nadal często myślą o produkcie, jako o czymś, co trzeba tworzyć z użyciem kamieni milowych.

W końcu przykład Flickra pokazuje, że aby często zmieniać aplikację, konieczna jest (3) automatyzacja procesów testowania i wdrażania na produkcję. Pozwala to zwiększyć tempo dostarczania nowych funkcjonalności oraz naprawiania błędów. Co za tym idzie, także szybko reagować na pojawiające się błędy.

Częste zmiany powinny być spowodowane nie tylko własnymi odczuciami odnośnie działania usługi, ale przede wszystkim potrzebami i opiniami użytkowników. (4) Sprawne wykorzystanie informacji zwrotnej staje się kluczowe dla rozwoju aplikacji, by ta od momentu spopularyzowania mogła zostać na fali sukcesu. Operations powinni wykorzystywać dane z logów technicznych, a deweloperzy powinni uwzględniać uwagi od marketingu oraz opinie zgłaszane przez użytkowników do helpdesku.

DevOps nie posiada jasno wyznaczonych reguł. To zbiór dobrych praktyk, dlatego ostatni postulat sugeruje (5) dzielenie się wiedzą: zarówno tą biznesową, jak i techniczną (kodem Open Source). Duże firmy takie jak Facebook czy Allegro posiadają dzisiaj dedykowane blogi techniczne, na których oddają społeczności owoce swojej pracy w postaci gotowego oprogramowania i skryptów. Pojawiają się także na konferencjach, gdzie chętnie dzielą się stosowanymi u nich rozwiązaniami DevOpsowymi.

Stosowanie tych postulatów pozwala firmie na dynamiczne dostosowanie się do potrzeb odbiorców i reagowanie na odmienne trendy internetowego świata. Wiele firm dzisiaj istniejących może w ciągu 5 lat zniknąć z rynku tylko dlatego, że nie zmieniają się wystarczająco szybko.

Nie można też zapominać o tym, że diabeł tkwi w szczegółach. Nie wystarczy zmienić sposobu organizacji pracy w zespole. Konieczne jest też stosowanie odpowiednich technologii, wśród których najgłośniej mówi się o chmurach obliczeniowych i przechowywania danych. Do tego dochodzą narzędzia automatyzacji, testowania i przetwarzania logów. Ich wykorzystanie z pewnością także będzie kluczowe dla rozwoju usług i aplikacji w najbliższych latach.

Ruch DevOps jak każdy medal ma dwie strony. Nazwa stała się na tyle lotna, że niektóre, szczególnie duże, firmy zaczęły powszechnie używać go jako nazwy stanowiska. W rzeczywistości szukają osób, które zadbają o wydajne i stabilne działanie usługi (tzw. SRE – System Reliability Engineer). Z tego powodu przed społecznością DevOps stoi trudne wyzwanie zmiany postrzegania DevOps jako stanowiska w zespole. Tym bardziej, że brak manifestu oznacza równocześnie, że nie do końca określone i jasne jest, czym w swojej istocie DevOps ma być. Dopiero najbliższe lata pokażą, czy idea zostanie zapomniana tak samo szybko, jak szybko się pojawiła.

Ilustracja: Designed by Freepik

Podaj dalej...Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInDigg thisShare on Tumblr