Jak udokumentować strategię aktualizacji oprogramowania komercyjnego?

Przez prawie dekadę nie aktualizowaliśmy naszego systemu RDBMS ani systemu operacyjnego serwera. Kolejny pakiet oprogramowania o znaczeniu krytycznym ma prawie dwie dekady i przez większość tego czasu nie był wspierany przez swojego dostawcę. Niektórzy z naszych kierowników uważają, że to dobra rzecz - zaoszczędziliśmy mnóstwo pieniędzy, nie kupując aktualizacji! Teraz krytyczne oprogramowanie wymaga aktualizacji, ale nowa wersja nie będzie obsługiwać dekad. Teraz garstka z nas traci włosy, próbując wymyślić, jak ulepszyć wszystko na raz przy minimalnym przestoju.

Starając się tego uniknąć w przyszłości, niektórzy z nas zastanawiają się nad stworzeniem dokumentu planu strategicznego IT (który będzie pasował do planu strategicznego organizacji, dopracowując elementy w większym dokumencie związanym z IT ... może to czyni IT doc taktycznymplan?) w nadziei, że uda nam się go przyjąć w ramach ogólnego planu strategicznego agencji. Zgłosiłem się na ochotnika, aby zebrać sekcję „Zarządzanie cyklem życia oprogramowania” (lub coś w tym rodzaju), aby rozwiązać wyżej wspomniany problem (z mosiężnymi haczykami prawdopodobnie w oddzielnym dokumencie od planu strategicznego). Prawie wszyscy dostawcy oprogramowania publikują cykle życia i plany wycofania swoich produktów i łatwo jest określić „optymalne” miejsce dla każdego oprogramowania, biorąc pod uwagę te informacje wraz z potrzebami naszej organizacji. Najtrudniejszą częścią (w każdym razie dla mnie) jest ułożenie planu dla każdego kawałka razem w coś bardziej spójnego.

Jak mogę udokumentować, że klienci A, B, C ... komputerów stacjonarnych są zależni od systemu operacyjnego OS X i RDBMS Y, które z kolei zależą od systemu operacyjnego serwera Z, a następnie oto, w jaki sposób utrzymujemy ich wszystkich w ich „słabych punktach”? Tam muszą być książki, ale całe moje googlowanie doprowadziło mnie do rzeczy o taktyce uaktualnienia jednego oprogramowania, a nie o strategii określania, kiedy zastosować te taktyki.

Wygląda na to, że próbujesz rozwiązać wiele problemów naraz (i nie wygląda to na dobry pomysł).

Z tego co czytam:

• nieaktualne systemy operacyjne i aplikacje
• brak długoterminowej strategii
• problemy z dokumentowaniem infrastruktury
• pilna potrzeba modernizacji krytycznego elementu infrastruktury

Aktualizacja „krytycznego oprogramowania”

Twoja infrastruktura jest nieaktualna z powodu czyjejś decyzji jest łatwa do zrozumienia. Prawdopodobnie w przeszłości wydawało się to dobrym pomysłem. Sprowadza się to do tego, co napisał Michael Hampton w komentarzach: W przypadku zarządzania mówisz o zaletach i wadach (ryzyko). Więc jeśli kierownictwo jest skłonne zaryzykować, to ok (cokolwiek o tym osobiście myślisz), a od tego czasu jest to ich odpowiedzialność. Ale ktoś z informatyków musi im powiedzieć, jakie jest ryzyko.

Pierwszą rzeczą, której bym szukał jest: czy menedżerowie wiedzieli o zagrożeniach związanych z przestarzałym oprogramowaniem? Powiedziano im?

Szczerze mówiąc, czuję, że prawdopodobnie nie znajdziesz w tym nic przydatnego, więc nie spędziłbym na tym zbyt wiele czasu. Jest to po prostu coś, co może ci pomóc w myśl „mówiliśmy ci przez ostatnie pięć lat”.

Chciałbym po prostu przeanalizować, co tak naprawdę oznacza wykonanie tej aktualizacji. Przygotuj prosty arkusz kalkulacyjny z ćwiczeniami i czasem ich trwania (jeśli nie wiesz, najlepiej zgadnij i wyraźnie podkreśl, że nie wiesz na pewno). Pamiętaj jednak, że to „zadanie aktualizacji” nie jest dobrze określone, nie można tego zrobić jako czas naprawy / cena naprawy.

Stworzenie takich list pomoże ci również zgłębić cały problem. Następnie należy utworzyć dziennik ryzyka i listę potrzebnych zasobów.

Na koniec powinieneś mieć listę działań, listę zagrożeń, listę materiałów / osób, których potrzebujesz. Jednym słowem, nie traktuj uaktualnienia jako codziennego problemu, zrób to jako PROJEKT. Umożliwi ci to przynajmniej kontrolę nad pilną potrzebą Twojej firmy.

Jeśli masz problemy z analizowaniem działań, które należy wykonać, możesz wypróbować mapę myśli (moim ulubionym oprogramowaniem jest xMind), a następnie przekonwertować ją na bardziej formalny dokument.

Pamiętaj, że jeśli masz kilka opcji aktualizacji, powinieneś dać swoim menedżerom spis możliwych rozwiązań (jeśli jest ich więcej), podsumowanych w kilku zdaniach, w tym koszt, wynik i ryzyko; najlepiej wspominając o opcji, którą polecasz i dlaczego. Ponieważ ostateczny wybór należy do nich - w końcu są menedżerami.

Może w tym konkretnym przypadku: Wspomnij, że aktualizacja może być w ogóle niemożliwa.

Brak długoterminowej strategii

Utworzenie planu strategicznego nie pomoże ci teraz. W ogóle ci to nie pomoże, jeśli jest to dokument tworzony w dziale IT. Plan strategiczny należy powiązać z potrzebami biznesowymi.

Przykładowa potrzeba biznesowa: za dwa lata będziemy otwierać nowe biura w Chinach i Australii.

Wyprowadzone zadania informatyczne: Przygotuj się na pozyskanie nowych pracowników w najgorszych sytuacjach, tworzenie infrastruktury w zagranicznych biurach, zapewnianie szkoleń dla nowych pracowników (być może przy użyciu ich języka ojczystego), zapewnianie bezpiecznej łączności z tych biur do centrali, ...

Jeśli wszystko pójdzie dobrze, możesz mieć strategię może ... za kilka miesięcy? A więc około pół roku, aż wszystko się uzgodni?

Utrzymanie i dokumentowanie infrastruktury

To jest dziedzictwo z przeszłości i teraz musisz coś zmienić. Priorytet. Zrób listę rzeczy, które chcesz / musisz zrobić teraz, aby zaktualizować większość rzeczy. Wybierz, na co możesz czekać, zrób przybliżoną mapę drogową. (Ta mapa drogowa powinna być częścią Twojej strategii IT, jeśli ją masz).

Jeśli aktualizujesz coś, co poszło dobrze, traktuj to jako codzienną pracę. Jeśli masz do czynienia z czymś, co może pójść źle (jest „duże” pod względem spędzonego czasu, przydzielonych ludzi itp.), Traktuj to jako projekt.

Istnieją narzędzia, które mogą pomóc w dokumentacji i zależnościach serwisowych - CMDB (na przykład iTop). Ale uruchomienie go może zająć trochę czasu i nadal potrzebujesz narzędzia do dokumentacji. Najlepszym pomysłem jest skonfigurowanie wiki dla dokumentacji, w której każdy może odtąd dokumentować / robić notatki. Możesz założyć wiki w pół godziny, więc jest to bardzo skuteczny sposób na rozpoczęcie pracy.

Uwaga osobista: Aktualizacja starego systemu operacyjnego byłaby ogromną PITA, nie wspominając o (prawdopodobnie złej / brakującej) dokumentacji. Czy nie jest łatwiej instalować serwery od nowa, migrować aplikacje i dokumentować wszystko od samego początku?