왜 웹 사이트 (이것조차도)가 때때로 "유지 보수를 위해 다운"됩니까?

나는 개인적으로 이것을 한 적이 없다. 개발 서버에서 개발하는 경우 왜 그렇게 많은 사이트가 필요한지 이해가되지 않습니다. 왜 프로덕션 사이트를 종료해야합니까?

나는 항상 이것에 대해 궁금했다.

이 기간 동안 그들은 무엇을하고 있습니까?

규모가 큰 것은 무엇이든 큰 문제는 데이터베이스 스키마를 어떤 식 으로든 변경하는 경우 일반적으로 큰 불쾌한 유지 관리 스크립트를 실행해야한다는 것입니다.

이제 개발 데이터 세트로 실행하는 데 1 초 정도 걸릴 수 있습니다. 그러나 테라 바이트와 페타 바이트 단위로 데이터 측정을 시작하면 단일 열을 테이블에 추가하는 데 몇 시간이 걸릴 수 있습니다.

따라서 배포가 얼마나 빠르고 자동화 되더라도 여전히 데이터 유지 관리 문제가 발생합니다. 실제로 계획을 잘 세우면 프로세스를 진행하는 동안 사이트의 읽기 전용 미러를 설정할 수 있지만 많은 사이트의 경우 읽기 전용이 의미가 없으므로 노력할 가치가 없습니다.

유지 보수를 위해 사이트를 중단하려는 이유는 여러 가지가 있습니다. 몇 가지 예를 들면 다음과 같습니다.

• 데이터베이스 변경
• DAL 변경
• 서비스 업데이트

기본적으로 사이트가 정적 인 것이 아니라면 논리 업데이트를 수행 할 때 사이트를 삭제하려고합니다. 그렇지 않으면 사이트를 방문하는 사람들이 오류나 예기치 않은 동작을받을 수 있습니다.

또한 사이트의 web.config (ASP.NET에서)를 만질 경우 사용자 세션이 종료되므로 유지 관리를 위해 먼저 중단해야합니다. 따라서 그들이 무언가의 한가운데에 있다면, 그것은 잃어 버릴 것입니다.

글쎄, 이것은 어떻게 든 추상적 인 질문입니다. HTTP 500 대신 "Down for Maintenance"를 사용하는 사이트도 보았습니다.

웹 사이트의 경우 때때로 업그레이드를 수행해야합니다. 예를 들어 데이터베이스를 변경하는 경우 해당 시간 동안 다른 사용자가 데이터베이스를 만지지 못하게합니다. 데이터베이스가 오프라인 상태이면 SqlException을 표시하는 것이 좋지 않기 때문에 사이트도 정상적으로 해제해야합니다. 또 다른 이유는 일부 HW 장애 또는 시스템 장애 (예 : 리소스 누수)로 인해 응용 프로그램 또는 시스템 재부팅이 필요합니다.

일단 우리나라에서 가장 큰 은행 중 하나에서 인터넷 뱅킹 시스템 업그레이드에 참여했습니다. 웹 사이트, 미들 티어 및 데이터베이스 업그레이드의 전체 프로세스는 시스템이 고객을 위해 오프라인 상태 인 데 3 일이 걸렸습니다. 또한 모든 경우의 전체 백업을 포함하여 장애 발생시 시스템을 이전 버전으로 되돌릴 수 있습니다.

서버를 실행하려면 패치가 필요하고 많은 운영 체제에서 이러한 패치를 재부팅해야합니다. 이것이 다운 타임의 한 범주입니다. 많은 회사에서 일요일 아침과 같이 사용량이 적은 패치로 재부팅을 예약합니다. 패치가없는 경우 정기적으로 예약 된 유지 관리 시간에 서버를 재부팅합니다 (매주 반마다 특정 카운터가 오버플로 된 NT4 일부터의 중단이므로 매주 재부팅하면 다른 버그가 발생하지 않습니다).

제가 일한 한 회사는 90 년대 후반에 전자 상거래 사이트를 운영하여 한 달에 $ 1,000,000 이상을 판매했습니다. 누군가 세금 테이블을 프로덕션 데이터베이스 서버로 승격했습니다. 치료는 DB 서버를 백업에서 복원하고 마지막 백업 이후 트랜잭션을 적용하는 것이 었습니다. 이 과정에는 몇 시간이 걸렸으며이 기간 동안 웹 사이트에서 주문을 할 수 없었습니다. 주문 부분과 정적 판매 브로슈어가 동일한 사이트에서 실행 중이고 분리 할 수 ​​없었기 때문에 둘 다 내려 와야했습니다.

내가 일한 한 회사가 잘못된 장소에 잘못된 텍스트를 삽입하고 CEO가 뒤집어지면서 웹 사이트가 "유지 보수를 위해"라인을 벗어난 상태에서 레이아웃과 텍스트가 "고정"되었고 적절한 피해자가 비난을당했습니다.

다른 답변은 정확하지만 올바른 아키텍처를 사용하면 거의 항상 다운 타임을 피할 수 있습니다. 그러나 이는 비용이 들며,이 비용은 가치가 없을 수 있습니다. 1 시간의 다운 타임 비용이 아마존이나 NASDAQ 기반 인프라에 많은 영향을 미칩니다. 스택 오버플로 ? 아마도 그렇게 많지 않을 것입니다.

가동 중지 시간을 피하는 방법 :

• 하드웨어 서비스 페이지 종료 : 웹 사이트 앞에 프록시가있는 경우 사용자에게 영향을주지 않고 오프라인 상태로 전환 할 수 있습니다
• 서버 재구성 : 위와 동일
• 데이터베이스의 데이터 업데이트 / 변경 : 웹 사이트를 읽기 전용 모드 등으로 설정할 수 있습니다.

일반적으로 계층화 된 아키텍처에서는 "최상위"에 가까울수록 상태 저장 (웹 서버와 데이터베이스)의 다운 타임을 피하기가 가장 어렵습니다.

예약 된 중단 시간이 발생할 때마다 아무 작업도하지 않아도 사이트에서 정기적 인 중단 시간을 예약 할 수 있습니다. 이렇게함으로써 사용자는 사이트가 자주 특정 시간 동안 다운되어 작업을 수행 해야 할 때 사용자가 그다지 불평하지 않을 것이라는 생각에 익숙해 집니다.

이것에 대한 심리적 및 마케팅 측면도 있습니다. 일부 경우 (대부분의 경우를 감히 말하지만 굵은 * g *는 아닙니다) "유지 보수를 위해 다운"이라는 메시지는 "다른 이유로 서버가 다운되었거나 서비스가 중단되었습니다"를 의미 할 수도 있습니다.

나는 이것을 아주 자주 보았다. 일반적으로 개발자는 "후프, 우리는 현재 많은 부하를 겪고 있으며 모든 요청을 처리 할 수있는 것은 아닙니다"와 같은 "실제"오류 메시지를 원하지만 마케팅 담당자는 "친구에게, 고객에게 문제가 있다고 알려주십시오. 예정된 유지 보수 중이라고 알려주십시오. 훨씬 나아질 것입니다. "

따라서 "유지 보수 중단"은 종종 "서비스 중단"의 또 다른 용어 일뿐입니다.

유지 관리를 위해 다운해야 할 서버가 없습니다. 규모, DB 변경, 서버 업데이트 등 어떤 일이든 피할 수 있습니다.

문제는 특정 규모의 가동 중지 시간 시스템이 생성 및 유지 관리 비용이 매우 높다는 것입니다. 어느 곳에서나 중복, 모든 곳에서로드 밸런싱, 데이터 복제, 동기화가 필요합니다. 어려운 문제입니다.

기본적으로 시스템의 일부가 업데이트로 바쁘거나 동기화되지 않은 경우에도 Netflix Chaos Monkey를 릴리스 할 수있는 수준에 도달해야합니다. 이것은 확실히 가능합니다. 또한 비용이 많이 들고 문제를 해결하는 데 많은 시간과 전문가가 필요합니다.

사이트를 유지 보수 모드로 설정하는 것은 선택하는 중간 단계 일 수 있습니다. 잠시 동안 사이트를 잠시 중단하지 않기 위해 많은 투자를하고 싶지 않기 때문입니다.

경제학.

물론, 가동 중지 시간을 선택하면 사이트는 가용성뿐만 아니라 그 이상의 이점을 얻을 수 있습니다. 이러한 모범 사례는 두 가지 목적을 모두 수행하므로 안정성도 향상됩니다.

개발 서버에서 개발하는 경우 왜 그렇게 많은 사이트가 필요한지 이해가되지 않습니다. 왜 프로덕션 사이트를 종료해야합니까?

젠장. 결과물에 대해 어떤 형태의 수학적 검증 ( 및 사양이 유효 함 )을 수행하지 않는 한 아무리주의를 기울여도 똥이 발생합니다.

또한 가동 중지 시간이 필요한 인프라의 핵심 부분 (예 : 데이터베이스 구조 변경)을 변경해야 할 수도 있습니다.

중요한 시스템 (예 : 5-9 또는 6-9 시스템)을 개발하지 않는 한 책임 있고 비용 효율적인 방법은 가동 중지 시간을 현실의 일부로 수용하여 시스템을 구축하는 것입니다.

또한 효과적인 복구를위한 명확한 이해와 절차를 통해 다운 타임을 관리 가능하고 감지 가능하도록 최소한의 시간을 확보함으로써 이러한 원칙을 더욱 강화할 수 있습니다.

웹 사이트가 해킹되면 (몇 년 전 이전 IIS6 및 Windows 2003 서버). 복원 작업을하는 동안 "유지 보수 중"페이지를 몇 시간 동안 두었습니다 ....