W DevOps próbujemy zrobić rzecz niemożliwą. Chcemy mieć zespół technicznych ludzi, którzy znają sie na wszystkim: począwszy od programowania, zarządzania kodem, administrowania systemem, chmury, automatyzacji, a kończąc na aplikacji. Dodajmy do tego jeszcze znajomość procedur obowiązujących w organizacji, raportowania statusu projektu i dojdziemy do wniosku, że cała sprawa jest nie do opanowania i dlatego… wprowadzamy model wspólnej odpowiedzialności za wszystko. Trochę to utopia, ale… jeśli takiego celu nie da się osiągnąć, to może chociaż można się do niego zbliżyć?
Każda implementacja DevOps jest trochę inna, ale można zaobserwować kilka trendów budowy takich zespołów.
Komandosi – Zróbmy jeden zespół zajmujący się DevOpsem
Ten model najmniej narusza istniejącą już w organizacji strukturę wyspecjalizowanych działów. Tworzymy po prostu jeden nowy dział i dajemy mu zadanie pracy nad automatyzowaniem budowy rozwiązania IT. Taki zespół będzie pewnie mniej znał szczegóły samej aplikacji, programowania, systemów operacyjnych, ale wyspecjalizuje się w budowie PipeLine budującego i testującego aplikację. Zespół osiągnie sprawność w zakresie specyficznych narzędzi i technologii, które są przez wykorzystywane przez budowaną aplikację.
Niestety, będzie to kolejny silos w organizacji i rozpocznie się na nowo… przepisywanie tematów z zespołu do zespołu. Żeby zrobić krok dalej, trzeba będzie uzyskać zgody i uprawnienia od innych zespołów. Sam zespół DevOps też może tworzyć blokady dla innych zespołów. Dlaczego niby mamy coś zautomatyzować, jeśli zadanie można przepisać do zespołu DevOps, który będzie przeciążony?
Desant – Dodajmy do każdego zespołu inżyniera DevOps
Jeśli w istniejącym zespole zaproponujemy zbudowanie automatyzacji opartej o DevOps, to spowoduje to oczywisty problem przeciążenia zespołu. Przecież do tej pory, każdy miał już swoje zadania i poświęcał na nie czas. Rozwiazaniem tego problemu może być dodanie do zespołu nowego człowieka, który dostanie zadanie automatyzacji – proste co? Na dodatek szukając takiego specjalisty można znaleźć kogoś, kto rzeczywiście dobrze orientuje się w specyfice DevOps. Na pewno cały zespół się ucieszy, bo oto jest „kozioł ofiarny”, któremu można oddelegować zadania związane z samym budowaniem aplikacji, a samemu skupić się na dalszym programowaniu.
Niestety i tu jest problem. Kiedy z jakiegoś powodu tego człowieka zabraknie, albo jeśli zatrzyma się on na jakimś problemie, to praca utknie w miejscu. Ma sie to nijak do modelu wspólnej odpowiedzialności za projekt. Mimo wszystko wydaje się, że może to być przynajmniej dobry początek. Trzeba tylko zadbać o dobry przepływ wiedzy, a takie „desantowe” podejście może się udać.
Przegrupowanie – połączmy dev i ops w jeden zespół
DevOps wymaga intensywnej współpracy między dev i ops. Jeśli do tej pory nad rozwojem 3 aplikacji pracowało 9 programistów i 6 administratorów, to można by podzielić zespół nie ze względu na specjalności ale ze względu na tworzoną aplikacje. Będziemy mieć (matematycznie ujmując) 3 zespoły i w każdym z nich 3 developerów i 2 administratorów. W tych nowych zespołach developerzy musią zacząć rozumieć adminów, a admini developerów. Każdy może się uczyć na błędach innych, korzystać z doświadczeń kolegów.
Jednak i tu jest problem. Czy na prawdę chcemy, aby developer uczył się administracji zamiast pogłębiać wiedzę programistyczną? Czy chcemy, aby adminstrator uczył się pisać koślawy kod zamiast rozwijać się w zakresie administracji systemami? Niestety, wyglada na to że tak, a to jednak mimo wszystko trochę zwariowany pomysł, ale… w tym kierunku idziemy.
Jest jeszcze jedna bolączka. Łatwiej się rozwijać np. w temacie programowania pracując w zespole z wieloma innymi doświadczonymi programistami niż w zespole, gdzie tylko kilku kolegów zna się na programowaniu, a reszta to admini. Właśnie takie wzajemne podciąganie się w poznawaniu technologii było i jest plusem pracy w „silosach”.
