eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingProgramowanie a system operacyjnyRe: Programowanie a system operacyjny
  • Data: 2013-01-22 23:34:12
    Temat: Re: Programowanie a system operacyjny
    Od: "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: