Zwyczajów nie przeskoczysz

Wystarczy o to spytać Ryana Kelleya, inżyniera systemów w NREL, centrum badawczym zajmującym się odnawialnymi źródłami energii. Po raz pierwszy zastosował on DevOps przy okazji projektu, w którym konieczne było uzyskanie formalnych pozwoleń na rozwinięcie możliwości chmurowych serwerów laboratorium. „Wszyscy byliśmy wtedy od siebie mocno odizolowani” – wspomina Ryan. „Niektóre zespoły pracowały praktycznie tylko we własnym składzie, ze znikomą komunikacją z innymi. DevOps pozwoliło na zlikwidowanie tej izolacji”.

Jednakże wprowadzenie nowego modelu okazało się o wiele trudniejsze, niż Kelley przypuszczał. „W sytuacji, gdy zostały już utarte pewne normy, trudno jest je przełamać, aby wprowadzić zmiany”.

Zobacz również:

• Najpopularniejsze stanowiska pracy w chmurze obliczeniowej
• Premiera GitHub Copilot Enterprise

Z Kelleyem zgadza się Jez Humble, wiceprezes działu inżynierii firmy Chef pracującej nad automatyzacją IT, autor książki „Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation”. „Głównym problemem z wprowadzeniem DevOps jest pewna różnica pomiędzy grupami, które miałyby zostać połączone. Administratorzy IT pragną stabilności, a deweloperzy chcą tworzyć kod najszybciej jak to możliwe. Przez swoje odmienne priorytety od razu po rozpoczęciu bliższej współpracy zaczyna się między nimi konflikt”.

Mówiąc inaczej, proces tworzenia oprogramowania jest jak podróż łódką. Administratorzy wolą spokojnie dryfować, a programiści wiosłują szybko przed siebie, nie zważając na to, jak bardzo buja. Problem w komunikacji między nimi potęguje także to, że najczęściej nie porozumiewają się wprost. Tę przeszkodę Nationwide pokonało poprzez stworzenie tzw. ADC, centrum developmentu programów (application development center). Z początku był to tylko eksperyment zrzeszający sześć zespołów obejmujących łącznie 50 osób, a dziś już ADC łączy 180 współpracujących grup, z których wszystkie są skupione na zwinnym wytwarzaniu oprogramowania.

Inną z powszechnych przeszkód w zaadaptowaniu DevOps jest skomplikowany proces uczenia się metod w nim używanych. „Model ten wymaga odmiennych umiejętności niż poprzednio używane, w związku z czym do jego zastosowania konieczne jest przeprowadzenie szkoleń” – uważa DeArdo. Dlatego Nationwide wprowadziło tzw. Teaching Tuesdays, powtarzane dwa razy w miesiącu. Na tych nieformalnych spotkaniach pracownicy mogą się dzielić swoimi doświadczeniami oraz udzielać innym cennych porad.

NREL odkryło podobną lukę w umiejętnościach swych pracowników po wprowadzeniu DevOps. Ich pracownicy IT mieli znikomą wiedzę o procesie ciągłego tworzenia oprogramowania. Jak to ujął Kelley, DevOps było niezwykle skomplikowane do opanowania, i nadal jest, a droga do jego całkowitego wprowadzenia jest wciąż bardzo długa.

Bez pracy nie ma kołaczy

Oprócz konieczności przełamania dotychczasowych zwyczajów ludzi z branży IT i organizowania szkoleń istotne jest zaoferowanie pracownikom czegoś w zamian za ich wysiłek. Według Wurster przejście na DevOps to na tyle głęboka zmiana, że bez odpowiedniej zachęty ludzie mogą nie chcieć jej dokonać.

Awanse, podwyżki, premie – to są sposoby, w jakie łatwo można napędzić zmianę modelu. Dużą zachętą jest także możliwość zobaczenia efektów swojej pracy. W przeszłości nie było czymś niezwykłym w branży IT, żeby deweloperzy przekazali program tworzony przez wiele miesięcy ludziom odpowiedzialnym za utrzymanie systemów, aby potem stracić go z pola widzenia.

Tak było w przypadku Humble’a. W trakcie jego długiej programistycznej kariery zdarzył mu się taki przypadek. Pracował długo nad programem, a po kilku latach usłyszał, że „pomimo dostarczenia go na czas oraz zgodnie z budżetem firma, dla której powstał, nie wydała go z powodu braku zapotrzebowania. To był pierwszy moment, w którym płynna produkcja w modelu DevOps do mnie przemówiła”.

Ponieważ DevOps wymaga pełnego zaangażowania programistów, to wyniki ich działań są cały czas widoczne w nieustannie aktualizowanym środowisku programistycznym. Daje to większe poczucie władzy nad własnym dziełem, co jest szczególnie satysfakcjonujące.

Korzyści wynikające z wprowadzenia DevOps są jasne dla programistów oraz administratorów. Natomiast ludzie ze ścisłego kierownictwa firmy mogą się zastanawiać: „co my będziemy z tego mieli?”. Dlatego przekonanie zarządu jest niezwykle istotne dla zaadaptowania modelu. „Przy tego rodzaju zmianie konieczne jest poparcie najważniejszych osób z firmy, ponieważ niesie ona ze sobą pewne ryzyko” – przyznaje DeArdo.

Znaj swoje możliwości

Z powodu tego ryzyka istotne jest ustalenie wyznaczników wydajności specyficznych dla DevOps, ale nadal ukierunkowanych na biznes, to znaczy na dochodowość, produktywność oraz udziały w rynku. Nicole Forsgren, dyrektor ds. wydajności organizacji oraz analityki w Chef, twierdzi że droga wprowadzenia DevOps „może być i długa, i męcząca”, a kluczowe w uzyskaniu poparcia kierownictwa jest wykazanie, w jaki sposób mocniejsza współpraca oraz ciągła produkcja wpłyną pozytywnie na biznes.

W jaki sposób DevOps skróciło czas tworzenia oprogramowania? Jak bardzo przyspiesza wydawanie nowych produktów? O ile ułatwia dostęp do usług oferowanych przez firmę? Poprzez ukazanie korzyści, jakie niesie ze sobą DevOps, zespoły IT dużo łatwiej mogą przekonać kierownictwo do jego wprowadzenia.

Równie duże korzyści odniosą sami członkowie zespołów, zarówno programiści, jak i administratorzy. W trakcie używania dawnego modelu produkcji obie te grupy przyzwyczaiły się do pracy w swoim zamkniętym zespole, bez konieczności komunikacji z innymi. Programiści po skończeniu pracy przekazują ją administratorom, po czym mogą tylko trzymać kciuki i liczyć na to, że program zostanie wykorzystany. Tymczasem DevOps wymaga od nich wyjścia poza swoją strefę komfortu i czynny udział w pracy osób zarządzających utrzymaniem systemów.