Oddzielenie szumu od byka: czego nie należy automatyzować

Niezależnie od tego, czy jesteś liderem DevOps, inżynierem ds. niezawodności witryny, menedżerem IT czy CTO, istnieje prawdopodobieństwo, że automatyzacja jest w dużej mierze zakorzeniona w tym, co robisz.

Pod wieloma względami terminy automatyzacja i DevOps są synonimami. A w ostatnich latach wydaje się, że termin ten przejął kontrolę, ponieważ rozwiązania, które mają na celu automatyzację, prawie nie mają końca.

Niedawny raport firmy Red Hat wykazał, że firmy zautomatyzowały średnio 36% swoich operacji w chmurze. Im dłużej firma istnieje, tym bardziej ręczne procesy są zastępowane zautomatyzowanymi przepływami pracy.

Istnieje wiele powodów wzrostu popularności automatyzacji:

• Firmy chcą, aby działania rozwojowe koncentrowały się na zadaniach o znaczeniu krytycznym
• Chęć przyspieszenia terminów publikacji
• Liderzy oczekują od zespołów większej elastyczności i współpracy
• Systemy ręczne są notorycznie podatne na błędy ludzkie
• Zapotrzebowanie na stanowiska IT, SRE i DevOps jest większe niż osób do ich obsadzenia

Automatyzacja – więcej niż modne hasło?

Rewind niedawno rozmawiał z różnymi liderami rozwoju oprogramowania na temat ich doświadczeń z automatyzacją, tego, jak automatyzacja pasuje do celów ich zespołu oraz ram, których używają do podejmowania decyzji.

Scott Sturgeon, CTO w Tugboat Logic by One Trust, jest sceptyczny. „Z mojej perspektywy automatyzacja stała się modnym słowem. Nie wszystko da się zautomatyzować w rozsądny sposób. Nie wszystko powinno być. Rzeczy, które są powtarzalne i czasochłonne, to rzeczy, na których zwykle się skupiam. Większość automatyzacji, o której słyszysz w dzisiejszych czasach, sprowadza się do CI/CD – ciągłej integracji, ciągłego wdrażania. Możesz tworzyć bardzo złożone potoki, które mogą automatycznie aktualizować instancję produkcyjną. Co jest świetne, jeśli jesteś skonfigurowany, aby zrobić to właściwie.

„Myślę, że automatyzacja to bardzo ogólny termin i chcesz dokładniej określić, do czego tak naprawdę dążysz. To technika i metoda, a nie wynik” — wyjaśnia Nigel Kersten, Field CTO w firmie Puppet. Nie automatyzujesz dla samej automatyzacji, automatyzujesz, ponieważ próbujesz osiągnąć wynik. Myślę też, że to dobre hasło marketingowe, ponieważ rezonuje z ludźmi, którzy myślą: „Mogę zmusić roboty, żeby to zrobiły”. Musisz więc uważać, jak używasz tego słowa”.

Mając na uwadze tę ostrożność, oto kilka najważniejszych zadań, które często są nadmiernie zautomatyzowane lub niepotrzebnie skomplikowane przez automatyzację.

Czego nie automatyzować

Chociaż większość zadań można zautomatyzować, nie oznacza to, że tak powinno być. Oto kilka szybkich wskazówek, co można usunąć z listy do zautomatyzowania :

• Zadania o niskim zwrocie z inwestycji, gdzie wymagany nakład pracy nie przynosi znaczących zwrotów
• Testy doświadczenia użytkownika lub cokolwiek, co daje subiektywny wynik
• Zadania, w których występuje bardzo wysoki stopień nieprzewidywalności
• Zadania o małej powtarzalności
• Zadania bez dobrze zdefiniowanej procedury/wzorca

„Rzeczy, których komputer nie potrafi dobrze zrobić, nie powinny być zautomatyzowane. Na przykład wiele firm próbuje zautomatyzować przeglądy kodu” — wyjaśnia Scott. „To jest dobre dla rzeczy następujących po składni lub dziwnych zależności cyklicznych. Komputer może to rozgryźć. Jednak patrzenie na logikę fragmentu kodu i na to, czy zostało to zrobione poprawnie, nie jest czymś, co komputer może zrobić dobrze. Moim zdaniem przegląd kodu nadal wymaga, aby osoba na niego spojrzała”.

James Ciesielski, CTO w Rewind, rozwija to oparte na ryzyku podejście do automatyzacji w programowaniu. „Jeśli chodzi o podejmowanie decyzji, co należy zautomatyzować, oceniamy ryzyko związane z zaangażowaniem ludzi w utrzymanie procesu. Widziałem środowiska programistyczne, w których ludziom przyznano boskie przywileje dla zespołu programistów. Często odbywa się to w imię służenia klientom, ale ludzie popełniają błędy, celowe i niezamierzone”.

Jak zdecydować, co wymaga automatyzacji

Rzeczywistość jest taka, że ​​wiele firm będzie musiało zautomatyzować rzeczy, które bezpośrednio lub pośrednio wpływają na ich produkt lub usługę. Wyjątkowe przypadki użycia mogą pojawić się w każdym środowisku, zwłaszcza gdy rynki stają się bardziej konkurencyjne, więcej firm SaaS pojawia się online, a plany drogowe stają się bardziej ambitne. Ale jak powie ci każdy zespół programistów na świecie, ich lista rzeczy do zrobienia jest niewiarygodnie długa. Jako zespół, w jaki sposób ustalacie priorytety i zgadzacie się, czym zająć się w następnej kolejności?

Chociaż nie ma uniwersalnego podejścia do podejmowania decyzji, oto kilka sygnałów, których używają eksperci IT, aby ocenić, czy proces jest dobrym kandydatem do automatyzacji:

• Ręczny : jak ręczne uruchomienie skryptu, który automatyzuje zadanie. Chociaż skrypt może być szybszy niż rzeczywiste wykonanie każdego kroku ręcznego, czas potrzebny na uruchomienie skryptu to wciąż czas, który można wykorzystać gdzie indziej. Innymi słowy, jeśli muszę ciągle naciskać przycisk, mogę w końcu spędzić cały swój czas na naciskaniu tego przycisku.
• Powtarzalne : po mniej więcej drugim wykonaniu tego samego zadania może być konieczne zautomatyzowanie. Rozwiązywanie nowych problemów się nie liczy.
• Automatyzacja : jeśli maszyna może wykonać tę samą pracę równie dobrze jak człowiek, można to uznać za trud. Jeśli zadanie wymaga, aby człowiek naprawdę myślał o rzeczach, może nie być dobrym kandydatem.
• Taktyka : jeśli coś ciągle przeszkadza twojej drużynie i wprowadza ją w tryb „reagowania”, warto zająć się minimalizowaniem tych czynników rozpraszających.
• Brak trwałej wartości: jeśli wykonujesz zadanie, a Twój produkt lub usługa pozostają takie same, prawdopodobnie przyczynia się to do trudów.
• Zadania rosną wraz ze wzrostem operacji: jeśli wielkość zadania rośnie wraz z rozmiarem usługi, natężeniem ruchu lub liczbą użytkowników — prawdopodobnie jest to problem.

W końcu często dobrym punktem wyjścia jest znalezienie procesów (które dodają wartość), które często wykonujesz i polegasz na człowieku. Kiedy zaangażowani są ludzie, prawdopodobieństwo popełnienia błędu rośnie wykładniczo.

Lena Feygin, DevOps Team Leader w OwnBackups, podkreśla ostrożność i rozwagę w kwestii chęci „: automate_all_the_things: .”. Jej rada? „Ostatecznie musimy zautomatyzować tylko problemy, które naprawdę powodują problemy, a nie naprawiać problemy, które nie istnieją”.

Szukasz więcej porad ekspertów na temat automatyzacji od profesjonalistów DevOps? Pobierz nasz kompletny przewodnik po automatyzacji w operacjach programistycznych - całkowicie za darmo.