Problem z ciągle odkładanymi aktualizacjami serwerów

Zestawienie obejmuje serwery, maszyny wirtualne, urządzenia sieciowe, zapory, punkty dostępowe, stacje robocze i aplikacje biznesowe razem z wersją i datą ostatniej aktualizacji. Część tych danych wyciągniesz z narzędzi, które już masz w środowisku, resztę trzeba spisać ręcznie. Przy pierwszym podejściu lista zawsze jest niepełna i tak to wygląda wszędzie, bo uzupełnia się ją przy kolejnych przeglądach. Krok jest zamknięty, gdy dla każdej pozycji z listy znasz wersję i wiesz, kto w firmie za nią odpowiada.

Okno ma mieć datę powtarzalną w miesiącu, godziny i zakres systemów, których dotyczy. Uzgadniasz je z osobami odpowiadającymi za pracę tych systemów, czyli z produkcją, logistyką, sprzedażą albo księgowością, i zapisujesz w kalendarzu widocznym dla całej firmy. Dla środowisk pracujących w ruchu ciągłym okno bywa nocne albo weekendowe i wtedy trzeba od razu ustalić, kto dyżuruje. Krok jest zamknięty, gdy terminy stoją w kalendarzu na kolejne pół roku i mają imiennie wskazaną osobę akceptującą.

Planowe czekają na najbliższe okno. Pilne idą poza kolejnością i dotyczą zwykle systemów wystawionych do internetu oraz podatności, dla których producent albo CERT podaje informację o aktywnym wykorzystaniu. Zapisz, co uruchamia tryb pilny, kto podejmuje decyzję i w jakim czasie od ogłoszenia ma nastąpić instalacja. Bez tego każda taka sytuacja zaczyna się od szukania osoby, która weźmie zgodę na siebie. Krok jest zamknięty, gdy reguła mieści się na jednej stronie i zna ją zarówno IT, jak i osoba decyzyjna po stronie biznesu.

Pełne środowisko testowe jest kosztowne i nie każda firma je utrzyma. Zastępuje je grupa pilotażowa, czyli kilka stacji roboczych i jeden serwer o mniejszym znaczeniu, które dostają poprawki wcześniej od reszty środowiska. Odstęp kilku dni wystarcza, żeby wyszły błędy widoczne dopiero w codziennej pracy. Przy systemach o największym znaczeniu dochodzi do tego kopia maszyny wirtualnej uruchamiana na czas sprawdzenia. Krok jest zamknięty, gdy wiesz, które urządzenia należą do grupy pilotażowej i jaki odstęp dzieli je od reszty.

Przy odrabianiu zaległości kolejność ustawia się od systemów, których zatrzymanie nikogo nie zablokuje, w stronę tych, na których stoi produkcja albo sprzedaż. Pierwsze niespodzianki wychodzą wtedy tam, gdzie można je spokojnie rozwiązać, a zespół zbiera wiedzę o tym, jak środowisko zachowuje się po zmianie. Urządzenia brzegowe i zapory są wyjątkiem i idą wcześniej, bo ryzyko z ich strony jest innego rodzaju. Krok jest zamknięty, gdy kolejność jest zapisana i uzgodniona z właścicielami systemów.

Dla każdej aktualizacji systemu produkcyjnego musi być znana droga powrotu, czyli migawka maszyny wirtualnej, kopia konfiguracji urządzenia albo sprawdzona kopia zapasowa sprzed zmiany. Do tego potrzebny jest moment graniczny, po którym rezygnujesz z dalszych prób naprawy i wracasz do stanu poprzedniego, żeby zdążyć przed początkiem zmiany roboczej. Bez takiego momentu prace potrafią się przeciągnąć do rana. Krok jest zamknięty, gdy dla każdego systemu w oknie masz zapisany sposób powrotu i godzinę decyzji.

Raport pokazuje liczbę systemów zgodnych z przyjętym poziomem, listę odstępstw z powodem oraz najstarszą zaległą poprawkę razem z datą jej publikacji. Jedna strona wystarczy. Ten dokument pracuje w dwie strony, bo daje zarządowi obraz stanu bez wchodzenia w technikalia, a przy audycie albo ankiecie kontrahenta jest gotowym dowodem, że proces istnieje. Krok jest zamknięty, gdy raport trafia do zarządu w stałym terminie i ktoś go czyta.