Dwa w pudełku (jeśli możesz) i wszyscy w dokumentacji (zawsze).
W kontekście IT „dwa w jednym pudełku” odnoszą się do dwóch serwerów lub komponentów zaprojektowanych do współpracy w celu zapewnienia nadmiarowości i zwiększonej niezawodności. Taka konfiguracja może zapewnić, że w przypadku awarii jednego komponentu drugi przejmie jego działanie, utrzymując w ten sposób ciągłość usług. Celem posiadania „dwóch w jednym pudełku” jest zapewnienie wysokiej dostępności i odzyskiwania po awarii. Dotyczy to również ról ludzkich w organizacji; jest jednak rzadko wdrażany.
Spójrzmy na odpowiedni przykład Analytics. Wszyscy prawdopodobnie znamy osobę w naszej firmie lub organizacji z imienia i nazwiska, która jest osobą, z którą można się kontaktować w przypadku Analytics. To oni mają raporty lub pulpity nawigacyjne nazwane ich imionami — Raport Mike'a lub Pulpit nawigacyjny Jane. Jasne, są inni ludzie, którzy znają się na analizie, ale są to prawdziwi mistrzowie, którzy zdają się wiedzieć, jak wykonać najtrudniejsze zadania i dotrzymać terminów. Problem polega na tym, że ci ludzie są samotni. W wielu przypadkach pod presją nie współpracują z nikim, ponieważ może to ich spowolnić i tu zaczyna się problem. Nigdy nie myślimy, że stracimy tę osobę. Powstrzymam się od typowego „powiedzmy, że potrącił ich autobus” lub posłużę się przykładem wykorzystującym obecne możliwości na rynku pracy i powiem coś pozytywnego, jak „wygrali na loterii!”, ponieważ wszyscy powinniśmy robić wszystko, co w naszej mocy, aby być pozytywnym w te dni.
O nas
Nadchodzi poniedziałkowy poranek, a nasz ekspert analityczny i mistrz MJ złożył rezygnację. MJ wygrał los na loterii i już opuścił kraj bez opieki na świecie. Zespół i ludzie, którzy znają MJ, są zachwyceni i zazdrośni, ale praca musi odejść. Teraz jest moment, w którym wartość i rzeczywistość tego, co robił MJ, ma zostać zrozumiana. MJ był odpowiedzialny za ostateczną publikację i weryfikację analiz. Zawsze wydawało się, że są w stanie poprawić wydajność lub wprowadzić tę trudną zmianę, zanim udostępnią wszystkim analitykę. Nikogo tak naprawdę nie obchodziło, jak to się robi, i był pewny, że to się po prostu stało, a MJ był indywidualną gwiazdą rocka Analytics, więc przyznano mu pewien poziom autonomii. Teraz, gdy zespół zaczyna zbierać elementy, prośby, codzienne problemy, prośby o modyfikacje, są zagubieni i zaczynają się plątać. Raporty / Dashboardy znajdują się w nieznanych stanach; niektóre zasoby nie zostały zaktualizowane przez weekend i nie wiemy dlaczego; ludzie pytają, co się dzieje i kiedy zostaną naprawione, zmiany, o których mówił MJ, nie pojawiają się i nie mamy pojęcia, dlaczego. Drużyna wygląda źle. To katastrofa, a teraz wszyscy nienawidzimy MJ.
Lekcje
Istnieje kilka łatwych i oczywistych rozwiązań na wynos.
- Nigdy nie pozwól, aby ktoś pracował sam. Brzmi dobrze, ale w mniejszych zwinnych zespołach nie mamy czasu ani ludzi, aby to osiągnąć. Ludzie przychodzą i odchodzą, zadań jest wiele, więc trzeba dzielić i rządzić w imię produktywności.
- Każdy musi dzielić się swoją wiedzą. Również brzmi dobrze, ale czy dzielimy się z właściwą osobą lub osobami? Pamiętaj, że wielu zwycięzców loterii to współpracownicy. Sesje dzielenia się wiedzą również odciągają czas od zadań, a większość ludzi inwestuje w umiejętności i wiedzę tylko wtedy, gdy jest to potrzebne.
Jakie są więc realne rozwiązania, które każdy może wdrożyć i z których każdy może skorzystać?
Zacznijmy od zarządzania konfiguracją. Użyjemy tego jako ogólnego terminu dla kilku podobnych tematów.
- Zarządzanie zmianami: Proces planowania, wdrażania i kontrolowania zmian w systemach oprogramowania w uporządkowany i systematyczny sposób. Proces ten ma na celu zapewnienie, że zmiany są wprowadzane w kontrolowany i efektywny sposób (z możliwością cofnięcia), przy minimalnym zakłóceniu istniejącego systemu i maksymalnych korzyściach dla organizacji.
- Zarządzanie projektem: Planowanie, organizacja i kontrola projektów rozwoju oprogramowania w celu zapewnienia ich ukończenia na czas, w ramach budżetu i zgodnie z pożądanymi standardami jakości. Obejmuje koordynację zasobów, działań i zadań w całym cyklu życia oprogramowania, aby osiągnąć cele projektu i dostarczyć oprogramowanie zgodnie z harmonogramem.
- Ciągła integracja i ciągłe dostarczanie (CI/CD): Proces automatyzacji budowania, testowania i wdrażania oprogramowania. Ciągła integracja wymaga regularnego łączenia zmian kodu we wspólnym repozytorium i przeprowadzania automatycznych testów w celu wykrycia błędów na wczesnym etapie procesu programowania. Ciągłe dostarczanie/wdrażanie polega na automatycznym wprowadzaniu przetestowanych i zweryfikowanych zmian kodu do produkcji, co pozwala na szybkie i częste wydawanie nowych funkcji i ulepszeń.
- Kontrola wersji: Proces zarządzania zmianami w kodzie źródłowym i innych artefaktach oprogramowania w czasie przy użyciu wyspecjalizowanych narzędzi programowych. Pozwala programistom współpracować nad bazą kodu, utrzymywać pełną historię zmian i eksperymentować z nowymi funkcjami bez wpływu na główną bazę kodu.
Wszystkie powyższe odnoszą się do dobrych praktyk wytwarzania oprogramowania. Analityka, która napędza i prowadzi biznes, zasługuje na nie mniej, ponieważ ma kluczowe znaczenie dla podejmowania decyzji. Wszystkie zasoby analityczne (zadania ETL, definicje semantyczne, definicje metryk, raporty, pulpity nawigacyjne, historie… itd.) to tylko fragmenty kodu z wizualnym interfejsem do projektowania, a pozornie drobne zmiany mogą spowodować spustoszenie w operacjach.
Korzystanie z Configuration Management zapewnia nam utrzymanie działania w dobrym stanie. Zasoby są wersjonowane, dzięki czemu możemy zobaczyć, co wydarzyło się w ciągu ich życia, wiemy, kto nad czym pracuje wraz z poczynionymi postępami i harmonogramami, i wiemy, że produkcja będzie kontynuowana. To, czego nie obejmuje żaden czysty proces, to przekazywanie wiedzy i zrozumienie, dlaczego rzeczy są takie, jakie są.
Każdy system, baza danych i narzędzie analityczne mają swoje dziwactwa. Rzeczy, które sprawiają, że poruszają się szybko lub wolno, przedmioty, które sprawiają, że zachowują się w określony sposób lub dają pożądany rezultat. Mogą to być ustawienia na poziomie systemowym lub globalnym albo elementy w projekcie zasobów, które sprawiają, że działają tak, jak powinny. Problem polega na tym, że większości z tych rzeczy uczy się z czasem i nie zawsze jest miejsce na ich udokumentowanie. Nawet gdy przechodzimy do systemów chmurowych, w których nie mamy już kontroli nad działaniem aplikacji i polegamy na dostawcy, który uczyni ją tak szybką, jak to możliwe, nadal ulepszamy definicje w naszych zasobach, aby odblokować dokładnie to, czego szukamy. Tę wiedzę należy uchwycić i podzielić się nią, udostępniając ją innym. Wiedza ta musi być wymagana jako część dokumentacji zasobów i stanowić integralną część kontroli wersji oraz sprawdzania i zatwierdzania CI/CD, a w niektórych przypadkach nawet jako część listy kontrolnej przed opublikowaniem rzeczy do zrobienia i nie Do.
Nie ma magicznych odpowiedzi ani sztucznej inteligencji, które mogłyby ukryć skróty w naszych procesach analitycznych lub ich brak. Niezależnie od wielkości zespołu, który utrzymuje przepływ danych i analiz, inwestycja w system do śledzenia zmian, wersjonowania wszystkich zasobów i pomoc w dokumentowaniu procesu rozwoju i pozyskiwaniu wiedzy jest koniecznością. Inwestycja w procesy i czas z góry pozwoli zaoszczędzić mnóstwo czasu zmarnowanego później na wymyślanie rzeczy, aby utrzymać zdrowy stan naszych analiz. Rzeczy się zdarzają i najlepiej mieć polisę ubezpieczeniową dla MJ-ów i innych zwycięzców loterii.
