Jak rejestrować zmiany serwera?

Więc prawdopodobnie wszyscy mieliśmy taką sytuację: debugujesz jakiś problem, tylko po to, aby zdać sobie sprawę, że był on spowodowany zmianą konfiguracji dokonaną sześć miesięcy temu i nie pamiętasz, dlaczego to zrobiłeś. Więc cofnij go i napraw problem, a teraz wróci jakiś inny problem. O tak, TERAZ pamiętam! Następnie naprawisz to poprawnie.

To dlatego, że nie zrobiłeś właściwych notatek, głupcze! Ale jak to zrobić?

W inżynierii mamy mnóstwo oprogramowania, które ma nam pomóc w wykrywaniu i śledzeniu zmian. Kontrola źródła, recenzje kodu i tak dalej. Każda zmiana jest śledzona, każda zmiana wymaga komentarza, co to jest. Typowe działy inżynieryjne wymagają dobrych komentarzy, więc w ciągu sześciu miesięcy, gdy zastanawiasz się, dlaczego tak się zepsułeś, możesz użyć historycznej funkcji „winy” lub kompilacji wyszukiwania binarnego, aby wskazać problem. Narzędzia te są bardzo skutecznymi narzędziami komunikacji i zapisami historycznymi.

Ale na serwerze mamy 500 różnych usług, wszystkie z różnymi sposobami ich konfiguracji. I nie zawsze mają format tekstowy (rozważ ustawienie uprawnień do folderu lub zmianę lokalizacji pliku strony), chociaż mogą mieć reprezentację tekstową.

W naszym środowisku sprawdzamy, jakie pliki konfiguracyjne możemy wprowadzić w Perforce, ale jest ich bardzo niewiele. Nie mogę dokładnie sprawdzić w bazie danych Active Directory ... chociaż może zrzut, który może być różny ...

W przeszłości próbowałem prowadzić dziennik ręcznych zmian na naszej wiki, ale bardzo trudno jest utrzymać dyscyplinę, aby to robić (wiem, że nie jest to dobra wymówka, ale to naprawdę trudne).

MOJE PYTANIE: Jakich strategii i narzędzi używasz, aby poradzić sobie z problemem śledzenia zmian konfiguracji na serwerach?

-- Aktualizacja --

Uwaga: nie szukam narzędzi do robienia notatek udostępnionych (znam OneNote itp.) Tak bardzo, jak automatyczne narzędzia przeznaczone specjalnie do śledzenia zmian na serwerze. Nie ma kompleksowego narzędzia do śledzenia zmian konfiguracji serwera, ale być może są pewne dla konkretnych aplikacji, takich jak obiekty GPO.

Jestem również bardzo zainteresowany konkretnymi strategiami, które uważasz za przydatne. „Dzielimy się notatkami w Sharepoint” jest dość niejasne. Jak utrzymujesz dyscyplinę? Jakiego formatu używasz do śledzenia zmian? Jak organizujesz swoje dane zmian? Naprawdę chciałbym przykłady i pomysły.

Na ziemi Linuksa ludzie stosują kilka różnych strategii:

• Systemy ograniczeń konfiguracji , takie jak cfengine lub marionetka lub szef kuchni . Są one podobne do GPO systemu Windows. Zwróć uwagę, że cała konfiguracja serwera jest celowo udokumentowana w jednym miejscu i wiesz, na jakiej szczegółowości (serwerownia, grupa, konkretny serwer) wprowadzono zasady. To cię nie uratuje przed „czym do diabła było inaczej sześć miesięcy temu?” ale pozwala tylko na konfigurację serwera i odbudowanie od zera. Możesz poddać kontrolę silnika i marionetek kontroli wersji, aby odpowiedzieć na pytanie.
• Kontrola wersji / itp . Ogólnie programy Linux przechowują swoją konfigurację w jednym miejscu / etc. Odważni zaczynają pisać skrypty, aby umieścić / etc w kontroli wersji. Jednym z takich programów, o których wiem, jest etckeeper :

Opis: przechowuj / etc w git, mercurial, bzr lub darcs
 Program etckeeper to narzędzie do przechowywania / etc w git, mercurial,
 repozytorium bzr lub darcs. Łączy się z APT, aby automatycznie zatwierdzać zmiany
 wykonane do / etc podczas aktualizacji pakietów. Śledzi metadane plików tej wersji
 systemy sterowania zwykle nie obsługują, ale jest to ważne dla / etc, takich
 jako uprawnienia / etc / shadow. Jest dość modułowy i konfigurowalny
 jest również prosty w użyciu, jeśli rozumiesz podstawy pracy z wersją
 kontrola.

Jednym z problemów w tej sytuacji jest to, że tak naprawdę jest to połączenie procesu biznesowego / problemu technologicznego. Jest zdecydowanie większy niż śledzenie zmian wprowadzonych przez administratora. Musisz także uważać na nieoczekiwane zmiany i dobrą koordynację między administratorami lub jednostkami, aby zmiana w kontrolerze AD nie złamała ustawienia uprawnień do bazy danych na niektórych serwerach departamentowych. Tj. Twoje pytanie to gigantyczna puszka robaków :)

W mojej organizacji mamy około roku na wdrożenie procesów i systemów, aby rozwiązać ten problem. Po stronie procesów biznesowych utworzyliśmy zespół ds. Zarządzania zmianami. Według SOP wszystkie zmiany w środowiskach produkcyjnych są za ich pośrednictwem koordynowane. Kompilują wszystkie zmiany, wraz z zakresem, systemami, których dotyczą, usługami itp. Egzekwują dobrą dokumentację zmian, a także plany wycofywania i wycofywania. Organizuj cotygodniowe (otwarte) spotkania, aby omawiać nadchodzące zmiany środowiska, a następnie wysyłaj e-maile ze szczegółami wszystkich tych zmian. Ostatecznym celem tego procesu jest, aby wszyscy w IT wiedzieli o wszystkim, co się dzieje. Pomaga to zatrzymać problem, na przykład, SysAdmin instalujący łatę do jądra i restartujący system, który usunie bazę danych zegara czasu.

Jeśli chodzi o stronę technologiczną, mogę mówić tylko o systemach Unix / Linux, ponieważ nie mam do czynienia z Windows. Wprowadzają Puppet firmy Reductive Labs do zarządzania konfiguracją wszystkich tych systemów. Po prostu jest to system klient / serwer, w którym definiuje się konfigurację maszyny na serwerze, a klient tak często wykorzystuje te szanse (domyślnie 30 minut). Dodatkowo, jeśli istnieje szansa na pliki zarządzane lokalnie, wówczas są one również cofane w tym czasie. Używamy go do zarządzania uruchomionymi usługami, konfiguracjami zapory ogniowej, autoryzacji użytkowników itp.

Poleciłbym również zajrzenie do czegoś takiego jak TippingPoint. Jest to usługa kliencka, która obserwuje konfigurację systemu i wysyła powiadomienia o zmianach. Sprawia, że ​​jesteśmy najbardziej zadowoleni z bezpieczeństwa. Jest w dużej mierze wykorzystywany do śledzenia złośliwych lub niepublikowanych zmian.

Byłem w 4 lub 5 firmach, teraz tak naprawdę nie pamiętam.

Wszyscy mieliśmy ten problem. Nikt z nas nie rozwiązał tego w 100 procentach, ale w firmie, w której obecnie jestem, mamy najlepszą, jak dotąd, strategię.

Sharepoint / Wiki / Evernote / PINs

• Sharepoint
  • narzekaj, ile chcesz ... ma kilka bardzo fajnych funkcji listy.
  • Listy adresów IP
  • Inwentarz
  • konta usług i korzystanie
  • zmień dzienniki powiadomień
• Wiki
  • Poradniki
  • listy zadań dalekiego zasięgu
• Evernote
  • ja i mój partner używamy tego do umieszczania wszystkiego, czego nie chcemy na Wiki
  • więcej poradników o charakterze technicznym
  • notki, które oboje musimy zobaczyć
  • rozliczanie zadań na tydzień
  • listy zadań wykonawcy
  • Evernote Clipper ułatwia ekranowanie ustawień AD / praw
  • dostępne wszędzie
• PIN-y
  • Repozytorium haseł

Prawdopodobnie są lepsze narzędzia do niektórych z nich, ale tego używamy:

• Śledź zmiany konfiguracji i uaktualnienia / łatki dla poszczególnych serwerów w prywatnej wiki
• Zachowaj także instrukcje i zapis problemów / rozwiązań na wiki
• Użyj Sharepoint lub Dokumentów Google, aby zachować autorytatywne kopie rzeczy, takich jak statyczne listy IP
• użyj Subversion do śledzenia zmian w plikach konfiguracyjnych

W przypadku systemu Windows sprawdź serię Microsofts System Center lub dowolnego innego konkurenta w zakresie konfiguracji i zarządzania usługami dla tej platformy.

Zmiany muszą być kierowane przez porządną procedurę zarządzania zmianami, która sama zatwierdza i rejestruje je, zanim zostaną faktycznie wykonane. Może to być instrukcja w 100% na początek. W przypadku niektórych lepiej zintegrowanych narzędzi można poprosić narzędzie o dokonanie rzeczywistych zmian i uzyskać „automatyczne” wylogowanie z centralnej bazy danych konfiguracji - zamiast wchodzić gołymi rękami w konsolę pojedynczego serwera, przeglądając ustawienia ręcznie, aby spróbuj rozwiązać problem w stylu kowbojskim.

Absolutnie powinieneś wdrożyć proces zarządzania zmianami, zwłaszcza jeśli w twoim środowisku jest wiele osób, które mają możliwość / dostęp do wprowadzania zmian na poziomie systemu. Zapewnia to również zarządowi możliwość wypisania się na potencjalne zmiany, jednak jego wadą jest opóźnienie w procesie zmian, jeśli nie można wprowadzać zmian w locie.

Niektóre sposoby śledzenia zmian mogą obejmować sprawdzanie poprawności zdarzeń w SEM (zakładając, że masz Security Event Managera) lub narzędzia takie jak Nessus (przy dużym nakładzie pracy można przeprowadzić audyt środowiska, aby znaleźć zmiany).

To jest bardziej zlokalizowana odpowiedź oparta na * nix. Nie znalazłem żadnych dobrych narzędzi do emulacji go w systemie Windows.

Istnieje kilka sposobów na wdrożenie tego ... i złapanie go, gdy zapomnisz.

Systemy kontroli wersji, takie jak subversion, git, cvs lub RCS, to dobry sposób na śledzenie historii pliku konfiguracyjnego. Jeśli nie chcesz instalować systemu kontroli wersji na swoich serwerach produkcyjnych, przechowywanie katalogów plików konfiguracyjnych lokalnie lub zdalnie przy użyciu czegoś takiego jak rsnapshot da ci większość korzyści z RCS, ale stracisz możliwość audytu lub pozostawienia zatwierdzenia logi (chociaż można to obejść z komentarzami w samych plikach).

Aby pomóc Ci zapamiętać zmiany, dobrym pomysłem jest zautomatyzowane raportowanie zmian konfiguracji za pomocą nocnego, cron'ed tripwire run. Po zbudowaniu bazy danych tripwire o bieżącym stanie plików, każda zmiana w nich spowoduje wysłanie e-maila podczas następnego uruchomienia. Będziesz nadal otrzymywać tę pocztę, dopóki baza danych nie zostanie zaktualizowana, tym samym „resetując” tripwire.

Korzystałbym z systemu śledzenia problemów, takiego jak flyspray (każdy zadziała, ale lubię flyspray dla rzeczy nieprogramujących). Zanim ktokolwiek dotknie konfiguracji, poprawa / problem powinien zostać zarejestrowany. Po naprawieniu / wdrożeniu zmiany są wprowadzane do zgłoszenia.

Wiki może być miło udokumentować bieżącą konfigurację, ale łatwo jest ją zaktualizować - i wydaje się, że potrzeba więcej wysiłku, aby zaktualizować IMO.

Nie znajdziesz czegoś zautomatyzowanego, aby to zrobić - chociaż prawdopodobnie możesz to skonfigurować, więc zmiany niektórych plików konfiguracyjnych są automatycznie wysyłane pocztą e-mail do narzędzia do śledzenia problemów, jeśli chcesz.

Myślę, że to tylko kwestia dobrej polityki, niskich barier i dyscypliny.

Stworzyliśmy coś domowego, aby zrobić śledzenie zmian dzienników w naszym środowisku; nie jest to nic bardzo skomplikowanego i działa całkiem dobrze.

• Polityka samokontroli polega na tym, że wszelkie zmiany, które w twoim oszacowaniu odbiegają od konfiguracji domyślnej lub mogą potencjalnie powodować problemy, powinny być udokumentowane w systemie dzienników zmian.
  • przeciwną stroną tej „monety” jest, jeśli rozwiązujesz problem, wyszukaj ostatnie lub powiązane wpisy dziennika zmian.
• Zaloguj się do systemu i wybierz serwer, usługę lub składnik sprzętowy, który zmieniasz
  • komponenty zostały wcześniej wprowadzone do tego samego systemu z podstawowymi informacjami „demograficznymi” (lokalizacja, dostawca, numer seryjny, odpowiedzialny dział)
• Wybierz z listy podstawowych kategorii
  • Nieplanowane przestoje
  • Łatanie
  • Konserwacja sprzętu
  • Instalacja oprogramowania
• Podaj szczegóły tego, co zrobiłeś, widziałeś, zaobserwowałeś
• kopia jest wysyłana do strony odpowiedzialnej i przechowywana jako pliki XML indeksowane przez moduł wyszukiwania.
• Zysk

Jak powiedziałem, nic szczególnego. Wykorzystuje PERL CGI (został napisany miliard lat temu) oraz moduł wyszukiwania Google do indeksowania.

Niedociągnięcia:

• Grupy usług są trudne do pracy, na przykład właśnie dodałeś tę samą poprawkę do wszystkich 25 kontrolerów domeny; nie mamy grupy „Kontroler domeny”, więc musimy ręcznie wybrać je wszystkie
• Nie integruje się z raportowaniem błędów dziennika sprzętu, oprogramowania lub dziennika zdarzeń, aby pomóc w rozwiązywaniu problemów
• w związku z tym ręczne wprowadzanie danych dla wszystkich danych „demograficznych”, jak powiedziałem powyżej

W każdym razie, jeśli mimo wszystko będziesz zainteresowany kodem, daj mi znać, a ja prawdopodobnie mogę go pobrać, aby udostępnić.

Jak już powiedziano, jest to często kwestia kulturowa - w końcu niektóre sklepy deweloperskie nie przejmują się już komentarzami (samodokumentujący kod jest dziś modnym modnym hasłem!), A niektóre używają systemu kontroli wersji jako świętego Graala zapisów historycznych. Oczywiście nie są one idealne.

Tak więc jedynym prawdziwym sposobem, aby to naprawić, jest uczynienie z tego rozwiązania kulturowego. Upewnij się, że wszystkie przyczyny zmian są rejestrowane w narzędziu do śledzenia błędów (lub w bazie wiedzy lub wiki) i upewnij się, że wszystkie zmiany są rejestrowane w systemie kontroli zmian.

Mamy klientów korzystających z usług ratunkowych, każda zmiana, która dzieje się w ich systemie, jest rejestrowana i za każdym razem, gdy logujemy się do ich systemu, musimy to rejestrować. W przypadku niektórych z nich musimy najpierw zadzwonić po pozwolenie (i myślę, że oni też to logują!). Każda zmiana jest rejestrowana, a zmiana systemu klienta bez logowania będzie karą dyscyplinarną.

Brzmi uciążliwie, ale nie jest. Szybko nabrałeś zwyczaju dodawania się do dziennika dostępu i zmiany dziennika - nie jest to gorsze niż pisanie komentarza podczas sprawdzania zmiany kodu.

Polecam narzędzie do śledzenia błędów jako dziennik przyczyny kontroli zmiany, ponieważ zazwyczaj są one łatwe do aktualizacji (używam Mantis).

Jeśli szukasz „rozwiązania dla przedsiębiorstw” (tzn. Masz więcej pieniędzy niż bóg i chcesz mieć naprawdę fajne narzędzie), narzędzie, którego użyłem do wspierania i zapewniania pracy na miejscu, robi to jako jedna z jego wielu funkcji.

Nie mam pojęcia, jaka jest podstawowa cena, ale zanim HP kupił Opsware, było to około 350 000 USD (bez wsparcia i zaufaj mi - chciałeś wsparcia, kiedy zaczynałem od Opsware).

Kilku klientów, których mieliśmy podczas pracy, korzystało z konfiguracji aplikacji i funkcji migawek w połączeniu z Tripwire .

Oczywiście, jeśli nie masz budżetu - jest to zły wybór ™ :)

I, fwiw, reklama, która pojawiła się u mnie na górze tej strony, gdy ją ponownie załadowałem, dotyczyła elementów specjalnych . Wygląda podobnie jak HPSA :)

Jeśli wszystko, co chcesz zrobić, to śledzić zmiany i nie zarządzać całym procesem (tj. Za pośrednictwem szefa kuchni lub marionetki), po prostu rsyncswój etckatalog (gdziekolwiek to możliwe) w lokalnym repozytorium git.

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

W razie potrzeby możesz oczywiście dodać inne źródła.