Plusy / minusy przerwania przepływu pracy DevOps?

Próbuję ocenić, czy dobrym pomysłem jest odejście od przepływu pracy w stylu devops do tradycyjnych programów typu dev-then-ops (nie jestem pewien, jak to nazywasz).

Jesteśmy małym 5-osobowym działem zamkniętym w 4000-osobowej firmie zajmującej się mediami tradycyjnymi (np. Nie-programową). Dwa lata temu zaczęliśmy budować oprogramowanie, aby umożliwić naszemu działowi znaczne zwiększenie produkcji. Odnieśliśmy duży sukces i większa firma zaczyna zauważać. Do chwili obecnej ponosiliśmy wyłączną odpowiedzialność za zaprojektowanie, rozwój i wdrożenie platformy, która stała się platformą mikrousług AWS ~ 10. Nasz zespół nie identyfikuje się jako DevOps, ale bez wątpienia żyjemy życiem DevOps, a każdy programista dokładnie zna zarówno kod, jak i system, na którym działa.

Jednym z pytań, na które wkrótce odpowiemy, jest to, jakie „wydajności” są dzielone między nami a działem IT naszej firmy macierzystej. Nasz właściciel projektu zwykle woli outsourcing niż kształcenie wewnętrzne, więc w naszym przypadku te wydajności prawdopodobnie oznaczają, że jak najwięcej pracy informatycznej „zejdziemy z siebie”. Obecnie powiedziałbym, że nasz zespół ma 70/30% podział między doświadczeniem w kodowaniu a infrastrukturą. Dział IT jest solidnie związany z branżą IT, bez widocznego przejścia do tworzenia oprogramowania.

Nasz właściciel projektu (osoba nietechniczna) ma nadzieję, że przekazując jak najwięcej pracy zespołowi IT, zobaczymy wzrost wydajności o ~ 1: 1 za każdą godzinę pracy, którą straciliśmy. Jestem jednak sceptycznie nastawiony do tego. Nasz produkt jest jeszcze w fazie wstępnej (mimo że jest już znaczącym zasobem biznesowym), a przy naszym ograniczonym doświadczeniu z działem IT zwykle występują znaczne opóźnienia w rzeczach tak prostych, jak zmiany uprawnień systemu plików.

W tej chwili moim idealnym rozwiązaniem byłoby, aby dział IT „nas” przyjął i pozwolił nam kontynuować wdrażanie własnej pracy, przy jednoczesnym zapewnieniu, że spełniamy standardy i wymagania biura IT. Nie jestem jednak pewien, jak realistyczne to jest. Co więcej, jest to prawie odwrotne podejście, które popiera nasz właściciel projektu, ponieważ dodałoby to dodatkowe operacje operacyjne w krótkim okresie.

W naszej sytuacji, jakie są prawdopodobne zalety / wady pozostania przy podejściu DevOps, a nie przekazywanie IT?

To nie jest dobry pomysł.

Z mojego doświadczenia wynika, że ​​zyskasz wady obu, podczas gdy jakiekolwiek przewidywane korzyści w jakiś sposób się nie urzeczywistnią.

Szczegółowy:

1. Stracisz prędkość.
   IT będzie przestrzegać własnego standardu. Nowe zadanie (dla nich) będzie zgodne z tym samym „powolnym” szablonem, jaki ma teraz ich praca. Przygotuj się, będą stanowić wyzwanie - więc nawet mniej prędkości niż standardowe proste czynności.
2. Nie uda ci się rozładować.
   Będą się na was opierać w przypadku każdej anomalii. Dołożycie wysiłku, aby przyspieszyć jednego faceta - a teraz będziecie powtarzać siebie, ponieważ w następnym zadaniu / problemie / dniu znów pojawi się nowy facet.
3. Dokumentacja będzie wymagana, ale nie pomoże.
   Ponownie zachowanie szablonu będzie polegało na tym, że krótkie podręczniki nie wychwycą każdej anomalii, a dokładne teksty nie będą czytane za zbyt długo. Tak więc każda inwestycja będzie stratą, podobnie jak ogromny wysiłek potrzebny do wdrożenia ulepszeń, aby Twoje narzędzia były jak najmniejsze.

I na koniec, wszelkie problemy będą dotyczyć was. Smoła, zasada tarbrush.

Jeśli powyższe brzmi cynicznie, cóż, obawiam się, że tam byłem. Wielokrotnie.

Co zamiast tego zrobić?

Idź na zakupy do działu IT, znajdź przydatnego kandydata i pozwól temu facetowi „pożyczyć”, aby zwolnić cię z pracy.

W odpowiedzi na ankietę DevOps znajdziesz wiele odpowiedzi, o które powinieneś poprosić właściciela produktu. Jest to dokument napisany specjalnie dla ludzi biznesu o małej wiedzy technicznej, rozmawiających w terminach, które powinien zrozumieć.

Średnio będziesz potrzebował 1 dodatkowego programisty na 4 osoby, aby utrzymać ten sam poziom rozwoju funkcji (38% vs 49% czasu poświęconego na nową pracę). Twój średni czas powrotu do zdrowia po awarii spadnie nawet 25 razy. Twoja praca będzie o 20% mniej przyjemna i będziesz miał 40% szans na polecenie swojej pracy znajomemu. Te trzy fakty powinny wystarczyć.

To, co stracisz, dopasowując się do organizacji IT, to część „Dev” Twojego małego zespołu DevOps. Kiedy zespoły dzielą się na sztuczne role NetOps, SysOps i Dev, wprowadzasz następujące problemy:

1. Niepotrzebna biurokracja i izolacja - Aby cokolwiek zrobić, programiści będą musieli przesłać zgłoszenie do działu IT i poczekać na ich wdrożenie. Nie będą już mogli sami zaimplementować go i wchodzić w interakcje - aż do instancji deweloperów i kontroli jakości, co ograniczy infrastrukturę, którą mogą kodować. Utknęli na barierze VM, zamiast móc kodować na pełnym stosie. Jeśli to, co przesyłają do IT, wygląda jak kod DevOps, będą źle przygotowani do obsługi tego i mogą wrócić do ręcznego wdrażania.
2. Zaniedbanie - Alternatywnie, mogą po prostu wdrożyć go takim, jaki jest, a następnie zaniedbać bestię, ponieważ nie wiedzą, jak z nią współpracować - i nie są programistami, więc kod nie jest ich problemem.
3. Przerwy - Jedną z często pomijanych zalet DevOps jest jego charakter programowy. Oczywiście wdrożenie tego serwera może potrwać dłużej, traktując go jak kod, ale to automatyzuje ludzkie błędy. Sposób, w jaki przeszedł do dev, to sposób, w jaki przejdzie on do kontroli jakości / Test to sposób, w jaki przejdzie do prod, zmniejszając w ten sposób przestoje. Gdy programiści tracą dostęp do sprzętu sieciowego, muszą wdrożyć swoją usługę lub infrastrukturę obliczeniową, nie tylko zajmuje to dłużej, ale wprowadza bardziej omylnych ludzi, co spowoduje więcej przestojów.
4. Dokumentacja - W pewnym sensie kod DevOps jest samodokumentowaniem. Wiesz, w jaki sposób serwer został zbudowany i wdrożony, ponieważ kod mówi ci. Za 5 lat, kiedy nadejdzie czas aktualizacji do CentOS 8 lub cokolwiek innego, nikt nie będzie już wiedział, jak wdrożyć twoją aplikację - w tym w warstwie sieci, pamięci, monitorowania i tworzenia kopii zapasowych.

Krótko mówiąc, powinieneś zasugerować, aby właściciel projektu poświęcił czas na przeczytanie The Mythical Man-Month, aby zdezorientować go, że zobaczysz relację wydajności 1: 1 i The Phoenix Project, który jest dobrze powieściowany (i zabawne) ilustracja tego, co zyskuje się i traci dzięki użyciu DevOps w nietechnicznym języku dla osób nietechnicznych. Jeśli właściciel projektu ma jakikolwiek dojazd, dostępna jest audiobooka The Phoenix Project.

Sugerowałbym, abyś przyjął część zespołu IT i przeszedł gruntowne szkolenie w nowym systemie.

Kiedy już w pełni zrozumieją system, sensowne jest odebranie go im.

W przeciwnym razie staniesz się Centrum Wsparcia dla IT - i będziesz spędzał dużo czasu na gaszeniu pożarów, gdy uczą się zawiłości nowego systemu.