Mam coś z cyklu ciemne strony kodowania. Dawno, dawno temu miałem stworzyć usługę do podglądania plików wszelakiej maści. Miało to wyglądać tak, że w systemie X użytkownik wybierał podgląd (na stacji, która nie rozumiała danego formatu) pliku, zlecenie wędrowało do usługi, usługa przygotowywała jpg/png i zwracała do stacji.
Niniejszy post jest częścią cyklu "Wasze Historie".
Autor: Arek
Niby prosta sprawa, bo formaty jakie miałem “podglądać” obsługiwała biblioteka Y, a reszta to prosty “plumbing”. Usługa napisana, przetestowana i wysłana do klienta. Klient sprawdził i wrzucił na tzw. produkcję… i nie działa. Błąd.
Wdrożeniowcy sprawdzali, szukali, oglądali…. nie bangla.
Całość wróciła do mnie. Więcej logów, więcej catchów, więcej wszystkiego. Kod powoli traci czytelność, ale teraz to już nie ma opcji, żeby nie działało. Release, testy, do klienta.
Akcja: BLOGvember! Post nr 14.
W listopadzie w każdy roboczy poranek na devstyle.pl znajdziesz nowy, świeżutki tekst. W sam raz do porannej kawy na dobry początek dnia.
Miłej lektury i do przeczytania jutro! :)
U klienta na środowisku testowym działa, na produkcji nie działa… wróciło do mnie. Jeszcze więcej diagnostyki i szukania, bo nie ma opcji, żeby nie działało. A błąd taki, że nic nie wiadomo. Remote debugging nie wchodził w grę a IntelliTrace-a jeszcze wtedy nie było. O mikroserwisach też nikt nie mówił mimo, że to był mikroserwis.
No nic, release, test i do klienta. U klienta na testach okej, a na produkcji klops…
Skończyło się na tym, że zostałem wysłany do klienta razem z moim dev boxem. Całkiem solidnym wielokilogramowym klockiem żelaza. Na miejscu podpinam zasilanie, klawiaturę, monitor, sieć. Sprzęt odpala i…. działa :(! Patrzę, szukam, no nie ma opcji: jest wszystko okej.
I tak z braku pomysłu snuję się po internetach. Wchodzę na jedną z popularniejszych w tamtym czasie stron – snuję się w poszukiwaniu jakiejś inspiracji. Tak od niechcenia rzucam do znajomego admina, że nie mają specjalnie zabezpieczonej sieci, bo mogę wejść na abc. On mi na to: bo wiesz, masz takie nasze IP, normalni userzy są na innej puli.
HA!
To wepnij mnie na takie normalne IP, takie od zwykłego usera. Przepiął mnie, odpalam i bam….. błąd w miejscu zupełnie nie takim jak bym się spodziewał. To nie tak, ze usługa miała jakiś problem, usługa była okej, to klient nie wysyłał requestów. Bo miał exception. Szybki reasearch i jedna, dosłownie jedna linijka kodu dopisana i wszystko bangla jak ta lala. W jednym miejscu brakowało DefaultCredentials…
Wyglądało to tak: w sieci była dosyć konkretna zapora zintegrowana z domeną, więc per user można było blokować strony (dzięki temu admini mieli pokaźny katalog stron z kategorii radosne ślizgacze pod jednym z nazwisk w firmie ;) ). Jeśli w kliencie nie ustawiłem tego cholernego DefaultCredentials to kontekst domeny nie był przekazywany i firewall obcinał cały ruch, bo nie wiedział do kogo on należy. Nie wiedział więc, jakie policy zapodać.
Cała historia trwała chyba z 2-3 miesiące. 2-3 miesiące, aby napisać JEDNĄ linijkę kodu. No cóż, czasem i tak bywa, taki zawód, taka robota ;)
2-3 miesiące – autor musi mieć niezłą odporność na stres :)
Dzięki Adam :) ponieważ to szło przez testy w dwóch organizacjach to miało swój poślizg i się ciągnęło. Takie czasem jest życie :)
Dzięki za takie historie!
Ja jak coś mi 3 dzień nie działa a działa, to już dostaję autoagresji, a mojemu ciału ubywa naskórka i włosów a przybywa siniaków, po tygodniu zaś popadam w ciężką depresję i uznaję że się nie znam i że w ogóle nieporozumieniem jest fakt, że zajmuję się właśnie tym- a z tego co ty piszesz, nie takie rzeczy się zdarzają i ludzie potrafią podołać. Szacun dla Ciebie!
lol, a wystarczyło tylko testować na produkcji :)
a wystarczyło w pełni odwzorować środowisko produkcyjne ;D
Piatkosia, szkoda zdrowia na autoagresję :) W tej historii “u mnie działało” :) Zawsze znajdzie się jakiś problem nie do rozwiązania – aż go rozwiążesz, wtedy problem jest prosty, exp i mana rośnie. Masz głowę i doświadczenie więc jak nie da się rozwiązać problemu to może warto zrobić spacerek, przerwę i coś wykombinujesz :) a depresje zostawmy Holandii.
jaką depresję? oni tam tyle jarają, że im nie grozi :)
Dobra historia. Arek opisałeś – wybacz może to za ostre stwierdzenie, nie znam szczegółów – problemy z wykonaniem wdrożeń. Dzisiaj to domena DevOps a faktycznie parę lat temu nie miało jeszcze swojej nazwy. No to po kolei.
1. Środowisko testowe miało inną konfigurację niż produkcja. Niestety budowa środowiska testowego dokładnie odwzorowującego produkcję może być dość skomplikowana (czytaj: kosztowna), więc niestety tak bywa. Ale mogło też być tak, że nikt tego nie dopilnował :-).
2. Piszesz że dodawałeś coraz to kolejne logi. Ale jeśli żądania do usługi nie dochodziły, to logi musiały być puste! Nikt tego nie sprawdził? Pusty log przychodzących żądań od razu sugeruje sprawdzenie w warstwie sieciowej.
3. Procedura wdrożenia, a właściwie weryfikacji poprawności wdrożenia, może przewidywać kontrolowane zawołanie wdrożonej usługi ze środowiska zbliżonego do środowiska klienta. Tego nie było? Często w ramach usług dodaje się operacje typu echo lub ping. One służą właśnie do weryfikacji czy połączenie z usługą da się nawiązać, czy są dobrze przekazywane poświadczenia itp., a jednocześnie te operacje „nie mieszają” w biznesie.
4. Napisałeś: „klient nie wysyłał requestów. Bo miał exception”. Czy ten klient miał logi w których wyjątek został zapisany? Ktoś to sprawdził?
Stawiam tezę, że sprawna realizacja punktów (2) do (4) pozwoliłaby namierzyć problem w dzień góra dwa. Z drugiej strony takie historie dają +100 do doświadczenia.
Dzięki RBL, To się działo kiedy DevOpsi jeszcze nie wiedzieli, że są DevOpsami ;)
AD1. Środowisko testowe było wycinkiem produkcyjnego (>200 komputerów w prod). No i zawsze przecież tak jest, na testowym nie ma takich samych warunków, choćby nie ma takiego samego obciążenia.
AD.2 Logi nie były puste. Wtedy nie wiedziałem czego szukać i nie przyszło mi do głowy że nic nie wychodzi z klienta. Post factum wydaje się to oczywiste ale wtedy to takie nie było.
AD.3 Tyle co mogę powiedzieć to nie była usługa działająca po http czy wcf więc było trudniej. Co do ping/echo to nie pamiętam czy było zaimplementowane czy nie.
AD.4 patrz AD.2 logi były sprawdzane, poszukiwania były ostre a mimo wszystko bez skuteczne. Dlatego szybciej i skuteczniej było pojechać z całym kompem na miejsce.
Co do tezy, też sądziliśmy, że to wszystko wystarczy. Jednak tamte technologie i dostęp jaki mieliśmy nie pozwalał to ogarnąć inaczej. Weź pod uwagę, że żaden cloud a serwery i desktopy. Klient też miał swoje ograniczenia i suma sumarum tą jedną cholerną linikję dopisywałem tak długi czas :)
Zobacz jaki postęp we wszystkich dziedzinach. I narzędzia i procedury (DevOps) i w końcu my (doświadczenie).
Fajna historia, niestety często się zdarzają podobne :| I DevOpsi nie do końca sa od tego :) – DevOps :)
Ta historia jakoś brzmi znajomo :)
Ja akurat jestem po drugiej stronie tej utrzymaniowej-administracyjnej. Wielokrotnie byłem w takiej sytuacji jak teks powyżej. Można to nazwać świętą wojną. Administrator na developera, developer na admina, a prawda leży po środku wszystko trzeba zwalić na project managera albo konsultanta ;)
Niekiedy odwzorowanie środowiska produkcyjnego nie da efektu, bo są różnego rodzaju ograniczenia. Trzeba wtedy kombinować. Nic nie poradzisz.
Kiedyś środowiska były mniej skomplikowane, miało się serwer bazy danych, serwer aplikacji (często na jednej maszynie), jakić firewall jeśli aplikacja była wypuszczona na zewnątrz i działało. Dzisiaj środowiska są czasami tak skomplikowane że bez kilkutomowej dokumentacji nie jesteś w stanie się pozbierać. W dzisiejszych czasach za system odpowiada zespół gdzie wiedza jest rozproszona po wielu specjalistach i łatwiej jest na popełnienie błędu lub znalezienie błędu.
2-3 miesiące to taki średni wynik. Coś na teście może nie działać, problem pojawia się jak przestaje działać na produkcji :) a działało wcześniej.