Jakie rzeczy sysadmin powinien wiedzieć każdy programista?

Jako programista zwykle przyjmujemy sysadmins za pewnik. Kilka razy, kiedy byłem bez dobrego administratora, naprawdę doceniłem to, co robicie. Kiedy zapuszczamy się w środowisko bez administratora, jakie słowa mądrości możesz nam zaoferować?

Zacząłbym od:

1. Zawsze miej jakiś system kopii zapasowych. Nawet lepiej, jeśli ma historię.
2. Zastanów się nad pojedynczymi punktami niepowodzenia i jak sobie z nimi poradzić w razie niepowodzenia.
3. W zależności od liczby zaangażowanych komputerów, znalezienie sposobu na stworzenie i utworzenie standardowego obrazu na różnych komputerach ułatwi życie każdemu - nie „działa na moim”, ponieważ takiego i takiego programu normalnie nie zainstalowano.
4. Dokumentuj wszystko, choćby dlatego, że zapomnisz, jak coś skonfigurowałeś.
5. Bądź na bieżąco z aktualizacjami zabezpieczeń.

<wstaw tutaj duże zastrzeżenie prawne>

Niektóre z nich zostały już powiedziane, ale warto je powtórzyć.

Dokumentacja:

• Dokumentuj wszystko. Jeśli nie masz, zainstaluj wiki pod radarem, ale upewnij się, że masz kopię zapasową. Zacznij od zbierania faktów, a pewnego dnia powstanie duży obraz.

• Twórz diagramy dla każdego logicznego fragmentu i aktualizuj je. Nie mogłem policzyć, ile razy uratowała mnie dokładna mapa sieci lub schemat klastrów.

• Zachowaj dzienniki kompilacji dla każdego systemu, nawet jeśli są to po prostu polecenia kopiuj i wklej, aby je zbudować.

• Podczas budowania systemu zainstaluj i skonfiguruj aplikacje, przetestuj, czy działa i przeprowadź testy porównawcze. Teraz wytrzyj dyski. Poważnie. „dd” pierwszy megabajt z przodu dysków lub w inny sposób uniemożliwi uruchomienie systemu. Zegar tyka: udowodnij, że twoja dokumentacja może go odbudować od zera (lub jeszcze lepiej, udowodnij, że twój kolega może jedynie dokumentacją). Stanowi to połowę planu odzyskiwania po awarii.

• Teraz masz pierwszą połowę planu odzyskiwania po awarii, udokumentuj resztę; jak przywrócić stan aplikacji (przywrócić pliki z taśmy, ponownie załadować bazy danych ze zrzutów), szczegóły dotyczące dostawcy / pomocy technicznej, wymagania sieciowe, jak i gdzie uzyskać sprzęt zastępczy - wszystko, co możesz o tym pomyśleć, pomoże przywrócić system.

Automatyzacja:

• Zautomatyzuj jak najwięcej. Jeśli musisz coś zrobić trzy razy, upewnij się, że drugi poświęca na rozwój automatyzacji, aby trzeci był w pełni zautomatyzowany. Jeśli nie możesz go zautomatyzować, udokumentuj to. Dostępne są pakiety automatyzacji - sprawdź, czy możesz sprawić, by działały dla Ciebie.

Monitorowanie:

• Instrumentacja aplikacji jest czystym złotem. Możliwość obserwowania transakcji przechodzących przez system znacznie ułatwia debugowanie i rozwiązywanie problemów.

• Twórz kompleksowe testy, które dowodzą nie tylko, że aplikacja jest aktywna, ale naprawdę robi to, co powinna. Punkty są twoje, jeśli można je podłączyć do systemu monitorowania w celu powiadamiania. Służy to podwójnemu obowiązkowi; oprócz udowodnienia, że ​​aplikacja działa, znacznie ułatwia aktualizację systemu (monitorowanie raportów systemowych na zielono, aktualizacja działała, czas wracać do domu).

• Porównuj, monitoruj i zbieraj dane dotyczące wszystkiego, co jest do tego rozsądne. Testy porównawcze podpowiedzą, kiedy można się spodziewać, że coś wydostanie się z magicznego dymu. Monitorowanie informuje, kiedy ma. Metryki i statystyki ułatwiają zdobycie nowego zestawu (ze świeżym magicznym dymem) poprzez zarządzanie.

• Jeśli nie masz systemu monitorowania, zaimplementuj go. Punkty bonusowe, jeśli faktycznie wykonasz w nim powyższe kompleksowe testy.

Bezpieczeństwo:

• „chmod 777” (inaczej udzielanie wszystkich uprawnień dostępu / uprawnień) nigdy nie jest rozwiązaniem.

• Subskrybuj zasadę „najmniej bitów”; jeśli nie jest zainstalowany, skopiowany lub w inny sposób żyje na dysku, nie można go złamać. Instalowanie systemu operacyjnego i oprogramowania „zlewozmywaka” może ułatwić życie w fazie kompilacji, ale ostatecznie trzeba za to zapłacić.

• Dowiedz się, do czego służy każdy otwarty port na serwerze. Często je kontroluj, aby upewnić się, że nie pojawiają się nowe.

• Nie próbuj czyścić zainfekowanego serwera; trzeba go odbudować od zera. Odbuduj na zapasowym serwerze ze świeżo pobranym nośnikiem, przywracając tylko dane z kopii zapasowych (ponieważ pliki binarne mogą być zagrożone) lub klonuj zainfekowanego hosta w miejscu izolowanym do analizy, abyś mógł przebudować na tym samym zestawie. Wokół tego jest cały legalny koszmar, więc popełniaj błąd po stronie ochrony na wypadek, gdybyś musiał skorzystać z legalnych dróg. (Uwaga: IANAL).

Sprzęt komputerowy:

• Nigdy nie zakładaj, że coś zrobi to, co jest napisane na pudełku. Udowodnij, że robi to, czego potrzebujesz, na wszelki wypadek. Przekonasz się, że „to prawie działa” częściej niż się spodziewałeś.

• Nie oszczędzaj na zdalnym zarządzaniu sprzętem. Zarządzanie konsolami szeregowymi i wyłączaniem oświetlenia należy uznać za obowiązkowe. Punkty bonusowe za zdalnie sterowane listwy zasilające na czas, gdy brakuje Ci opcji.

(Poza tym: Istnieją dwa sposoby rozwiązania problemu o 3 nad ranem, jeden polega na cieple, pracy na laptopie przez VPN w piżamie, drugi na grubej kurtce i przejażdżce do centrum danych / biura. Wiem który woleć.)

Zarządzanie projektem:

• Zaangażuj ludzi, którzy będą utrzymywać system od pierwszego dnia cyklu życia projektu. Czas oczekiwania na zestaw i czas mózgu może i zaskoczy, i nie ma wątpliwości, że (powinny?) Będą mieć standardy lub wymagania, które staną się zależne od projektu.

• Dokumentacja jest częścią projektu. Nigdy nie będziesz miał czasu na napisanie wszystkiego po zamknięciu projektu i przejściu systemu do konserwacji, więc upewnij się, że jest on uwzględniony jako wysiłek w harmonogramie na początku.

• Zaimplementuj planowane starzenie się w projekcie od pierwszego dnia i rozpocznij cykl odświeżania na sześć miesięcy przed dniem wyłączenia określonym w dokumentacji projektu.

Serwery mają określony okres użytkowania, jeśli nadają się do użytku w produkcji. Koniec tego okresu użytkowania jest zwykle definiowany jako ilekroć sprzedawca zaczyna naliczać więcej w ramach rocznej konserwacji, niż koszt odświeżenia zestawu, lub około trzech lat, zależnie od tego, który z tych okresów jest krótszy. Po tym czasie są one idealne dla środowisk programistycznych / testowych, ale nie należy na nich polegać, aby prowadzić działalność. Powrót do środowiska po 2 i pół roku daje mnóstwo czasu na przeskoczenie niezbędnych zasobów zarządzania i finansowania, aby zamówić nowy zestaw i przeprowadzić płynną migrację, zanim wyślesz stary zestaw do dużego dostawcy na niebie.

Rozwój:

• Upewnij się, że twoje systemy programistyczne i pomostowe przypominają produkcję. Maszyny wirtualne lub inne techniki wirtualizacji (strefy, LDOM, vservers) ułatwiają klonowanie produkcji w świecie rzeczywistym pod każdym względem, ale z zachowaniem wydajności.

Kopie zapasowe

• Dane, których nie tworzysz, to dane, których nie chcesz. To niezmienne prawo. Upewnij się, że twoja rzeczywistość pasuje do tego.

• Kopie zapasowe są trudniejsze niż się wydaje; niektóre pliki będą otwarte lub zablokowane, podczas gdy inne należy wyciszyć, aby mieć nadzieję na odzyskanie, i wszystkie te problemy należy rozwiązać. Niektóre pakiety kopii zapasowych mają agentów lub inne metody radzenia sobie z otwartymi / zablokowanymi plikami, inne nie. Zrzucanie baz danych na dysk i tworzenie kopii zapasowych liczy się jako jedna z form „wygaszania”, ale nie jest to jedyna metoda.

• Kopie zapasowe są bezwartościowe, chyba że zostaną przetestowane. Co kilka miesięcy wyciągaj losową taśmę z archiwów, upewnij się, że rzeczywiście zawiera dane, a dane są spójne.

I co najważniejsze...

Wybierz tryby niepowodzenia, bo inaczej Murphy ... a Murphy nie działa w twoim harmonogramie.

Projektuj pod kątem awarii, dokumentuj słabe punkty każdego systemu, co je uruchamia i jak je naprawić. To zrobi różnicę, gdy coś pójdzie nie tak.

Nie zakładaj, że to łatwe. Znam wielu programistów, którzy myślą, że tylko dlatego, że mogą skonfigurować IIS lub Apache na urządzeniu deweloperskim, aby mogli uruchomić farmę internetową. Zrozum, na czym polega praca, i dokonaj badań i planowania, nie myśl tylko, że praca sysadmin jest łatwą rzeczą, którą możesz zrobić w 10 minut, aby wdrożyć aplikację.

• Uświadom sobie, że na lepsze lub gorsze, wiele serwerów i / lub sprzętu sieciowego, które zwykle są bardzo podobne do dzieci z drugiej rodziny. To są ich dzieci. Opiekują się nimi, pomagają im, gdy są chorzy, i czujnie ich monitorują pod kątem problemów. Nie powinno tak być, ale po wielu latach często tak jest . Miej to na uwadze, gdy przekażesz im swoje obawy dotyczące nieprawidłowego działania sprzętu lub oczekiwania. A jeśli otrzymasz odpowiedź, której nie rozumiesz, spróbuj przefiltrować ją przez ten widok świata.
• Bądź na dobrych warunkach pracy. Brzmi serowo, ale na wagę złota. Pewnego dnia będziesz potrzebować specjalnej przysługi. I pewnego dnia ten sysadmin z przyjemnością zrobi wszystko, aby ułatwić ci życie, tylko tym razem.
• Ta relacja robocza przebiega w obie strony. Jeśli administrator jest bardzo zajęty i możesz ułatwić sobie życie, pisząc mały skrypt lub program, zrób to! Docenią to bardziej niż wiesz.
• Bądź bardzo jasny. „To do bani” nie jest tak jasne, jak „przerywane połączenie sieciowe jest trochę denerwujące, czy jest szansa, że ​​na to spojrzysz?”
• Jeśli uważasz, że Twoja aplikacja będzie skalować, poproś administratora przed zakładając, że będzie. Mogą „zobaczyć” coś, czego nie znasz, lub wiedzieć coś o limitach wydajności sprzętu, na którym zamierzasz zainstalować.
• Jeśli Twoja aplikacja wymaga dostrojenia, ale nie wydaje się, że to problem z kodem, zapytaj ładnie o wydajność serwerów. Sysadmini opiekują się swoimi maszynami z miłością i nie są zadowoleni, gdy są „chorzy” lub „źle zachowani”. Ładne zadawanie spowoduje obrócenie chorej maszyny (lub jej naprawę / wymianę).
• (jak wspomniano w innym miejscu) udokumentuj używane ustawienia i powód ich używania. Samo ustawienie „checkbox X” lub „uncomment pliku konfiguracyjnego linii Y” nie pomaga. Możesz ustawić opcję, która usuwa wszystkie dane przy następnym ponownym uruchomieniu komputera dla wszystkich, których znasz.
• Jeśli nie masz czasu, aby udokumentować ustawienie na papierze, spróbuj udokumentować je w systemie, jeśli to możliwe. W przypadku plików konfiguracyjnych powinna to być prawie standardowa praktyka - każda zmiana ustawienia powinna być oznaczona datą, z inicjałami, oczekiwanym efektem tego ustawienia i powodem, dla którego został zmieniony (patrz poprzedni punktor). Ten mały nawyk uratował mi boczek więcej niż raz podczas chrupania. „Dlaczego to zrobiliśmy?” „Ponieważ upoważniliśmy zasadę X, a ustawienie Y daje nam zachowanie, którego potrzebujemy dla zasady X”.
• Piwo. Lub Cola. A nawet woda. Napoje są zawsze mile widziane. Bycie sysadminem to spragniona praca.

Bezpieczeństwo to nie koniec. Chociaż zaatakowana aplikacja może sprawić, że programista wygląda na niekompetentny, jest to (przynajmniej) stracony weekend poświęcony weryfikacji, czyszczeniu i / lub przywracaniu z kopii zapasowych dla administratora systemu.

W tym przypadku nie traktuj kopii zapasowych jako kontroli wersji. Są przeznaczone do odzyskiwania po awarii i nie są tak naprawdę zaprojektowane do przywracania kodu, ponieważ zapomniałeś, co zmieniłeś.

I przestań ślepo obwiniać aktualizacje systemu Windows o uszkodzenie kodu. Nie obchodzi mnie, że to zadziałało, powiedz mi, dlaczego teraz nie działa - wtedy możemy zobaczyć, czyja to wina.

Jak debugować problemy z siecią i oglądać, jak program działa z narzędziami sysadmin. Jako programista, który rozpoczął administrację systemem, jestem zdumiony tym, jak bezradni wielu programistów staje się, gdy sieć „po prostu przestaje”.

• Wireshark , aby oglądać kod działający w czarnej skrzynce, pakiet po pakiecie
• Narzędzia do bezpośredniego łączenia się z usługami sieciowymi:
  • Telnet, netcat lub socat dla zwykłych połączeń przez TCP lub UDP
  • OpenSSL to samo z szyfrowaniem (wskazówka: spróbuj openssl s_client -connect target-host:portkiedyś), do ręcznego łączenia się z usługami sieciowymi
• dig (w pakiecie BIND 9) do debugowania rozpoznawania nazw
• Zdolność do określenia, która część stosu sieciowego uległa awarii na podstawie czasu i innych cech nieudanego połączenia
• Prawdopodobnie HTTPFox i / lub Firebug

Wiedzieć, jak rozwiązywać problemy.

Bardzo łatwo jest przekazać złotówkę (np. Twoja sieć ukrywa moją komunikację z bazą danych). Może to być wina sieci, ale powinieneś mieć dzienniki aplikacji z błędami, które przy użyciu Google lub SO mogą ujawnić problem w konfiguracji aplikacji.

Wszyscy lubią obwiniać sprzęt, system operacyjny lub sieć, więc jeśli wykonasz trochę więcej staranności, sprawisz, że sysadmin będzie szczęśliwą osobą. Ponieważ, jeśli nic innego, możesz być w stanie skierować je w określonym kierunku, co może być nie tak (w przeciwieństwie do powiedzenia „Twoja sieć jest do bani” lub coś równie pomocnego).

Dokumentuj wszystko, co możesz. Nie mogę powiedzieć, ile razy ostatni sysadmin pomyślał, że byłoby uroczo nie dokumentować czegoś dla „bezpieczeństwa pracy” lub ktoś po prostu chciał wejść i wyjść. Podobnie jak programista powinien zostawiać dobre komentarze, sysadmins powinien dokumentować. Schemat topologii też byłby miły.

Plan B.

Podczas projektowania i opracowywania rozwiązania zawsze należy mieć na uwadze plan odzyskiwania po awarii. Rozpoznaj pojedyncze punkty awarii, które mogą doprowadzić do awarii.

Dokumentacja: nie trzeba zwariować, ale jak działa aplikacja, schemat pokazujący dopasowanie bitów i sposoby testowania każdego komponentu, gdy wszystko pójdzie nie tak. Przykładowe dane i dane wyjściowe są ładne.

Wymagania: na jakich modułach polega? Wersje OS?

Monitorowanie: idealnie, aby deweloperzy obejmowali monitorowanie informacji i testów z aplikacją.

Mówiąc o opakowaniu, PAKOWANIE! Nie ma nic gorszego niż „wdrożenie”, co oznacza sprawdzenie nowej wersji pliku z VCS i skopiowanie go na kilka serwerów. Zbyt często programiści nie doceniają złożoności wdrażania oprogramowania: istnieją powody, dla których wersjonowane, pakowane oprogramowanie stanowi kręgosłup większości systemów operacyjnych.

Gdyby deweloper przyszedł do mnie z RPM, który został zainstalowany po raz pierwszy ze zwięzłą, kompleksową dokumentacją i niektórymi testami Nagios, byłby moim nowym najlepszym przyjacielem.

Dziwi mnie, że jak dotąd żadna z 17 odpowiedzi nie zawiera żadnych informacji na temat uruchamiania aplikacji po zalogowaniu się jako zwykły użytkownik.

Poza procesem instalacji aplikacja powinna działać poprawnie po zalogowaniu przy użyciu standardowego konta użytkownika.

Kopia zapasowa Kopia zapasowa Kopia zapasowa .... Przetestuj kopię zapasową ... Zawsze bądź gotowy do wycofania

Może to dotyczyć tylko początkujących programistów, ale z niektórymi programistami zajmuję się kilkoma rzeczami w każdym projekcie.

1. „Działa na moim komputerze” nigdy nie jest prawidłowym stwierdzeniem. Programista jest odpowiedzialny za stworzenie programu instalacyjnego do użytku na serwerze lub przynajmniej udokumentowanie każdego połączenia, dll i dodatku, które będą wymagane na serwerze.

2. (Słyszałem to wiele razy, więc proszę się nie śmiać) Uruchamiam exe na serwerze z mojego komputera i działa. Ale kiedy uruchomię go na serwerze (Citrix, Terminal Server itp.), To nie działa. Proszę zrozumieć pliki dll i ocx oraz wszystko inne, czego wymaga Twój program, a także miejsce i sposób ich rejestracji oraz sposób ich używania.

Mogą się wydawać proste, ale ciągle sobie z tym radzę.

Brian

• porozmawiaj z administratorem, zarówno formalnie, jak i nieformalnie, o tym, co robisz. Zazwyczaj będą zainteresowani i mogą wcześnie wyrazić możliwy wpływ na produkcję. Nie musisz się zgodzić, ale pomaga to zidentyfikować miejsca problemów.
• Nie, nie możesz mieć całego serwera dla siebie ... W razie potrzeby jest to decyzja polityczna, niezależnie od tego, jak technicznie to brzmi. Jeśli chcesz popracować nad polityką, śmiało.
• Sprzęt produkcyjny często wygląda inaczej niż serwer programistyczny, a nawet w gospodarstwach specyfikacje maszyn są różne.
• Dowiedz się, jak konfigurowana jest produkcja, ponieważ prawdopodobnie nie można jej replikować na pulpicie, ponieważ pozwala to uniknąć złych założeń.
• To, że możesz buforować rzeczy w pamięci, nie oznacza, że ​​powinieneś poczekać na wąskie gardło (w testach jednostkowych lub testach wydajności przedprodukcyjnej)
• jeśli umieszczasz dane w bazie danych, zastanów się, jak możesz podzielić dane na dane tylko do odczytu (które mogą być skalowane w poziomie) i dane do odczytu i zapisu (które zwykle są skalowane tylko w pionie).
• jeśli umieszczasz dane w bazie danych, to naprawdę musi to być RDBMS? istnieją inne systemy par klucz-wartość, które skalują się lepiej (netcache).
• nie sądzę, że AJAX jest rozwiązaniem całościowym, wygląda fajnie, ale ogranicza możliwości monitorowania i automatyzacji. Nie mówię, nie używaj go, pomyśl tylko dwa razy.

OK, to trochę rant, ale:

a) Podczas kodowania należy założyć, że podstawowa infrastruktura może zawieść i nie pochodzi z zawsze szczęśliwego lądu. Lub Google.

b) Prawdopodobnie nie mamy zasobów, aby zaimplementować coś takiego, jak infrastruktura, o której czytałeś, więc uspokój się, gdy wszystko się ułoży. Prawdopodobnie wiemy, co należy zrobić, ale z jakiegokolwiek powodu to się jeszcze nie wydarzyło. Jesteśmy twoimi partnerami!

c) Jak jhs powiedział powyżej, to naprawdę by pomogło, gdybyś miał przejściową znajomość narzędzi do rozwiązywania problemów z infrastrukturą, takich jak ping, traceroute (lub łączenie obu - mtr), wykopywania itp. Ogromne punkty bonusowe za nawet wiedzę o Wireshark.

d) Jeśli programujesz komputer, naprawdę powinieneś wiedzieć, w jaki sposób łączy się on z siecią, i podstawy, takie jak umiejętność analizowania danych wyjściowych ipconfig / all lub ifconfig. Powinieneś być w stanie uruchomić połączenie internetowe z minimalną pomocą.

W przeciwnym razie uważam, że Avery całkiem go przybiła. Deweloperzy, którzy robią trochę sysadminów, są na wagę złota! Ale równie dobrze sysadmini, którzy rozumieją, jak deweloperzy radzą sobie z różnymi rzeczami (w tym wersjonowaniem itp.), Są bardzo istotni w dzisiejszych czasach.

W tej chwili wydaje się, że jest w powietrzu, zauważyłem więcej dyskusji na temat relacji deweloperów / blogów na blogach - sprawdź

Prowadzenie Twittera Twitter

Partycje i działania wojenne

Najpierw przetestuj w operacjach

Że żadna grupa lub funkcja nie jest „lepsza” niż inna i że żadna z nich nie wymaga „większych mózgów” od siebie. Widziałem, jak obie strony robiły się prima-dona'ish w towarzystwie drugiej - wszyscy staracie się osiągnąć te same cele - skupić się na tych podobieństwach, a nie na tym, że używacie różnych narzędzi.

Architekt infrastruktury został programistą, ale może chcieć wycofać tę transakcję w przyszłości :)

1. Rozmawiajcie ze sobą wcześnie i często. Przejrzyj projekty z facetami, którzy będą zarządzać infrastrukturą, na której zostanie wdrożona Twoja aplikacja (jeśli wiesz, kto to będzie).
2. Zerowa utrata danych jest możliwa, ale odpowiedzialność ponoszą programiści i administratorzy. Znów rozmowa może tu pomóc.
3. Pracownicy infrastruktury powinni być zaangażowani w określanie wymagań niefunkcjonalnych.
4. Umów piwo (kiedy praca jest skończona) i pizzę (kiedy pracujemy). W jakiś sposób obecność tego rodzaju żywności wpływa na naszą zdolność do zmuszenia naszych ładnych małych 32 procesorów do robienia tego, co chcesz :)

Jako ktoś, kto był administratorem sys dla programistów i sam programista, podane tu porady nie są tylko złotem, ale powinny być częścią dokumentacji rekrutacyjnej dla nowych programistów dla firm na całym świecie.

Coś, czego „jeszcze nie widziałem”, to to, że programiści naprawdę powinni znać produkty, których będą używać do tworzenia programów, za które otrzymują wynagrodzenie. Czas, który musiałem wyjaśniać i konfigurować serwery Apache, instalacje Eclipse i Visual Studio oraz bazy danych na komputerach programistów, jest trochę niepokojący.