6 najczęściej popełnianych błędów przy wdrażaniu DevOpsa

Jest wiele błędów, którego mogą spowodować, że wdrażanie procesów DevOps może rozbić się o skały. Część z tych problemów występuje regularnie, a znając je, można ich uniknąć.

Słuchając bezkrytycznych zwolenników DevOps o tym, jak działa ta metodologia w praktyce, można odnieść wdrożenie, że jej wdrożenie jest drogą usłaną różami, niezależnie w jakim miejscu akurat znajduje się organizacja. Gdy jednak faktycznie rozpocznie się proces wdrożenia, szara rzeczywistość szybko da znać o sobie. W końcu DevOps to odważna próba połączenie działów rozwojowego i operacyjnego, aby wydajnie ze sobą współpracowały. Dodatkowo mechanizmy automatyzacji mają sprawić, że proces wdrażania nowych wersji oprogramowania stanie się powtarzalny i odporny na błędy. Osiągnięcie tego celu nie jednak łatwe i pod drodze można popełnić wiele brzemiennych w skutkach pomyłek. Są jednak sposoby, jak im zaradzić.

Najczęściej popełniane błędy można zaliczyć do trzech kategorii. Co warte odnotowania, żadna z nich nie dotyczy technologii. Mimo że automatyzacja jest niezbędnym elementem DevOps, to funkcjonowanie służących jej narzędzi można opanować. Nawet najdziwniejsze problemy z narzędziami nie doprowadzą do niepowodzenia projektu, chyba jest on już w poważnych tarapatach.

Zobacz również:

„DevOps to tylko automatyzacja”

Owszem, kluczową częścią DevOps jest automatyczna dystrybucja oprogramowania. Dla niektórych to właśnie jest najważniejsza korzyść z przejścia na DevOps. Jednak jeśli automatyzacja dystrybucji jest wszystkim, co obejmuje migracja, trudno będzie faktycznie w całości przejść na tę metodologię. Automatyzacja nie zapewni bowiem komunikacji i pozostawi przepaść pomiędzy procesami realizowanymi przez zespoły rozwojowym i operacji. Dlatego należy traktować automatyzację, jako część DevOpsa, a nie jako całą metodologię. To zdecydowanie przybliży do sukcesu całego projektu.

Ignorowanie audytów i regulacji prawnych

Wdrożenie DevOps w naturalny sposób koncentruje się na działach rozwojowym i operacji. Jednak nie można zapominać o pozostałych, ponieważ nawet najlepiej dopracowany plan może lec w gruzach, kiedy przyjdzie do przeprowadzenia audytów zgodności z regulacjami. W tym miejscu często popełnianym błędem jest myślenie: jeśli coś, co właśnie tworzymy, działało w innych okolicznościach, w naszym przypadku również przejdzie audyty.

Dobrym pomysłem jest jak najwcześniejsze zaangażowanie w projekt osób odpowiedzialnych za przeprowadzenie audytów. Warto pytać się o ich opinie na temat konkretnych technologii i procesów czy wskazanie newralgicznych punktów. Przydaje się również opinia audytorów na temat planowanych działań – czy mają szansę przejść audyt.

Brak elastyczności

Pierwszym krokom na drodze w kierunku DevOps najczęściej towarzyszy entuzjazm napędzany wizją czekających korzyści. Wszystko chce się robić ściśle według nowych reguł, a wszelki opór bezwzględnie zwalczać. Nie jest to dobre podejście do utrzymywania centrum danych. W praktyce reguły DevOps należy traktować jako wytyczne, a nie jako aptekarskie receptury, których trzeba się trzymać. Każda organizacja jest unikalna. Kultura, technologia i procesy różnią się i trzeba to brać pod uwagę przy wprowadzaniu DevOpsa.

Jeśli potraktuje się DevOps jako okazję do zastąpienia przestarzałych procesów, to dobrze. Trzeba upewnić się, że ten projekt nie polega na przykrawaniu organizacji do założeń DevOps, ale raczej na optymalizowaniu tych założeń tak, żeby dobrze służyły firmie.

Przecenianie DevOps

Zdarza się, że DevOps jest przedstawiany jako rozwiązanie wszystkich firmowych problemów. Pracownicy staną się szczęśliwi, produktywność wzrośnie, spadną koszty, a systemy IT przestaną się psuć. Jeśli takim językiem, który obiecuje zbyt dużo, przedstawi się przejście na nowy proces, zarząd będzie rozczarowany, niezależnie od faktycznych korzyści, jakie przyniesie DevOps. Podczas rozmów z biznesem na temat DevOps należy pozostać realistą do co efektów, jakie może przynieść ta metodologia. Zawsze lepiej nie doszacować korzyści, a później dostarczyć więcej, niż odwrotnie.

Zapominanie o kulturze organizacji

Wiele osób podchodzi z rezerwą do terminu „kultura korporacyjna”, jednak każda firma ma swoją specyfikę, to, jak podchodzi do wyzwań, jak podejmuje decyzje, jak rozwiązuje problemy między działami. Zmierzając w kierunku DevOps, ignorowanie tych różnic jest nieodpowiedzialne. Podobnie, jak trzeba dostosować DevOpsa do procedur i procesów stosowanych w organizacji, tak samo organizacja musi przyjąć DevOpsa. Oczywiście, potrzebna jest komunikacja między działami. Zamiast jednak przejmować reguły komunikacji stosowane przez kogoś innego, lepiej wykorzystać standardy komunikacji już stosowane w organizacji.

Jeśli firma wypracowało już metody współpracy między działami, lepiej jest wykorzystać już te osiągnięcia, niż próbować je porzucić. Zawsze należy mieć na uwadze kulturę korporacyjną przy wprowadzaniu zmian. To jedyny sposób, aby ukończyć projekt z sukcesem.

Ignorowanie informacji zwrotnych

Komentarze i wszelka informacja zwrotna są bardzo ważne podczas wprowadzania tak istotnych zmian, jak DevOps. Kwestią do ustalenia pozostaje, jak szeroko chce się zbierać takie informacje. Jeśli ograniczy się tylko do działów rozwoju i operacji, można całkowicie przeoczyć, jak pozostała część organizacji reaguje na wprowadzane zmiany.

Taka ignorancja, szczególnie w dużych organizacjach, to najgorsza sytuacja, w jakiej mogą znaleźć się osoby odpowiedzialne za rozwój i operacje. Aby jej uniknąć, należy zaangażować działy biznesowe w ocenę projektu, zarówno na etapie planowania, jak i wdrożenia.