5 grzechów glownych systems

Ostatnio zagłębiliśmy się w 5 Grzechów Głównych Programisty i Testera. Przyszedł czas na Systemsa, jesteście gotowi?

1. Brak Backupu

W firmie pada ważny serwer i trzeba natychmiast go przywrócić. Masz backup? Uruchamiasz przywracanie i idziesz na kawę. Nie masz backupu? Przygotuj się na horror. Przez najbliższe kilka godzin będziesz na wyścigi stawiał serwer i konfigurował usługi, przy akompaniamencie wrzasków Project Managera.

Przy założeniu, że był to serwer usługowy, który nie był jedynym magazynem ważnych dla firmy treści – w takim wypadku przeniesiesz się natychmiast w IX krąg dantejskiego piekła i bogatszy o nowe doświadczenia będziesz uroczyście ślubował wyznawanemu przez siebie bóstwu, że już NIGDY nie zgrzeszysz brakiem backupu.

Jest to najgorszy grzech jaki może popełnić administrator.  Jak powiedział T.E Ronneberg – „Being too busy to worry about backup, is like being too busy driving a car to put on the seatbelt.”

2. DDI
(z ang. Disaster Driven Infrastructure)

Istotą chyba każdego aspektu IT jest ciągły rozwój. Niestety, zaskakująco duża liczba administratorów jest zdania, że system zaprojektowany w 1999 roku, z myślą o firmie liczącej 30 pracowników nie wymaga modernizacji 16 lat później, gdy liczba pracowników dawno przekroczyła pół tysiąca. Taki administrator dowiaduje się o ogromie swojego błędu w jeden sposób – gdy cały system ulega przeciążeniu lub awarii i z całą mocą wybucha mu w twarz.

W dużym skrócie: Infrastruktura, podobnie jak każda inna dziedzina IT, wymaga ciągłego myślenia o potencjalnych zagrożeniach i problemach i podejmowania działań by im zapobiec. Nie pomyślałeś o zapasowym łączu internetowym? Przypomnisz sobie gdy Twój dostawca zaliczy dwugodzinną awarię. Nie wymuszasz szyfrowania dysków w firmie? Nauczysz się gdy Solution Architect zamelduje Ci kradzież komputera, na którym miał zapisane hasła do wszystkich firmowych systemów. Wiecie o co mi chodzi…

3. Brak automatyzacji

Czas administratora jest cenny. Jeśli robisz coś więcej niż raz, pomyśl czy nie warto tego zautomatyzować.

Automatyzacja jest zagadnieniem o tyle specyficznym, że jej brak odczuwa się nagle. Nie wdrożyłeś WDSa (Windows Deployment Service)? Najbliższe 2 tygodnie spędzisz instalując system i oprogramowanie na 100 nowych firmowych laptopach. Albo ręcznie stawiając 20 identycznych serwerów, bo Twój hypervisor nie obsługuje szablonów…

Obecnie na rynku można znaleźć narzędzia umożliwiające automatyzację chyba każdego powtarzalnego procesu. Przy odpowiednio zoptymalizowanej infrastrukturze, możesz w zasadzie wyzbyć się konieczności wykonywania nudnych, rutynowych czynności i prawie cały swój czas poświęcać na wdrażanie nowych rozwiązań i technologii (a resztę na piłkarzyki i grę na konsoli)

4. Security through obscurity.

Jest to temat dość kontrowersyjny, gdyż bezpieczeństwo w każdym środowisku IT opiera się w pewnym stopniu na zachowaniu poufności. Jednak, moim zdaniem, o grzechu Security through obscurity możemy mówić wtedy gdy niejawność informacji (haseł, adresów IP, portów) jest jedyną linią obrony.

Swoim zwyczajem posłużę się przykładem. W firmie X sieć WiFi jest zabezpieczona hasłem (niezmienionym od 2 lat) i umożliwia nieograniczony dostęp do wewnętrznej sieci firmy.

Osoba znająca hasło (były pracownik, osoba, która weszła w jego posiadanie np. wyczytując je z listy zapamiętanych haseł na smartfonie/tablecie/laptopie pracownika) może z samochodu zaparkowanego przed siedzibą firmy zainfekować komputery złośliwym oprogramowaniem, podsłuchiwać ruch w sieci, wysyłać wiadomości email z firmowego serwera bez autoryzacji (bo serwer nie wymaga uwierzytelnienia od komputerów z sieci lokalnej) itd. Żeby było śmieszniej, firma X istnieje naprawdę.

Jak powinna być zabezpieczona taka sieć WiFi? Wystarczy autoryzować użytkowników przy pomocy zewnętrznego serwera (RADIUS), ograniczyć uprawnienia użytkowników WiFi lub wymagać autoryzacji maszyny klienckiej  (np. przez Active Directory).

5. Nieumiejętne wdrażanie nowych rozwiązań

Ostatni grzech jest sformułowany dość ogólnie (narzucono mi limit 5 grzechów – muszę sobie jakoś z tym poradzić). Dość często spotykanym zjawiskiem w IT jest wdrażanie nowych technologii  bez odpowiedniego zdefiniowania oczekiwań wobec nich, bez testowania i bez dokumentacji.

Po raz kolejny oprę się na konkretnym przykładzie. Załóżmy, że wdrażamy w firmie platformę wirtualizacji serwerów. Po pierwsze, powinniśmy wiedzieć dokładnie czego od takiej technologii  oczekujemy. Czy ma wspierać migrację między hostami bez wyłączania maszyny albo redundancję. Kryteriów może być wiele. Najczęstszy błąd popełniany na tym etapie to wybranie konkretnego produktu  – bo kolega mówił że jest fajny, bo ładnie wygląda, bo oferują szkolenia na Bahamach.

Jeśli nawet chcemy wdrożyć konkretny produkt, warto spojrzeć czy nie ma lepszej/tańszej alternatywy. Zanim zaczniemy robić cokolwiek, wypiszmy sobie czego oczekujemy od danego rozwiązania. Wtedy już na samym początku będziemy w stanie zawęzić listę produktów do przetestowania.

Po drugie, przetestujmy produkt. Przetestujmy go na etapie PoC, przetestujmy go w sandboksie, przetestujmy go na wybranych serwerach/użytkownikach/telefonach czy czymkolwiek na czym produkt ma działać. Jeśli odpuścimy sobie ten etap, uruchomienie nowej technologii może z sukcesu przerodzić się w koszmar i skończycie jako wrak człowieka, opisując swojemu psychoanalitykowi koszmary w których ciągle musicie ręcznie usuwać śmieci po snapshotach z hypervisorów (na Ciebie patrzę XenServerze).

Na koniec, sporządźmy dokumentacje. Tak naprawdę dokumentację powinniśmy sporządzać na bieżąco (czy to opisując deployment, czy komentując skrypty). Gdy macie dobrze opisane rozwiązanie dużo prościej wdrażać w nie nowych ludzi, modyfikować je czy deployować. Jak za 2 lata okaże się że coś trzeba zmienić, łatwiej wyszukać odpowiedni punkt skryptu po komentarzach, niż śledzić cały jego przebieg (albo przebieg kilku/kilkudziesięciu skryptów, bo nie pamiętacie gdzie co było).

Powyższa lista jest oczywiście moim subiektywnym zestawieniem opartym o moje dotychczasowe (traumatyczne) przeżycia z IT i rozmaite zasłyszane anegdoty. W każdym razie – mam nadzieję, że pomoże ona komuś uniknąć kilku błędów.

Myślisz, że ten wpis pomoże Twoim znajomym systemsom unikać błędów? Podziel się z nimi treścią artykułu.