Z Wojciechem Ehrenfeldem, dyrektorem Departamentu Publicznych Usług IT w Grupie Onet.pl rozmawiamy o zmianie w sposobie zarządzania pracami nad rozwojem i utrzymaniem produktów w Onet.pl, wdrożeniu metody DevOps, wadach i zaletach tego podejścia.
Jak można najkrócej streścić założenia metodyki DevOps? Które jej założenia są w praktyce najważniejsze?
DevOps to wspólna praca developerów i administratorów nad rozwojem i utrzymaniem produktu.
Kluczowy w tym podejściu jest właśnie produkt, którego rozwój jest planowany w sposób iteracyjny, zgodnie z podejściem SCRUM i CONTINOUS INTEGRATION, ale z jednoczesnym uwzględnieniem zachowania wysokiej jakości i niezawodności działania.
Podejście DevOps, w którym ten sam zespół odpowiada za całość procesów w swoim produkcie powoduje zmniejszenie niepotrzebnej biurokracji.
Czym DevOps różni się od ITIL’a? W czym jest lepszy, w czym gorszy?
ITIL i DevOps nie są przeciwstawne. ITIL to zbiór zdroworozsądkowych, dobrych praktyk, które oczywiście mają identyczne zastosowanie w świecie DevOps, jak i w świecie silosów „Operation” i „Development”. Zespoły DevOps usuwają awarie, rozwiązują problemy, planują maksymalną wydajność i raportują jakość działania własnych usług. Posiadają też “zbiór standardów”, według których powinny działać poszczególne procesy. Jednak podejście, w którym sam zespół odpowiada za całość procesów w swoim produkcie powoduje zmniejszenie niepotrzebnej biurokracji.
Jak wygląda modelowe wdrożenie DevOps, jako metody zarządzania produkcją, rozwojem i utrzymaniem oprogramowania?
Kluczem jest stworzenie produktów, z którymi ludzie się identyfikują. Jeśli to się uda to reszta jest już zdecydowanie prostsza, choć wymaga wysokiej dojrzałości osób pracujących w takich zespołach.
Najważniejsze zalety i wady DevOps?
Wśród najważniejszych zalet wymieniłbym: wzrost zaangażowania i identyfikacja pracowników z produktem, a co za tym idzie z firmą!
Jest wśród nich też elastyczność – możliwość decydowania na bieżąco o różnej intensywności rozwoju i utrzymania w zależności od cyklu życia produktu. Przykładowo, jeśli produkt ma problemy z jakością to decyzją zespołu jest zatrzymanie jego rozwoju i ustabilizowanie produkcji lub odwrotnie, kiedy przygotowywana jest duża, nowa funkcjonalność zespół może podjąć decyzję o zwiększeniu ryzyka związanego np. z dostępnością usługi.
Kluczem do wprowadzenia DevOps w organizacji jest stworzenie produktów, z którymi ludzie się identyfikują. Jeśli to się uda to reszta jest już zdecydowanie prostsza, choć wymaga wysokiej dojrzałości osób pracujących w takich zespołach.
Wśród zalet można wymienić też: „chmurowatość” IT, tzn. różne zespoły pracują nad swoimi produktami niezależnie, ale są one ze sobą połączone znanymi wszystkich zasadami – API. Produkty dzięki temu mogą udostępniać innym „własne” usługi i korzystać z innych. Dodatkowym bonusem planowanie pracy – dość precyzyjnie wiemy, czego możemy oczekiwać w kolejnym dniu, tygodniu, maksymalnie miesiącu.
Najważniejszym zagrożeniem jest zaś – szczególnie w okresie początkowym – brak dojrzałości pracowników w zespołach DevOps, których przerasta wzięcie na swoje barki dużej odpowiedzialności i brak możliwości obarczania swoich niepowodzeń narzucanymi procesami IT. Może to skutkować obniżeniem jakości tworzonych produktów. Potrafię sobie wyobrazić środowiska, gdzie wyżej wymieniona elastyczności będzie niedopuszczalna.
Dlaczego Onet.pl zdecydował się na to podejście? Jakie są najważniejsze korzyści w Waszym przypadku?
To przede wszystkim skrócenie czasu tworzenia nowych produktów oraz konieczność pracy w środowisku cloud computing, gdzie technologia – a co za tym idzie zespoły je rozwijające udostępniają swoje usługi – w XaaS.
Świat usług cloud computing powoduje zacieranie się różnic między Dev i Ops. Przykładowo, jeśli infrastruktura jest zwirtualizowana i zautomatyzowana, to liczba zadań ‘administracyjnych’ maleje powodując szansę na zwiększenie czasu na budowę aplikacji.
Czy DevOps faktycznie powoduje zmniejszenie ryzyka projektowego i usprawnienie komunikacji między różnymi grupami uczestników prac?
Zdecydowanie zmniejsza ryzyko w krótkim terminie. Natomiast wymaga bardzo dobrego planowania terminowego. Tutaj nic się nie zmienia w porównaniu do „tradycyjnego” podejścia. Jednak budowa produktów iteracyjnie daje szanse na lepszy monitoring postępu prac i możliwość podejmowania decyzji w odpowiednim czasie.
W jakim kierunku zmierza, lub w jakim powinien zmierzać rozwój metod DevOps?
W zasadzie świat usług cloud computing powoduje zacieranie się różnic między Dev i Ops. W świecie gdzie infrastruktura jest zwirtualizowana i zautomatyzowana, to liczba zadań ‘administracyjnych’ maleje dając szansę na zwiększenie czasu na budowę aplikacji.
Więcej na ten temat na 6. Kongresie itSMF (19 września, Warszawa), na którym mają być prezentowane inne przykłady zastosowania DevOps w Polsce. ITwiz objął patronat nad Kongresem.
Dużo tekstu ale niewiele mówi czym jest DevOps. Może na początku trzeba by zdefiniować co leży w kompetencji developera a co administratora i jak oni się dogadują mając często różny aparat pojęć. Jakiś żywy przykład problemu, który został skutecznie rozwiązany w DevOps. Dla jak dużej grupy ludzi to ma sens. Jaka jest struktura decyzyjna (czy płaska) ? Co jeśli jedna grupa DevOps ma “skończony” (działający) produkt a druga grupa DevOps nadal kulejący i z wąskim gardłem. Co z wymianą doświadczeń pomiędzy grupami DevOps.