DevOps - utopia czy źródło przewagi konkurencyjnej?

Czy deweloperzy powinni mieć dostęp do systemów produkcyjnych?
Odpowiedź na to pytanie wydaje się prosta. Oczywiście, że tak/nie! (zależnie, kto odpowiada). ;-)

 

W dużych firmach o strukturze silosowej zwykle podział ten jest "naturalny". Z kolei w małych firmach, gdzie wszyscy zajmują się wszystkim, podziału takiego nie ma. Rozdzielenie rozwoju systemów od ich utrzymania ma niewątpliwie pewne zalety, ale wydaje się, że zyskuje ostatnio na popularności trend odwrotny - nazwany DevOps.

Aby dobrać właściwy model, należy przeanalizować potrzeby i ograniczenia konkretnej organizacji. Osobiście skupiłbym się przede wszystkim na następujących czynnikach:

• niezawodność/dostępność - deweloperzy bez doświadczenia utrzymaniowego mogą zwyczajnie zagrozić stabilności środowiska produkcyjnego
• integralność - deweloper majstrując przy wnętrzu aplikacji na produkcji może np. rozspójnić dane
• poufność - deweloper z dostępem do produkcji to dodatkowe potencjalne źródło wycieku danych
• wymogi formalne - przepisy prawa mogą wymuszać na danej organizacji wyraźne odseparowanie rozwoju systemów od środowiska produkcyjnego
• generyczność aplikacji - system może być rozwijany pod to jedno, konkretne wdrożenie i wymaga głębokiej wiedzy o zachowaniu systemu na produkcji
• zmienność - systemy bywają modyfikowane bardzo często lub np. raz na kilka lat
• skuteczność - rozwiązywanie problemów bez dostępu do produkcji może być trudne, długotrwałe, a przez to kosztowne
• procedury i struktura firmy - procedury bywają stosowane bezmyślnie, dodatkowo rozdział rozwoju od utrzymania generuje więcej stanowisk dla menedżerów, którzy mogą mieć słabą komunikację lub wręcz konkurować

Tak więc należy ustalić, czy w danej sytuacji deweloper na produkcji bardziej szkodzi czy pomaga? I jeśli nie ma naprawdę dobrych powodów uzasadniających ścisłą separację rozwoju od eksploatacji, tej separacji warto po prostu unikać jako szkodliwego narzutu. :)

Niektórzy idą dalej i łączą obie funkcje: rozwój i eksploatację (we code and run). Wydaje mi się, że to nie zawsze ma sens, np. w przypadku aplikacji biznesowych, gdzie duży wysiłek dewelopmentu to prace analityczne. Ale w przypadku aplikacji webowych, tolerujących krótkotrwałe przestoje i zdolnych testować nowe funkcjonalności na końcowych użytkownikach - jak najbardziej.

Sporo ciekawych uwag na ten temat można przeczytać we wpisie Should Developers have Access to Production? oraz jego komentarzach.

 

Tematyka zaszczepiania DevOps nie tylko przy utrzymaniu środowisk web, ale w organizacjach typowo biznesowych (w tym przekonywania menedżerów do tego podejścia), jest także tematem niniejszych paneli InfoQ:

• DevOps outside of Web Operations
• Making the Business Case

Uczestnicy zwracają w nich uwagę m.in. na:

• model DevOps to nie zwykła zmiana organizacyjna lecz zmiana kultury (rozbijanie silosów) i nie należy jej wprowadzać odgórnie, raczej przez dobry przykład
• można pokazać DevOps jako podejście ułatwiające osiągnięcie celów biznesowych organizacji
• istotne jest wcześniejsze ustalenie dobrych metryk (KPI) - bez tego nie da się menedżerom pokazać, czy zmiana cokolwiek poprawiła (np. skrócony TTM)
• metryki należy monitorować i stopniowo doskonalić organizację
• dla menedżerów wyższego szczebla często nie liczą się już liczby, lecz zaszczepienie wizji

 

Podsumuję cytatem z posta What Is This Devops Thing, Anyway?

Devop requires a certain state of mind. It's an attitude which says: I'm going to make a difference, I'm going to cooperate and communicate, and I'm going to understand that in the business of delivering great software, we're all in it together. If you're a sysadmin, this means spending time with the developers. (...) If you're a developer, go and make friends with your sysadmins. Don't view them as lower life forms, or as people to lob problems to. Go and join in - pair with them.

Brzmi jak utopia? ;-)