Jakie są typowe oznaki i sygnały braku zespołu DevOps? Jak uzasadniłbyś / wyjaśniłbyś prośbę o dodanie nowego zespołu?

Chciałbym zachować ogólne pytanie, ale oto kilka dodatkowych informacji:

Obecnie mamy 2 specjalistów DevOps pracujących razem jako zespół, ale wymagania, ilość i złożoność produktów rosną. Zastanawiamy się, czy poprosić o nowy zespół, ale mamy trudności z wyjaśnieniem i udowodnieniem, dlaczego byłby to dobry pomysł.

Są cztery główne powody, dla których możesz czuć, że twój zespół ma za mało personelu:

1. Zła organizacja i planowanie pracy
2. Wykonywanie pracy, którą powinien wykonywać ktoś inny
3. Robienie pracy, której wcale nie należy wykonywać
4. Faktycznie brakuje personelu

Zacznij od przeglądu pierwszych trzech punktów. Przeczytaj projekt Phoenix na temat pomysłów, jak zrobić pierwszy. Zadaj sobie pytanie o każde zadanie, któremu komukolwiek pomożesz, czy powinno ono być w ogóle wykonane i czy to ty powinieneś wykonywać to zadanie, czy też po prostu pozwól komuś, kto go wykona, aby zrobił to sam. To da ci dokumentację, dlaczego cała twoja praca jest konieczna.

Następnie przejrzyj cztery rodzaje prac wspomniane w projekcie Phoenix:

1. Projekty biznesowe - co robisz dla innych zespołów w organizacji
2. Projekty wewnętrzne - co robisz, aby ułatwić Ci pracę w przyszłości
3. Zaplanowana konserwacja - co robisz, aby włączyć światła
4. Nieplanowane przerwy - co robisz, ponieważ coś poszło nie tak

Jeśli praca twojego zespołu jest zrównoważona, poświęcisz mniej więcej tyle samo czasu na każdą z czterech. Jeśli nieplanowana praca zaczyna pełzać blisko do 50% twojego czasu, jest to znak, że masz zdecydowanie za mało personelu.

Powinieneś być w stanie zatrudnić około jednej osoby przed nieplanowaną pracą, która osiągnie 25% twojego czasu, w przeciwnym razie jedna osoba odchodząca wyśle ​​cały zespół na obroty ogonem, z których nigdy nie wyzdrowiejesz. Przeszacowanie ludzi i technologii ma te same przyczyny i zalety.

Tło: Oprócz zapewniania wsparcia dla naszej obecnej infrastruktury i naszych programistów, jako zespół DevOps planujemy co miesiąc, co chcemy osiągnąć, oprócz pomocy zespołom deweloperów w sprintach i nowych projektach, które są uruchamiane. Jednak w ciągu miesiąca często zauważamy dodatkowe rzeczy, które należy zrobić i ulepszyć, które następnie dodajemy do naszego zaległości. Jesteśmy również odpowiedzialni i pomagamy w różnych innych sprawach, które wykraczają poza nasz zakres, ale pomagamy biznesowi, gdybyśmy mogli :)

Odpowiedź : Gdy tylko zauważysz, że nie zbliżasz się do wielu zadań, a zwłaszcza ich konserwacji, odkładasz je na później, myślę, że to dobry wskaźnik (z tego, czego doświadczyłem). Ponadto, im więcej nowych projektów i zespołów programistycznych, które są cieńsze, zespół DevOps się rozprzestrzenia, tym więcej ludzi będzie potrzebnych.

Bardzo łatwo jest po prostu złapać się na codzienne wykonywanie zadań, ale uważam, że to bardzo ważne (nawet raz w miesiącu), aby cofnąć się i ocenić to.

W rzeczywistości biorę stronę z Podręcznika SRE na ten temat, co moim zdaniem jest bardzo istotne. Specjalizacje DevOps nie powinny rosnąć poziomo w organizacji. Raczej, jeśli widzisz, że rzeczy się nie załatwiają, oznacza to, że nie dajesz odpowiednich uprawnień programistom do samoobsługi.

Oceń swoje procesy i zobacz, jak dopasowują się one do powszechnie przyjętych zasad DevOps i jak postępujesz zgodnie z najlepszymi praktykami branżowymi.

Zakładam, że ten zespół dwóch osób przechodzi od projektu do projektu i tworzy tam rzeczy DevOps (tworzenie potoków CI / CD, wspieranie innych twórców tworzących pliki Docker lub dowolną używaną technologię). Innymi słowy, wpisz 3, 4, 5 lub 6 zgodnie z http://web.devopstopologies.com/ .

W tym przypadku oznaką niedoboru jest po prostu zbyt duże obciążenie pracą dla tych dwóch; zbyt wiele projektów żądających ich usług; za dużo biletów; z biegiem czasu; stres, wypalenie zawodowe. Czynniki te powinny stanowić wystarczający powód do odpowiedzialnego przywództwa, aby zwiększyć możliwości. Nie widzę w tym znaku specyficznego dla DevOps, jest to po prostu funkcja, której brakuje personelu.

Kolejny znak, aby coś zmienić, to jeśli przyjrzysz się uważnie i zauważysz, że tworzysz „silos DevOps”, w którym cała wiedza DevOps skupia się na tych dwóch facetach / dziewczynach, a wszyscy inni odchylają się, ponieważ ci dwaj „robią DevOps”. Nie o to chodzi w DevOps. W takim przypadku zastanów się nad aspektem kulturowym i zmodyfikuj go, aby był więcej ewangelistów / nauczycieli / trenerów dla innych zespołów.

W obu przypadkach głębszy powód, dla którego posiadanie DevOps na pierwszym miejscu jest dobrą rzeczą (ogólne dobre rzeczy), powinien być jasny dla wyższej kadry kierowniczej. Jeśli nie możesz przekazać tej wiadomości, zmniejsz skalę pracy, którą wykonuje Twój zespół, przenosząc ją na zwykłych Devs / Ops (tak jak powinno być w każdym razie).

Byłem pod wrażeniem, że DevSecOps był nastawieniem, a nie zespołem - jeśli masz „zespół Dev (Sec) Ops”, robisz to źle… Próbuję owinąć głowę, umieszczając dwóch „DevOps Engineers” razem i nazywając ich „zespołem DevOps”.

Mamy zespoły programistów, SCM, bezpieczeństwo aplikacji i inżynierów systemów, którzy pracują w tandemie nad szybkim wdrożeniem / wydaniem modelu w celu przekazywania kodu i zmian konfiguracji / systemu do określonego punktu końcowego - etapowego lub produkcyjnego

Nie ma to nic wspólnego z żadnym inżynierem „devOps” jako takim.

Grupowanie zadań

Podejście, które stosowaliśmy w przeszłości w podobnych sytuacjach, polega na zorganizowaniu pracy zespołu w 4 głównych grupach zadań i przydzieleniu ekwiwalentu 2 pełnych etatów (ekwiwalentów pełnego czasu pracy) do (próby) wykonania tych zadań. W naszym przypadku było to związane z uruchomieniem pomocy SCM w środowisku mainframe, przy czym około 300 programistów prosiło o wszelkiego rodzaju pomoc / interwencje z tych 2 FTE. Grupy zadań są podzielone na 4 możliwe priorytety:

• Zadania o priorytecie 1 i 2 muszą zostać zakończone (nie ma wymówek / negocjacji)
• Zadania o priorytecie 3 należy wykonać „ tak szybko, jak pozwala na to czas”.
• Zadania o priorytecie 4 należy wykonać „ jeśli czas na to pozwala”.

Czytaj dalej, aby uzyskać więcej informacji o rodzaju zadań w każdej z tych 4 grup ...

Opisy zadań

Priorytet 1 - Obsługuj dział pomocy technicznej

• Przez ekspertów, którzy są łatwo dostępni i zawsze dostępni.
• Przez telefon, e-mail lub system biletowy w godzinach pracy.
• Zgodny z predefiniowanymi umowami SLA.
• Rejestracja wszystkich zgłoszeń do pomocy technicznej na podstawie ITIL z okresowym raportowaniem wszystkich połączeń.
• Zastosuj awaryjne dostosowania (obejścia) w przypadku krytycznych problemów.

Priorytet 2 - Usługi służby wachtowej

• Dostępność przez całą dobę, 7 dni w tygodniu.
• Zgodny z predefiniowanymi umowami SLA.
• Raportowanie wszystkich wezwań do pełnienia wacht.
• Eskalacja zarządzania w razie potrzeby.

Priorytet 3 - Rutynowa konserwacja

• Podawanie.
• Wejście na pokład.
• Gospodarowanie.
• Ulepszenia wydajności.
• Zarządzanie przestrzenią.
• Strojenie zużycia zasobów.
• Zaproponuj ulepszenia dostosowań, aby zmniejszyć liczbę zgłoszeń do pomocy technicznej i / lub obserwować interwencje służbowe.

Priorytet 4 - Poprawki i ulepszenia

• Twórz i utrzymuj dokumentację użytkownika.
• Testowanie jakości nowych dostosowań.
• Opracowuj i wdrażaj żądania ulepszeń.
• Weź udział w testach DRP.

Ocena

Jeśli korzystasz z podejścia opisanego powyżej, mogą zacząć się pojawiać różne rzeczy:

• Jeśli zespół ma za mało personelu, prawdopodobnie większość czasu przejdzie na zadania o priorytecie 1 i 2, a uzyskanie zadań o priorytecie 3 może trochę potrwać ... a zadania o priorytecie 4 mogą cierpieć głód (wydaje się, że nigdy nie będzie czasu na te zadania).
• Im więcej czasu (staje się) dostępnego na „ inwestowanie ” w zadania o priorytecie 4, tym więcej czasu potrzebnego na zadania o priorytecie 1 i 2 zostanie zmniejszone, dzięki czemu można „zainwestować” jeszcze więcej czasu (z dostępnego budżetu 2 EPC) „w zadaniach o priorytecie 4.
• Będziesz zaskoczony, gdy zobaczysz, jak po pewnym czasie liczba zadań o priorytecie 1 i 2 spadnie. A jeśli odpowiednio raportujesz o tych zadaniach, kierownictwo uwielbia to słyszeć. W naszym przypadku liczba ta spadła z około 300 / miesiąc do poniżej 100 / miesiąc ...
• Jeśli jednak wydaje się, że 2 EPC nigdy (lub prawie nie mają) czasu na zadania o priorytecie 4, masz doskonałe wyjaśnienie i dowód na zarządzanie ... że masz za mało personelu.