Jak przekonać programistów w moim zespole, by przyjęli „Ty budujesz, uruchamiasz”?

Jak przekonać programistów w moim zespole, by przyjęli „Ty budujesz, uruchamiasz”? W związku z tym mam na myśli cytat Wernera Vogelsa :

Przekazanie programistom obowiązków operacyjnych znacznie poprawiło jakość usług, zarówno z punktu widzenia klienta, jak i technologii. Tradycyjny model polega na tym, że przenosisz swoje oprogramowanie na ścianę oddzielającą programowanie i operacje, odrzucasz je, a potem o nim zapominasz. Nie w Amazon. Budujesz, uruchamiasz. Dzięki temu programiści mają kontakt z codziennym działaniem swojego oprogramowania. Umożliwia im także codzienny kontakt z klientem. Ta pętla informacji zwrotnych od klientów ma zasadnicze znaczenie dla poprawy jakości usługi.

Mam na myśli szczególnie zestaw programistów, którzy:

• Zostali zatrudnieni do roli programisty, przy niewielkiej / żadnej wzmiance o zadaniach związanych z ops.
• Tradycyjnie „wyrzuciłem kod przez ścianę” do zespołu operacyjnego.
• Tradycyjnie mają harmonogram prac 9–5 i są aktywnie wrogo nastawieni do „obowiązku pagera”, uczestniczenia w usuwaniu skutków awarii, pisania sekcji zwłok itp., Zwłaszcza poza normalnymi godzinami pracy. (Uwaga: mam na myśli tylko bardzo rzadkie przestoje; nie proponuję dodania obsługi klienta po godzinach do obciążenia tego zespołu).
• Nie są obecnie odpowiedzialni za pisanie / wspieranie monitorowania lub alarmowania w swoich aplikacjach.

Załóżmy, że istnieje zespół, który szybko rozwija nowe mikrousługi w chmurze o profilu, który ma być taki, że przekazywanie tych usług zespołowi operacyjnemu jest nieoptymalne, ponieważ nie mogą nadążyć za uzyskaniem głębokiej wiedzy na temat usługi wymagane do skutecznego zarządzania nimi i monitorowania. „Budujesz, uruchamiasz” działałoby lepiej dla tego zespołu, ponieważ zadania można przekazywać każdemu odpowiedzialnemu członkowi zespołu. Tak więc zespół ten zacznie brać udział w projektowaniu infrastruktury, monitorowaniu / ostrzeganiu przed usługami i (bardzo rzadko) reagowaniu na awarie.

Szczególnie interesują mnie metodyki, poparte przykładami z prawdziwego świata. Jak udało się to skutecznie wdrożyć w innych miejscach pracy i czy istnieją jakieś kanoniczne kroki, które należy wykonać podczas wdrażania? Wszelkie linki do opisów, które mogą wspierać odpowiedzi, byłyby bardzo pomocne.

Myślę, że najprostszym sposobem jest zmiana celów dotyczących wydajności, aby opierały się one na niezawodności oraz dostarczaniu kodu. Sprzedaj to, ponieważ firma nie może odnieść sukcesu bez obu, więc dlaczego programiści mieliby być oceniani tylko na jednym? Najlepszym sposobem na osiągnięcie celów w zakresie wydajności jest zaangażowanie w działania.

Ostatecznie musisz ich przekonać, że jest to najlepszy sposób na odniesienie sukcesu przez firmę, a tym samym na odniesienie sukcesu. To trudne i nie można oczekiwać, że będą na pokładzie od samego początku. Muszą też być sprzedawane według wartości.

Jeśli chodzi o wpływ na kulturę biznesu, najlepszym sposobem jest prawdopodobnie znana metoda „ugotowania żaby”. Musisz powoli wprowadzać te zadania do programistów, ponieważ wiem, że ja (jako programista) nie chciałbym brać na siebie całej tej nowej odpowiedzialności naraz.

Najpierw zacznij od wprowadzenia jednego lub dwóch nowych zadań, które będą wykonywane tylko w normalnych godzinach pracy. Muszą nauczyć się robić devops, co może być procesem uczenia się dla (tylko do tego) programisty i może wymagać pewnego nadzoru. Prawdopodobnie będą też wrogo nastawieni do zmiany równowagi między życiem zawodowym a prywatnym, ponieważ wspominasz, że są przyzwyczajeni do 9-5. W tym momencie zapisz dane o nowych procesach do późniejszego wykorzystania (poproś, aby napisali ten kod, dane są zawsze przydatne).

Później, gdy zabraknie Ci nowych zadań do opracowania (tak, że pierwszy, drugi i czwarty punkt są już prawie ukończone), przynieś pierwsze zadania, które przedstawiłeś jako kandydaci do wykonania poza standardowymi godzinami pracy . Możesz zobaczyć trochę luzu i możesz nawet zauważyć pewne ścieranie w zależności od tego, jak mocno to naciskasz i od tego, jak silnie zakorzeniona jest kultura pracy do piątej. Aby się przed tym bronić, mam nadzieję, że dane wspierają pogląd, że praca poza standardowymi godzinami będzie rzadka, występuje tylko w ekstremalnych sytuacjach i przyniesie ogromne korzyści zarówno firmie, jak i klientowi. Jeśli Twoje dane nie obsługują tego, lepiej przygotuj się na konsekwencje tego wyboru.

Nawet z danymi może być jeszcze łatwiej prosić programistów o napisanie kodu monitorowania / ostrzegania (więc stają się programistami, ale nadal głównie programistami) i utrzymywać zespół alternatywnych operatorów jako wsparcie na pierwszej linii (jak sugerowało kilku innych). Jak powiedziałem, małe zmiany są ważne, aby uniknąć luzu. Integracja pracy deweloperów poza standardowymi godzinami będzie trudna, ponieważ mogą wiedzieć, że mogą szukać pracy gdzie indziej, jeśli im się to nie spodoba, ponieważ rynek deweloperów jest obecnie silny, szczególnie jeśli już mieli umiejętności deweloperskie. Zastrzegający emptor!

Patrząc poza DevOps, jeśli mówisz o dużych (ish) środowiskach korporacyjnych, metodologia SAFe ma całkiem dobry sposób na zachęcanie do tego rodzaju zachowań.

Zasadniczo sprowadza się do kilku kluczowych etapów:

• projekty zaczynają się jako pociągi wydawnicze. Zamiarem (i oczekiwaniem tego, kto je finansuje) jest to, że będzie on długo działał. Mówię o latach, nic z tego „nie stój zespołu przez 3 miesiące, a potem odstąp od nich”.

• w trakcie projektu kolejna wersja nieuchronnie zgromadzi więcej ludzi, ponieważ więcej zarówno nowych wymagań projektowych opartych na nowo zrealizowanych możliwościach biznesowych, jak i bieżącego podatku od prac konserwacyjnych.

• Prawie zawsze widzę, że pociągi uruchamiają swój pierwszy przyrost jako zespoły projektu / zmiany w 100%, a drugi krok poświęca procent czasu na pracę w trybie Run. Trzecie zarządzanie przyrostami zdaje sobie sprawę, że mają problem i zaczynają dodawać zespoły, aby spróbować obsłużyć przepełnienie Run, aby dać doświadczonym programistom i inżynierom czas na pracę nad nowymi wymaganiami.

• jeśli zostanie osiągnięta odpowiednia równowaga między zespołami projektowymi, które są w stanie nadal osiągać wyniki projektu bez większego zaangażowania w prace konserwacyjne, a od nowych zespołów, które dołączą do pociągu, nie oczekuje się natychmiast, że będą tylko stuprocentowymi zespołami wsparcia, ale zamiast tego przyjmą spora część prac nad zmianą, które miały zostać wykonane, to w końcu zespoły dostawcze, które są domyślnie właścicielami produktów, które budują, nie musi przychodzić do nich od razu, że teraz są zespołem Run, zamiast tego powoli integruje się z codziennymi czynnościami.

Tam, gdzie ten model ma oczywiście pewne słabości, to ceny dla firmy. Generalnie spodziewałbym się, że zapłacę o wiele więcej za zasób zmiany niż zasób uruchamiany, zwykle prowadzone umowy z głównymi dostawcami mają stałą cenę, a ich celem jest zarabianie na ciągłym doskonaleniu, a tym samym oszczędności kosztów.

Biorąc to pod uwagę, nie jest wcale takie trudne, aby rozważyć zmianę zespołów, które powstały jako część wydania, aby po prostu dostarczać ciągłych ulepszeń. Jeśli istnieje coś, co można zbudować lub zrobić, co poprawi ich zdolność do koncentrowania się na nowych projektach i mniejszego zainteresowania pracą „jak zwykle”, należy to zalegalizować i uszeregować pod względem ważności w oparciu o postrzegane korzyści dla każdego, kto posiada pieniądze na zwolnić pociąg.

IMHO You build it, you run itnie należy traktować dosłownie. Na początek - to prawie brzmi jak kara;)

Żadna pojedyncza osoba ani nawet niewielki zespół programistów nie może w rozsądny sposób obsługiwać narzędzia lub zestawu narzędzi używanych w procesie tworzenia oprogramowania (tj. W produkcji!) Przez długi czas. Byłem tam, zrobiłem to :)

Obowiązki wsparcia mają tendencję do rozszerzania się wraz ze wzrostem bazy klientów narzędzia (zestawu). Jeśli przejmie się wyłącznie te obowiązki, zespół programistów może w większości wspierać, a na rozwój będzie niewiele czasu. Skutecznie ślepy zaułek - ilu programistów chciałoby pozostać w takim środowisku?

Posiadanie profesjonalnego zespołu wsparcia pierwszej linii jest kluczowe, aby zapobiec frustracji, stresowi i innym skutkom długotrwałego narażenia na obowiązki wsparcia w stosunku do członków zespołu programistów.

Zespół wsparcia pierwszej linii oczywiście wycofałby się do zespołu programistów (ponownie zespół, a nie jednoosobowy!) Z powodu problemów, których nie mogą rozwiązać bezpośrednio. Tak, początkowo może być to trudne, ale sytuacja się poprawi. Powinna to być współpraca - na tym właśnie polega DevOps.

To ostatecznie zależy od wielkości i struktury firmy. Istnieją naprawdę trzy etapy, w których Twoja firma może być:

1. Etap uruchamiania (poniżej 150 inżynierów). Oczywiście programiści muszą uruchomić własne oprogramowanie. Każdy robi to przy starcie. Być może nawet nie masz zespołu operacyjnego, ale nawet jeśli tak jest, jest on niewielki, a szybkość postępu jest tak duża, że ​​nie ma sposobu na przekazanie wiedzy wymaganej do skutecznego prowadzenia go w innym zespole wystarczająco szybko, aby mogli odnieść sukces.

2. Średniej wielkości firma (ponad 150 inżynierów, ale jeden zespół operacyjny). Na tym etapie odejście w firmie zaczyna być zbyt duże, inżynierowie, którzy tworzą oprogramowanie, niekoniecznie muszą również pozostać przy nim, aby go uruchomić. Nie znasz już wszystkich i trudno jest skutecznie komunikować się, aby wszyscy mogli działać. Zacznie się zamieniać w chaos. Na tym etapie chcesz przejść do modelu Google, w którym każdy zespół musi operacjonalizować swoje oprogramowanie, ale niekoniecznie je obsługiwać. Będą go obsługiwać na początku, ale dużą częścią budowania oprogramowania jest obniżenie kosztów eksploatacji do punktu, w którym obciążenie jest na tyle małe, że zespół operacyjny może podpisać się po jego uruchomieniu. Tylko wtedy uznaje się to za zrobione.

3. Duże przedsiębiorstwo z wieloma jednostkami biznesowymi (gdzie każda ma swój własny zespół operacyjny): Na tym etapie możesz wrócić do modelu Amazon, w którym każdy niezbędny zespół rozwija i obsługuje własne usługi. Każda jednostka biznesowa musi być na tyle mała, aby wszyscy mogli się poznać, więc mniej niż 150 inżynierów i każda z nich działa w zasadzie jako startup. Amazon ma każdą usługę AWS działającą mniej więcej osobno i działa dla nich.

Musisz dowiedzieć się, na jakim etapie znajduje się Twoja firma i / lub w jaki sposób się wprowadzasz i odpowiednio działać. Nie ma rozwiązania „jeden rozmiar dla wszystkich”.

Moje zdanie na ten temat (gdybym spotkał się z takim przykazaniem, czy jakkolwiek byś to nazwał), byłoby coś w stylu „ What else would you expect?!?!”. Ponieważ przypadkowo:

• Bez niego nie byłbym nawet w stanie żyć, i
• Uwielbiam jeść własne (psie) jedzenie.

Pozwól, że wyjaśnię trochę więcej ...

Moja firma / hobby / pasja to scm , a dokładniej w środowiskach mainframe . I gdziekolwiek pójdę (aby dopracować rzeczy dostosowane do potrzeb klientów), pierwszym wymogiem, który narzucam (w mojej umowie), jest to, że wszelkie dostrojenie systemu, który wdrażamy, odbywa się za pośrednictwem tego samego systemu. I robiąc to (to prawda, że ​​zajmuje to kilka godzin, powiedzmy maksymalnie pół dnia), otrzymujemy z tego następujące korzyści (niepełna lista):

• Prawie nie dokumentuję niczego, co zrobiłem, aby uruchomić system. W razie jakichkolwiek pytań po prostu odpytuję system (i uczę klienta, jak odpytywać system bez mojej pomocy).
• Jeśli zostanę wezwany w ciągu X miesięcy / lat (w celu uaktualnienia do nowej wersji?), Chcę wiedzieć (pamiętać), co robiłem wcześniej (a jedyną rzeczą, której ufam, jest to, co mówi mi system, czyli przypomina mi o).
• Muszę tylko raz zapytać klienta, jak zrobić określone rzeczy na swojej stronie (konwencje nazewnictwa są trudne do zapamiętania), lub przekonać ich do przyznania wymaganych uprawnień „systemowi” (nie mnie ...).
• Testujesz continuouslykontrolę jakości własnego systemu ... w produkcji. Istnieje prawdopodobieństwo, że samemu wystąpią błędy, błędy logiczne lub brakujące funkcje (a co nie). A te są niezwykle motywujące, aby jak najszybciej zwrócić się do nich ... np. Aby zwiększyć produktywność.
• ... a jeśli chcesz, mogę dodać jeszcze kilkanaście powodów ...

Jednak zanim wypróbujesz to w domu, pamiętaj o pewnych pułapkach, aby uniknąć:

• chcesz, aby wszyscy dołączyli do imprezy (korzystaj z systemu), ponieważ tylko 1 „wyjątek” (czyli menedżer / właściciel firmy?) może zepsuć imprezę (możesz pomyśleć, że możesz zaufać swojemu systemowi, ale wtedy ktoś coś zrobił bez pytania / korzystania z systemu). Ta sprawa może kosztować kilka dni, aby odkryć ...
• nowi użytkownicy mogą narzekać, że korzystając z tego (nowego) systemu, zajmuje im więcej czasu na wykonanie swojej pracy (w porównaniu do tego, z czego korzystali wcześniej). I gdziekolwiek ma to sens, wykorzystają to jako usprawiedliwienie, dlaczego spóźniają się z zakończeniem pracy. W tym momencie lepiej kieruj swoim zasięgiem wyższe kierownictwo, ponieważ w przeciwnym razie twój projekt / system może zostać obwiniony.
• upewnij się, że znasz swój system i jak go skonfigurować, aby pasował do twoich potrzeb. Jako przykład (w moim przypadku): chcesz skonfigurować system, aby używać środowiska operacyjnego do dostarczania do środowiska eksperymentalnego, a nie na odwrót ... Widziałem to w przeszłości ... używanie (nadużywanie) systemu testowego do dostarczania do wysoce zabezpieczonych środowisk.