Typowe wdrożenie systemu informatycznego jest pasmem nerwów i nieporozumień. Odbiorcy biznesowi do ostatniej chwili zgłaszają swoje wymagania lub zmieniają istniejące. Programiści nanoszą poprawki, usuwają błędy i integrują rozwiązanie. Testerzy do późnego wieczora testują ostatnie błędy; wiadomo, że trzeba będzie przesunąć termin albo żyć z błędami... nadchodzi wdrożenie, a potem kilka trudnych godzin, dni, a czasem nawet tygodni, kiedy nieodnalezione błędy ujawniają się podczas normalnej pracy. Aż wreszcie użytkownicy biznesowi zapoznają się narzędziem i... natychmiast zgłaszają do niego poprawki. Tego nie przemyśleli, tamto zostało inaczej wykonane, ważny klient wymaga jakiejś funkcjonalności... i cała historia zaczyna się od początku.

Utrzymanie obwinia rozwój za niską dostępność systemów; rozwój pyta użytkowników biznesowych, co jest ważniejsze: nowe funkcjonalności czy usuwanie znanych błędów; użytkownicy biznesowi irytują się długim czasem pomiędzy pomysłem a wdrożeniem gotowego rozwiązania.

Czy można inaczej? Chyba można. Koncepcja „skruszenia murów” pomiędzy biznesem, rozwojem a utrzymaniem nazywa się DevOps i dynamicznie rozwija się od kilku lat, przede wszystkim w Europie.

DevOps, czyli cały łańcuch wartości

Od dawna wiadomo, że ciężkie, kaskadowe metodyki rozwoju oprogramowania nie sprawdzają się w przypadku dużej zmienności wymagań i warunków – czyli w większości zastosowań we współczesnym przedsiębiorstwie. Odpowiedzią na tę słabość są zwinne (Agile) metodyki – kilka lat temu margines, dzisiaj główny nurt w rozwoju systemów.

DevOps to przeniesienie pryncypiów Agile na całość cyklu życia oprogramowania, od rozwoju poprzez utrzymanie. Nazwa pochodzi z połączenia słów development (rozwój) i operations (utrzymanie) Ducha DevOps oddaje najlepiej zdanie: Zrobiłeś, więc utrzymuj (You build you run). Zamiast dążenia do kompletnego opisu i formalnego procesu rozwojowego albo utrzymaniowego, DevOps zakłada:

• ścisłą współpracę między klientem biznesowym, rozwojem, testami a utrzymaniem w ramach połączonych zespołów rozwojowo-utrzymaniowych;

• zagęszczenie wdrożeń, nawet do kilku, kilkunastu dziennie wprowadzających niewielkie, przyrostowe zmiany – w miejsce dużych, „ciężkich”, oddzielonych wieloma tygodniami lub miesiącami;

• szerokie wykorzystanie chmury obliczeniowej i technologii automatyzacji infrastruktury.

DevOps to rozwój oprogramowania z myślą o utrzymaniu w chmurze obliczeniowej. Wymagania płynące z infrastruktury – konieczność jej skalowalności, obecność specyficznych rozwiązań sprzętowych czy platformowych, bezpieczeństwo – mają równoprawny charakter względem wymagań odbiorcy biznesowego. „Kod systemu” to nie tylko funkcjonalność widoczna dla użytkowników czy interfejsy do innych systemów, ale także wszystko to, co wiąże się z zestawianiem wirtualnych serwerów

Patrick Debois, twórca DevOps, jest niezależnym konsultantem. Wcześniej pracował bodaj w każdej roli w przemyśle IT (sprzedawca, programista, administrator, tester, konsultant). Prywatnie – to miłośnik „Gwiezdnych wojen”, o czym świadczy choćby adres strony poświęconej DevOps (http:://www.jedi.be). Stawia sprawę jasno: „Rozwój to tylko element łańcucha wartości, który informatyka dostarcza klientowi”. Zamiast osobnych metodyk – rozwojowej, opartej na Agile i utrzymaniowej, opartej np. na standardzie ITIL – każe patrzeć na całość łańcucha.

Infrastruktura Agile

DevOps jest neutralne, jeśli chodzi o język programowania, wykorzystywane technologie, platformy, systemy operacyjne; nie rekomenduje także konkretnego cyklu wytwórczego lub częstotliwości wdrożeń (poza tym, że zaleca robić je często). Ma natomiast wiele zalet dotyczących wdrożenia i utrzymania.

Aplikacje powinny same się instalować i same przygotowywać do działania. W świecie, w którym fizyczna lokalizacja serwera i użyta technologia mają coraz mniejsze znaczenie, aplikacje powinny być wyposażone w możliwość automatycznego stworzenia wirtualnego środowiska, skonfigurowania się na nim, przygotowania odpowiednich plików, struktur danych itd. oraz niezależnego działania.

Automatyczne testy aplikacji powinny umożliwiać diagnozę jej stanu w każdej chwili. Obowiązkowo przed wdrożeniem, ale także na żądanie. Nic dziwnego, skoro DevOps zakłada wdrożenia kilka razy w ciągu dnia, a dostępność ma pozostać wysoka. Wdożenie – umieszczenie aplikacji na serwerach, modyfikacja danych, plików konfiguracyjnych, itd. – również musi podlegać testom.

Następny element to sprawdzanie własnego działania. Wysoka dostępność aplikacji powinna być zapewniona poprzez ciągły monitoring jej wydajności i reakcję na niestandardowe zdarzenia (np. przerwę, nagłe spowolnienie, nieprawidłowe odpowiedzi, stopniowe wysycenie mocy obliczeniowej lub zasobów). Monitoring powinien zbierać dane, a dane mają podlegać analizie.

W modelu chmury płacimy nie za serwer, a za zużycie mocy obliczeniowej. Mniej mocy, mniej miejsca na dyskach, to niższe koszty; optymalizacja algorytmu przekłada się na pieniądze. DevOps wymaga innych akronimów: IaaS (Infrastructure as a Service) i PaaS (Platform as a Service) oraz zwirtualizowanej infrastruktury, dostępnej on-demand.

Kolejne czynniki, o których programiści zapominają, a które w DevOps są obowiązkowe, to możliwość aktualizowania aplikacji, jej bezpieczeństwo, tworzenie kopii zapasowej (i odzyskiwanie z niej) itd.

DevOps to programowanie z myślą o utrzymaniu albo utrzymanie z myślą o funkcjonalności biznesowej. Albo po prostu maksymalizacja wartości dodanej dla biznesu za pomocą środków, jakie zapewnia technologia informatyczna, zwłaszcza grupa technologii związanych z chmurą obliczeniową.

Kultura DevOps

We wszystkich wystąpieniach i prezentacjach o DevOps podkreślana jest zmiana kulturowa, którą podejście przynosi. Nie ma „my-rozwój, wy-utrzymanie” albo odwrotnie – i nie ma pokazywania palcami: „to wy zrobiliście niedziałający system!”, „to wy nie umiecie go utrzymać!”. Nie ma – jak w standardzieITIL – koncentracji na zdefiniowaniu i rozliczaniu kontraktu czy usługi.

DevOps jest jak Agile: wymaga iteracyjności, zaufania, mieszanych zespołów, komunikacji i ciągłego doskonalenia Niezmiernie trudne jest w dużych, zhierarchizowanych organizacjach i tam, gdzie nie ma miejsca na podejmowanie ryzyka. Przecież kilka czy kilkanaście wdrożeń dziennie oznacza, że produkt jest ciągle doskonalony, zaś użytkownicy końcowi są jego ostatecznymi testerami. Lepiej zrobić błąd i potem go poprawić, niż tygodniami „szlifować” rozwiązanie – oto filozofia DevOps.

DevOps stosowane jest najchętniej w takich firmach, jak: Flickr, Netflix, Amazon i Groupon – a więc głównie w biznesie internetowym, który polega na dostarczaniu zawartości użytkownikowi końcowemu. Ale pamiętajmy – dzisiaj dostęp do klienta za pośrednictwem internetu to core business nieomal każdego przedsiębiorstwa.

Słabość metodyk Agile jest powszechnie znana; dotyczy ich skalowalności, ładu architektonicznego i procesowego, ale głównie ograniczeń związanych ze strukturą, kulturą oraz zasadami funkcjonowania w dużych organizacjach. Ta sama krytyka poniekąd dotyczy DevOps. Jeśli myślimy o wdrożeniu DevOps w organizacji IT, należy zastanowić się nad jej kulturą.

Nie wszędzie taka filozofia się sprawdzi. Patrick Debois radzi być ostrożnym w zastosowaniach klasy mission critical. Częste, inkrementalne zmiany sprawdzają się w dynamicznym i szybko rosnącym biznesie, przy dużej zmienności rynku i niewielkiej skali regulacji. Takie podejście w biznesie konserwatywnym i ściśle regulowanym może się skończyć bałaganem. Może, ale nie musi – jeśli DevOps potraktuje się jako inspirację, a nie „prawdę objawioną”, którą można wdrożyć w całości albo wcale.

Nowa srebrna kula?

Niedawno zmarły nestor polskiej informatyki Władysław M. Turski porównał kiedyś informatyków do alchemików, którzy przez wieki szukali kamienia filozoficznego. Świat nowoczesnych technologii ciągle poszukuje czegoś nowego – języka, technologii, metodyki, notacji – która pomoże połączyć biznes z technologią, analityków z programistami, odbiorców z inżynierami. W literaturze anglojęzycznej częściej pojawia się motyw srebrnej kuli, cudownego środka na wampiry, po których nie wstają już z grobu.

DevOps nie aspiruje do bycia kolejną srebrną kulą czy kamieniem filozoficznym. Stawia sobie za cel wysoką dostępność, budowanie wartości dla odbiorcy biznesowego i patrzenie na całość cyklu życia aplikacji w sposób jednolity. DevOps to reakcja na sformalizowane i zbiurokratyzowane metodyki typu PMI/PMBok, CMMI lub ITIL, w których wiele jest formalizmów, ale…

DevOps różni się od innych „zwinnych” w wielu punktach. Na przykład przykłada ogromną wagę do kwestii infrastruktury – co dla typowej inżynierii oprogramowania, w której maszyna jest „przeźroczystą” w punktu widzenia inżynierii bazą, jest nie do pomyślenia. DevOps każe patrzeć całościowo i rozliczać autora oprogramowania nie z tego, jaką funkcjonalność dostarczył, ale także jak sprawuje się ona na produkcji jako usługa. Powtórzmy tutaj hasło DevOps: „Zrobiłeś, więc utrzymuj”. Wreszcie, DevOps z pietyzmem podchodzi do miar – każe je zbierać, analizować i wyciągać na ich podstawie wnioski, podczas gdy tradycyjne podejście Agile wobec miar i mierzenia jest ambiwalentne, jeśli niepodejrzliwe.

DevOps jest w okresie dynamicznego wzrostu popularności. Kolejne firmy – także w Polsce – zaczynają korzystać z DevOps, jeszcze inne ze zdziwieniem odkrywają, że ich dobre praktyki zostały nazwane, opisane i poniekąd „skodyfikowane” jako DevOps.

Najbliższe lata pokażą, czy nowy sposób na połączenie rozwoju i utrzymania na trwałe zagości w polskich organizacjach IT.