Czy są jakieś dobrze znane anty-wzorce w dziedzinie administracji systemem? [Zamknięte]

Znam kilka typowych wzorców, które wydają się oprzeć prawie każdemu projektowi w pewnym momencie jego cyklu życia:

1. Brak możliwości przerwania dostaw
2. Komponenty firm trzecich blokujące aktualizacje
3. Niejednorodne środowiska
4. Brak monitorowania i ostrzegania
5. Brakuje nadmiarowości
6. Brak pojemności
7. Słabe zarządzanie zmianami
8. Zbyt liberalne lub wąskie zasady dostępu
9. Zmiany organizacyjne niekorzystnie zacierają własność infrastruktury

Miałem nadzieję, że istnieje jakaś dobrze wyartykułowana biblioteka tych anty-wzorów streszczona w książce lub na stronie internetowej. Jestem prawie pewien, że wiele organizacji uczy się metodą prób ogniowych. Jeśli nie, zacznijmy jeden.

Pozostawienie zautomatyzowanych zadań do zautomatyzowania, dopóki nie zostanie wykonane ręcznie, zajmuje wystarczająco dużo czasu, aby nie można ich zautomatyzować, ponieważ wykonywanie zadań ręcznie przez cały czas je.

I odwrotnie, przedwczesna automatyzacja. Absolutnie nie ma potrzeby poświęcania 3N godzin na automatyzację jednorazowego zadania, które zajmuje N godzin ręcznie (nawet jeśli automatyzacja jest przyjemniejsza niż przerzucanie rzeczy ręcznie).

A. nie testowanie przywracania - kopię zapasową można zweryfikować i jest w porządku, ale jak przywrócić?

Jak długo to trwa? Musisz to zrobić w sytuacjach stresowych ...

B. brak zarządzania konfiguracją, brak jednolitości - po prostu zmiana tu i tam i myślę, że tu dostroiłem ...

Kto wie, jak replikować dobrze wykonany serwer, jeśli wszystkie dziwactwa nie są spisane i nie ma identycznych konfiguracji w sklepie? Co się stanie, jeśli uda się przywrócić dane, ale nie konfigurację, aplikacji?

C. brak monitorowania - nie mam pojęcia, jak i co robią skrzynki

Jest to dwojakie: a) musisz monitorować alarmy, aby zareagowały na czas, zanim zabraknie jakiegoś zasobu lub dziwnego zachowania oraz b) musisz monitorować długoterminową tendencję do zarządzania pojemnością (dysk, procesor, pamięć RAM, sieć,. ..).

D. brak redundancji w twoim cfg - co dzieje się, gdy XX umrze

Oznacza to planowanie z wyprzedzeniem, co chcesz od swojego administratora systemu.

Dla mnie są one najważniejsze.

Najbardziej zabójczym wzorcem jest sytuacja, gdy dział administracji systemu (lub cały dział IT) staje się biernym uczestnikiem firmy. Oznacza to, że są postrzegane jako samoobsługa, w której każdy ma już sformułowane pomysły na to, jak należy to robić, biorąc pod uwagę wyłącznie potrzeby użytkowników, a nie potrzeby całego ekosystemu IT jako całości.

Drugi najbardziej zabójczy wzorzec ma miejsce, gdy dział administracji systemu zamienia się w kilka popychaczy przycisków, tj. Całe oprogramowanie / narzędzia są kupowane lub rozwijane i instalowane przez osoby trzecie, a administracja systemu przechodzi oficjalne szkolenie i instrukcję, a następnie postępuje zgodnie z instrukcjami obsługi i instrukcjami eskaluj do dostawcy wszystko, co nie jest wyraźnie zawarte w instrukcji. Ta sytuacja może być bardzo wygodna dla (niektórych, jeśli nie większości) administratorów systemu, ale jest to katastrofa, która czeka się, gdy fakt, że nikt tak naprawdę nie wie, jak działa cały system, sprowadzi go na ziemię (pomyśl subtelne interakcje między komponentami i gra o winy między sprzedawcami).

1) zbyt obiecujące i niedostateczne dostarczanie (tj. Utrzymywanie realistycznych oczekiwań użytkowników)

2) Brak weryfikacji kopii zapasowych, dopóki nie będą potrzebne.

edycja: Zamierzałem, aby numer 2 obejmował przywracanie plików / danych

Brak monitorowania wzorców użytkowania kont AD, takich jak czas ostatniego logowania> 30 dni

(Musimy to zrobić z powodów kontrolnych, ale wyniki są dość szokujące)

• Przechowywanie kluczowych informacji w folderze głowa / skrzynka odbiorcza / dokumenty jednej osoby. Jeśli jest to ważne, np. Dane kontaktowe dostawcy, klucze licencyjne, instrukcje konfiguracji, muszą być dostępne dla każdego w dziale, który ma uprawnienia i może wymagać dostępu, oraz w standardowym miejscu.

• Pytanie osoby, która wie o czymś, aby to udokumentować. Brzmi dobrze, ponieważ to oni mają wiedzę, ale tak naprawdę jest źle, ponieważ nie mogą łatwo powiedzieć, co jest ważną wiedzą. Lepiej mieć z tym do czynienia z kimś nowym, prosząc znaną osobę o wszelkie potrzebne informacje i posiadając przy tym dokumentację.

• Niejasna dokumentacja. Każdy może rozwiązać problem o średnim priorytecie w ciągu dnia, z całym działem IT dostępnym do rozmowy. Kolejną sprawą jest rozwiązanie problemu o wysokim priorytecie późną nocą, kiedy jesteś prawie sam i nie masz pojęcia, dlaczego system jest skonfigurowany tak, jak jest lub dlaczego nie pasuje do tego, co mówi dokumentacja.

• Niewłaściwe śledzenie haseł. Więc szybko potrzebujesz konta, utwórz je z losowym hasłem, a następnie 18 miesięcy później będzie ono nadal używane i nikt nie zna hasła ani które usługi się zepsują, jeśli zostaną zmienione.

• Nie kupowanie pomocy technicznej dla kluczowych systemów, ponieważ jest to „zbyt drogie”.

• Niewłaściwe priorytety. Informatycy powinni kierować się zarządzaniem - powinna istnieć zgoda, które projekty są priorytetowe, aw nagłych przypadkach, które systemy są wymagane w pierwszej kolejności. Jeśli dział IT próbuje naprawić system biznesowy, zarząd żąda wiadomości e-mail, a użytkownicy wymagają przetwarzania zamówień, to przepis na bałagan.

• Niewłaściwe rozwiązania - IT bardzo łatwo utknęło w myśleniu „naprawić, system IT musi działać tak, jak wcześniej”, kiedy bardziej odpowiednie może być zawarcie umowy zarządzania z IT, aby „spróbować 2 godziny, jeśli nie zostanie to naprawione, przestań, nawet jeśli wygląda obiecująco, i przejdź do odzyskiwania z kopii zapasowej ”.

• Wszędzie kopie plików testowych. Nie chcesz otwierać folderu z systemem biznesowym lub witryną i wyświetlać „strona internetowa nowa /, strona internetowa aktualna /, strona internetowa kopia /, strona internetowa testowanie /, strona internetowa test-dave /, strona internetowa- ten-jeden /, strona internetowa z lutego / itp.) Opracowanie, produkcja i testy powinny istnieć i powinny być oddzielone od każdego zaangażowanego działu (IT, deweloperów, zarządzania projektami itp.), wiedząc, co powinno być, gdzie i uzgodniono, w jaki sposób zmiany są zatwierdzone. Również dla plików konfiguracyjnych.

• Zmień zatwierdzenie - nawet jeśli najpierw rozmawiasz ustnie, nie zmieniaj sposobu, w jaki ważne rzeczy działają bez wiedzy innych osób. Od Ciebie zależy, jakie „ważne” okrycia dla Twojej sytuacji.

• Rozwiązania nierozwiązane pozostawiono na miejscu na dłuższą metę. Wiem, że po prostu szybko połączyłeś ten serwer do tej sieci ze starym przewodem telefonicznym, abyś mógł rozwiązać pilny problem. Wiem, że nie masz czasu, aby poprawnie go przerobić. Znajdź czas.

• Słabe relacje z resztą firmy. IT to usługa, która pomaga reszcie firmy wykonywać swoją pracę. Jeśli potrzebują szybko dużych plików, spraw, by tak się stało. Jeśli potrzebujesz zgody menedżera na zakup sprzętu, zdobądź go. Jeśli nie możesz tego zrobić, wyraźnie komunikuj, że ogromne pliki nie mogą się szybko przenosić, ponieważ zarząd nadał priorytet innym wydatkom. Jeśli potrzebujesz archiwizacji z przyczyn prawnych, ale nie masz budżetu, musisz jak najlepiej dopasować archiwizację do swojego systemu.