Dlaczego rozwój sprzeciwia się operacjom?

Nadal jestem studentem, ale nie mam wiedzy na temat operacji, a mój angielski jest nadal zły.

Moje pytanie brzmi: dlaczego rozwój sprzeciwia się operacjom ? Kiedy rozwijanie się sprzeciwia się operacjom?

Sedno DevOps polega na tym, że rozwój nie powinien przeciwstawiać się operacjom, lecz powinny się wspierać.

Tradycyjnie, z powodu wdrożeń kaskadowych i aktualizacji na dużą skalę, rozwój spowodowałby wiele problemów operacyjnych podczas wdrażania z powodu nieodpowiednich testów, zmiany środowisk serwerów, lista jest długa. Zasadniczo aktualizacje były zbyt duże, aby zespół operacyjny mógł je skutecznie wdrożyć bez problemów związanych z procesem. Te problemy mogą być powodem, dla którego uważasz, że rozwój sprzeciwia się operacjom .

Z drugiej strony DevOps działa w celu zmniejszenia rozmiaru aktualizacji, zmniejszenia sztywnych środowisk i ogólnie poprawy przekazywania aplikacji między programowaniem a operacjami poprzez zwiększenie liczby przypadków, w których przekazywanie odbywa się każdego roku. Wraz ze wzrostem liczby wdrożeń zmniejsza się ból głowy związany z operacjami, ponieważ albo zautomatyzowały one dużą ilość pracy wymaganej do aktualizacji produktów, albo lepiej przewidują i przygotowują się do aktualizacji.

Tldr: DevOps ma na celu zniesienie teorii, że rozwój przeciwstawia się operacjom poprzez stworzenie sposobu myślenia, w którym operacje i programowanie współpracują ze sobą, aby często wdrażać produkty w sposób terminowy i łatwo powtarzalny.

Myślę, że otrzymałeś już wyczerpujące odpowiedzi, ale powiedziałeś, że twój angielski nie jest świetny, więc postaram się udzielić bardzo krótkiej i zrozumiałej odpowiedzi:

• Podstawowym celem rozwoju jest wprowadzanie zmian.
• Podstawowym celem operacji jest utrzymanie stabilności środowiska.

Te dwie rzeczy są sprzeczne. To powiedziawszy, rozwój i operacje nie powinny się przeciwstawiać. Powinny one współpracować, aby zapewnić osiągnięcie obu celów. Taki jest cel DevOps.

Napięcie między rozwojem a działaniami jest często spowodowane niedopasowaniem zachęt i próbami optymalizacji w zespole.

Programiści są często oceniani na podstawie szybkości i liczby problemów, przez które mogą sobie poradzić i scalonych w repozytorium kodu, a ich nagroda często nie jest powiązana z tym kodem, który faktycznie działa lub działa poprawnie. Znacznie mniej skalowania, wydajności i innych czynników.

Działania są często oceniane na podstawie stabilności środowiska i tego, jak dobrze kod działa w środowisku produkcyjnym, ale rzadko na jakości procesu szybkiego wprowadzania zmian.

Stwarza to problem polegający na tym, że programiści są zachęcani do tworzenia dużej ilości kodu i rzucania go ponad ścianę do zespołu operacyjnego, a zespół operacyjny ma motywację do akceptowania jak najmniejszych zmian, aby zapewnić stabilność środowiska.

DevOps jest w pewnym sensie zestawem rozwiązań tego problemu:

• Niektóre z nich mogą mieć charakter organizacyjny, a procesy i zachęty zespołów mogą się zmieniać. Na przykład, jeśli praca programistów jest oznaczona jako wykonana tylko wtedy, gdy jest uruchomiona w produkcji przez pewien czas, nie było żadnych problemów i zespół operacyjny zgadza się przejąć na własność kod. Podobnie operacje można oceniać bardziej na podstawie szybkości, z jaką kod jest akceptowany, podczas gdy środowisko jest nadal w pewnych granicach stabilności.
• Inną częścią rozwiązania może być komunikacja i cross-polination, gdzie osadzasz ludzi operacyjnych w zespole programistów i odwrotnie. Przełamujesz mur między tymi zespołami, a inżynierowie DevOps są często wynikiem tego rodzaju mostkowania.
• Narzędzia wspierające procesy takie jak Continuous Integration i Continuous Deployment to kolejna część rozwiązania, która może zwiększyć szybkość zmian, zachowując jednocześnie wysoką jakość i szybkie odzyskiwanie środowiska produkcyjnego w przypadku jakichkolwiek problemów poprzez wycofanie kodu lub szybki postęp naprawy do produkcji.

Większość organizacji radzi sobie ze złożonością, dzieląc swoją organizację na części funkcjonalne i żądając, aby każda część wymyśliła, jak się poprawić. Jest to często nazywane podejściem „silosowym”.

Ważne jest, aby zrozumieć, dlaczego to podejście silosowe blokuje sukces firmy i często nie udoskonala organizacji jako całości. I nie wpływa tylko na rozwój i operacje - wpływa na wszystkie inne funkcjonalne silosy w dużej organizacji, takie jak zespół zapewnienia jakości, finanse, zarządzanie produktami i projektami.

Ponieważ menedżerom każdego funkcjonalnego silosu nakazuje się poprawę poprzez obniżenie kosztów lub zwiększenie prędkości, ich reakcja jest często:

• Jestem całkowicie przytłoczony problemami związanymi z naprawą po ostatnim ulepszeniu. Zostaw mnie w spokoju.
• Co chcesz, abym robił, wypełniał moje obowiązki lub pracował nad projektami usprawniającymi? Nie mam czasu robić obu rzeczy.
• Nie znowu! Nadchodzi kolejny program miesiąca.

Przy tych typowych reakcjach, jakikolwiek kierownictwo podejmujący niewielki wysiłek ulepszenia rzadko jest witany z entuzjazmem. Menedżerowie stają w ostrej konkurencji z innymi obszarami funkcjonalnymi o zasoby potrzebne do wprowadzenia ulepszeń. Nic więc dziwnego, że polecenie poprawy nasila interdyscyplinarne bitwy!

Nawet gdy kierownik zakończy swoją część projektu doskonalenia, spotyka inne obszary funkcjonalne i inne organizacje (dostawców, kontrahentów itp.), Którzy nie wykonali swojej pracy. To zmniejsza lub całkowicie neguje wyniki.

To napięcie międzyfunkcyjne nie ogranicza się do wysiłków na rzecz poprawy. Jest to sedno codziennego podejmowania decyzji i oceny skuteczności zarządzania w całej organizacji. Oto jeden prawdziwy przykład:

Menedżerowi finansowemu powiedziano „popraw”. Postanowił zablokować zatrudnianie wykonawców, którzy kosztują więcej niż nominalna cena akceptowana na rynku. Wdrożył nową politykę i twierdził, że w tym roku zaoszczędził milion dolarów. Ponieważ programiści i dział IT nie mogą zatrudnić kontrahentów, aby pomóc im w korzystaniu z kontenerów i organizacji kontenerów, ponieważ ci kontrahenci są kosztowni. Kierownik działu IT w tej samej firmie obliczył, że brak poprawy infrastruktury kosztował firmę znacznie ponad 100 000 USD dodatkowych kosztów każdego miesiąca. Przy takim tempie roczne oszczędności na zatrudnianiu kontrahentów zostały zużyte przed końcem roku.

Możesz sobie wyobrazić, że związek między tymi dwoma obszarami funkcjonalnymi nie był tak naprawdę miłosny.

Te konflikty międzyfunkcyjne są oparte na podejściu silosowym, w którym organizacja mierzy każdy silos w celu ulepszenia niezależnie. Jeśli jesteś centrum kosztów, poprawa oznacza oczywiście większą wydajność lub redukcję kosztów w silosie.

W tych ramach odniesienia koszty uznaje się za przestrzeganie zasady „dodatku”. Zsumowane koszty każdego silosu są równe całkowitemu kosztowi organizacji. Dlatego menedżerowie postrzegają każdą redukcję kosztów w swoim obszarze jako „dobrą”, ponieważ widzą bezpośrednie przełożenie na oszczędności kosztów dla firmy jako całości. W tym układzie odniesienia wysiłki usprawniające są rozłożone wszędzie, aby atakować koszty i marnotrawstwo w całej organizacji.

Świetny przykład, kiedy zespół programistów zaczyna pracować zwinnie i wypycha kod do kontroli jakości i operacji co dwa tygodnie zamiast co kwartał, jak kiedyś. Kontrola jakości i operacje nie są gotowe na taką zmianę i są obwiniani za zwolnienie. Ponownie, nie ma to większego wpływu na miłość między ludźmi w rozwoju i działalności.