프로덕션 모드에서 실행되는 내부 서버를 고려하면 정기적인 업데이트를 배포할 때 사용자에게 미치는 영향을 가능한 한 낮게 유지하고 싶습니다(사용자 컴퓨터가 아닌 서버 자체에 .. 그러나 이는 꽤 비슷한 문제가 됩니다).
내 질문에 대한 분명한 대답은 "사용자가 집에 있는 밤에"입니다. 그러나 "밤"은 긴 시간이다. 업데이트 문제를 조기에 파악하고 롤백할 준비를 하려면 저녁 일찍 시작해야 합니까? 아니면 아침 일찍 시작하여 첫 번째 사용자를 "실험용 실험 장치"로 활용하여 문제를 더 빨리 유발하는 것이 더 낫습니까? 아니면 업데이트를 감독하는 사람의 집중력이 상당히 낮은 한밤중에 늦게 작업하는 일부 사용자의 열린 파일 핸들이 없는 것이 보장되는 경우는 없습니까?
해당 주제에 관한 연구 논문이 있나요?
답변1
과거에 시스템의 동시 사용량을 살펴보고 하루 중 사용량이 가장 낮은 시간을 파악해 보는 것은 어떨까요? 그런 다음 사용률이 낮은 기간 중간에 변경 사항을 적용하십시오.
변경에 소요되는 시간을 계산할 때 구현 전/후 테스트와 프로덕션 검증 테스트가 포함됩니다. 또한 테스트가 실패할 경우 변경 사항을 롤백하는 데 걸리는 시간도 알아보세요.
IMHO '첫 사용자'는 실험용 돼지가 되어서는 안 됩니다. 기본적으로 실제 사용자에게 프로덕션 검증을 통해 변경 사항을 테스트하게 하는 것은 좋은 일이 아닙니다. 이는 최종 사용자의 신뢰를 파괴하고 예상치 못한 결과로 인해 생산이 엉망이 될 수 있습니다. 즉, 변경 사항을 롤백해야 할 뿐만 아니라 변경으로 인해 발생한 '손상'도 롤백해야 함을 의미합니다.
연구 논문은 모르지만 ITIL과 같은 ITSM(IT 서비스 관리 프레임워크)을 살펴보면 소프트웨어 릴리스 관리에 대한 많은 표준과 모범 사례를 찾을 수 있습니다. 모든 시스템이 다르기 때문에 채택하는 관행의 정도와 형식이 다릅니다. ITSM 표준은 대규모 시스템을 염두에 두고 있습니다.
답변2
이는 전적으로 사업의 성격에 달려 있습니다. 일부 사무실은 주 5일 9~5일 근무합니다. 다른 사업체는 1년 365일 24시간 운영됩니다. 직원 및 자원 가용성과 같은 다른 요소도 중요한 역할을 합니다. 가능한 모든 일정이나 상황을 포괄적으로 다룰 수 있는 연구 논문은 없습니다.
궁극적으로 회사나 부서의 경영진은 IT 경영진과 협력하여 무엇이 최선인지 결정해야 합니다.
성공의 열쇠는 다운타임이 시작될 예정인 시기, 예상 지속 시간, 사용자에게 필요한 준비 사항, 성공 또는 실패의 결과로 기대할 수 있는 사항을 사용자와 소통하는 것입니다. 그것의 가장 큰 부분은 당신이 설정한 기대치를 충족시키는 것입니다.
결국 돌에는 아무것도 새겨지지 않습니다. 프로세스가 작동하지 않으면 조정하십시오. 귀하의 유연성과 적응력은 높이 평가될 것입니다.
가능하면 테스트 장비에 대한 유지 관리 및 업데이트 절차를 미리 수행함으로써 생산 시스템에 구현해야 할 시점에 더 잘 대비할 수 있습니다.
답변3
나는 ISP에서 일하고 있으며 내 경험상 강력한 시스템 관리자라고 생각하는 대부분의 사람들은 휴일 주말의 금요일 저녁을 선택하여 주요 네트워크 점검을 수행합니다. 그러면 테스트할 수 있는 추가 24시간이 주어지고 필요한 경우 변경 사항을 롤백할 수 있습니다. 그러나 이는 전적으로 사용자의 성격과 습관에 따라 달라집니다.
답변4
제 경우에는 조금 늦게 일하는 사용자라도 모든 사용자에게 영향을 미치지 않도록 오전 4시에 업데이트를 설치합니다.
문제가 발생하면 경고하는 좋은 모니터링 시스템이 있다면 아침 일찍, 심지어 출근하기 전에 문제를 해결할 수 있어야 합니다.