po trochę dłuższej niż przewidziana przerwie, część druga tego arta.

Kontrola wersji

Jeżeli coś jest tekstem i będziesz to zmieniać – trzymaj to w Gicie. Czy to configi, czy własne skrypty, trzymanie tego w repo ma same zalety. Oszczędzasz czas gdy usuniesz coś w skrypcie przez przypadek, albo gdy 2 tygodnie po zmianach w skrypcie okazało się że jednak nie działa poprawnie i trzeba cofnąć się do poprzedniej wersji.

Tak samo z configami, toole takie jak etckeeper (jest w Debian squeeze, w lenny troche przestarzała wersja)  automatyzują commitowanie zmian (conocne + przy upgrade pakietu), chociaż warto zrobić commit “ręcznie” z odpowiednim komentarzem, zwłaszcza gdy nie jesteśmy sami. Łatwo można się cofnąć po popsuciu, mamy dokłądny obraz jak konfiguracja zmieniała się z czasem, łącznie ze zmianami w /etc podczas aktualizacji paczek. Można też robić backup konfiguracji przez git push do zdalnego repo, lub kopię na innej maszynie przez git clone.

Automatyzacja

Jeżeli coś robisz raz na miesiąc lub częściej i jest to czynność typu “odpal to to i to tu”, oskrypć to:

  • Oszczędność czasu
  • Nigdy nie zapomnisz, od tego jest cron ;]
  • Mniejsze znudzenie – zamiast powtarzać te same shellowe litanie co dzień/tydzień/miesiąc masz więcej czasu na fixowanie bugów/optymalizację/research

Rzeczy typu zautomatyzowany deploy (zamiast “scp here, restart there”) czy własne repo z paczkami nie dość że oszczędzają tonę czasu to jeszcze usprawniają debugging. Ustawienie repo paczek czy zrobienie “one-click deploy” może zająć dzień lub tydzień, ale dzięki temu deploy bugfixa na maszyny potrwa chwilę, bez niepotrzebnego zajmowania czasu, co pozwala na bardziej “inkrementacyjne” update. “Deploy trwa długo i jest pracochłonny” nie jest już wymówką do odwlekania małych bugfixów do większego release (czy to aplikacji czy Twoich “narzędzi admina”), oraz mniejszy update = mniej nowych bugów ujawni się na raz. Odpada też problem “tego samego” skryptu na 5 maszynach w 4 różnych wersjach

I to prowadzi do następnego punktu:

Testy!

Wszelakiego rodzaju. Od testów w skryptach (czy cel do którego kopiujemy istnieje, czy komenda zwraca error code itd.) poprzez testy backupu (fajnie że jakieś pliki odtwarzają się z restore ale ile Ci zajmie przywrócenie z nich infrastruktury ? I czy aby na pewno backupujesz wszystko co potrzeba ?) aż do testów usług (fajnie że site zwraca HTTP 200 OK, ale pusty index.html nie wygląda zbyt podobnie do site’a który tu był poprzedniego dnia).

Rzeczy z czasem się psują, czy to z powodu niedopatrzenia/nieuwagi (backupy się robią ale stare się nie usuwają i oops! dysk pełen),  niewiedzy (nowy admin nie wiedział o czymś co stary admin ustawił bo nie zajrzał do wiki, albo nie było udokumentowane), czy zwykłej awarii.

Nawet prosty test, jak chociażby sprawdzenie czy katalog sshfs naprawdę się zamontował przed zrobieniem backupu, czy poproszenie programistów o napisanie /check.php sprawdzającego czy wszystko co potrzebuje aplikacja jest ok potrafi oszczędzić sporo czasu/nerwów/kasy ;]

Murphy is your friend

(szczególnie gdy masz serwery w ovh.net)

Niektóre rzeczy są bardzo mało prawdopodobne. Nie znaczy to że Tobie się nie zdarzą (np. to że pakiety z maszyny A dochodzą do maszyny B nie znaczy że odwrotne też jest prawdą ;]).  Tcpdump/wireshark (<3)  i debug mode pomaga, a support techniczny odpowiada po tym jak problem przestał się pojawiać mailem: “Dziwne, u mnie działa”. Jeżeli wyczerpałeś wszystkie standardowe metody naprawiania problemu, grzeb dalej, w najgorszym wypadku stracisz parę godzin, w najlepszym naprawisz problem.

I tyle, część kolejna jak mi się uzbiera :).

Related Posts: