Programiści są z Marsa, administratorzy są z Wenus

Zbiegi okoliczności są przypadkowe i rzeczywiście było to na innej planecie...

Chciałbym podzielić się trzema historiami sukcesów i porażek na temat pracy programisty backendowego w zespole z administratorami.

Najpierw historia.
Studio internetowe, liczbę pracowników można policzyć jedną ręką. Dziś jesteś projektantem układu, jutro jesteś backenderem, pojutrze jesteś administratorem. Z jednej strony można zdobyć ogromne doświadczenie. Z drugiej strony brakuje kompetencji we wszystkich obszarach. Pamiętam jeszcze pierwszy dzień w pracy, jeszcze jestem zielony, szef mówi: „Otwórz kit”, ale nie wiem, co to jest. Komunikacja z administratorami jest wykluczona, ponieważ sam jesteś administratorem. Rozważmy zalety i wady tej sytuacji.

+ Cała władza jest w twoich rękach.
+ Nie trzeba nikogo błagać o dostęp do serwera.
+ Szybki czas reakcji we wszystkich kierunkach.
+ Dobrze poprawia umiejętności.
+ Pełne zrozumienie architektury produktu.

— Duża odpowiedzialność.
— Ryzyko przerwania produkcji.
— Trudno być dobrym specjalistą we wszystkich dziedzinach.

Nie jestem zainteresowany, idziemy dalej

Druga historia.
Duża firma, duży projekt. Istnieje dział administracji zatrudniający 5-7 pracowników i kilka grup rozwojowych. Kiedy przychodzisz do pracy w takiej firmie, każdy administrator myśli, że nie przyszedłeś tu, aby pracować nad produktem, ale żeby coś zepsuć. Ani podpisana NDA, ani wybór podczas rozmowy kwalifikacyjnej nie wskazują inaczej. Nie, ten mężczyzna przyszedł tutaj ze swoimi brudnymi rączkami, żeby zrujnować naszą produkcję dotyczącą pocałunków. Dlatego z taką osobą potrzebujesz minimum komunikacji, a przynajmniej możesz w odpowiedzi rzucić naklejkę. Nie odpowiadaj na pytania dotyczące architektury projektu. Zaleca się nie udzielać dostępu, dopóki lider zespołu o to nie poprosi. A gdy poprosi, odda z jeszcze mniejszymi przywilejami, niż żądali. Prawie cała komunikacja z takimi administratorami jest pochłaniana przez czarną dziurę między działem rozwoju a działem administracji. Niemożliwe jest szybkie rozwiązanie problemów. Ale nie możesz przyjść osobiście - administratorzy są zbyt zajęci 24 godziny na dobę, 7 dni w tygodniu. (Co cały czas robisz?) Niektóre cechy wydajności:

• Średni czas wdrożenia w środowisku produkcyjnym to 4-5 godzin
• Maksymalny czas wdrożenia w środowisku produkcyjnym 9 godzin
• Dla programisty aplikacja w środowisku produkcyjnym jest czarną skrzynką, podobnie jak sam serwer produkcyjny. Ile ich jest w sumie?
• Niska jakość wydań, częste błędy
• Deweloper nie uczestniczy w procesie wydawania

No cóż, czego się spodziewałem, oczywiście, nowi ludzie nie są dopuszczeni do produkcji. No cóż, po zdobyciu cierpliwości zaczynamy zdobywać zaufanie innych. Ale z jakiegoś powodu sprawy z administratorami nie są takie proste.

Akt 1. Administrator jest niewidoczny.
W dniu wydania programista i administrator nie komunikują się ze sobą. Administrator nie ma pytań. Ale dlaczego zrozumiesz później. Administrator jest osobą pryncypialną, nie ma komunikatorów, nikomu nie podaje swojego numeru telefonu i nie ma profilu na portalach społecznościowych. Nigdzie nie ma nawet jego zdjęcia. Jak wyglądasz, koleś? Siedzimy z odpowiedzialnym menadżerem przez około 15 minut w oszołomieniu, próbując nawiązać komunikację z tym Voyagerem 1, po czym w firmowym e-mailu pojawia się wiadomość, że zakończył. Czy będziemy korespondować mailowo? Dlaczego nie? Wygodne, prawda? No cóż, uspokójmy się. Proces już trwa, nie ma odwrotu. Przeczytaj wiadomość ponownie. "Skończyłem". Co skończyłeś? Gdzie? Gdzie mam cię szukać? Tutaj rozumiesz, dlaczego 4 godziny na wydanie są normalne. Dostajemy szok rozwojowy, ale kończymy wydanie. Nie ma już pragnienia uwolnienia.

Akt 2. Nie ta wersja.
Następne wydanie. Po zdobyciu doświadczenia zaczynamy tworzyć listy niezbędnego oprogramowania i bibliotek dla serwera dla administratorów, wskazując wersje dla niektórych. Jak zawsze otrzymujemy słaby sygnał radiowy, że administrator coś tam dokończył. Rozpoczyna się test regresyjny, który sam trwa około godziny. Wszystko wydaje się działać, ale jest jeden krytyczny błąd. Ważna funkcja nie działa. Następne kilka godzin to taniec z tamburynami, wróżenie na fusach kawy i szczegółowe przeglądanie każdego fragmentu kodu. Administrator twierdzi, że zrobił już wszystko. Aplikacja napisana przez nieuczciwych programistów nie działa, ale serwer działa. Jakieś pytania do niego? Po godzinie prosimy administratora o przesłanie wersji biblioteki na serwerze produkcyjnym do chatu i bingo – to nie jest ta, której potrzebujemy. Prosimy administratora o zainstalowanie wymaganej wersji, ale w odpowiedzi otrzymujemy, że nie może tego zrobić ze względu na brak tej wersji w menedżerze pakietów systemu operacyjnego. Tutaj z zakamarków pamięci menadżer pamięta, że ​​inny administrator rozwiązał już ten problem, po prostu ręcznie montując wymaganą wersję. Ale nie, nasi tego nie zrobią. Regulamin zabrania. Karl, siedzimy tu już kilka godzin, jaki jest limit czasu?! Przeżywamy kolejny szok i jakoś kończymy wydanie.

Akt 3, krótki
Pilne zgłoszenie, kluczowa funkcjonalność nie działa u jednego z użytkowników w środowisku produkcyjnym. Spędzamy kilka godzin na szturchaniu i sprawdzaniu. W środowisku deweloperskim wszystko działa. Panuje jasne zrozumienie, że dobrym pomysłem byłoby sprawdzenie logów php-fpm. W tamtym czasie w projekcie nie było systemów logujących takich jak ELK czy Prometheus. Otwieramy bilet do działu administracji, aby dał dostęp do logów php-fpm na serwerze. Tutaj musisz zrozumieć, że nie bez powodu prosimy o dostęp, nie pamiętasz o czarnej dziurze i administratorach zajętych 24 godziny na dobę, 7 dni w tygodniu? Jeśli poprosisz ich, aby spojrzeli na same dzienniki, jest to zadanie z priorytetem „nie w tym życiu”. Zgłoszenie powstało, otrzymaliśmy błyskawiczną odpowiedź od kierownika działu administracyjnego: „Nie powinieneś potrzebować dostępu do logów produkcyjnych, pisz bez błędów”. Zasłona.

Akt 4 i dalej
Wciąż zbieramy dziesiątki problemów na produkcji, spowodowanych różnymi wersjami bibliotek, nieskonfigurowanym oprogramowaniem, nieprzygotowanym obciążeniem serwera i innymi problemami. Oczywiście zdarzają się też błędy w kodzie, nie będziemy winić adminów za wszystkie grzechy, wspomnimy tylko o jeszcze jednej typowej operacji dla tego projektu. Mieliśmy całkiem sporo pracowników w tle, które zostały uruchomione przez nadzorcę, a niektóre skrypty musiały zostać dodane do cron. Czasami ci sami pracownicy przestawali pracować. Obciążenie serwera kolejek rosło błyskawicznie, a smutni użytkownicy patrzyli na wirujący moduł ładujący. Aby szybko naprawić takich pracowników, wystarczyło ich ponownie uruchomić, ale znowu mógł to zrobić tylko administrator. Podczas wykonywania tak podstawowej operacji mógł minąć cały dzień. Tutaj oczywiście warto zaznaczyć, że nieuczciwi programiści powinni pisać robotniki tak, aby się nie zawieszały, natomiast gdy już ulegną, dobrze byłoby zrozumieć, dlaczego – co czasami jest niemożliwe ze względu na brak dostępu do produkcji – oczywiście i w konsekwencji brak logów od dewelopera.

Transfiguracja.
Wytrzymując to wszystko dość długo, wraz z zespołem zaczęliśmy obierać kierunek, który był dla nas bardziej pomyślny. Podsumowując, jakie problemy napotkaliśmy?

• Brak dobrej jakości komunikacji pomiędzy programistami a administracją
• Okazuje się, że administratorzy w ogóle nie rozumieją, jak zbudowana jest aplikacja, jakie ma zależności i jak działa.
• Programiści nie rozumieją, jak działa środowisko produkcyjne i w rezultacie nie mogą skutecznie reagować na problemy.
• Proces wdrażania trwa zbyt długo.
• Niestabilne wydania.

Co my zrobiliśmy?
Dla każdego wydania została wygenerowana lista Uwagi do wydania, która zawierała listę pracy, którą należy wykonać na serwerze, aby następna wersja mogła działać. Lista zawierała kilka sekcji, prace, które powinien wykonać administrator, osoba odpowiedzialna za wydanie i programista. Programiści otrzymali dostęp inny niż root do wszystkich serwerów produkcyjnych, co ogólnie przyspieszyło rozwój, a w szczególności rozwiązywanie problemów. Deweloperzy mają też wiedzę, jak działa produkcja, na jakie usługi jest podzielona, ​​gdzie i ile kosztują repliki. Część ładunków bojowych stała się wyraźniejsza, co niewątpliwie wpływa na jakość kodu. Komunikacja podczas procesu wydawniczego odbywała się na czacie jednego z komunikatorów internetowych. Po pierwsze, mieliśmy dziennik wszystkich działań, a po drugie, komunikacja odbywała się w bliższym otoczeniu. Posiadanie historii działań nie raz pozwoliło nowym pracownikom szybciej rozwiązywać problemy. To paradoks, ale często pomagało to samym administratorom. Nie podejmę się tego powiedzieć na pewno, ale wydaje mi się, że administratorzy zaczęli lepiej rozumieć, jak działa projekt i jak jest napisany. Czasami nawet dzieliliśmy się ze sobą niektórymi szczegółami. Średni czas wydania został skrócony do godziny. Czasem kończyliśmy w 30-40 minut. Liczba błędów znacznie, jeśli nie dziesięciokrotnie, spadła. Oczywiście na skrócenie czasu wydania wpłynęły również inne czynniki, takie jak autotesty. Po każdym wydaniu zaczęliśmy przeprowadzać retrospektywy. Tak, aby cały zespół miał pojęcie o tym, co nowego, co zmienione, a co usunięte. Niestety admini nie zawsze do nich przychodzili, cóż, admini są zajęci... Moja satysfakcja z pracy jako programisty niewątpliwie wzrosła. Kiedy potrafisz szybko rozwiązać niemal każdy problem, który leży w Twoim obszarze kompetencji, czujesz się na szczycie. Później zrozumiem, że w pewnym stopniu wprowadziliśmy kulturę devops, oczywiście nie do końca, ale już ten początek transformacji zrobił wrażenie.

Historia trzecia
Uruchomienie. Jeden administrator, mały dział rozwoju. Po przyjeździe jestem zupełnym zerem, bo... Nie mam do tego dostępu nigdzie poza pocztą. Piszemy do administratora i prosimy o dostęp. Dodatkowo pojawia się informacja, że ​​jest on świadomy istnienia nowego pracownika i konieczności wydania loginów/haseł. Dają dostęp z repozytorium i VPN. Po co dawać dostęp do wiki, teamcity, rundesk? Bezużyteczne rzeczy dla osoby, która została wezwana do napisania całej części backendowej. Dopiero z czasem uzyskujemy dostęp do niektórych narzędzi. Przyjazd oczywiście spotkał się z nieufnością. Próbuję powoli oswoić się z działaniem infrastruktury projektu poprzez czaty i zadając pytania naprowadzające. W zasadzie nic nie rozpoznaję. Produkcja to ta sama czarna skrzynka, co poprzednio. Co więcej, nawet serwery sceniczne używane do testów to czarna skrzynka. Nie możemy zrobić nic innego, jak tylko wdrożyć tam gałąź z Git. Nie możemy również skonfigurować naszej aplikacji jak plików .env. Dostęp do takich operacji nie jest przyznawany. Musisz błagać o zmianę linii w konfiguracji aplikacji na serwerze testowym. (Istnieje teoria, że ​​administratorzy muszą czuć się ważni w projekcie; jeśli nie zostaną poproszeni o zmianę linii w konfiguracjach, po prostu nie będą potrzebni). Cóż, jak zawsze, czyż nie jest to wygodne? To szybko staje się nudne, po bezpośredniej rozmowie z administratorem dowiadujemy się, że programiści urodzili się, aby pisać zły kod, są z natury niekompetentnymi osobami i lepiej trzymać ich z dala od produkcji. Ale tutaj także z serwerów testowych, na wszelki wypadek. Konflikt szybko się nasila. Brak komunikacji z administratorem. Sytuację pogarsza fakt, że jest sam. Poniżej znajduje się typowy obraz. Uwolnienie. Niektóre funkcje nie działają. Długo zajmuje nam zorientowanie się, co się dzieje, na czacie wrzucane są różne pomysły programistów, ale admin w takiej sytuacji zwykle zakłada, że ​​winę ponoszą programiści. Potem pisze na czacie, czekaj, poprawiłem go. Gdy jesteśmy proszeni o pozostawienie historii zawierającej informację o problemie, otrzymujemy toksyczne wymówki. Na przykład nie wtykaj nosa tam, gdzie nie powinien. Programiści muszą pisać kod. Sytuacja, gdy wiele ruchów ciała w projekcie przechodzi przez jedną osobę i tylko ona ma dostęp do wykonywania operacji, których wszyscy potrzebują, jest niezwykle smutna. Taka osoba to straszne wąskie gardło. Jeśli pomysły Devops dążą do skrócenia czasu wprowadzenia produktu na rynek, to tacy ludzie są najgorszym wrogiem pomysłów Devops. Niestety, tutaj kurtyna się zamyka.

PS Po krótkiej rozmowie na temat programistów kontra administratorów na czatach z ludźmi spotkałem ludzi, którzy podzielali mój ból. Ale byli też tacy, którzy twierdzili, że nigdy nie spotkali się z czymś takim. Na jednej z konferencji Devops zapytałem Antona Isanina (Alfa Bank), jak poradzili sobie z problemem wąskiego gardła w postaci administratorów, na co odpowiedział: „Zastąpiliśmy je przyciskami”. Przy okazji podcast z jego udziałem. Chciałbym wierzyć, że dobrych adminów jest o wiele więcej niż wrogów. I tak, zdjęcie na początku to prawdziwa korespondencja.

Źródło: www.habr.com