DevOps as a Service — kiedy się opłaca i ile kosztuje

DevOps as a Service to model, w którym firma korzysta z pracy inżyniera DevOps zewnętrznego dostawcy — rozliczanej za wykorzystany czas — zamiast budować własny zespół infrastruktury. Inżynier konfiguruje i utrzymuje środowiska chmurowe, automatyzuje wdrożenia, dba o monitoring, kopie zapasowe i bezpieczeństwo oraz reaguje, gdy produkcja przestaje działać.

Warto odróżnić ten model od klasycznego helpdesku. W dobrze zorganizowanym DevOps as a Service pracuje z Tobą konkretna osoba, która zna Twój system i Twój stos technologiczny. W modelu zgłoszeniowym każdy problem trafia do kolejki, a osoba, która go podejmuje, często zaczyna od czytania historii od nowa. Przy awarii produkcji ta różnica liczy się w godzinach.

Liczby z raportu (Just Join IT) to tylko punkt wyjścia. Przy umowie o pracę do wynagrodzenia brutto dochodzą koszty po stronie pracodawcy, sprzęt, szkolenia i czas rekrutacji. Ważniejsze od samej stawki jest jednak pytanie: ile pracy infrastrukturalnej faktycznie masz w każdym miesiącu?

W wielu firmach wygląda to nierówno. Konfiguracja środowisk, migracja do chmury czy wdrożenie automatycznych wdrożeń to okresy intensywnej pracy. Potem przychodzą miesiące, w których wystarczą aktualizacje, przegląd kosztów chmury i reagowanie na incydenty. Pełny etat opłaca się przy stałym, dużym obciążeniu. Przy obciążeniu falującym płacisz za dostępność, której przez większość czasu nie wykorzystujesz.

Drugie ograniczenie jednej osoby na etacie to ciągłość. Ta osoba ma urlop, choruje i musi odpoczywać — a awaria nie czeka. Całodobowy dyżur wymaga rotacji kilku osób, a kompetencje zamknięte w głowie jednego pracownika to ryzyko przy każdym jego odejściu.

Poziomy usług (SLA). Czas reakcji i czas naprawy dla incydentów o różnej wadze. Rozróżnij je wprost: czas reakcji mówi, kiedy ktoś zajmie się problemem, a czas naprawy — kiedy system znów zadziała. Umowa gwarantująca tylko reakcję gwarantuje niewiele.

Zasady dyżuru. W jakich godzinach i dniach obowiązuje, jakim kanałem zgłaszasz awarię i czy dyżur jest wliczony w stawkę, czy rozliczany osobno.

Raportowanie godzin. Przy rozliczeniu godzinowym — raport z opisem prac, najlepiej co tydzień lub przy każdej fakturze. Sprawdź też, co dzieje się z niewykorzystanymi godzinami.

Własność kont i dostępów. Konta w chmurze powinny należeć do Twojej firmy, a inżynier powinien dostać uprawnienia potrzebne do pracy — nie więcej.

Dokumentacja i zakończenie współpracy. Aktualna dokumentacja infrastruktury i procedury awaryjne to warunek, żeby w razie zmiany dostawcy nikt nie zaczynał od zera.

Szerzej o zapisach chroniących firmę zamawiającą piszemy w tekście umowa z software house'em — co musi się w niej znaleźć.

Dobra współpraca DevOps powinna dać się zmierzyć. Punktem odniesienia są wskaźniki opisywane przez program badawczy DORA, który od lat analizuje skuteczność dostarczania oprogramowania. Należą do nich m.in.:

• częstotliwość wdrożeń — jak często zmiany trafiają na produkcję,
• czas realizacji zmiany — ile mija od zmiany w kodzie do jej wdrożenia,
• odsetek wdrożeń kończących się problemem — ile wdrożeń wymaga poprawek lub wycofania,
• czas przywrócenia działania po nieudanym wdrożeniu.

Do tego warto dodać dwa wskaźniki biznesowe: miesięczny koszt chmury i liczbę przestojów odczuwalnych dla klientów. Jeśli po kilku miesiącach żaden z tych wskaźników się nie poprawia, masz rzeczową podstawę do rozmowy z dostawcą.

U nas pracuje z Tobą konkretny inżynier DevOps, który zna Twój system i pracuje na Twoim stosie — AWS, Azure lub Google Cloud. Rozliczamy się za godziny wykorzystane w danym miesiącu: bez minimum, bez progów wejścia i bez umowy na rok z góry, a niewykorzystane godziny przechodzą na kolejny miesiąc. Przy awarii produkcji reagujemy w ciągu godziny, w ramach dyżuru całodobowego.

Dla agencji i software house'ów pracujemy w modelu white label — z NDA i zakazem konkurencji wobec ich klientów. Szczegóły i zakres usług znajdziesz na stronie DevOps.