On 2013-01-22, PK <P...@n...com> wrote:
[cut-n-paste]
> Bez obrazy i bez nerwów - szczerze pytam, bo nie wiem.

Tę część odebrałem jako szczere zainteresowanie i absolutnie się nie
obrażam.

> BTW: Nie wiem jak to jest teraz, ale kilka lat temu to się ludzie
> z administratorów raczej nabijali. Kiedy studiowałem informatykę,
> popularne były żarty o byciu administratorem po studiach (trochę jak
> o kserowaniu po ekonomii i wykładaniu glazury po fizyce :)).
> Naprawdę masz taką fajną i dobrze płatną pracę, czy po prostu trochę
> koloryzujesz?

Naprawdę mam taką fajną robotę. Ustalmy tylko od razu, że trochę czymś
innym jest coś, co ostatnimi czasy nazywam on-site supportem (pomoc
użytkownikom, opieka nad desktopami, również konserwacja drukarek
i innego sprzętu okołokomputerowego), trochę innym jest zarządzanie
siecią, a jeszcze czymś innym -- serwerami.

Ja się zajmuję tym ostatnim, konkretnie -- serwerami linuksowymi, stroną
systemu operacyjnego. W zespole jest nas około dziesięciu, a pod opieką
mamy Red Haty ({4,5,6} x {i386,x86_64}) w liczbie 500+, używane przez
programistów w kilkunastu oddziałach (bliżej 20 niż 10; nie pamiętam
dokładnie).

Programiści używają głównie toolboksa opracowanego i rozwijanego
specjalnie na potrzeby tej organizacji. Naszym zadaniem jest
(niekoniecznie w kolejności, lista nie wyczerpująca zadań)
* instalacja i aktualizacja softu (toolboksa i softu z systemu
operacyjnego)
* doprowadzenie serwerów do i utrzymanie ich w stanie używalności
(ustawianie i rekonfiguracja klientów NIS/LDAP/NFS, hypervisorów
wirtualizacji, NTP, softu do komunikacji ze sprzętem (HP ProLiant
Support Pack), jednolitego środowiska w shellu dla użytkowników
i tak dalej)
* zbieranie i przetwarzanie informacji o pracy tych maszyn
(obciążenie, lista i wersje uruchamianych przez użytkowników
elementów wspominanego już toolboksa, operacje rekonfiguracji
wykonane na serwerach)
* utrzymanie repozytoriów z własnymi narzędziami
* opracowywanie nowych narzędzi wspomagających pracę z tą liczbą
serwerów
* przygotowanie usług (np. Samba, LXC) do wdrożenia na serwerach

Oczywiście nie jesteśmy sami. Trzeba doliczyć masę techników, którzy
montują sprzęt w szafach i instalują system operacyjny na serwerach,
ludzi ze wsparcia technicznego, którzy debuggują problemy zgłaszane
przez użytkowników i tak dalej.

Źródłem "fajności" tej roboty jest skala (ekipy w tym momencie nie
liczę, choć jest rewelacyjna). Może i 0.5k maszyn nie jest środowiskiem
_ogromnym_ (koledzy po fachu bywa że miewają i 17k pod opieką), ale
z pewnością nie co dzień się takie spotyka.

Właśnie z powodu skali dość często programuję, a między językami się
przełączam albo dlatego, że narzędzie przez nas używane jest w takim
napisane (pluginy do Fluentd to Ruby), albo dlatego, że dany język
oferuje coś, czego inne nie mają (np. Python -- obecność w świeżo
zainstalowanym systemie i moduł kliencki do XML-RPC w cenie), albo
dlatego, że model pracy jest odpowiedni do zadań (myślę tu o make), albo
trzeba zdebuggować niedziałające narzędzie (C, PHP, Java). Choć zdarzają
się też inne powody zmiany bieżącego języka.

--
Secunia non olet.
Stanislaw Klekot