상용 소프트웨어 업그레이드 전략을 문서화하는 방법은 무엇입니까?

거의 10 년 동안 RDBMS 또는 서버 OS를 업그레이드하지 않았습니다. 또 다른 미션 크리티컬 소프트웨어 패키지는 거의 20 년이 지났으며 그 기간 동안 공급 업체가 지원하지 않았습니다. 우리 경영진 중 일부는 이것이 좋은 것이라고 생각하는 것 같습니다. 업그레이드를 구입하지 않으면 많은 돈이 절약되었습니다! 이제 중요한 소프트웨어는 업그레이드가 필요하지만 새 버전은 10 년 전부터 지원되지 않습니다. 이제 우리 중 소수는 다운 타임을 최소화하면서 모든 것을 한 번에 업그레이드하는 방법을 알아 내려고 노력하고 있습니다.

미래에 이것을 피하기 위해, 우리 중 일부는 IT 전략 계획 문서 (조직의 전략 계획에 맞고 IT와 관련된 더 큰 문서의 항목을 살려내는 것)를 만드는 것을 고려하고 있습니다. IT 문서를 전술로 만듭니다계획?)을 선택하여 기관의 전체 전략 계획의 일부로 채택 할 수 있기를 바랍니다. 저는 위에서 언급 한 문제를 해결하기 위해 "Software Lifecycle Management"(또는 이와 유사한 것) 섹션을 구성하려고 노력했습니다 (전략 계획과는 별도의 문서에 놋쇠가 붙어 있음). 거의 모든 소프트웨어 공급 업체가 제품의 수명주기 및 폐기 계획을 게시하고 있으며 조직의 요구와 함께 해당 정보를 고려하여 각 소프트웨어의 "스위트 스폿"을 쉽게 결정할 수 있습니다. 까다로운 부분은 (어쨌든 나를 위해) 각 조각에 대한 계획을 더 응집력있는 것으로 만드는 것입니다.

데스크탑 클라이언트 A, B, C ...가 데스크탑 OS X 및 RDBMS Y에 종속되고 서버 OS Z에 따라 달라진다는 것을 어떻게 문서화 할 수 있습니까? 그런 다음 모든 클라이언트를 "스위트 스폿"에 유지하는 방법은 무엇입니까? 책이 반드시 있어야하지만, 모든 인터넷 검색을 통해 해당 전략을 구현할시기를 결정하기위한 전략이 아니라 단일 소프트웨어를 업그레이드하는 전술에 대해서만 설명하게되었습니다.

한 번에 많은 문제를 해결하려는 것처럼 보입니다 (그리고 좋은 생각처럼 보이지는 않습니다).

내가 읽은 것에서 :

• 오래된 OS 및 응용 프로그램
• 장기 전략 없음
• 인프라 문서화 문제
• 중요한 인프라를 업그레이드해야하는 긴급

"중요한 소프트웨어"업그레이드

누군가의 결정으로 인해 인프라가 오래되었다는 것은 이해하기 쉽습니다. 과거에는 언젠가 좋은 생각처럼 보였습니다. 이것은 Michael Hampton이 다음과 같이 논평 한 내용으로 요약됩니다. 경영진에게는 찬반 양론 (위험)에 대해 이야기하고 있습니다. 따라서 경영진이 기꺼이 위험을 감수하려고한다면 괜찮습니다 (개인적으로 생각하는 것에 상관없이). 그러나 IT 담당자는 위험이 무엇인지 알려 주어야합니다.

가장 먼저 찾아야 할 것은 : 관리자가 오래된 소프트웨어의 위험에 대해 알고 있었습니까? 그들이 말했습니까?

솔직히, 나는 당신이 아마 그것에 대해 유용한 것을 찾지 못할 것이라고 생각합니다. 그래서 나는 그것에 너무 많은 시간을 소비하지 않을 것입니다. "우리는 지난 5 년 동안 당신에게 말하고있었습니다"라는 문구를 따라 당신을 도울 수있는 것입니다.

업그레이드를 수행하는 것이 실제로 무엇을 의미하는지 분석하기 만하면됩니다. 활동과 소요 시간이 포함 된 간단한 스프레드 시트를 준비하십시오 (모르는 경우 확실하지 않은 것으로 추측하고 명시 적으로 강조하십시오). 그러나이 "업그레이드 작업"이 제대로 지정되어 있지 않다는 것을 기억하십시오. 수정 시간 / 수정 가격으로 수행하는 것은 불가능합니다.

이러한 목록을 작성하면 전체 문제를 자세히 파악할 수 있습니다. 다음은 위험 로그와 필요한 리소스 목록을 만드는 것입니다.

마지막에는 활동 목록, 위험 목록, 필요한 자료 / 사람 목록이 있어야합니다. 한마디로, 일상적인 문제로 업그레이드를 처리하지 말고 프로젝트로 수행하십시오. 이를 통해 회사의 긴급한 요구를 최소한 어느 정도 통제 할 수 있습니다.

어떤 활동을 수행해야하는지 분석하는 데 문제가있는 경우 마인드 맵 (내가 가장 좋아하는 sw는 xMind 임)을 사용해보다 공식적인 문서로 변환 할 수 있습니다.

업그레이드를 수행하는 방법에 대한 몇 가지 옵션이있는 경우 관리자에게 비용, 결과 및 위험을 포함하여 몇 가지 문장으로 요약하여 가능한 솔루션 (있는 경우)을 작성해야합니다. 권장하는 옵션과 이유를 이상적으로 언급하십시오. 최종 선택은 자신의 선택이기 때문에-결국 관리자입니다.

이 특별한 경우에는 업그레이드가 불가능할 수도 있습니다.

장기 전략 없음

전략 계획을 세우면 지금 도움이되지 않습니다. IT 부서에서 만든 문서 인 경우 전혀 도움이되지 않습니다. 전략 계획은 비즈니스 요구와 관련이 있어야합니다.

비즈니스 요구의 예 : 우리는 2 년 안에 중국과 호주에 새로운 지사를 열 것입니다.

IT 과제 도출 : 신입 사원에게 최악의 상황을 알리고, 외국 사무소에서 인프라를 구축하고, 신입 사원을위한 교육을 제공하고 (모국어 사용 가능) 해당 사무소에서 중앙으로 안전하게 연결합니다.

상황이 좋으면 몇 개월 안에 전략을 세워도 되겠습니까? 모든 것이 합의 될 때까지 약 반년?

인프라 유지 관리 및 문서화

이것은 과거의 유산이며 지금은 사물을 바꿔야합니다. 우선 순위를 정하십시오. 대부분의 일을 최신 상태로 유지하기 위해 지금하고 싶은 일 /해야 할 일의 목록을 만드십시오. 기다릴 수있는 항목을 선택하고 조잡한 로드맵을 만듭니다. (이 로드맵은 IT 전략이있을 때 IT 전략의 일부 여야합니다.)

잘 된 것을 업데이트하는 경우 일상 업무로 처리하십시오. 나빠질 수있는 것을 처리하고 있다면 (소요 된 시간, 할당 된 사람 등의 관점에서 "큰") 프로젝트로 처리하십시오.

설명서 및 서비스 종속성 (CMDB) (예 : iTop)에 도움이되는 도구가 있습니다. 그러나 제대로 작동하려면 약간의 시간이 걸릴 수 있으며 여전히 일부 문서 도구가 필요합니다. 가장 좋은 아이디어는 모든 사람이 지금부터 문서화 / 메모 작성을 시작할 수있는 문서 용 위키를 설정하는 것입니다. 30 분 안에 위키를 설정할 수 있으므로 작업을 시작하는 데 매우 효과적인 방법입니다.

개인 참고 사항 : 오래된 OS를 업그레이드하는 것은 거대한 PITA가 될 것입니다 (아마도 나쁜 / 누락 된) 문서는 언급하지 않았습니다. 서버를 새로 설치하고, 앱을 마이그레이션하고, 처음부터 모든 것을 문서화하는 것이 쉽지 않습니까?