Karta operacyjna

Wstęp

Karta operacyjna to zestaw 32 podstawowych i koniecznych dobrych praktyk i właściwości cechujących wysoko wydajny zespół operacyjny, czyli personel odpowiadający za sprzęt, oprogramowanie oraz infrastrukturę sieciową i serwerową. Oryginalny tekst został napisany przez Thomasa A. Limoncelli, autora świetnych książek dla administratorów: Zarządzanie czasem. Strategie dla administratorów systemówThe Practice of System and Network Administration oraz The Practice of Cloud System Administration z pomocą Petera Grace, pracownika Stack Exchange.

Ocena własnego zespołu powinna opierać się na przeczytaniu pytań oraz opisujących je esejów, a następnie udzielenie uczciwej odpowiedzi TAK/NIE. W przypadku braków lub niekompletnej implementacji poszczególnych zagadnień, należy przedyskutować w zespole ich sens i ideę oraz oczekiwane wyniki, jakie powinny one nieść w odniesieniu do własnej organizacji. Po oszacowaniu za i przeciw oraz czasochłonności ich wdrożenia można podjąć – samodzielnie lub w dyskusji z przełożonymi popartą uzyskaną wiedzą – decyzję o możliwej implementacji lub udoskonaleniu istniejących rozwiązań.

Zapraszamy do lektury kolejnych stron – nawigacja poniżej!

Spis treści

Czy to działa?

Tu nie ma żadnej magii. Możliwe, że istnieją wydajne zespoły, które nie korzystają z części zawartych tu praktyk, jednak jest bardziej prawdopodobne, że jednak znają je i aktywnie wykorzystują. Tak samo możliwe jest, że istnieją zespoły działające słabo, mimo że postępują zgodnie ze wszystkimi zawartymi tu wskazówkami, ale jest to też dalece mniej prawdopodobne. Żadna pojedyńcza technika nie poprawi działania zespołu. Problemy mogą być poważniejsze – brak wiedzy, doświadczenia czy dobrej woli może zniweczyć dowolną liczbę dobrych praktyk.

Ludzie często pytają w jaki sposób poprawić działanie zespołów administratorów. Zwykle wystarczy normalna dyskusja, aby znaleźć miejsca stanowiące fundamentalne luki, których wypełnienie pozwoli znacznie podnieść produktywność i jakość pracy oraz dostarczanych przez grupę usług.

Wskazówki tu zawarte to fundament. Podstawowa platforma pracy i komunikacji. Zignorowanie którejkolwiek będzie prowadzić do efektu domina tworząc kolejne, z czasem spiętrzające się problemy. Jeśli czujesz, że zbyt ciężko pracujesz, może rozwiązaniem nie jest pracować jeszcze dłużej, ale zatrzymać się na chwilę i spojrzeć na główne problemy, które powodują wszystkie pozostałe?

Nie tracić czasu na wylewanie wody za burtę, a raczej na znalezienie i załatanie dziury w pokładzie!

Jak używać karty?

Odpowiedz na wszystkie pytania i policz odpowiedzi na TAK. To twój wynik. Większości pytań  (prócz #2) nie trzeba tłumaczyć. Poczytaj opisy każdego pytania, aby dowiedzieć się więcej o temacie, dlaczego jest on istotny oraz poznać zasoby pozwalające na jego zgłębienie i wdrożenie.

Co powiedzieć szefowi?

Nie ma nic bardziej frustrującego, niż wiedza, że istnieją lepsze metody pracy, z których nie korzystamy. Jest więc szansa, że wystarczy że podasz swojemu szefowi link do tego opracowania i poprosisz go, aby sam wykonał ocenę TAK/NIE.

Nie traktuj tej listy jako wyroczni i nie próbuj wdrażać rozwiązań tylko dlatego, że znajdują się na liście. Pomyśl i zaimplementuj te elementy, które pozwolą ci na pozbycie się realnych problemów. Wykonaj ocenę i zmierz wyniki przed i po wdrożeniem. To pomoże ci podjąć decyzję dotyczącą wdrożenia kolejnych działań z listy.

Pudełko na napiwki

W przyszłości to opracowanie być może przyjmie formę książki. Do tego czasu jego udoskonalanie jest uzależnione od dobrowolnych datków.

Jeśli ta lista pomogła ci, weź pod uwagę przekazanie drobnej donacji autorom.

A. Działania reprezentacyjne

1. Czy zlecenia od użytkowników są śledzone w systemie ticketowym?

To tak podstawowa kwestia, że jej wyjaśnianie jest niemal bolesne.

Ludzie nie są tak dobrzy w zapamiętywaniu jak komputery. Wymaganie od administratora, że zapamięta wszystko, co mu zlecono to prosta droga do niezrealizowanych zadań.

Trzymanie zgłoszeń w bazie poprawia ich współdzielenie w zespole. Zapobiega sytuacjom, kiedy nad jednym zgłoszeniem pracują dwie osoby. Pozwala na podzielenie się bieżącą pracą w zależności od aktualnego obłożenia członków zespołu innymi zadaniami. Daje możliwość przenoszenia zadania między osobami, z zachowaniem kontekstu i historii korespondencji. Łatwo i bez opóźnień umożliwia zastępowanie nieobecnych współpracowników, na urlopie albo chorobowym.

Dzięki systemowi lepiej można zarządzać własnym czasem. Każde przerwanie pracy administratora, to średnio 7 minut, które musi poświęcić, aby powrócić do dawnego kontekstu. System ticketowy pozwala użytkownikom zgłaszać nowe problemy, czy na sprawdzanie statusu wcześniejszych zgłoszeń, bez konieczności osobistej rozmowy. Pozwala administratorom na ustalanie priorytetu rozwiązywania problemów, zamiast odpowiadania najpierw temu, kto najgłośniej krzyczy.

Managerowie mogą być dzięki niemu lepszymi managerami. Mogą śledzić i reagować jeśli jakieś zgłoszenie utknie w systemie. Mogą wychwytywać powtarzające się zgłoszenia i problemy, jako kandydatów do automatyzacji lub usprawnienia procesów i procedur. Ci, którzy ogarnięci są potrzebą mikrozarządzania mogą śledzić informacje w systemie, zamiast niepokoić co chwilę pracowników. Daje to pole do merytorycznej dyskusji ze zgłaszającymi, zamiast „marudzenia” i „biadolenia”. Czy zadanie faktycznie trwało długo? Czy tylko takie było przeświadczenie zgłaszającego? Jeśli „problem jest znany od miesięcy”, ale zgłoszono go wczoraj mamy okazję do przekazania niezadowolonemu podstawowych faktów naukowych świadczących o niemożliwości czytania w umysłach, podróży w czasie i odniesienie się do podobnych nonsensów.

System pozwala zidentyfikować okresowe problemy. Miałem szefa, który korzystał z raportów systemu ticketowego i odkrył, że 3 z 1000 użytkowników otworzyło 10% wszystkich zgłoszeń. Prosta analiza dowiodła, że mogliśmy zidentyfikować i usunąć podstawowe problemy, które to powodowały.

Użytkownicy mogą pomóc sami sobie. Jeśli nauczymy ich rzetelnego opisywania ich problemów… mogą sami dojść do rozwiązania już w trakcie jego opisywania. A jeśli nie, uzyskamy dokładny opis problemu, pozwalający trafnie analizować i zadawać kolejne pytania, co z pewnością będzie miało wpływ na lepszą komunikację i obsługę danej operacji.

Spędziłem lata 90 będąc fanatykiem nakłaniającym ludzi do systemów ticketowych. W latach 2000 byłem zadowolony, widząc rezultaty. Jesteśmy w trzeciej dekadzie – jeśli nadal nie masz systemu, pozwalającego śledzić zgłoszenia od użytkowników, powinieneś się wstydzić!

2. Czy wdrożono „3 podstawowe pełnomocnictwa administratora” i są one używane?

Istnieją 3 publiczne dokumenty opisujące reguły współpracy z administratorami, które musisz posiadać, żeby możliwe było wykonanie jakiejkowiek pracy. Jest to jednakowo ważne, aby zachować profesjonalną obsługę klientów, jak i wydajność własnego zespołu.

Jeśli jesteś managerem i uważasz, że zespół nie potrafi odpowiednio wykorzystywać czasu pracy, to może być twoja wina. Czy zdefiniowałeś:

  • Akceptowalne zasady zgłaszania problemów przez użytkowników
  • Definicję słowa „awaria”
  • Zakres udzielanych świadczeń: Kto? odpowiada za co? i konkretnie kiedy?

Wszystkie te tematy można zawrzeć w jednym dokumencie, prawdopodobnie na jednej kartce A4. Powinny one być dostępne jako PDF w firmowym intranecie oraz wywieszone w pokoju administratorów, tak aby były powszechnie znane i przestrzegane. Musisz również upewnić się, że zarząd je rozumie i akceptuje. Oznaczać to będzie, że wszyscy będą zgodni powiedzieć „nie”, jeśli zgłoszone zadanie wybiega poza ramy zdefiniowane poza zakresem ustalonych świadczeń. I to nie na zasadzie „spowalniacza”, ale solidnej „ściany”.

Jak otrzymać pomoc?

Dzięki jasnej procedurze zgłaszania swoich żądań możemy w pełni wykorzystać opisywany poprzednio system ticketowy. W przeciwnym wypadku zalety mogą nie być widoczne, bo użytkownicy zwyczajnie zamiast korzystać z systemu będą nadal przychodzić do administratorów, a ci, chcąć pomagać, staną się nieefektywni, a ich praca „sterowaną przerwaniami”.

Pracownik musi mieć możliwość powiedzenia użytkownikowi „idź sobie” jeśli ten nie przestrzega protokołu. Bez możliwości wskazania tej reguły ryzykujesz, że cały dzień pracownik będzie zajmował się rzeczami błahymi i o niskim priorytecie, a każdy z pracowników wypracuje sobie własną listę rzeczy, którymi chce się zajmować, przez co zespół będzie wyglądał niespójnie, a administratorzy będą komunikować swoją frustrację w niezdrowy sposób. W szczególności niezdrowy dla użytkowników.

Co jest „awarią”?

Oficjalna definicja awarii jest pomocna w przydzielaniu priorytetów. Bez tego wszystko może być uznawane za awarię, co znów prowadzi do nieefektywnej, „przerwaniowej” pracy.

Jasne reguły pozwalają managerom przekazać zespołowi jasną informację o priorytetach, tak aby nie musieli sami zgadywać, jak istotna jest dana sprawa i być posądzani i karani za złą klasyfikację bazującą na domysłach. Ich brak przejawia się w odbiorze zespołu jako niezarządzanym, podejmującym sprzeczne działania, faworyzującym lub lekceważącym osoby ze względu na osobiste przekonania i niekompetentnym.

To filtr względem oczekiwań użytkowników – ci, nazywający wszystko „awarią” mogą zostać skorygowani w swoich przekonaniach.

Każda organizacja powinna mieć definicję awarii, można ją nazwać „alarmem czerwonym”. Alarm czerwony dla gazety, to cokolwiek, co mogłoby spowodować opóźnienie w wydrukowaniu jutrzejszego wydania i załadowania go o 4 nad ranem na ciężarówki. W fabryce, alarm czerwony to wszystko, co mogłoby zatrzymać linię produkcyjną. Alarm czerwony systemu obsługi płatności to każde zdarzenie zaburzające procesy finansowe. Zespoły edukacyjne wiedzą, że kolejny wykład nie może być po prostu przełożony, a więc awarią będzie każda sytuacja uniemożliwiająca odbycie się lekcji w zaplanowanym czasie. Dla uniwersytetów alarm czerwony będzie oznaczał brak możliwości złożenia dokumentów dotyczących grantów przed deadlinem.

Natomiast „alarm żółty”, to będzie cokolwiek, co – jeśli zostanie zignorowane – może doprowadzić do „alarmu czerwonego”. Przykładowo system finansowy może funkcjonować, kiedy system planowania pojemności uległ awarii. Ryzykowne jest w tym przypadku dołączanie nowych klientów, bez posiadania aktualnych prognoz obciążenia systemu. Ostatnie szacunki mówiły o 2 tygodniach, zanim wydajność systemu sięgnie szczytu. Ryzyko zatrzymania całego systemu zwiększa się codziennie dopóki „alarm żółty” nie zostanie zażegnany.

Wszystko inne to „bieżączka”. Duże zespoły mogą kategoryzować te pozostałe zgłoszenia na wysoki, średni i niski priorytet, tworzenie nowych systemów, rozbudowę istniejących, itp, itd. Jeśli jeszcze nic nie zostało zdefiniowane, powinieneś jednak najpierw skoncentrować się na awariach.

Co jest wspierane?

Ukonstytuowanie terminu „wsparcia” pozwala pracownikom powiedzieć „nie”. Definiuje kiedy, kto i co ma obowiązek robić. Czy udzielacie wsparcia po godzinie 17? W weekendy? Czy udzielane jest zdalne wsparcie? A wizyty domowe? Czy wspierany jest każdy, kto zadzwoni czy tylko pracownicy konkretnych działów? Jakie oprogramowanie i sprzęt są objęte wsparciem? Czy jest zdefiniowany cykl życia systemów i usług, czy też wszystko co zostało umieszczone na systemach produkcyjnych musi być  wspierane w nieskończoność? Czy każda nowa technologia jest wspierana kiedy tylko się pojawi, czy jednak dopiero po okresie testów i jej oficjalnym zaakceptowaniu?

Bez możliwości powiedzenia „nie”, administratorzy będą wspierać wszystko. Ambitny i pomocny pracownik spędzi niezliczone godziny próbując naprawić niewspieraną kartę graficzną, kiedy dużo taniej byłoby podarować mu inną, która nie powodowałaby żadnych problemów, nawet z własnej kieszeni. Administrator dawno uznany za zaginionego pojawi się nagle niespodziewanie po tym, jak spędził cały dzień w domu jednego z użytkowników naprawiając jego prywatne łącze internetowe. Albo w drugą stronę – mrukliwy admin będzie każdemu mówił „to niewspierane” po prostu dlatego, że jest czymś zajęty.

3. Czy zespół śledzi miesięczne statystyki?

Twoje decyzje muszą bazować na solidnych danych, kiedy podejmujesz własne decyzje albo będziesz próbować przekonać kogoś z wyższej kadry zarządzającej.

Najlepsza metoda na utworzenie statystyk to stworzenie metryki dla każdego zdania opisującego listę twoich obowiązków.

Przykład: Zespół odpowiedzialny za instalację stacji PC musi: dostarczać wysokowydajne, ustandardyzowane stanowisko komputerowe dla każdego pracownika w pierwszym dniu jego pracy. W okresie 3 lat stacje te muszą być wymieniane, bazując na dostępnych w danej chwili komponentach o najlepszym stosunku możliwości/ceny.

Możliwe metryki: Liczba tygodni pomiędzy aktualizacją standardowej konfiguracji, koszt aktualnej standardowej konfiguracji, liczba nowych pracowników w bieżącym miesiącu, wydatki na środki trwałe, wydatki na usługi. Liczba dni, które nowi pracownicy czekali na sprzęt („kubełki” na: sprzęt dostępny przed zatrudnieniem, pierwszego dnia, drugiego, 3-go, 4-go, 5-go i dłużej). Wiek sprzętu („kubełki”: <1 rok, 1-2 lata, 2-3 lata, 3+ lat). Liczba komputerów skonfigurowanych w sposób niestandardowy.

Jeśli nie posiadasz listy obowiązków – wypracuj taką ze swoim managerem. Alternatywnie możesz skorzystać z poniższej listy startowej:

  • Jaka jest liczba administratorów?
  • Jaka jest liczba wspieranych użytkowników?
  • Ile jest serwerów? Fizycznych? Wirtualnych?
  • Jak dużo jest sumarycznie przestrzeni dyskowej? Pamięci? Rdzeni CPU?
  • Jak dużo jest obecnie otwartych zgłoszeń w systemie ticketowym?
  • Jak dużo ticketów otwarto od ostatniego miesiąca?
  • Kto (lub jaki dział) otworzył w tym miesiącu najwięcej ticketów?
  • Jaka była średnia zrealizowanych ticketów na administratora w poprzednim miesiącu?
  • Wybierz 4-5 najważniejszych SLA i zapisz jak dużo brakowało do ich wypełnienia.
  • Jak dużo dostępnej przepustowości zostało zużyte w poprzednim miesiącu – średnio i w szczycie?

Zapisuj te dane co miesiąc w arkuszu kalkulacyjnym. Będzie to niezwykle pomocne w trakcie spotkań z zarządem dotyczących pracy grupy i planowania przyszłych zadań.

To naprawdę wszystko. To wystarczy. Zapisywanie comiesięcznych statystyk pozwoli zacząć ci prezentację od czytelnego wykresu pokazującego wzrost liczby serwerów w sieci, zamiast zaczynania od słów „cześć, jestem Jacek i zarządzamy tu serwerami… hm, mamy dużo… serwerów”. Takie podstawowe odpowiedzi na pytania pozwolą na konstruowanie bardziej zaawansowanych pytań dotyczących budżetowania, jak np. „Jak dużo średnio kosztuje nas ticket?” (zeszłoroczny budżet / liczba ticketów w roku). „Jeśli będziemy mieć 100 użytkowników, jak dużo przestrzeni dyskowej będziemy potrzebować?” (dostępne miejsce / liczba użytkowników * 100).

Docelowo zbieranie tych statystyk powinno zostać zautomatyzowane. Do tego czasu, po prostu wysyłaj sobie automatycznie maila, aby robić to pierwszego każdego miesiąca.

B. Progresywna praca zespołowa

4. Czy używacie wiki opisującego „reguły i procedury”?

Zespół potrzebuje wiki. To miejsce, gdzie można opisywać wszystkie polityki (co powinno być zrobione) oraz procedury (jak to powinno być zrobione).

Automatyzacja jest niezastąpiona, ale zanim będziesz mógł zautomatyzować wszystko musisz wiedzieć, jak zrobić to manualnie. Dokumentowanie tego manualnego procesu jest warunkiem koniecznym do wprowadzenia automatyzacji. W międzyczasie zapewnia powtarzalne działania przez każdą osobę z zespołu i pozwala ci delegować zadania do innych pracowników. Jeśli coś jest dobrze udokumentowane, inna osoba powinna nie mieć problemów ze zrobieniem tego.

Spis treści wiki powinien zawierać typowe i rutynowe działania. Można zacząć od dodawania, edycji (i czasem usuwania) rzeczy, które każdy w zespole powinien potrafić zrobić, a także tych zadań, których nie lubisz wykonywać i jeśli miałbyś asystenta „juniora”, to chciałbyś je na niego scedować.

Lista procedur:

  • Zatrudnienie nowego pracownika
  • Odejście pracownika
  • Dyscyplinarne zwolnienie pracownika
  • Instalacja nowej maszyny
  • Wyłączanie niepotrzebnej maszyny
  • Dodawanie/usuwanie VPN dla pracownika
  • Wymiana dysków w RAID
  • Zmiana hasła „root” na wszystkich serwerach

Ta lista zawiera trzy kategorie: rzeczy, które powinny być robione zawsze w sposób spójny i uporządkowany; rzeczy, które robisz rzadko i nie chcesz tracić czasu na przypominanie sobie procedury; wreszcie rzeczy, które robisz w panice i nie masz wtedy głowy do myślenia o tym, jak.

Wszystko to może zostać udokumentowane w postaci list kontrolnych (checklist) opisujących wykonanie zadania krok po kroku.

Kiedy zostaną udokumentowane, każdy w zespole powinien móc je powtórzyć. Także nowi pracownicy powinni potrafić zrealizować rutynowe działania. Mogą one wręcz posłużyć do pisania ofert pracy, kiedy organizacja zdecyduje się zatrudnić asystenta mającego wykonywać powtarzające się prace.

Nawet jeśli nie masz zespołu i te zadania wykonujesz sam, ich dokumentowanie niesie ze sobą zalety. Im mniej zastanawiasz w trakcie wykonywania zadań, tym mniejsza szansa na zrobienie czegoś źle. Trafnie punktują to powiedzenia „automatyzujemy wszystko, bo jesteśmy leniwi” oraz „dokumentujemy wszystko, bo jesteśmy niecierpliwi”.

Wielu administratorów nie lubi pisać ton dokumentacji. ale tworzenie list kontrolnych to co innego – są one dużo łatwiejsze w pisaniu i utrzymaniu. Poza tym na wiki każdy może je edytować i w razie potrzeby na bieżąco korygować.

Dla każdego zadania możesz potrzebować osobnych stron opisujących „polityki” i „procedury”. Polityka, to cele zdefiniowane przez kadrę zarządzającą, np: każdy nowy pracownik otrzyma bezprzewodową mysz. Procedura, to jak coś zrobić: myszy bezprzewodowe są w 3 pudle, naładuj je i przetestuj wykonując określone kroki: … Polityka powinna być modyfikowana tylko w porozumieniu z managerami. Procedury powinny być utrzymywane przez inżynierów, wiki powinno też powiadamiać o zmianach osoby, które dany dokument utworzyły, bądź go obserwują.

5. Czy używacie sejfu haseł?

Posiadanie sejfu pokazuje, że organizacja zarządza hasłami w dojrzały sposób.

Jest wiele świetnych programów szyfrujących i przechowujących hasła. Czasem wystarczy jednak zamknięta koperta przechowywana w sejfie.

Problemem często pozostaje weryfikacja. Skąd wiadomo, że złośliwy pracownik nie umieszcza nieprawidłowych haseł w kopertach? Być może powinien być wdrożony system weryfikacji ich poprawności przed umieszczeniem w sejfie?

6. Czy tworzony przez zespół kod znajduje się w repozytorium?

Gdy instalacja serwera następuje poprzez żądanie API, okazuje się że wszyscy jesteśmy teraz programistami. -Limoncelli, o chmurach obliczeniowych, devops i konieczności wprowadzania umiejętności deweloperskich do środowisk administratorów systemów.

Wszyscy jesteśmy obecnie programistami. Programiści używają systemów kontroli wersji.

Rzeczy, które powinny znajdować się w repozytoriach: skrypty, programy, pliki konfiguracyjne, dokumentacja, wszystkie potrzebne do pracy zasoby. Jeśli nie jesteś pewien czy coś powinno się tam znaleźć, przyjmij że odpowiedź brzmi: „tak”.

Trzymanie plików konfiguracyjnych w repozytorium może wydawać się zbytkiem, ale zwykle po czasie okazuje się ratować życie.

Każdy system jest lepszy od żadnego. Użyj tego systemu, który używają deweloperzy. Brak deweloperów? Naucz się git, mercurial, w ostateczności subversion. Desperacko potrzebujesz zapisywać historię zmian w plikach konfiguracyjnych? http://www.nightcoder.com/code/xed (To wrapper który zapisuje historię i wywołuje $EDITOR).

7. Czy zespół używa systemu śledzenia błędów dla własnego kodu?

System śledzenia błędów to co innego niż system ticketowy. Jeśli błędy w programach są sporadyczne (być może po prostu nie piszecie dużo kodu), tworzenie ticketu może być wystarczające.

Jeśli jednak wreszcie zaczniecie pisać go więcej, utwórzcie dedykowanych system śledzenia błędów. Takie systemy mają inne zasady działania – system ticketowy jest zorientowany wokół komunikacji pomiędzy agentami a użytkownikami. System śledzenia błędów jest zorientowany na cykl życia wokół buga (raportowanie, weryfikacja, przypisanie, poprawka, wdrożenie, weryfikacja).

8. Czy zgłoszenia dotyczące błędów otrzymują priorytet nad nowymi funkcjami?

Dodawanie nowych funkcji jest ciekawsze niż naprawianie błędów. Niestety życie nie składa się wyłącznie z przyjemności.

Dojrzałe zespoły tak priorytetyzują zgłoszenia:

  • błędy bezpieczeństwa (najwyższy priorytet)
  • stabilność
  • bugi
  • wydajność
  • nowe funkcje (najniższy priorytet)

Zespół musi potrafić usuwać błędy przed wprowadzaniem nowych funkcji. Błędy bezpieczeństwa mogą być poważnym przypadkiem problemów ze stabilnością.

Jedna z zasad promowanych przez Marka Burgess to „zajmuj się stabilnością, potem nowymi funkcjami”. Niektóre zmiany mogą dodawać funkcje, inne polepszają stabilność. Kolejność ich wprowadzania powinna wyglądać tak: funkcja, stabilność, funkcja, stabilność, funkcja, stabilność. Nie zaś: funkcja, funkcja, funkcja, o cholera!, stabilność, stabilność, stabilność. Najpierw ustabilizuj to, co jest, zanim przejdziesz do kolejnej wyśmienitej funkcji.

Lekarze to rozumieją. Pacjent przybywający do szpitala jest zwykle najpierw stabilizowany. Nie można pomóc komuś wyzdrowieć z grypy jeśli właśnie się wykrwawia.

Priorytet błędów związanych z wydajnością jest dyskusyjny – niektóre środowiska mogą postrzegać wydajność tak samo jak stabilność.

9. Czy zespół tworzy „dokumentację projektową”?

Dobre zespoły administratorów „myślą zanim zrobią”. W dużym zespole konieczne jest komunikowanie zmian, które mają być lub właśnie zostały wykonane.

Dokument projektowy to standardowy sposób proponowania nowych rzeczy lub opisujących te istniejące. Powinien być na początku krótki, maksimum 1-2 strony, ale może być rozbudowywany w razie potrzeby.

Stwórz szablon i używaj go we wszystkich możliwych sytuacjach. Nagłówki mogą zawierać: Podsumowanie, Cele, Nie-cele, Opis, Zaproponowane rozwiązanie, Rozważane alternatywy, Bezpieczeństwo, Plan kryzysowy, Szacowany koszt.

Taki format może być użyty do napisania 20-stronicowego planu restrukturyzacji sieci, jeśli potrzebujesz do tego wsparcia wielu osób. Może to być także 5-stronowy dokument o tym, jak został zbudowany prototyp funkcji, tak, aby każdy się z nim zapoznał i zaproponował uwagi, zanim rozwiązanie ostatecznie zostanie zbudowane. Może być też użyty jako szkic na pół strony wyjaśniający plan zaprojektowania drzewa katalogów na nowym serwerze plików (w takim wypadku część z nagłówków może okazać się zbędna). Użyj go, kiedy system już zostanie zbudowany, aby powiadomić innych członków zespołu. Niech to, użyj go nawet do tego, żeby opisać jak zespół ma się zmieniać przez najbliższy rok.

Celem jest posiadanie mechanizmu umożliwiającego wymianę myśli przed przystąpieniem do pracy, poza zwyczajowymi dyskusjami w kuchni i na korytarzach. Mechanizmu który zostawia ślady, do których można się odnieść w przyszłości, aby zrekonstruować i zrozumieć jak i dlaczego coś zostało zrobione.

Działa też kiedy poszukujesz porady lub chciałbyś poddać swoją propozycję krytyce lub po prostu chcesz powiedzieć „daj znać jeśli to coś konfliktuje z pracami, które teraz wykonujesz”.

Twój dokument projektowy może mieć więcej lub mniej nagłówków, niektóre z nich mogą być opcjonalne, inne wymagane. Bądź elastyczny. Mały projekt, może wymagać małego planu. Olbrzymi może wymagać jeszcze większej liczby nagłówków. Bądź elastyczny. Miej wersję „krótką” i „długą”. Posiadanie standardowego szablonu, który każdy może użyć pozwala zwalczyć „syndrom pustej kartki”.

10. Czy wykonywane są analizy „post mortem”?

Czy po awarii piszecie notatkę o tym co się stało i jakie wnioski wyciągnięto, czy po prostu liczycie, że nikt nie zauważy co się stało i problem się nie powtórzy?

Dobra procedura post-mortem (PM) zawiera linię czasu (wydarzeń; co się stało?), zasięg (kto był poszkodowany?), podjęte działania (jak naprawiono system?), koszty (jak problem wpłynął na biznes?) oraz rozwiązania (jak zapobiec ponownemu pojawieniu się takiego problemu?). Każda propozycja powinna być zgłoszona jako bug albo ticket, aby możliwe było śledzenie podjętych działań zaradczych.

Systematyczne robienie PM sprzyja stabilizacji środowiska. Po każdej awarii powinien być opracowany przynajmniej jeden środek zapobiegawczy. Można monitorować system, aby wykryć sytuację przed użytkownikami. Można wykryć przyczyny prowadzące do wystąpienia problemu. Często systemy są wyposażone w szereg testów, które sprawdzają nową konfigurację zanim zostanie ona użyta (np. skrypty pre-commit w repozytoriach kodu). Czy możliwe jest dodanie testu, który wychwyci literówkę, która tym razem doprowadziła do awarii?

Post-mortem nie polega na obwinianiu i zawstydzaniu. W zdrowej kulturze i zespole każdy powinien czuć się swobodnie, aby umieścić swoje inicjały w sekcji „co poszło źle”. Rozwój jest możliwy tylko w przypadku, kiedy nauczysz ludzi, że to nie popełnianie błędów jest złe, ale ich powtarzanie.

Jeśli wasz przełożony używa PM, aby dowiedzieć się kogo ukarać to znaczy, że nie rozumie, że rolą działu operacyjnego nie jest bycie idealnym, ale robienie rzeczy coraz lepiej każdego dnia. Każdy manager który zwalnia pracownika z powodu awarii, do której doprowadził nieświadomie może być potencjalnie przyczynkiem do upadku organizacji.

PM powinny być publicznie dostępne dla każdego. Pracownicy nie powinni się wstydzić lub przejmować, że „publicznie prane są brudy zespołu”. W rzeczywistości systematyczne publikacje tego typu wzbudzają zaufanie przez poczucie szczerości i transparentności.

Oczywiście, aby ten proces działał wszystkie tickety utworzone na podstawie procesów PM muszą być systematycznie rozwiązywane.

C. Praktyki operacyjne

11. Czy każda usługa zawiera „dokumentację operacyjną” (OpsDoc)?

Kiedy twój serwer DNS umiera, przebudowujesz go od nowa – wiesz jak. Super, prawda? Musisz skompilować i postawić najnowszego BINDa i robisz to, bo wiesz jak. Kiedy system monitoringu zgłasza czasem problem, też wiesz jak go naprawić, prawda? Wszystko to wynika z doświadczenia. Po co to zapisywać?

Oto dlaczego:

Czy będziesz o tym pamiętać za pół roku? Ja zazwyczaj muszę wymyślać jak coś zrobić na nowo, jeśli nie robiłem tego od kilku miesięcy (a czasami wystarczy tylko kilka dni!). Nie tylko wymyślam wszystko na nowo, ale powtarzam wszystkie moje stare błędy, których nauczyłem się już przecież nie robić na nowo. Strata czasu.

Czy będziesz pamiętać to wszystko pod presją czasu? Moja pamięć najbardziej szwankuje właśnie w czasie awarii.

Co w sytuacji, kiedy jesteś niedostępny? Czy będziesz się czuć zrelaksowany na wakacjach, jeśli ktoś będzie dzwonił? Nie możesz narzekać na przepracowanie i niemożliwość przekazania swojej wiedzy, jeśli nie stworzyłeś systemu, który pozwoli podzielić i rozłożyć tę pracę na większą liczbę osób.

Czy członkowie zespołu powinni uczyć się patrząc jak ty coś robisz, czy powinni próbować zrobić to samodzielnie? Jeśli nauczą się samodzielności będą się do ciebie zgłaszać tylko jeśli staną w miejscu. To duża oszczędność czasu i niezdrowego jęczenia o więcej informacji, którego chciałbyś zapobiec. W rzeczywistości, ludzie czują się bardziej częścią teamu jeśli takie informacje i zadania są udokumentowane.

Jak twój manager mógłby cię awansować do nowego, bardziej interesującego projektu, jeśli jesteś obecnie jedyną osobą w dziale, która wie jak coś działa?

Każda usługa powinna mieć udokumentowanych kilka rzeczy. Jeśli każda usługa będzie udokumentowana w taki sam sposób, ludzie się do tego przyzwyczają i dużo łatwiej będzie im zdobyć informację. Ja utworzyłem osobną przestrzeń nazw wiki dla każdej usługi z takimi stronami:

  1. Podsumowanie: krótki opis usługi – co to jest, do czego nam to potrzebne, kto jest osobą odpowiedzialną/kontaktową dla tego projektu, jak zgłaszać bugi, linki do dokumentacji projektowej i innych powiązanych informacji.
  2. Budowa: jak zbudować system i oprogramowanie, tworzące usługę. Skąd je ściągnąć, gdzie jest repozytorium kodu, kroki budowania i dystrybucji (np. przy użyciu systemu pakietowania właściwego dla używanego systemu operacyjnego). Jeśli to oprogramowanie można modyfikować (lokalny projekt, lub projekt opensource którego organizacja współtworzy) dołącz instrukcję startową dla nowych deweloperów. Rezultatem powinien być pakiet, który można zainstalować na serwerze.
  3. Wdrażanie: jak zainstalować usługę. Jak zbudować odpowiedni serwer (wymagania RAM/dysk, minimalna wersja systemu operacyjnego, szczegóły jego konfiguracji, konieczne zależności, itp, itd). Jeśli proces jest zautomatyzowany przez oprogramowanie do zarządzania konfiguracją jak cfengine/puppet/chef (a powinno!), załącz szczegóły tej konfiguracji (klasyfikacja serwerów, wprowadzanie niezbędnych danych).
  4. Typowe zadania: instrukcje krok po kroku zawierające powszechne zadania, jak provisioning (dodawanie/zmiana/usuwanie), typowe problemy z rozwiązaniami, zadania cykliczne, itp.
  5. Spis alarmów: lista testów systemu monitoringu, specyficznych dla tej usługi z załączonymi instrukcjami „co zrobić jeśli…”.
  6. DRP: plan na wypadek katastrofy. Jeśli stracisz część maszyn dla tej usługi, co dalej robić? Jak dodać kolejne węzły? Gdzie są dostępne hot/cold spare?
  7. SLA: przyjęty umownie lub formalny kontrakt z klientami dotyczący dostępności usługi. Zazwyczaj zawiera cel dostępności (jak wiele dziewiątek?), RPO (czas z jakiego dane mogą być utracone – określa częstotliwość backupowania i np. replikację) i RTO (czas do odzyskania systemu po awarii – określa zasoby i metody odzyskiwania, w tym np. centra zapasowe).

Jeśli usługa jest rozwijana wewnętrznie, dodatkowa 8 strona powinna zawierać informację dla zespołu: jak skonfigurować środowisko developerskie, jak przeprowadzać testy integracyjne, jak wydawać nowe wersje, czy inne wskazówki potrzebne deweloperom. Przykładowo, jeden projekt, w którym mam udział opisuje tu procedurę dodania nowego RPC do systemu.

Wyjdź przed szereg i stwórz szablon dla pozostałej części zespołu. Zacznij od rzczy prostych – np. wewnętrznego systemu DNS. Potem przejdź do bardziej skomplikowanych. Utwórz szkielet, żeby mógł być używanych przez innych jako szablon, w którym wypełniają tylko brakujące pozycje. Wypracuj nawyk tworzenia nowego szkieletu OpsDoc za każdym razem, kiedy startuje nowy projekt.

12. Czy każda usługa jest odpowiednio monitorowana?

Usługa nie jest produkcyjna dopóki nie jest monitorowana. Jeśli nie ma monitoringu, to tylko uruchamiasz jakieś tam programy. -Limoncelli

Monitoring powinien bazować na SLA z dokumentacji operacyjnej (OpsDoc). Jeśli brak SLA, minimum to monitoring „działa/nie działa”.

Nie zapomnij zaktualizować spisu alarmów w dokumentacji!

13. Czy zespół ma zdefiniowany harmonogram pracy rotacyjnej w przypadku awarii („on call”)?

Czy macie zdefiniowany kalendarz, określający, kto reaguje na awarie po godzinach, czy jesteś tym frajerem do którego dzwoni się zawsze?

Harmonogram pracy rotacyjnej to dokument, który określa kto w jakim czasie musi być dostępny pod telefonem.

Możesz mieć telefon, który przechodzi z rąk do rąk, w zależności od tego, kto odpowiada w danym czasie za odbieranie telefonów, albo twój system monitoringu może sprawdzać harmonogram i wysyłać powiadomienia na odpowiedni telefon. Najlepiej mieć wspólny email i nr telefonu (IVR), tak aby klienci nie musieli znać twojego harmonogramu.

Harmonogram może być prosty lub złożony. Bycie na dyżurze 1 tydzień z n tygodni (gdzie n to liczba ludzi w twoim zespole) to rozwiązanie, które ma sens jeśli problemów nie jest zbyt dużo. Dla bardziej złożonych sytuacji warto podzielić dzień na trzy 8-godzinne zmiany. Warto skorzystać z zasady „podążaj za słońcem”, czyli tak przydzielać zmiany, aby dla poszczególnych osób w globalnym zespole odpowiadały one godzinom przypadającym na dzień. Możesz mieć zmiany 8-godzinne co n tygodni, jeśli twój zespół będzie miał 3n pracowników. Możliwości są nieskończone.

Harmonogram służy wielu grupom: tobie i twojemu zespołowi, klientom, zarządowi, czy działowi HR.

Korzyścią dla ciebie jest to że możesz planować swój czas poza pracą. Kładę duży nacisk na dobre wyważenie proporcji pracy do życia prywatnego. Jeśli te proporcje są u ciebie zaburzone i nie masz harmonogramu rotacyjnego – lekarzu, lecz się sam!

Rotacja poprawia stosunki z klientami, bo nie dochodzi do paniki, bo „wszyscy dzwonią do wszystkich próbując znaleźć jakiegoś admina” i sprawia że proces staje się prosty i przewidywalny.

Służy też zarządowi, bo daje im pewność że support jest świadczony i następnym razem kiedy będzie potrzebny nie będzie problemu, że „nikogo nie ma”.

W końcu służy działowi HR, bo firma może płacić za nadgodziny zgodnie z obowiązującym prawem. Twój harmonogram jest czytelny i w formie strawnej dla komputerów – prosty skrypt może generować raporty z czasu wykorzystanego poza normalnymi godzinami pracy.

Jeśli nie masz harmonogramu, to twój harmonogram, to „24x7x365” i jesteś frajerem. (Ale nadal, nie oznacza to że możesz odpowiedzieć TAK na to pytanie.)

14. Czy dostępne są wydzielone środowiska deweloperskie, testowe i produkcyjne?

Programiści pracują i testują swoją pracę na serwerach deweloperskich. Kiedy uznają pracę za skończoną budowane są pakiety i instalowane na środowisku testowym. Jeśli oprogramowanie przechodzi testy, te same pakiety służą do instalacji środowiska produkcyjnego.

Elementarz administracji, prawda?

Dlaczego zatem ciągle spotykam adminów, którym managerowie zabraniają tego robić? Jeśli manager mówi „druga maszyna kosztuje nas zbyt dużo”, to nie ma nadziei. Testowanie nie kosztuje dużo. Wiecie co kosztuje dużo? Awarie.

Niekontrolowane zmiany na żywym systemie nie są po prostu złe, w regulowanych środowiskach są też nielegalne. Pozwalanie programistom na dewelopowanie kodu na żywym organizmie nie wchodzi w grę!

System testowy nie musi być tak drogi jak odpowiadająca mu produkcja. Nie musi być tak mocne jak produkcyjne, może mieć mniej RAMu, dysków i gorsze CPU. Może bazować na wirtualnych maszynach współdzielących zasoby jednego fizycznego serwera.

Oczywiście jeśli skalowanie i czas odpowiedzi są kluczowe, będzie prawdopodobne, że środowisko testowe będzie musiało być lepiej odwzorowane, aby wytrzymać określone testy obciążeniowe symulujące prawdziwy ruch.

15. Czy masowe wdrażanie zmian jest poprzedzone systemem „kanarkowym”?

Powiedzmy, że masz wykonać zmianę na 500 maszynach. Powiedzmy, jest to nowy kernel. Może po prostu jakiś prosty bugfix.

Czy wdrażasz to od razu na 500 maszynach? Nie. Zmiany są wprowadzane najpierw na małej liczbie serwerów i weryfikowane są wyniki. Jeśli nie ma problemów – wprowadzamy zmianę na więcej i więcej maszyn, aż do osiągnięcia stanu, kiedy na wszystkich odpowiednie zmiany zostaną uwzględnione.

Te pierwsze maszyny, na których znajdzie się wdrożenie nazywamy „kanarkami”.

Górnicy zabierali kanarki na szychtę i umieszczali w ślepych przodkach, gdzie zawsze były trudności z doprowadzeniem powietrza i gdzie często byli narażeni na kontakt z metanem lub tlenkiem węgla. Pracując górnicy nieustannie obserwowali zachowanie kanarków. Wrodzona wrażliwość ptaków na toksyczne zagrożenia powodowała, że ptaki wyczuwały wcześniej nagromadzenie lub eksplozję szkodliwych gazów. Kanarki najpierw stroszyły piórka, potem spadały z żerdek a przy dużych zagrożeniach padały martwe. Obserwacja ptaków dawała górnikom sygnały do opuszczenia kopalni w momencie zagrożenia. (źródło)

Przykłady technik „kanarkowych”:

  • Jeden… kilka… wiele:

    Wykonaj zmianę na 1 maszynie (np. swojej stacji roboczej), potem na większej ilości (np. maszynach roboczych współpracowników), potem na wielu innych (np. po kolei maszynach należących do kolejnych działów). Dowolna pojedyńcza awaria lub niekompletne wdrożenie powinno być sygnałem do zatrzymania procesu i jego poprawienia, tak aby problem nie występował.

  • Grupa kanarków:

    Zaktualizuj 1 maszynę, potem 1% maszyn, potem 1 maszynę na sekundę, aż do wdrożenia na 100% maszyn. (Typowe wykorzystanie w Google i innych bardzo dużych instalacjach.)

Ta procedura może być wykonywana przez administratora, ale często technika ta jest „zaszyta” w narzędziach do automatycznego zarządzania konfiguracją.

D. Praktyki automatyzujące

16. Czy używane są narzędzia automatyzujące takie jak cfengine, puppet lub chef?

Oprogramowanie Config Management (CM) to narzędzie koordynujące konfigurację serwerów. Może służyć kontrolowaniu systemu operacyjnego, działającego oprogramowania, dostarczanej usługi, albo wszystkich wymienionych komponentów razem.

Przed epoką CM administratorzy ręcznie wprowadzali zmiany w konfiguracji. Jeśli musieli to zrobić na 100 maszynach, to mieli 100 identycznych kroków do powtórzenia. Wielu sprytniejszych pracowników używało własnych skryptów do automatyzacji.

Jeszcze sprytniejsi doszli do wniosku, że generyczne narzędzia, które można elastycznie dostosować do własnych potrzeb mogą być jeszcze lepsze. Opracowali frameworki automatyzacji takie jak track, cfengine, bcfg2, Puppet, Chef i inne.

Podstawą działania systemów CM jest określenie stanu w jakim ma się znaleźć system i pozwolenie mu zadecydować w jaki sposób wykonać zmiany, które doprowadzą do tego stanu. To, co robi człowiek to deklaratywne określenie systemu przez opisanie go, np: „hostA jest serwerem www” i „serwer www ma zainstalowane następujące pakiety oraz następującą ich konfigurację”. Oprogramowanie CM na podstawie opisu przygotowuje serię komend, które muszą być wykonane. Inną znaczącą cechą jest to, że deklaracje są uniwersalne (np. „zainstaluj skrypt foo.sh jako zadanie crona”), zaś oprogramowanie CM ma za zadanie przystosować dany system operacyjny do oczekiwanego stanu (np. przez wybranie „/etc/crontab” lub „/var/spool/cron”).

Używając CM, zamiast robić ręczne zmiany edytujesz po prostu plik konfiguracyjny (w repozytorium pozwalającym śledzić historię zmian) i pozwalasz CM aby zajął się jego dystrybucją.

Lokalne zmiany na serwerach nie są mile widziane. Za każdym razem kiedy tworzysz plik w stylu /etc/crontab.bak albo /etc/hosts.[dzisiejsza data] – robisz to źle.

Zarządzanie konfiguracją to mistrzostwo automatyzacji. Przejście z etapu ucznia czarnoksiężnika do władcy marionetek. Kompletna antyteza tymczasowej partyzantki.

17. Czy automatyczne działania administracyjne są uruchamiane przez wydzielonego użytkownika?

Często uruchamiamy zautomatyzowane zadania w określonym przedziale czasowym, np. skrypt, który sprawdza spójność bazy danych uruchamiany co noc.

W niektórych organizacjach te skrypty są wykonywane z uprawnieniami jednego z administratorów. Jeśli ten administrator opuszcza organizację te automatyczne procesy pozostają osierocone lub znikają.

Dobrze działające organizacje uruchamiają te skrypty przez konto dedykowanego użytkownika. Może to być „root”, ale sensowniej (i bezpieczniej) użyć do tego specjalnego konta z ograniczonymi uprawnieniami.

18. Czy automatyczne działania administracyjne generują maile tylko jeśli faktycznie mają coś do powiedzenia?

Znacie ten problem, kiedy nikt nie reaguje na dźwięk syreny alarmowej, bo w przeszłości zdarzały się tylko fałszywe alarmy? A co w przypadku: „nikt nie zauważył awarii bo ten cron zawsze przysyłał maila, kiedy skończył pracę, informując o tym, że zadanie się powiodło”?

Moje reguły są proste:

  • jeśli to wymaga natychmiastowej reakcji: wyślij SMS i/lub wygeneruj automatyczny telefon.
  • jeśli to wymaga reakcji w ciągu 24h: stwórz ticket.
  • jeśli to ma wyłącznie cel informacyjne: zapisz to do logu.
  • jeśli brak jest informacji do przekazania – nie generuj żadnej informacji.

Wysłanie SMS i stworzenie ticketu może być wykonane przez email, ale sam email nie jest tu dobrym narzędziem. Możesz dołączyć swój email jako CC, ale samo wysłanie emaila zdecydowanie nie wystarczy.

Najgorsza sytuacja to system logujący zdarzenia, które zostały zarejestrowane poprzez interfejs emailowy. Twoja skrzynka pocztowa nie jest dobrym miejscem na przechowywanie logów.

Historia, która wydarzyła się naprawdę: kolega pracował w Nowym Jorku w firmie, gdzie wszystkie automaty wysyłały rezultat mailem na adres root@domena-firmowa. „root” to była lista dyskusyjna, na którą byli zapisani wszyscy administratorzy w firmie. To był ciągły strumień wiadomości, żaden administrator nie mógł przez to normalnie czytać poczty. Żadne filtry nie nadążały tego skasować. Wynik? Pracownicy zaczęli używać prywatnych adresów email do komunikacji, nawet do innych pracowników tej firmy. Co to była za firma? Jeden z większych dostawców poczty, który zbankrutował. (Ciekawe jakie inne złe decyzje doprowadziły ich do bankructwa?)

E. Zarządzanie flotą

19. Czy wszystkie zasoby są zinwentaryzowane?

Każda organizacja powinna wiedzieć jakie zasoby posiada. Baza danych powinna przechowywać podstawowe atrybuty, takie jak: OS, RAM, rozmiar dysków, adresy IP, właściciela, płatnika, osoby powiadamiane na wypadek prac serwisowych, itp, itd.

Dzięki bazie wszystkich serwerów możliwe jest wdrożenie automatyzacji. Możliwość wykonania zmian na konkretnych maszynach, opisanych przez konkretne właściwości jest kluczowe dla wielu procedur operacyjnych.

Dane powinny być automatycznie gromadzone i aktualizowane, chociaż małe instalacje mogą poradzić sobie po prostu z arkuszem lub stroną na wiki.

Posiadanie inwentaryzacji pozwala na podejmowanie decyzji bazujących na danych i zapobiega pojawianiu się problemów.

Znam mały uniwersytet w New Jersey, który mógł zapobiec dużej awarii gdyby tylko prowadzili lepszą inwentaryzację. Mianowicie – próbowali oni  zaktualizować wszystkie swoje komputery do najnowszej wersji Microsoft Office. Dziekan był bardzo zadowolony, że w końcu znikną wszystkie problemy z kompatybilnością powstających dokumentów, które tak często powodowały frustrację. A do tego te wszystkie nowe funkcje! Entuzjazm szybko przerodził się w rozgoryczenie jak tylko projekt zaczął się sypać. Okazało się że jedna trzecia maszyn znajdujących się w kampusie miało za mało pamięci lub miejsca na dysku. Różne wydziały nagle nie mogły pracować ze względu na przerwane w połowie procedury upgrade’u. Dziekan nie tylko był niezadowolony, ale zaczął również bardzo ostrożnie podchodzić do zmian, które mogły wiązać się z ryzykiem. Od tego czasu przez długi okres nikt nie chciał słyszeć o żadnych upgrade’ach. Wszystko to nie zdarzyłoby się gdyby istniał dobry system rejestrujący aktywa. Proste zapytanie mogłoby zwrócić listę maszyn, które potrzebowały odświeżenia ze względu na nowe wymagania. Budżet i czasochłonność mogły zostać oszacowane i włączone do procesu aktualizacji oprogramowania.

20. Czy instalacja nowych systemów jest zautomatyzowana?

Automatyczna instalacja systemów operacyjnych jest szybsza, bardziej powtarzalna i pozwala użytkownikom instalować własne serwery samodzielnie, tak żebyś sam nie musiał tego robić.

Jeśli proces jest zautomatyzowany każda zainstalowana maszyna wygląda tak samo. Walka z entropią jest trudna, jeśli systemy różnią się już na starcie bo zostały „ręcznie wyrzeźbione” – staje się wręcz niemożliwa.

Jeśli instalujesz systemy ręcznie, marnujesz czas dwukrotnie: po raz pierwszy podczas instalacji, potem za każdym razem, kiedy musisz rozwiązywać problem powstały w czasie instalacji, któremu można było zapobiec przez posiadanie spójnego mechanizmu konfiguracji.

Jeśli dwie osoby zainstalują system ręcznie, połowa z nich będzie zainstalowana niezgodnie z zasadami, ale nie wiesz która to połowa. Obaj będą twierdzili, że użyli tych samych procedur, ale gwarantuję ci, że będzie inaczej. Niech każdy z nich usiądzie osobno i opisze na kartce listę kroków. Potem pokaż im wzajemnie kartki. Poleje się krew.

Użytkownicy odczytują brak spójności jako niekompetencję. Jeśli nowe serwery zawsze są dostarczane z taką samą konfiguracją, która im się nie podoba – zmieniają ją sami i po kłopocie. Jeśli jednak w połowie przypadków coś jest ustawione raz tak, a raz inaczej, utracą oni zaufanie do administratorów systemów. Czy oni nie pamiętają jak to robili wcześniej?

Jeśli możesz automatycznie przeinstalować system, mogą to zrobić też twoi użytkownicy. Masz mniej do roboty. Automatyzacja, która oszczędza czas jest super. Automatyzacja, która pozwala robić pewne rzeczy innym ludziom jest jeszcze lepsza.

Niemożność łatwego wyczyszczenia i przeinstalowania maszyny może być problemem bezpieczeństwa. Serwer powinien być  wyczyszczony i przeinstalowany kiedy zostaje przekazany do innego działu lub projektu. Jeśli ten proces nie jest „bezbolesny”, pojawia się pokusa, żeby „oszczędzić czas” nie robiąc tego.

21. Czy możliwe jest łatanie oprogramowania w całej flocie?

Jeśli instalacja systemów jest zautomatyzowana wszystkie serwery zaczynają jako takie same. Jeśli łatanie jest zautomatyzowane, wszystkie pozostają takie same. Spójność to duża zaleta.

Aktualizacje bezpieczeństwa są bardzo istotne, bo wymaga tego dostępność i niezawodność systemów. Aktualizacje nie związane z bezpieczeństwem też są ważne, bo mogą wpływać na niezawodność, a do tego dostarczają klientom nowych funkcjonalności. Nie pozwalanie na łatanie systemów jest jak niepozwalanie dzieciom na rozwijanie się przez zabawę. Czy chcesz być złym rodzicem?

Łatanie aplikacji jest podobnie ważne jak łatanie systemów operacyjnych. Użytkownicy nie odróżniają „systemu” od „aplikacji”, szczególnie jeśli aplikacja jest w powszechnym użytku. Źli goście, którze piszą malware też nie przejmują się tym rozróżnieniem.

Byłoby świetnie, jeśli banki miały by obowiązek publikacji swoich procedur aktualizacji – wiedziałbym któremu powierzyć swoje pieniądze.

Alternatywą dla automatyzacji może być chodzenie od biurka do biurka, logowanie się i łatanie maszyn od czasu do czasu. To wkurza użytkowników, marnuje ich czas i w sposób mało zorganizowany zużywa twój własny. Teraz, kiedy laptopy są w powszechnym użytku to nierozsądne w ogóle zakładać, żeby chodzić pomiędzy nimi.

Jeśli to tylko możliwe aktualizacje powinny być wykonywane w sposób cichy (nienadzorowany). Jeśli wymagają one restartu lub innej interakcji użytkownik powinien mieć opcję ich odroczenia do czasu, który mu odpowiada. Niemniej powinien być tu maksymalny limit, np. 2 tygodnie. Okres ten powinno dać się skrócić, zależnie od tego jak bardzo krytyczny jest to błąd z punktu widzenia bezpieczeństwa.

22. Czy istnieje polityka wymiany zużywających się narzędzi?

Jeśli nie masz polityki kiedy stacje będą wymieniane, to nie będą one wymieniane.

[Przez stacje rozumiem desktopy i laptopy używane przez ludzi, nie serwery.]

W serwerowni w większości przypadków procedura wsparcia i wymiany serwerów jest bardziej sformalizowana. W przypadku środowiska stacji roboczych potrzebujesz jakiegoś powtarzalnego, cyklicznego procesu, aby pozostały one aktualne. Jeśli nie będzie takiego procesu, sprzęt będzie się starzał i zostanie niewspierany, albo ludzie zaczną wymagać wymiany sprzętu jako symbol swojego statusu w organizacji i cały temat zostanie uznany za polityczny. Dobre procedury pozwolą na bezproblemową pracę i będą bardziej oszczędne.

Jakiś ułamek twojej floty pewnie będzie pozostawał stary – takie są zasady ekonomii. Jednak bardzo stare maszyny są często dużo droższe w bieżącym utrzymaniu od kosztu ich wymiany na nowe. Czy to nie strata czasu pracować nad obejściem problemu, tak żeby nowe oprogramowanie pracowało na starych i niewydajnych maszynach? Czy to nie strata czasu, kiedy pracownicy muszą marnować czas czekając aż ich komputer zacznie odpowiadać? Posiadanie bardzo starych komputerów to przykład złego zarządzania czasem i braku produktywności.

Firmy często borykają się z tym problemem. Czasem „oszczędzają” poprzez niekupowanie nowego sprzętu, ale to żadna oszczędność kiedy pracownicy nie mogą używać sprawnie komputerów do swojej pracy. Czasem po prostu nie zdają sobie sprawy że komputery nie są wieczne.

Jeśli nie masz procedury, możesz zacząć od takiej: wszystkie komputery amortyzują się przez 3 lata. Budżet każdego roku zakłada wymianę 1/3 wszystkich maszyn. Na początku każdego kwartału zamawiane jest tyle maszyn, aby można było wymienić 9% najstarszych komputerów w firmie.

Dyrektorzy finansowi lubią takie planowanie, bo wiąże się ono z przewidywalnością. W jednej z firm CFO była bardzo szczęśliwa, kiedy dałem jej możliwość kontrolowania w których miesiącach budżetować zakupy. Ustaliliśmy, że 1/4 planu będzie wykonane w każdym kwartale i ona sama wybierała miesiące. Mogła nawet podzielić poszczególne dostawy w razie potrzeby na mniejsze miesięczne faktury.

Teraz zamiast iść do CFO i co pół roku błagać o nowe komputery to stało się regularnym, zaplanowanym zadaniem. Wszystkim żyło się lepiej.

Protip: niektóre firmy używają innego czasu starzenia się dla serwerów – są one zaprojektowane, aby działać bezproblemowo przez dłuższy okres czasu i można je wymieniać np. co 4 lata. Okazuje się jednak, że serwery są używane przez duże grupy użytkowników, co może usprawiedliwiać nawet dwuletni cykl ich upgrade’u.

F. Wprawa przed katastrofą

23. Czy serwery mogą kontynuować pracę jeśli jeden dysk zawiedzie?

Awaria dowolnego komponentu komputera zwykła powodować awarię. Istniała zależność – jeden komponent, który zawiódł równał się jednek awarii. Jeden martwy dysk równał się jednemu dniowi, który administrator spędzał na odtwarzaniu danych z taśm. Beznadzieja, jeśli na ten dzień została zaplanowana jakaś praca, jeszcze większa beznadzieja jeśli właśnie planowałeś urlop. Jeden martwy dysk oznaczał zepsuty dzień.

Dzisiaj jest nieco inaczej. Budujemy systemy zorientowane na przetrwanie. Jeśli dysk jest komponentem replikującej się pary, wtedy jeden dysk z pary może się zepsuć i nie będzie to oznaczało awarii. Awaria następi tylko kiedy zepsuje się kolejny dysk. Statystycznie daje ci to godziny, a nawet dni aby wymienić szwankujący dysk przed tym, jak pojawi się widzialna dla użytkownika awaria. Pośpiech w wymianie dysku jest lepszy niż spędzenie całego dnia odtwarzając dane z taśm.

Jeśli będziesz hołdować tej zasadzie oddzielisz „awarię komponentu” od „awarii systemu”. Życie staje się prostsze.

Macierze RAID były kiedyś drogie i rzadko widziane. Luksus dla bogatych. Teraz są powszechnie widziane, tanie, a wręcz darmowe (jeśli używasz soft-RAID). Czy powiedziałem powszechne? Miałem na myśli obowiązkowe. Spędzanie dnia na odtwarzanie danych z taśm nie jest tylko oznaką złego planowania, to złe zarządzanie czasem. To strata czasu spędzonego na pocieszanie użytkownika, który stracił lata, miesiące a czasami tylko godziny swojej pracy. To nie heroizm. To oznaka złego zarządzania infrastrukturą. Nie zapominajmy o stracie czasu użytkowników, być może ich setek, w czasie kiedy muszą oni czekać aż dane zostaną przywrócone z taśm. Awarie dysków nie są rzadkie. Jaki jest sens budować system zakładając, że się nie zdarzą?

MTBF (średni czas przed awarią) typowego serwera to 1.5 miliona godzin. Jeśli masz 1000 dysków, średnio na awarię przyjdzie ci średnio czekać 2 miesiące. Jeśli masz ich 10000, najbliższa awaria wydarzy się co tydzień. Czy naprawdę planujesz zajmować się całodziennym odtwarzaniem taśm tak często?

Moja zasada jest prosta: partycja boot powinna być mirrorowana, każdy inny dysk powinien być elementem RAID1 lub wyższego.

Partycja boot: polecam mirror na każdym serwerze, bo nie da się jej przebudować od nowa. Partycje boot zazwyczaj kumulują pliki. Przez lata wiele wersji programów może być tam zainstalowane. Nowe sterowniki, łaty i obejścia mogą nie być udokumentowane. Konfiguracja wygląda bardziej jak historia informatyki niż wynik jakiegokolwiek planowania. W idealnym świecie nic takiego by się nie zdarzyło. Każdy serwer powinien dać się przebudować za pomocą automatycznego systemu. Taki jest cel, ale nie jesteśmy jeszcze u celu. Być może wyjątkiem są klastry HPC, albo takie budowane przez Google i Yahoo. W każdym razie, drogi czytelniku, obstawiam że tam samo jest w twojej sytuacji. Obstawiam nawet że Google i Yahoo mają serwery Windows, które służą autoryzacji kart, które wpuszczają ludzi do budynków, gdzie partycja boot wygląda w taki sposób i ponieważ ich niezawodność jest krytyczna te serwery potrzebuję jej mirrorowania.

Tak, jeśli masz szczęście to może wystarczyć ci dzień na przebudowanie serwera, ale kontroler RAID1 jest tańszy niż minimalna stawka za dzień pracy.

Dane użytkowników: polecam RAID1 lub wyższy dla danych użytkowników ponieważ jest on tak tani, że nieużywanie go byłoby wstrydliwe. Przy okazji, czy wiecie że RAID6 to minimum przy dyskach 2T i większych? Używanie RAID5 przy tak dużych dyskach jest skrajnie nieprofesjonalne. RAID6 lub RAID10 to minumum, przynajmniej na teraz. Koniec dygresji.

Wyjątkiem dla tych reguł jest wdrożenie gdzie usługa może nadal działać niezależnie czy awaria nastąpi na poziomie dysku, maszyny czy całego data center. Także wtedy, kiedy dane mogą zostać przeliczone od zera w czasie mniejszym niż ten gwarantowany przez SLA. Garść przykładów:

  • Użycie nowoczesnych redundantnych systemów plików jak Google FS. System ten sam dba aby każdy obiekt został zapisany przynajmniej na 3 dyskach. GPFS Native RAID (GNR) od IBM robi coś podobnego.
  • Przestrzeń tymczasowa lub „efemeryczna”, co do której użytkownicy wiedzą, że nie mają gwarancji jej dostępności.
  • Pliki wideo, które mogą być odzyskane z oryginalnych nośników.
  • Repliki danych tylko do odczytu, których kopia znajduje się gdzieś indziej. W tej sytuacji jeśli skorzystasz z RAID5 możesz też przyspieszyć proces aplikacji przez użycie większej liczby talerzy dyskowych.
  • Jednorazowe serwery, np. serwer www serwujący statyczne obrazki lub serwer DNS służący jako kopia „secondary” – czyli rodzaje serwerów które mogą być przebudowane szybko i w sposób automatyczny. Jeśli masz ich setki oszczędność na kartach RAID może być zauważalna.

24. Czy szkielet sieci jest redundantny (N+1)?

Awaria dotycząca jednej osoby jest obciachowa. Awaria, która dotyczy wielu osób nie jest akceptowalna. Tak samo jak redundantne dyski są minimum w naszych czasach, tak samo redundantna sieć jest koniecznością.

Wciąż jest akceptowalne, że pojedyńcze połączenie od serwera lub stacji roboczej do pierwszego switcha może zawieść. Jednak poza nim wszystko inne powinno być redundantne na poziomie N+1. Każde łącze trunk powinno składać się przynajmniej z 2 linków. Idealnie jeśli dowolny jeden uplink, karta liniowa lub urządzenie aktywne (router/switch) zawiedzie, komunikacja powinna być utrzymana.

Sieci są przeważnie zorganizowane w podobny sposób: komputery są podłączane do switchy dostępowych, posiadających wiele portów. Te switche mają porty trunk które łączą je z hierarchią switchy core’owych, które odpowiadają za odpowiedni routing pakietów, w tym takich o dalekim zasięgu (do innych budynków i internetu).

Moja zasada jest prosta: sieć core musi być redundatna. Dawniej to był luksus dla bogatych. Obecnie jest to wymaganie minimalne.

Jeśli twoja organizacja nie jest skonfigurowana w taki sposób, żyjecie w świecie, gdzie komputery mogły być przydatne bez połączenia z siecią.

Wyjątek: organizacje tak małe, że nie mają sieci core. Nawet wtedy wszystkie połączenia pomiędzy switchami (porty trunk) powinny być redundantne i powinien być zapewniony „switch na zapas” dla każdego wykorzystywanego w sieci modelu.

25. Czy backupy działają automatycznie?

To pytanie zakłada że backupy są wykonywane. Robicie backupy, prawda?

Potrzebujesz backupów tylko dla 4 powodów:

  1. Cholera, skasowałem plik.
  2. Cholera, serwer zdechł.
  3. O nie, budynek spłonął.
  4. Archiwizacja.

Każdy z tych powodów może zakładać inną metodologię backupów.

Scenariusz (1) rozwiązywany jest w krótkim okresie czasu przez snapshoty. Czasem jednak plik zostaje skasowany i musi być odtworzony znacznie później. Snapshoty nie pomogą. RAID nie pomoże, bo RAID nie jest mechanizmem backupowym. Jeśli ktoś przez pomyłkę skasuje plik, RAID automatycznie zreplikuje tę pomyłkę na wszystkie swoje kopie. Teraz RAID oznacza „Redundant Array of Incorrect Data” (nadmiarową macierz nieprawidłowych danych, oryginalnie „Redundant Array of Inexpensive Drives” – nadmiarowa macierz tanich dysków).

Scenariusz (2) brzmi jak zadanie dla RAID, ale musisz pamiętać że podwójna awaria dysku oznacza, że tracisz cały mirror RAID1 lub cały zestaw dysków RAID5. W RAID10 i RAID6 utracisz dane przy awarii 3 dysków. Takie rzeczy się zdarzają. Zawsze gdzieś czai się szalony elektryk, który zrobi spięcie w instalacji i rozwali ci wszystkie dyski na raz. Serio.

Scenariusz (3) jest często nazywany „disaster recovery” (odtwarzanie awaryjne). Jedyna twoja nadzieja w backupach przechowywanych na dyskach i taśmach poza pierwotną lokalizacją danych.

Scenariusz (4) często jest związana z wymaganiami zgodności. Technologia wykonywania backupów będzie często podobna do (3), ale ze zwiększonym znacznie czasem retencji. Jeśli jakiś dział wymaga archiwizacji dla zachowania zgodności z przepisami, powinni oni pokryć koszt nośników.

Dla każdego z powyższych scenariuszy proces musi być zautomatyzowany. Jeśli budynek spłonie i się zawali zarząd nie zaakceptuje wyjaśnienia, że backupy nie zostały wykonane, bo administrator był na wakacjach albo wypadło mu to z kalendarza.

26. Czy plany awaryjne („disaster recovery”) są okresowo testowane?

Ostatni punkt w sumie oszukuwał. Nie ma 4 powodów dla tworzenia backupów. Są 4 powody aby wykonywać odtworzenia.

Nikt nie przejmuje się tworzeniem backupów. Ludzi interesuje tylko czy mogą odzyskać dane. Jeśli w jakiś sposób wymyślisz jak odzyskać dane bez robienia backupów twoimi pracami najprawdopodobniej zainteresuje się komitet ds. nagród Nobla i będziesz pierwszym administratorem, który taką nagrodę otrzyma.

Nie wiesz czy twoje backupy w ogóle działają zanim nie zaczną być testowane. Systemy backupowe bazujące na nadziei w odtworzenie nie są skuteczne. Wiara czyni cuda, ale nie stanowi skutecznej strategii IT.

Kompletny test powinien symulować pełną awarię i odtworzenie od zera.

Nie będziesz sobie zdawać sprawy z czasu, jaki jest potrzebny na odtworzenie, zanim go nie przetestujesz. Odwarzanie z taśm przeważnie zajmuje 10x więcej czasu niż tworzenie kopii. Jeśli twój system księgowy backupuje się w 8 godzin powinieneś być przygotowany na 80-godzinny czas odtwarzania od zera. To ponad 3 dni.

Jeśli nie robisz jeszcze żadnych testów, robienie jakichkolwiek testów będzie lepsze niż nic. Napisz mały skrypt, który wybierze losowo serwer, potem losowo wybierze dysk i plik na tym dysku. Potem ten skrypt powinien utworzyć ticket w systemie prosząc administratora o odtworzenie tego pliku z backupu w stanie sprzed 6 tygodni. Niech ten skrypt wykonuje się co 6 tygodni. Jest duża szansa że w ten sposób znajdziesz serwer albo dysk, który jeszcze nie jest objęty backupem. Jeśli uważasz że zajmie to dużo czasu, mała podpowiedź: te tickety może robić któryś z twoich współpracowników. Napisz skrypt tak, żeby generował wiadomość tak, jakby faktycznie ktoś prosił o odzyskanie pliku, wtedy twoi koledzy nie zorientują się że to test.

Trochę bardziej zaawansowana technika to ustalenia „dnia zagłady”, kiedy będzie testowany cały system odtwarzania awaryjnego. Niech plan zakłada, że część zespołu zginęła w katastrofie, a pozostali przy życiu muszą wiedzieć jak doprowadzić system do działania w lokalizacji zapasowej. Napisz skrypty które udokumentują w jaki sposób test będzie przeprowadzany. Możesz faktycznie doprowadzać elementy systemu do awarii (np. przez odłączenie zasilania od sprzętu sieciowego) albo odgrywać scenariusz: „martwy” członek zespołu może być prowadzącym scenariusz gry. „Przyjmijmy teraz, że dostaliście wiadomość z takim komunikatem. Powiedzcie jakie komendy wykonacie i jakie działania podejmiecie”. Jeszcze inny sposób, to pozwolenie waszemu CEO na to, aby wszedł do data center i odłączył kabelki, które mu się spodobają.

27. Czy maszyny w datacenter mają możliwość zdalnego dostępu (KVM i kontrola zasilania)?

To nie wymaga tłumaczenia. Zdalne konsole (KVM-over-IP) są niedrogie, większość współczesnych serwerów ma je wręcz wbudowane. Zdalna kontrola zasilaniato nie luksus jeśli komputer jest zlokalizowany dalej niż kilka kilometrów.

Wyjątkiem może być klaster składający się z setek lub tysięcy jednakowych maszyn – jeśli jedna zawiedzie może być automatycznie zastąpiona przez inną.

G. Bezpieczeństwo

28. Czy stacje robocze, laptopy i serwery są wyposażone w samoaktualizujący się, bezobsługowy system anty-malware?

Wirusy i malware to proza życia codziennego. Jeśli uważasz, że złe rzeczy nie zdarzają się dobrym ludziom, to wszyscy musimy być źli. Każda maszyna potrzebuje dziś dobrego softu anty-malware.

Każdy atak złośliwego oprogramowania to praca dla ciebie: czyszczenie popsutych maszyn, odzyskiwanie danych, pocieszanie ludzi, którzy stracili dane. To strata twojego czasu i nieuzasadniona przerwa dla użytkowników. Przykład złego zarządzania czasem.

Programy anty-malware muszą się okresowo aktualizować. Niektóre odmiany pokazują duży popup „Hej, jest aktualizacja! Czy mam ją zainstalować?” – to bardzo ważne okno, bo pokazuje duże logo producenta. Jeśli użytkownicy wiedzą, kto jest producentem, mogą polecać to oprogramowanie także swoim znajomym. Powszechna znajomość marki wpływa też pozytywnie na wycenę rynkową tej firmy. Niezależnie od tego w 9 przypadkach na 10 użytkownik kliknie „nie”. Oprogramowanie, które samo się aktualizuje w tle, bez zadawania głupich pytań nie ma tych zalet. Co za nieodpowiedzialna banda inżynierów, którzy nie wykorzystali takiej okazji!

Jeśli nie masz pewności – tak, to sarkazm.

Jest wiele rozwiązań anty-malware. Te, które powinny cię interesować, to te, które aktualizują się same.

Twoją rolą jest wdrożenie polityki bezpieczeństwa, i część tej polityki to instalacja aktualizacji. Delegowanie tej odpowiedzialności na użytkowników jest złe, możliwe że nawet nieetyczne. Nie pyta się pieszego „Czy powinienem nacisnąć hamulec przed przejściem żeby cię nie przejechać?” i nie pyta się użytkowników czy nie chcieli by być gorzej zabezpieczeni. Oczywiście, kiedyś używaliśmy wolnych modemów i ściąganie definicji wirusów mogło zająć dobre 30 minut. Ale to prawdopodobnie było jeszcze przed tym, jak się urodziłeś. Nie możesz nadal używać tej wymówki. Jeśli pamiętasz te czasy (tak jak ja), to zapewne jesteś na tyle doświadczony, żeby wiedzieć, że to prawda.

Z podobnych powodów oprogramowanie anty-malware nie powinno dać się łatwo wyłączyć. Użytkownicy będą wyłączać tego typu programy pod byle pretekstem. Powszechnie wyłączają je żeby przyspieszyć działanie komputera. Miałem użytkownika, który wyłączał je „bo przyciąga wirusy”. Tłumaczył: widzisz, jak jest aktywne, ciągle wyskakują okna ostrzegające przed wirusem. Jeśli je wyłącze już nic nie wyskakuje. Tak, ludzie którzy mylą przyczynę ze skutkiem występują powszechnie w przyrodzie.

Oprogramowanie anty-malware było długo opcją „dobrze byłoby mieć”, ale teraz jest wymagane. Oto moje osobiste zasady:

  1. Skaner anty-malware musi być uruchomiony na wszystkich maszynach, włączając w to serwery, na których występują wykorzystywane przez użytkowników pliki: katalogi domowe, udziały współdzielone, treści stron WWW, serwery FTP, itp, itd.
  2. Aktualizacje muszą instalować się automatycznie i po cichu. Bez ingerencji użytkownika.
  3. Musi istnieć mechanizm pozwalający wykryć, że program został wyłączony. Powinien on się komunikować z centralną konsolą i wysyłać raporty, tak, żebyś wiedział które maszyny przestały się aktualizować.
  4. Poczta musi być skanowana na serwerze, nie kliencie (lub tylko dodatkowo na kliencie). Wiadomości zawierające malware muszą być odrzucane, wiadomości zawierające spam powinny być umieszczane w kwarantannie. Nie możesz ufać, że każda stacja robocza będzie miała tej samej jakości filtry jak oprogramowanie serwerowe. Zatrzymaj problem, zanim dotrze on do klienta.

29. Czy istnieje opisana formalnie „polityka bezpieczeństwa”?

Wzorowanie się na istniejących politykach to świetny pomysł na start i czerpanie pomysłów. Amerykański SANS ma stronę ze zbiorem przykładów (po angielsku):

Zasoby po polsku:

To bardzo ważne, aby istniała pisemna polityka zanim przejdziesz do jej wdrażania.

30. Czy wykonywane są periodyczne wewnętrzne audyty bezpieczeństwa?

Ten punkt nie wymaga rozwinięcia. Jeśli nie testujesz swojej infrastruktury pod kątem bezpieczeństwa, nie wiesz jak bardzo podatna jest twoja infrastruktura.

31. Czy dowolne konto może być zablokowane wszędzie w przeciągu 1 godziny?

To w dużej mierze test jak działa twój zespół i twoje środowisko, niż samo formalne wymaganie zablokowania konta. Pokazuje, że używacie globalnej bazy użytkowników.

Posiadanie centralnej bazy uwierzytelniającej, już wyszło poza kategorię „ciekawych wdrożeń”. Teraz to „mus”. Jeśli myślisz, że jej nie potrzebujesz, bo organizacja jeszcze nie jest taka duża, zobaczysz, że nie będziesz mieć czasu na jej wdrażanie, kiedy ona zacznie dynamicznie rosnąć.

Najlepsza praktyka to posiadanie systemu określającego cykl życia konta użytkownika. Taki system śledzi, kiedy konta są tworzone i jak są zmieniane od czasu rekrutacji pracownika aż do czasu rozwiązania umowy i dalej. Co się dzieje kiedy użytkownik zmienia nazwisko? Co, jeśli już kiedyś pracował? Co, jeśli już kiedyś pracował i zmienia nazwisko? Jest wiele przykładów przypadków brzegowych, które taki system musi wspierać.

32. Czy hasło „root” może być zmienione wszędzie w przeciągu 1 godziny?

To także oznacza wiele więcej niż tylko to, o co dosłownie pyta to pytanie. Oznacza, czy dostępy administracyjne są dobrze zarządzane.

Jeśli nie masz takiej możliwości, stwórz listę kontrolną (checklist), miejsc gdzie dostępy powinny być zmienione i umieść ją na wiki. Zmień hasła globalnie, krok po kroku realizując listę i dodając do niej nowe punkty dla nowych urządzeń o których sobie przypominasz. Dla egzotycznych systemów możesz chcieć udokumentować też sam proces – jak zmienić hasło.

Jeśli masz taką możliwość, to stwórz stronę wiki, która określa kto może zarządać takiej globalnej zmiany. Zautomatyzuj ją za pomocą skryptów i udokumentuj miejsca, gdzie wciąż trzeba ją wykonać ręcznie.

 

Kontakt

Oryginalni twórcy są osiągalni tutaj. W kwestiach związanych z tłumaczeniem prosimy o kontakt tutaj.

Od tłumacza:

Ponad półtora roku zajęło mi „przykładanie się” do tłumaczenia tego świetnego opracowania, najpierw na potrzeby mojej własnej organizacji, potem jako konsultant i szkoleniowiec, aby pomóc własnym klientom odnieść sukces. Jeśli ta lektura była dla ciebie pomocna, albo chciałbyś podzielić się swoimi uwagami, to zapraszam do kontaktu bądź elektronicznego (link powyżej) lub osobistego, np. na warszawskich spotkaniach WPUG – rozmawiamy tam nie tylko o puppecie, ale też devops i wszystkim tym, co może pomóc w utrzymaniu nowoczesnej infrastruktury. Lubimy też krafty. Serdecznie zapraszam!

Comments are closed.