Prawa Murphy'ego znane sią chyba każdemu, także osobom nietechnicznym, od dobrych dwóch dekad. W tym krótkim wpisie przytoczę kilka "praw", które zazwyczaj traktowane z przymrużeniem oka, są podstawą rzemiosła profesjonalisty, a szczególnie administratora lub wdrożeniowca.

Stosując metodykę DevOps, a nawet ograniczając się tylko do samego continuous delivery lub continuous deployment, istotnym czynnikiem jest zapewnienie jakości. Przeprowadzając wszelakie operacje w środowiskach produkcyjnych istnieją dwie naczelne zasady: możliwie najkrótszy downtime (lub zero downtime) oraz niedopuszczanie do wprowadzania wadliwych wersji.

Mówiąc ogólnie - naczelną zasadą jest nie szkodzić użytkownikowi eksploatowanego systemu. A jak powszechnie wiadomo człowiek jest z zasady istotą omylną, najsłabszym ogniwem każdego łańcucha, dlatego do zapewnienia jakości każdemu profesjonaliście potrzebne są odpowiednie procedury postępowania.

Ciekawą pomocą w ich opracowywaniu, prawdopodobnie stosowaną powszechnie nieświadomie, są moim zdaniem Prawa Murphy'ego. Każdy odpowiedzialny profesjonalista powinien być w jakiejś części sceptykiem i pesymistą, choć niekoniecznie musi to okazywać ;)

Jeżeli coś może się nie udać, to się nie uda.
Jeśli coś może pójść źle, to pójdzie.

Powinny być podstawowymi zasadami każdego inżyniera operującego w środowiskach produkcyjnych. Błąd operatora jest jedną z najczęstszych przyczyn awarii. Przykłady można mnożyć - od przypadkowych usunięć danych, długich dysfunkcji usług sieciowych (co jest krytyczne w modelu SaaS), aż po spektakularne wycieki danych (spowodowane np. pozostawieniem "otwartego na świat" narzędzia). Nie, chmury nie rozwiązują "magicznie" takich problemów ;)

Opracowując procedury postępowania, czy to tworząc playbooki Ansible lub innego narzędzia orkiestracji, czy też wykonując operacje typowo manualne, powinno się mieć na uwadze że każdy krok może się nie powieść. Powinno się też przewidzieć w jakim stanie będzie system i jaki będzie sposób przywrócenia do stanu pierwotnego.

Jeśli wiesz, że coś może pójść źle i podejmiesz stosowne środki zapobiegawcze, to źle pójdzie coś innego

Zawsze trzeba mieć plan "B". Nawet zwykły backup. Często robiąc wdrożenia mocno modyfikujące dane, skracam RPO do absolutnego minimum tworząc kopie danych tuż po przejściu w tryb przerwy technicznej (aby wyeliminować napływ nowych danych). Czasem robię hotcopy zakładając, że częściowe odzyskanie danych będzie możliwe i nie będzie wiązać się z nadpisaniem nowszych informacji. Ostatecznie zawsze pod ręką powinien być backup całej maszyny lub okresowe dumpy danych.

Moje plany "B" zazwyczaj są wielowarstwowe, przez co na wiele niespodziewanych przypadków jestem odporny z zachowaniem RPO (Recovery Point Objective) oraz RTO (Recovery Time Objective) wynikającego z przyjętej polityki bezpieczeństwa.

Powinieneś być przerażony, gdy dziecko jest zbyt ciche.

Ta "prawda życiowa" ma swoją analogię w świecie IT. System wykazujący zbyt niskie obciążenie w stosunku do typowego dla danego dnia i pory dnia, powinien być poddany natychmiastowej inspekcji. Oznacza to, że konieczne są narzędzia monitorujące pracę systemu, ale nie tylko on-line ale również gromadzące dane historyczne. Nie ma lepszego sposobu jak ogląd krytycznych parametrów systemu w formie wykresów.

Tu warto zauważyć, że skuteczny monitoring wymaga personelu, który w niego patrzy i reaguje na jego zgłoszenia. Bez tego każdy system monitorowania jest niestety niemym głosem tonącego.

Nigdy nie mów „ups”, gdy pacjent jest przytomny

Profesjonalista nigdy nie poddaje się, gdy obsługuje awarię. Nie można wycofać się nawet wtedy, gdy za awarię w 100% odpowiedzialny jest ktoś inny. W opanowaniu sytuacji pomogą ci procedury i twoje plany "B".

Z tego wynika jeszcze coś, co nie jest oczywiste. Musi istnieć dokumentacja techniczna systemu, z której pomocą inżynier będzie mógł podejmować odpowiednie działania. Alternatywą jest posiadanie pełnej wiedzy o funkcjonowaniu całego systemu i sposobie jego obsługi, ale to podejście ma istotne wady, gdyż...

Wiedza i doświadczenie przychodzą z wiekiem. Najczęściej jest to wieko od trumny.

... każdy jest śmiertelny. Jeśli z nim zniknie wiedza, to biznes będzie miał niemały kłopot. Tworzenie dokumentacji technicznych oraz instrukcji obsługi systemu/podsystemów jest częścią pracy profesjonalisty. Zawsze trzeba na to mieć czas.

Ten, który się waha, ma prawdopodobnie rację

Trzeba być wyczulonym na takie sygnały. Wynikają one zazwyczaj z umiejętności przewidywania oraz z doświadczenia. Znowu zabezpieczeniem są procedury, plany "B".

Zawodowcy są przewidywalni – strzeż się amatorów

To się samo komentuje.