TL; DR, w jaki sposób dowiadujesz się, że deweloperzy, a zwłaszcza automatyzacja wdrażania, poprawiają wskaźniki niepowodzenia zmian?
Wszyscy próbujemy uchwycić wskaźniki dotyczące „niepowodzeń wdrażania” przy użyciu aktualnych (głównie ręcznych) środków. Niestety rzadko zdarza się „niepowodzenie”, prawda? Ponieważ gdy coś pójdzie nie tak, zespół zbiera się (zazwyczaj z heroiką), aby rozwiązać problem (zwykle uprawnienia, brak konfiguracji, znasz ćwiczenie). Więc ... kiedy pytamy, jak przebiegło wdrożenie, odpowiedź brzmi: „zadziałało”.
Ale intuicyjnie wszyscy wiemy, że to nie jest dobre. W raporcie o stanie deweloperów z 2017 r. Stwierdzono, że wskaźnik niepowodzenia wynosi około 31–45% . Chociaż intuicyjnie brzmi to dobrze, czy są one śledzone jako incydenty? Nie Ponieważ są naprawiane dość szybko, zwykle podczas sprawdzania poprawności. O wiele rzadziej faktycznie wycofuje się wdrożenie.
Dlatego dokładne dyscyplinowanie wymaga zgłaszania błędów. Nie zniechęcamy się do takiego zgłaszania, ponieważ chcemy, aby rzeczy działały i robimy wszystko, aby tak się stało.
Jak zatem udowodnić, że deweloperzy, a zwłaszcza automatyzacja wdrażania, poprawiają wskaźniki niepowodzenia zmian?
(PS próbował oznaczyć to jako „# devops-capability-model”)
Odpowiedzi:
Techniką, którą stosowaliśmy w przeszłości w podobnych sytuacjach, jest „zaangażowanie kierownictwa”, które nakłada te zasady na każdego członka zespołu:
Dostęp do wykonywania aktualizacji docelowych obszarów wdrażania (tj. Produkcji) jest ograniczony do wybranych automatycznych systemów, które mają odpowiednie ścieżki audytu (= rejestrowanie) wszelkiego rodzaju aktualizacji obszarów, którymi zarządzają.
Ręczne aktualizacje docelowych obszarów wdrażania, z jakiegokolwiek powodu, nie są już dozwolone przez typowych członków zespołu (identyfikatory użytkowników), którzy kiedyś byli w stanie (autoryzowani) wykonywać te aktualizacje. Zamiast tego zostaną utworzone NOWE (dodatkowe) identyfikatory użytkowników, które będą miały wszystkie wymagane uprawnienia do (wciąż) przeprowadzania takich ręcznych aktualizacji w razie potrzeby. Ale aby faktycznie móc korzystać z tych nowych identyfikatorów użytkowników (= wykonać logowanie przy ich użyciu), członek zespołu, który chce wykonać logowanie przy użyciu takiego nowego identyfikatora użytkownika, będzie musiał wykonać „jakiś” dodatkowy krok, aby uzyskać dostęp do hasła taki nowy identyfikator użytkownika. Idealnie ten dodatkowy krok jest również zautomatyzowany (użyj własnej wyobraźni, jak powinien on wyglądać), ale jeśli coś innego zawiedzie: po prostu skontaktuj się z (= e-mail, zadzwoń itp.) Strażnikiem wymaganego hasła, w tym „jaki problem mają naprawić ”
Po wdrożeniu tych procedur należy tylko okresowo sprawdzać każdy z tych raportów / powody, dla których wymagane było użycie takiego specjalnego identyfikatora użytkownika, i zadać pytanie „ Czy można coś zrobić, aby to zautomatyzować, aby jeszcze bardziej zmniejszyć potrzebę takiego specjalnego logowania? ”.
Aktualizacja :
Cytat z dodatkowego komentarza poniżej tej odpowiedzi:
To prawda, że stanowi dodatkową barierę, ale nie jestem przekonany, że jest „sztuczny”. Ponieważ jest to, o ile mi wiadomo, jedyny sposób, aby uświadomić sobie rzeczy, które członkowie zespołu w innym przypadku nigdy ci nie powiedzą z takich powodów:
źródło
Problem, który szybko się rozwiązuje, nadal jest problemem. Jeśli nie zgłaszasz ich jako takich, to jest problem.
Jeśli Twoim celem jest, aby rzeczy działały, musisz być uczciwy w kwestii awarii, aby zapobiec im w przyszłości. To brzmi jak zespół tutaj kłamie (być może do siebie, z pewnością do zarządzania) o awarii, ponieważ ich celem jest mieć rzeczy wydają się działać.
To są różne rzeczy. Weźmy na przykład stary dowcip, że QA produkuje błędy - „mój kod był w porządku, dopóki QA go nie złapał, a potem zrobili wszystkie te błędy!”. Błędy występowały cały czas, ale deweloper nie wiedział o nich. Celem zespołu operacyjnego powinna być faktyczna niezawodność i jako takie powinny być motywowane przez kierownictwo. Oznacza to, że jeśli wprowadzą więcej monitoringu prowadzącego do odkrywania nowych problemów, powinni zostać nagrodzeni, a nie ukarani za późniejszy spadek wskaźników niezawodności.
Jeśli próbujesz zmotywować zmiany w swojej organizacji, nie powinieneś próbować niczego udowadniać, ale dostarczać dowodów na to, co inne organizacje mówią o swoich przejściach. Jeśli próbujesz zmierzyć procesy, które już masz, i uzasadnić ich dalsze istnienie, powinieneś śledzić standardowe wskaźniki niezawodności, takie jak średni czas naprawy (MTTR).
Ale zasady devops nie polegają jedynie na zwiększeniu niezawodności. Nawet inżynieria niezawodności witryny nie polega wyłącznie na zwiększeniu niezawodności. Zamiast tego chcesz uzyskać odpowiedni poziom niezawodności - coś, co przynosi korzyści firmie, ale nie utrudnia rozwoju. I to wywołuje prawdziwą motywację u dewów, która ma umożliwić zmianę . Chcesz, aby firma mogła szybciej reagować na bodźce rynkowe, co dzieje się poprzez zmniejszenie tarcia programisty, zwiększenie tempa wdrożeń, automatyzację procesów ręcznych itp. Przy zachowaniu akceptowalnej granicy niezawodności. Oznacza to, że musisz zmierzyć niezawodność, ale musisz także zmierzyć prędkość, ponieważ Twoim celem jest zwiększenie tego drugiego, przy jednoczesnym zachowaniu względnej statyczności tego pierwszego.
źródło