Cześć, jestem Valerio, inżynier oprogramowania, założyciel & CTO w Inspektorze.
W tym artykule chciałbym podzielić się z Państwem moim doświadczeniem na temat tego, dlaczego programiści powinni zawsze preferować narzędzia do monitorowania oparte na kodzie, a nie na infrastrukturze.
Zrozumienie ich różnych podejść może pomóc w lepszym zorganizowaniu zespołu, zachowaniu elastyczności i szybkości w czasie dostaw oraz szybkim identyfikowaniu problemów, zanim klienci się o nich zorientują.
Jako CTO produktu Code Execution Monitoring Co tydzień mam okazję rozmawiać na ten temat z firmami różnej wielkości.Z powodu błędów oprogramowania i przestojów byłem świadkiem sporów między zespołami, wściekłych klientów, anulowanych umów, procesów sądowych i wielu innych katastrof.
W większości przypadków było to po prostu ponieważ zespół programistów nie był w odpowiednim stanie do wykonywania swojej pracy.
W tym artykule znajdziesz moje prawdziwe doświadczenie, które możesz wykorzystać, aby ułatwić życie swoim programistom i uniknąć utraty klientów i pieniędzy z powodu nieoczekiwanych problemów technicznych w twoich aplikacjach.
Dlaczego monitorowanie jest ważne
Czas wielu programistów odczuwa potrzebę częstego monitorowania swoich aplikacji, gdy po raz pierwszy rozpoczynają pracę nad średnim/dużym projektem.
Monitorowanie to dla programistów sposób na unikanie nieoczekiwanych incydentów i jak najdłuższe utrzymanie zadowolonych klientów – co oznacza stabilny dochód w czasie.
Monitorowanie oparte na infrastrukturze narzędzia
Najbardziej znane platformy monitorujące, takie jak DataDog, Dynatrace, NewRelic, AppDynamics i inne, wymagają zainstalowania i skonfigurowania na poziomie serwera lub ogólnie w infrastrukturze IT, ale wielu programistów nie lubi się tym zajmować, a zamiast tego uwielbia pozostać koncentruje się na kodowaniu.
Wspomniane powyżej narzędzia wymagają dużej pomocy i szkoleń, a nawet dedykowanego zespołu inżynierów (znającego się na serwerach i infrastrukturze) do konfiguracji i konserwacji, i wydają się być zbyt skomplikowane i drogie dla małych/średnich zespołów, które muszą skupić się tylko na tworzenie aplikacji.
Zajmowanie się infrastrukturą jest problemem dla wielu programistów z dwóch powodów:
1) Przeciążenie pracą
Zarządzanie operacjami IT to zawód sam w sobie . Wymaga wielu umiejętności wertykalnych dotyczących środowisk serwerowych i obejmuje skomplikowane technologie (takie jak Kubernetes).
W przypadku podstawowych potrzeb programiści zwykle polegają na zewnętrznych narzędziach do automatyzacji udostępniania serwerów, takich jak panele Cloud Hosting, platformy PaaS lub podobne, aby zmniejszyć ten problem.
Jednak w średnich i dużych organizacjach lub gdy firma się rozrasta, może być konieczne posiadanie dedykowanego zespołu, który zajmie się infrastrukturą, pozostawiając programistom swobodę spędzania czasu na pracy nad kodem aplikacji i wdrażaniu nowych funkcji.
2) Wszystko skonfigurowane na poziomie serwera zwykle pozostaje poza kontrolą programistów
< p>Niezależnie od tego, czy korzystasz z narzędzi do automatyzacji infrastruktury, czy nawet masz zewnętrzne zespoły, które się tym zajmują, wszystko skonfigurowane na poziomie serwera jest poza cyklem rozwoju oprogramowania, a programiści tracą autonomię w stosunku do innych zespołów.Każdy zespół w Twojej firmie ma własne potrzeby w zakresie monitorowania (Kubernetes, Cyberbezpieczeństwo, sieci i infrastruktura, prywatność i amp;Zgodność, zastosowanie itp.). Coś, co działa w jednym scenariuszu, może być wąskim gardłem w innym.
Ostatnio podczas telekonferencji z kierownictwem jednej z największych firm użyteczności publicznej w Europie (Terna S.P.A.) Po raz pierwszy od lat pracy w firmie spotkałem się szefów zespołu rozwoju oprogramowania i zespołu ds. operacji na infrastrukturze.
Ponieważ udostępnianie narzędzi w różnych zespołach nie było łatwe, zamiast polegać na zespole operacyjnym w zakresie jakiejkolwiek konfiguracji lub dostosowania, twórcy oprogramowania nadal polegali na dziennikach w celu monitorowania swoich aplikacji.
Wymuszanie współpracy różnych zespołów o różnych celach w tym samym narzędziu może spowodować zamieszanie, ciągłą wymianę wiadomości e-mail między zespołami w celu dostosowania konfiguracji lub dokonania dostosowań, a ostatecznie programiści prawie zawsze mają najgorsze, ponieważ nie mają kontroli nad wszystkim, co jest zainstalowany wewnątrz infrastruktury.
Jeśli programiści nie są w odpowiednich warunkach do wykonywania swojej pracy, marnują godziny lub dni przed jakimkolwiek problemem.
Jest to doskonały przykład na lepsze zrozumienie wad, jakie narzędzia do monitorowania oparte na infrastrukturze mogą tworzyć dla programistów.
Narzędzie do monitorowania oparte na kodzie
Zamiast tego narzędzia do monitorowania oparte na kodzie udostępniają bibliotekę oprogramowania, którą można zainstalować i używać jak inne zależności aplikacji (pakiet kompozytora dla aplikacji PHP, moduł npm dla nodejs itp.).
Ta różnica techniczna (polegaj na bibliotece aplikacji zamiast na agencie na poziomie serwera) ma wiele konsekwencji dla zdolności twórców oprogramowania do szybkiego identyfikowania błędów i wąskich gardeł w aplikacjach, zanim staną się one przestojami.
Dzięki narzędziu, które można zainstalować, swobodnie konfigurowane i dostosowywane, bez uzależnienia od zespołu zewnętrznego, programiści będą mogli szybciej identyfikować i rozwiązywać problemy w aplikacjach:
- With no interaction with other teams;
- Without endless tickets or email exchanges that are bounced on multiple levels inside the company;
- Without delays for your customers.
Jedną z najważniejszych rzeczy, za które płacą klienci, jest „nie ma problemów”. Zapewnienie zespołowi programistycznemu możliwości szybkiej i niezależnej pracy ma kluczowe znaczenie dla:
- Less bug reports;
- Faster bug fix;
- More happy customers.
Dla kilku osób miesięcy Podzieliłem się naszym pomysłem na temat Inspectora jako narzędzia do monitorowania opartego na kodzie, wygłaszając prelekcje na wydarzeniach włoskich społeczności PHP i dyskutując z innymi dyrektorami ds. technologii.Na tej stronie zebrałem recenzje programistów, którzy używają Inspectora w swojej codziennej pracy: https://www.inspector.dev/testimonials
Nie ufaj moim słowom, wypróbuj za darmo
Aby umożliwić wszystkim zainteresowanym wypróbuj to nowe rozwiązanie, oferujemy całkowicie bezpłatny poziom, do 30 000 transakcji miesięcznie. To nie jest ograniczony okres próbny.Ty i Twój zespół możecie zapoznać się z Inspektorem bez ścigania Cię w terminie.
Mam nadzieję, że spodoba Ci się korzystanie z Inspektora.
Stworzyliśmy również link polecający dla tego konkretnego posta.Korzystając z tego linku, otrzymasz 50 000 dodatkowych miesięcznych transakcji jako nagrodę za bycie czytelnikiem LaravelNews - Zarejestruj swoje konto - więc założysz konto z 80 000 miesięcznymi transakcjami za darmo.
Lub odwiedź naszą stronę internetową, aby uzyskać więcej informacji: https://inspektor.dev/laravel/
