Praca - trochę szczegółów - część 1

Ostatnio dość często pisałem różnym ludziom o mojej pracy w Facebooku, więc napiszę parę postów na ten temat. Na początek:

Stanowisko

Inżynier produkcji (po angielsku Production Engineer - opis stanowiska na stronie Facebooka ) - termin zapożyczony z przemysłu, raczej niespotykany w firmach informatycznych. O co w tym chodzi? To taki mix, jak w orange, między programistą a administratorem. Aby pracować na tym stanowisku nie wystarczy tylko potrafić programować - trzeba do tego znać się na sieciach oraz systemach operacyjnych. Jesteśmy rozrzuceni po całej firmie i większość ważnych/dużych komponentów ma w swoich zespołach ludzi na takim stanowisku. Ja wybrałem zespół odpowiedzialny za najmniej lubianą część każdego portalu - reklamy.

Głównym zadaniem jest zapewnienie tego, żeby komponenty za które odpowiadam były stabilne i nie miały problemów z wydajnością. Jest to bardzo ogólne pojęcie, tak samo jak i praca - opracowywanie monitoringu i alarmów, konfiguracja nowych serwerów/klastrów, pisanie skryptów do automatycznego rozwiązywania problemów, walidacji, etc. Do tego też pisanie kodu samych komponentów, ale w częściach związanych z infrastrukturą (np. migracja na nową wersje jakiegoś frameworku do komunikacji z innymi komponentami) - nie tworzymy kodu który implementuje biznesową funkcjonalność. Coś więcej? Masa - uczestniczenie w planowaniu rozwoju - też głównie od strony infrastruktury. Czy to co chcemy stworzyć będzie w stanie działać u nas - ze względu na pamięć, sieć, opóźnienia, dostępne maszyny, etc? A może jest już taki komponent, używany przez inny team, który będzie się nadawał do wykorzystania przez nas? Czy jak zwiększymy ilość przesyłanych danych to czy będzie to dalej działać? Czy możemy dostać 2x więcej serwerów pod to? A czy naprawdę je potrzebujemy? Uruchamiamy nowy klaster - ile czego tam potrzebujemy i na kiedy? Tego typu pytania są kierowane do nas.

I najgorsze zło każdego admina - dyżury telefoniczne ;-). Programiści też mają swoje, ale nasze są raczej bardziej obciążające niż ich - często pomagamy SRO (w skrócie - zajmują się utrzymaniem ciągłości pracy całego portalu - pracują w systemie zmianowym 24h/7d - w USA i Irlandii - oryginalnie aplikowałem na to stanowisko, więc darzę ich dużą sympatią :-) ) w identyfikacji który dokładnie komponent sprawia problem (SRO odpowiadają za wszystko, więc nie mają odpowiedniej wiedzy na temat poszczególnych produktów, aby móc je dokładnie zdiagnozować) a potem osobie która jest za niego odpowiedzialna w dokładnym zrozumieniu co się dzieje - czy to problem z siecią, z maszynami, nową wersją oprogramowania, albo może jakiś inny komponent, z którym on współpracuje zaczął się inaczej zachowywać? Musimy więc mieć szeroką wiedzę na temat tego co się dzieje.

Do tego często "ubieramy" różne maski - np. dla ludzi od sieci jesteśmy programistami a dla programistów jesteśmy ludźmi od sieci. Łączymy 2 różne światy - dział programistów z działem infrastruktury - formalnie należymy do tego drugiego (i dobrze - dostajemy najczęściej dużo fajniejsze koszulki niż programiści ;-) ).

Dużo tego - a to i tak nie wszystko - to główne rzeczy z którymi miałem styczność przez 2 miesiące w zespole. Jedynie dyżuru on-call jeszcze nie miałem, ale spokojnie - na początku marca wypada mój pierwszy, więc jeszcze dużo czasu - znam już dość dobrze jakieś 2-3 komponenty z jakiś 30 za które odpowiada mój zespół :-).

Nie ma więc co narzekać w pracy na nudę, ale nie jesteśmy przeładowani i wysycani z całej energii w pracy - niektóre rzeczy brzmią strasznie, ale wokół są ludzie którzy chętnie pomogą (i to naprawdę, a nie tylko tak się mówi) a robiąc takie rzeczy własnoręcznie człowiek uczy się super szybko i jest to bardzo przyjemny sposób na naukę, przynajmniej dla mnie :-).

Jest to bardzo fajne, ale wymagające stanowisko (jak w całym Facebooku). Nie jest to zdecydowanie firma do której idzie się po ciepłą posadkę przed emeryturą - tu się idzie jeśli chce się uczyć masy nowych rzeczy przy tworzeniu innych fajnych rzeczy. Go big or go home.