Redundancja to nadmiarowość, czyli więcej niż niezbędne minimum, aby coś działało. Na pierwszy rzut oka taka nadamiarość kojarzy się z wydaniem za dużej ilości pieniędzy. Bo jeśli jest czegoś więcej niż potrzeba to przepłaciliśmy. Wielu finansistów się tutaj zgodzi.
Wydatki to zaledwie jedna strona medalu, bo dużo bardziej liczą się zyski. I tutaj już spojrzenie na redundancje będzie zupełnie inne – redundancja daje dostępność, czyli krewną niezawodności. Możliwość działania głównych funkcji wybranego systemu, w przypadku awarii jego pojedynczych komponentów.
Najprostszy przykład ze świata IT to dyski twarde połączone w macierze dyskowe, zwane RAID’ami (Redundant Array of Independend Disks – nadmiarowa macierz niezależnych dysków). Dyski psują się raczej rzadko, więc możliwe jest postawienie dobrze działającego systemu firmowego na serwerze posiadającym dwa niezależne dyski. Może to działać kilka lat. Gdyby się jednak tak zdarzyło, że dysk ulegnie uszkodzeniu, a klienci nie mogą kupować naszych usług czy prouktów, to czas postawienia nowego serwera może kosztować dużo więcej niż redundantny dysk. RAID 1, tworzy lustrzaną kopię danych i wtedy dysk twardy przestaje być najsłabszym ogniwem.
Eliminacja jednego najsłabszego ogniwa powoduje, że w nowym miejscu powstaje inne najsłabsze ogniwo. Skoro dysk nie jest problemem to teraz może jest nim serwer, albo przełącznik sieciowy, może firewall i tak dalej.
Technologia to nie wszystko
O tych technicznych rzeczach najłatwiej pamiętać nam pracującym w IT. Popularny termin Single Point of Failure (SPOF), odnosi się zazwyczaj do sytuacji, gdy przerwa w działaniu jednego komponentu powoduje przerwę całego systemu.
Rzadziej jednak pamiętamy, że SPOF odnosi się też do ludzi. Do osób, których nie da się aktualnie zastąpić, ze względu na to jakie posiadają umiejętności czy wiedzę. Ich tygodniowy urlop da się jeszcze zorganizować, ale gdyby postanowili odejść to byłoby to już problematyczne.
Dlatego tak ważne jest zarządzanie nie tylko systemami informatycznymi, ale też wiedzą, którą posiadają ludzie. Jeżeli programista-twórca aplikacji odejdzie to czy będzie ktoś kto jest wstanie w pełni przejąć pisanie poprawek, zmian i ulepszeń? Czy odejście sieciowca nie spowoduje problemów z VPN’ami, firewallami? Odejście administratora nie spowoduje, że nie będzie komu odnowić wygasających certyfikatów SSL do strony-wizytówki firmy?
Repozytorium nie tylko kodu, ale i wiedzy, procesów, dokumentacji, najlepszych praktyk, konfiguracji, instrukcji postępowania, wprowadzonych zmian jest sygnałem, że mamy do czynienia z dojrzalszym działem IT. Z minimalizacją ryzyk przeprowadzoną przez zarządzających tym działem.
I o ile nie ma jednego najlepszego sposobu na tworzenie i prowadzenie takiego repozytorium, to istnieją dobre sposoby żeby zacząć. Bardzo polecam np. Macierz kompetencji zespołu. Tylko to nie ma być jednorazowe wydarzenie, a część codziennej pracy, kultury zespołu. Wszelkie podejścia typu Configuration management database (CMDB, Baza danych zarządzania konfiguracją) często upadają, bo po zrobieniu pierwszego „zrzutu danych”. Tak się dzieje gdy nikt nie dba o aktualizowanie tego co zostało stworzone. To z kolei powoduje, że dane zawarte w takim repozytorium stają się przestarzałe, co dalej wpływa na to, że ludzie przestają tam zaglądać. I spirala się szybko nakręca, lecąc w dół.
Co zrobić żeby się udało?
Nie zmuszać do zmiany i pokazywać korzyści.
Wytłumaczyć co dobrego z tego wynika (np. przejrzystość, dostępność, szybkość dostępu do informacji, a więc skrócony czas trwania awarii, zmniejszone ryzyka, powtarzalne i prostsze szkolenia dla nowych osób itp.). Zachęcić do uczestnictwa w przedsięwzięciu, a może nawet wyznaczyć 'kamienie milowe’ i zespołowe nagrody za ich osiągnięcie? Poprawić procesy, by teraz odwoływały się do repozytorium wiedzy. By naturalne stało się zaglądanie tam i aktualizowanie bazy.
I pilnować przede wszystkim siebie, żeby nie wyłamywać się z uzgodnionych ustaleń. Bo zmiana zawsze musi zajść też w nas samych.
