Terytoria IT

Kilka dni temu wysłałem IT do psychiatry. Dziś serwuję (za Just Enough Developed Infrastructure) IT wraz z otoczeniem zobrazowane na mapie - The Map is not the Territory: The IT-World Anno 2010. Klienci, użytkownicy, wielka czapa wszelkich form zarządzania, rozwój, testowanie i utrzymanie, bezpiecznicy, service desk oraz infrastruktura.
Ładnie to wygląda, ale co to oznacza w praktyce? W realnym świecie mamy np.:

1. Podział na biednych i bogatych. Jeden dział ma lepsze "przełożenie" i konsumuje pieniądze potrzebne innym działom.
2. Strefy skażenia. Nikt nie chce ich nawet dotykać (syndrom "to nie moje").
3. Wojenki. Jeden lokalny kacyk robi na złość drugiemu za nie swoje pieniądze i trzeba go jakoś obchodzić, żeby dopiąć celu.
4. Każdy sobie rzepkę skrobie. Brak zdolności współpracy w obliczu nadciągającej katastrofy.

Brzmi znajomo?

DevOps - utopia czy źródło przewagi konkurencyjnej?

Czy deweloperzy powinni mieć dostęp do systemów produkcyjnych?
Odpowiedź na to pytanie wydaje się prosta. Oczywiście, że tak/nie! (zależnie, kto odpowiada). ;-)

 

W dużych firmach o strukturze silosowej zwykle podział ten jest "naturalny". Z kolei w małych firmach, gdzie wszyscy zajmują się wszystkim, podziału takiego nie ma. Rozdzielenie rozwoju systemów od ich utrzymania ma niewątpliwie pewne zalety, ale wydaje się, że zyskuje ostatnio na popularności trend odwrotny - nazwany DevOps.

Aby dobrać właściwy model, należy przeanalizować potrzeby i ograniczenia konkretnej organizacji. Osobiście skupiłbym się przede wszystkim na następujących czynnikach:

• niezawodność/dostępność - deweloperzy bez doświadczenia utrzymaniowego mogą zwyczajnie zagrozić stabilności środowiska produkcyjnego
• integralność - deweloper majstrując przy wnętrzu aplikacji na produkcji może np. rozspójnić dane
• poufność - deweloper z dostępem do produkcji to dodatkowe potencjalne źródło wycieku danych
• wymogi formalne - przepisy prawa mogą wymuszać na danej organizacji wyraźne odseparowanie rozwoju systemów od środowiska produkcyjnego
• generyczność aplikacji - system może być rozwijany pod to jedno, konkretne wdrożenie i wymaga głębokiej wiedzy o zachowaniu systemu na produkcji
• zmienność - systemy bywają modyfikowane bardzo często lub np. raz na kilka lat
• skuteczność - rozwiązywanie problemów bez dostępu do produkcji może być trudne, długotrwałe, a przez to kosztowne
• procedury i struktura firmy - procedury bywają stosowane bezmyślnie, dodatkowo rozdział rozwoju od utrzymania generuje więcej stanowisk dla menedżerów, którzy mogą mieć słabą komunikację lub wręcz konkurować

Tak więc należy ustalić, czy w danej sytuacji deweloper na produkcji bardziej szkodzi czy pomaga? I jeśli nie ma naprawdę dobrych powodów uzasadniających ścisłą separację rozwoju od eksploatacji, tej separacji warto po prostu unikać jako szkodliwego narzutu. :)

Niektórzy idą dalej i łączą obie funkcje: rozwój i eksploatację (we code and run). Wydaje mi się, że to nie zawsze ma sens, np. w przypadku aplikacji biznesowych, gdzie duży wysiłek dewelopmentu to prace analityczne. Ale w przypadku aplikacji webowych, tolerujących krótkotrwałe przestoje i zdolnych testować nowe funkcjonalności na końcowych użytkownikach - jak najbardziej.

Sporo ciekawych uwag na ten temat można przeczytać we wpisie Should Developers have Access to Production? oraz jego komentarzach.

 

Tematyka zaszczepiania DevOps nie tylko przy utrzymaniu środowisk web, ale w organizacjach typowo biznesowych (w tym przekonywania menedżerów do tego podejścia), jest także tematem niniejszych paneli InfoQ:

• DevOps outside of Web Operations
• Making the Business Case

Uczestnicy zwracają w nich uwagę m.in. na:

• model DevOps to nie zwykła zmiana organizacyjna lecz zmiana kultury (rozbijanie silosów) i nie należy jej wprowadzać odgórnie, raczej przez dobry przykład
• można pokazać DevOps jako podejście ułatwiające osiągnięcie celów biznesowych organizacji
• istotne jest wcześniejsze ustalenie dobrych metryk (KPI) - bez tego nie da się menedżerom pokazać, czy zmiana cokolwiek poprawiła (np. skrócony TTM)
• metryki należy monitorować i stopniowo doskonalić organizację
• dla menedżerów wyższego szczebla często nie liczą się już liczby, lecz zaszczepienie wizji

 

Podsumuję cytatem z posta What Is This Devops Thing, Anyway?

Devop requires a certain state of mind. It's an attitude which says: I'm going to make a difference, I'm going to cooperate and communicate, and I'm going to understand that in the business of delivering great software, we're all in it together. If you're a sysadmin, this means spending time with the developers. (...) If you're a developer, go and make friends with your sysadmins. Don't view them as lower life forms, or as people to lob problems to. Go and join in - pair with them.

Brzmi jak utopia? ;-)

Narzut protokołów na łączu ADSL

Technologia ATM wydaje się dziś nieco skostniała, ale tu i ówdzie trzyma się nieźle. :) Dlatego warto czasem wiedzieć co jest na rzeczy, np. gdy klient  nie może wysycić swojego wypasionego łącza ADSL-owego ruchem IP.

Narzut wprowadzany przez łącze ADSL jest dwojaki i wynika z:

• enkapsulacji np. PPPoE
• warstwy adaptacji np. AAL5, która wprowadza szczególnie wielki narzut dla małych pakietów (np. TCP ACK)

To, z czym wiele osób ma problem to fakt, że łącze ADSL z "ATM pod spodem" choć ma stałą przepustowość (ustaloną w komórkach na sekundę, a komórka ma zawsze 53B), to w warstwie IP nie jest ona stała. Zależy od wielkości przesyłanych pakietów IP, ze względu na zmienność narzutu. Często przyjmuje się pewną uśrednioną wielkość narzutu dla średniego rozmiaru pakietów IP w obserwowanym ruchu i dodaje gratis użytkownikowi - w pewnych sytuacjach użytkownik może więc zaobserwować, że łącze transmituje dane szybciej, niż by to wynikało z oferty, którą zakupił. ;)

Jak wielki jest to narzut, ładnie uświadamia fachowiec we wpisie: ADSL Overhead. Pod wpisem wywiązała się także interesująca dyskusja nt. doboru optymalnego MTU dla łączy ADSL z enkapsulacją PPPoE i PPPoA.

Popularność i żywotność tego jakże pokręconego rozwiązania daje się łatwo wyjaśnić: dostarcza łatwość zarządzania tak podłączoną bazą klientów nawet przy bardzo dużych rozmiarach sieci. Istnieją sieci czysto Ethernetowe, które - choć nie musiałyby - wdrażają PPPoE tylko po to, żeby sobie to zarządzanie ułatwić.

OSEC Barcamp - czerwiec 2010

Kilka dni temu odwiedziłem klub studencki "Dziekanat 161" na SGGW, gdzie odbywał się Barcamp - kameralna impreza o smaku open source, w cieniu której promuje się jej organizator czyli OSEC. ;)

Gwiazdą wieczoru był Michał Gruchała z GG Network S.A., opowiadający o zastosowaniach open source w zarządzaniu infrastrukturą dla znanego komunikatora i innych projektów tej spółki.

Jeśli mam być szczery, rozwiązania wypracowane przez Allegro lub naszą-klasę, prezentowane na różnych konferencjach np. PLNOG, wydają się ciekawsze.

Audytorium było wyraźnie zaskoczone:

• brakiem redundancji geograficznej - tylko jedno datacenter (i tylko 300 fizycznych serwerów)
• polityką aktualizacji systemów - zgodne z zasadą "działa, to nie ruszaj" (delikatna sugestia, że na serwerach backendowych pomija się nawet poprawki bezpieczeństwa), a jak nie działa - to zaoraj od nowa
• brakiem uzasadnienia dla strategicznych wyborów oprogramowania np. wybór Xen-a jako rozwiązania do wirtualizacji podyktowany faktem, że "był w Debianie"
• wyborem leciwego już Nagiosa jako rozwiąznia fault management

Moją uwagę zwrócił także rozmiar opartej o collectd instalacji performance management - aż 300 tys. plików RRD. Obciążenie podsystemu dyskowego było tak wielkie, że wykorzystano w tym miejscu dyski SSD. Postaram się w jednym z kolejnych wpisów poświęcić nieco uwagi dużym instalacjom RRDtoola.

W drugiej części spotkania Łukasz Podkalicki prezentował swój projekt fstorage - będące w początkowym stadium rozwoju rozproszone repozytorium plików i danych strumieniowych np. do zastosowań webowych, mające zaadresować słabości innych rozwiązań (autor często odnosił się do MogileFS).

Audytorium zwrociło uwagę, że autor skupiając się na deweloperce wyraźnie zaniedbał otoczenie projektu warunkujące o być albo nie być - stronę, dokumentację instalacyjną, forum użytkowników, narzędzie śledzenia błędów.


Całość okraszona była browarami i ciepłą strawą, a od czasu do czasu prelekcje przerywał barman z głośnym shakerem i zbłąkane studentki uciekające na widok sali geeków. ;)

knowledge sharing

Niektórzy specjaliści IT uważają się za niezastąpionych. Istotnie, niektórzy są wybitnymi fachowcami.

Niestety, trudność z zastąpienia ich nie zawsze wynika li tylko z ich kompetencji, ale także z tego, że zazdrośnie strzegą swej wiedzy i nie dokumentują pracy.


Tego typu postawa może wynikać z różnych przyczyn. Chyba najbardziej typowe to:

• Zazdrość, że sami ponieśli duży nakład pracy na naukę, a inni mieliby tę wiedzę otrzymać "na talerzu".
• Chęć utrzymania uprzywilejowanej pozycji poprzez niedopuszczanie konkurencji.
• Lenistwo - "po co to dokumentować, każdy może sobie przejrzeć listę procesów i przegrepować /etc", "to oczywiste" itd.

Nikt nie oczekuje, że ekspert podzieli się całą swoją wiedzą za darmo. Ale sytuację, w której tego typu postawy blokują upowszechnienie wiedzy w zakresie potrzebnym do pracy zespołu, uważam za szkodliwą.

Miałem kiedyś przyjemność kierować zespołem administratorów IT. Wiedza o utrzymywanych systemach była rozproszona w głowach różnych osób, w tym także byłych pracowników. :) Kilkugodzinny czas rozwiązania awarii z SLA był nie do utrzymania.

Jednym z moich pierwszych ruchów było wprowadzenie wiki i zachęcenie zespołu do dokumentowania utrzymywanych systemów: stanu obecnego (AS-IS) oraz Przypadków Użycia dotyczących tych systemów (np. cykliczne czynności administracyjne lub sposób rozwiązywania typowych zgłoszeń dotyczących danego systemu). Chodziło o osiągnięcie stanu, w którym każdego można zastąpić - przynajmniej krótkookresowo.

Zalety wiki to m.in.

• łatwość edycji dokumentów - klikasz "edytuj" i piszesz, nie myślisz o rozdziałach, czcionkach itd.
• tworzenie sieci powiązanych dokumentów - wiki rośnie za "skojarzeniami", w miejscach gdzie są najbardziej palące braki
• brak rygoru co do struktury i kompletności - dokument może mieć na początku kilka zdań i stopniowo się rozrastać
• podążanie za zmianami w systemach - klasyczna dokumentacja projektowa jest bardzo obszerna i ma tendencję do utraty aktualności

Zebranie głównej wiedzy operacyjnej na wiki pozwoliło na jej upowszechnienie w świadomości administratorów i podniosło jakość usług świadczonych przez zespół. To z kolei umożliwiło swobodniejsze planowanie dyżurów oraz urlopów. Nie zagroziło zaś niczyjej pozycji zawodowej. :) Ułatwione było także wdrażanie nowych pracowników - zamiast pytać o wszystko bardziej doświadczonych kolegów, poszukiwania wiedzy rozpoczynali od wiki.

elastyczność nie zawsze jest atutem

Jednym z oczywistych atutów rozwiązań opartych o platformę PC i otwarty system operacyjy klasy UNIX jest ich niski koszt i elastyczność.

Potrzebujesz zrobić coś nietypowego? Masz rozwiązanie pudełkowe - masz problem. Masz Linuksa lub BSD? - wydziergasz sobie wszystko, choćby trzeba było zniżyć się do edycji poziomu kodu źródłowego.

Elastyczność stwarza jednak pokusę, by tworzyć rozwiązania nietypowe i skomplikowane. Pokusa ta jest silna zwłaszcza dla fanów tych systemów, który lubią udowadniać otoczeniu, że ich system może robić dosłownie wszystko.

Póki autor rozwiązania jest jedyną osobą skazaną na bezpośrednie obcowanie z nim, nie jest to wielki problem. Schody zaczynają się, gdy trzeba je później utrzymywać lub pielęgnować rękami innych pracowników.

Okazuje się, że wniesiona dodatkowa komplikacja może skutkować wzrostem nakładów czasu potrzebnych później do jej zrozumienia przez inne osoby, a koszt tego czasu może przekroczyć uzyskane wcześniej oszczędności.

Środowisko open source jest tego oczywiście świadome. Dlatego powstają rozwiązania specjalizowane, dystrybucje przeznaczone do użycia w ściśle określonej roli - zapory sieciowej, rutera, NAS-a itp. Celowo ograniczają one elastyczność systemów, na których je oparto. Użytkownik jest odcinany od powłoki, otrzymuje ograniczone CLI lub interfejs webowy. Sposób konfiguracji wzoruje się na rozwiązaniach pudełkowych. Wszystko po to, aby można się było skupić na prostym i szybkim dostarczeniu określonej funkcjonalności, bez wnikania, jak to jest zrobione "pod spodem". Nagle umniejszona elastyczność staje się nie wadą lecz atutem.


Podsumowując: wybór rozwiązań "ograniczonych" lub wręcz "drogich pudełek" dla wielu firm ma duży sens biznesowy, nawet jeśli z perspektywy fanboya systemu X nie zawsze da się go dostrzec.