W trakcie awarii usług świadczonych przez firmę Amazon w 2012 roku[1], która wpłynęła na działanie takich serwisów internetowych jak Redit, czy Imgur nikt z pracowników nie musiał dotykać firmowych urządzeń. Nikt nie biegał od serwera do serwera, aby sprawdzać jego działanie, co też z racji rozproszonych lokalizacji byłoby praktycznie niemożliwe. Ta sytuacja pokazuje jak dzisiejsze operations różni się od tego sprzed dwudziestu, trzydziestu lat. Mamy zdecydowanie mniej pracowników w roli utrzymaniowej, a liczba serwerów przypadających na jedną osobę jest zdecydowanie większa. W związku z tym nastąpiło również przesunięcie części kosztów z działów operacyjnych do działów rozwoju. Mimo tego główny cel pozostał nie zmieniony. Usługi świadczone klientom muszą pozostać na oczekiwanym poziomie. Nie jest jednak kluczem do sukcesu całkowite przeniesienie specjalistów utrzymania do działów rozwoju. Nawet najlepszy programista nie jest w stanie zagwarantować, że jego oprogramowanie będzie odporne na wszystkie możliwe zakłócenia w działaniu. Najważniejszym aspektem jest to, aby nie pozwalać developerom odciąć się od konsekwencji ich pracy i potencjalnych błędów, które popełnili w trakcie pisania kodu. Prowadzi to do budowania i poszerzania odpowiedzialności w firmie świadczącej usługi IT już nie tylko w ramach ich eksploatacji, ale również rozwoju.

źródło: http://devopscube.com
źródło: http://devopscube.com

Dzielenie się odpowiedzialnością ma także inne zalety. Dotychczasowo developerzy odpowiedzialni byli za swoją pracę tylko do momentu wdrożenia zmiany. Od momentu pojawienia się aplikacji na środowisku produkcyjnym za wszystkie błędy odpowiadali operatorzy. W przypadku pojawienia się incydentu często dochodziło do sytuacji wzajemnego obarczania się stron, czy wytykania palcem popełnionych błędów. Jedni mówili o złym kodzie, który zawiera dziury, drudzy o nieprawidłowym wdrożeniu, czy nieodpowiednim przygotowaniu do implementacji zmiany. W efekcie pracy w oparciu o DevOps zespoły przy wykorzystaniu dostępnych procesów i narzędzi mogą współpracować przy rozwiązywaniu incydentów i problemów. W wyniku tej pracy i zebranych doświadczeń powstają jeszcze lepsze aplikacje, jeszcze bardziej odporne na zakłócanie ich pracy. Zatem zamiast budować kolejne procedury, które jako podstawę swojego działania zakładają udział ludzi, buduje się takie rozwiązania, które systemowo pozwalają się zabezpieczyć przed codziennymi przerwami w działaniu.

[1] Por. B. Butler, Amazon EBS failure brings down Redit, Imgur, others, Network World, 2012