WSFC를 사용하여 클라우드에서 고가용성을 달성하는 방법

WSFC를 사용하여 클라우드에서 고가용성을 달성하는 방법

Microsoft Windows Server에는 중요한 응용 프로그램의 가용성을 보장하는 WSFC(Windows Server 장애 조치 클러스터링) 소프트웨어가 포함되어 있습니다. 온프레미스 환경에서 클러스터의 기본 노드와 대기 노드는 동일한 공유 스토리지에 연결됩니다. 그러나 이 인프라를 클라우드로 직접 가져올 수는 없습니다. 기본 시스템과 대기 시스템 모두에 걸쳐 있는 공유 저장소는 WSFC에서 필수적이지만 공유 저장소는 AWS, Azure 또는 Google Cloud의 IaaS(Infrastructure as a Service)와 같은 공용 클라우드 서비스와 함께 사용할 수 없습니다.

지리적으로 분리된 공유 스토리지 WSFC용 클라우드에서 사용할 수 없음

기업은 온프레미스 애플리케이션을 클라우드로 마이그레이션할 때 온프레미스 운영 프로세스를 변경하지 않고 WSFC를 포함한 전체 인프라를 클라우드로 이동하는 것을 선호합니다. 이를 통해 동일한 WSFC 기술과 노하우를 클라우드에 적용하여 중단을 최소화할 수 있습니다.

클러스터를 구성하는 서버는 애플리케이션이 실행되는 기본 노드와 대기 노드로 나뉩니다. WSFC 소프트웨어는 애플리케이션과 서버 노드를 모니터링하여 작동하는지 확인합니다. WSFC가 기본 노드에 문제가 있음을 감지하면 "장애 조치(failover)"라는 프로세스에서 애플리케이션의 작동을 대기 노드로 전환합니다.

WSFC 환경에서 기본 서버와 대기 서버는 공유 스토리지(일반적으로 SAN(Storage Area Network) 또는 iSCSI-SAN 스토리지라고 하는 스토리지)에 연결됩니다.

기본 서버에서 대기 서버로 작업을 페일오버하려면 대기 서버가 일반적으로 기본 서버에서 읽고 쓰는 SAN에서 읽고 쓸 수 있도록 네트워크 링크를 전환해야 합니다. 이러한 방식으로 짧은 시간에 서비스를 다시 시작할 수 있어 대기 서버가 기본 노드와 동일한 데이터에 액세스하고 낮은 RPO(복구 시점 목표)를 충족할 수 있습니다.

관련 콘텐츠 보기: 재해 복구 기초 .

그러나 WSFC를 클라우드로 마이그레이션할 때 사용할 수 있는 SAN이 없습니다. 예를 들어 Amazon Web Services(AWS) 및 Microsoft Azure를 여러 노드(서버)에 연결하여 공유 스토리지로 사용할 수 없습니다. 다른 클라우드 서비스의 IaaS에도 동일하게 적용됩니다.

공유 스토리지 없이 WSFC를 기반으로 HA 클러스터 구성을 구축하는 것도 가능하지만 대기 노드에서 데이터를 복구하는 자체 프로그램을 만드는 것과 같은 고도의 기술이 필요합니다. 조작이 복잡하고 사고 발생시 확인이 쉽지 않습니다.

데이터 복제 소프트웨어로 문제 해결

이 문제를 해결하려면 다음을 설치할 수 있습니다. 데이터 복제 SIOS DataKeeper Cluster Edition과 같은 HA 클러스터에 특화된 소프트웨어를 사용하고 로컬 서버 간에 스토리지를 동기화합니다. 기본 및 대기 노드의 로컬 디스크에 있는 데이터는 호스트 기반 블록 수준 복제를 사용하여 실시간으로 동기화됩니다. 이 방법을 사용하면 공유 저장소가 필요하지 않습니다. 대신 기존 프로세스를 방해하지 않고 친숙한 WSFC를 사용하여 HA 클러스터 구성을 구축할 수 있습니다.

DataKeeper를 사용하면 동기화된 노드가 WSFC 관리 화면(장애 조치 클러스터 관리)에 SAN으로 나타납니다. 운영 관리자가 WSFC를 사용한 경우 이 접근 방식에 대한 교육이 거의 또는 전혀 필요하지 않습니다.

온프레미스 HA를 능가하는 클라우드의 고가용성 SIOS DataKeeper 및 WSFC 사용

DataKeeper 클러스터 에디션 WSFC(Windows Server Failover Clustering)와 원활하게 통합되어 성능이 최적화된 호스트 기반 동기 또는 비동기 복제를 추가하는 소프트웨어 애드온입니다. 드물게 HA 클러스터가 오작동하는 경우 WSFC는 대기 노드에 대한 작업 장애 조치를 조정하고 공유 스토리지인 것처럼 공유 스토리지에 액세스합니다. 이 간단한 메커니즘을 통해 기존 시스템의 운영을 변경하지 않고 AWS로 이전할 수 있습니다.

친숙한 WSFC 작업을 손상시키지 않고 온프레미스와 동일하거나 더 나은 DataKeeper를 사용하여 클라우드에서 고가용성을 보장할 수 있습니다. 고가용성 . 이 클러스터 구성의 장점은 매우 간단하고 모든 클라우드 환경에 쉽게 적용할 수 있다는 것입니다.

WSFC와의 원활한 통합

SIOS DataKeeper Cluster Edition은 성능에 최적화된 호스트 기반 데이터 복제 메커니즘을 제공하여 WSFC(Windows Server Failover Clustering)와 원활하게 통합 및 확장합니다. WSFC가 소프트웨어 클러스터를 관리하는 동안 SIOS는 재해 보호를 활성화하고 클라우드, 가상 및 고성능 스토리지 환경과 같이 공유 스토리지 클러스터가 불가능하거나 비실용적인 경우 데이터 손실을 방지하기 위해 데이터 복제를 수행합니다.

의 허가를 받아 재생산 시오스

쿼럼/감시를 배포하는 가장 좋은 단일 방법

쿼럼/감시를 배포하는 가장 좋은 단일 방법

최근 회의에서 한 고객이 고가용성(HA) 및 쿼럼/증인 실행 가능성의 필요성에 대해 질문했습니다. 그들의 질문은 "정족수/증인을 배치하는 가장 좋은 방법은 무엇입니까?"였습니다. 그들의 질문에 대한 대답은 간단합니다. 쿼럼을 배포하는 가장 좋은 방법은 없습니다.그 이유를 이해하기 위해 감시 리소스, 쿼럼 리소스 및 분할 브레인 시나리오의 세 가지 주요 사항을 정의하는 것으로 시작하겠습니다.

스플릿 브레인이란?

일반 클러스터 환경에서 보호된 애플리케이션은 클러스터의 기본 노드에서 실행됩니다.해당 기본 노드의 애플리케이션 오류가 발생하는 경우 클러스터링 소프트웨어는 애플리케이션 작업을 기본 노드의 역할을 가정하는 보조 또는 원격 노드로 이동합니다. 주어진 시간에 하나의 기본 노드만 있습니다.

스플릿 브레인은 클러스터의 구성원이 서로 통신할 수 없지만 실행 및 작동 가능한 상태에 있으며 이후에 공통 리소스의 소유권을 동시에 가져갈 때 발생하는 상태입니다. 실제로 두 명의 버스 운전사가 운전대를 놓고 싸우고 있습니다.분할 브레인은 파괴적인 특성으로 인해 데이터 손실 또는 데이터 손상을 유발할 수 있으며 클러스터 중재를 위한 펜싱, 쿼럼, 감시 또는 쿼럼/감시 기능을 사용하여 방지하는 것이 가장 좋습니다.

대부분의 클러스터 관리자에서 쿼럼은 다음과 같은 경우에 유지됩니다.

1. 모든 서버는 모든 클러스터 피어 및 증인에 대해 동일한 상태를 볼 수 있습니다.
2. 모든 서버는 모든 클러스터 피어에 대해 동일한 상태를 볼 수 있지만 증인은 아닙니다.
3. 모든 서버는 서로는 아니지만 감시 리소스를 볼 수 있으며 분할 브레인 시나리오를 피할 수 있습니다.

대부분의 클러스터 관리자에서 다음과 같은 경우 쿼럼이 손실됩니다.

1. 서버는 모든 클러스터 피어와 감시 서버를 볼 수 없습니다.
2. 서버는 감시 서버를 볼 수 있지만 대다수의 클러스터 피어를 볼 수 없습니다.
3. 서버는 쿼럼 구성원 및 리소스 액세스를 성공적으로 중재하기 위해 쿼럼 리소스에 액세스하거나 액세스를 유지할 수 없습니다.

감시 리소스(또는 서버)란 무엇입니까?

감시 리소스는 클러스터에 짝수의 구성원이 있는 경우 쿼럼을 달성하고 유지 관리하는 데 사용되는 서버, 네트워크 끝점 또는 장치입니다.클러스터 과반수를 사용하는 홀수의 구성원이 있는 클러스터는 과반수 구성원을 중재하기 위해 클러스터 서버의 모든 구성원으로 감시 리소스를 사용할 필요가 없습니다.

쿼럼 및 쿼럼 리소스란 무엇입니까?

쿼럼 리소스는 클러스터 상태 및 구성원 자격을 중재하는 수단으로 사용되는 리소스(장치, 시스템, 블록 저장소, 파일 저장소, 파일 공유 등)입니다.일부 클러스터 관리자에서 쿼럼은 클러스터 상태 및 클러스터 구성원 결정에 도움이 되거나 필요한 클러스터 내의 리소스입니다.다른 클러스터 관리자에서 쿼럼은 분할 브레인을 방지하기 위한 결정자 역할을 합니다.

쿼럼을 배포하는 여러 가지 방법

쿼럼의 중요한 특성을 감안할 때 HA 아키텍처가 쿼럼/감시 리소스를 적절하게 배포하는 것이 중요합니다. 하나도 없다 , 쿼럼을 배포하는 가장 좋은 방법입니다.증인 및 정족수 자원이 작동하는 방식을 형성할 수 있는 몇 가지 요인이 있습니다.이러한 요인에는 다음이 포함됩니다.

1. 배포가 온프레미스, 클라우드 또는 하이브리드인지 여부

파이버 채널 스토리지, 전원 제어 장치 또는 연결 또는 기존의 stonith 장치와 같은 추가 스토리지 장치가 있는 온프레미스 데이터 센터에 배포하면 클라우드에 없을 수 있는 쿼럼 및 감시 기능에 대한 추가 옵션이 고객에게 제공됩니다.마찬가지로 클라우드 및 하이브리드 환경은 배포할 수 있는 것과 방지하기 위해 배포하는 사용 사례 쿼럼에 차이가 있습니다. 또한 대기 시간 요구 사항과 차이점으로 인해 쿼럼/감시 구성에 사용할 수 있는 장치 및 리소스 유형이 제한될 수 있습니다.  

2. 복구 목표

복구 목표는 쿼럼 및 감시 리소스를 설계하고 구성할 때 고려해야 할 중요합니다.2개의 노드 클러스터(노드 A 및 노드 B)의 예에서 노드 A에서 노드 B에 대한 연결이 끊어지면 복구를 위한 가장 높은 우선 순위가 무엇입니까? 감시/쿼럼 리소스가 노드 A와 동일한 네트워크에 있는 경우 노드 A가 온라인 상태로 남아 있지만 클라이언트에서 분리될 수 있는 반면 노드 B는 쿼럼 및 인계를 평가할 수 없습니다.마찬가지로, 쿼럼 장치가 지역, 데이터 센터 또는 노드 B가 있는 네트워크에만 있는 경우 손실이 발생하면 리소스가 없어진 네트워크 또는 센터로 장애 조치되거나 기능 및 작동 기본 노드에서 멀어질 수 있습니다.

3. 인프라 내에서 사용 가능한 데이터 센터(또는 지역)의 이중화

데이터 센터 또는 지역의 이중화도 쿼럼/감시가 있는 HA 토폴로지에서 중요한 요소입니다. 데이터 센터에 두 가지 수준의 중복만 있는 경우 기본 또는 대기 클러스터 노드와 동일한 데이터 센터에 쿼럼/감시 배치 간의 균형을 이해해야 합니다. 데이터 센터에 세 번째 가용 영역 또는 두 번째 지역에 대한 액세스와 같이 두 개 이상의 중복 계층이 있는 경우 이 옵션은 클러스터에 더 높은 수준의 중복성을 제공합니다.

4. 재해 복구 요구 사항

실제 재해 복구 요구 사항을 이해하는 것도 설계의 주요 요소입니다. 클러스터 관리자 소프트웨어에서 전체 데이터 센터 중단(또는 지역 장애)을 복구하기 위해 쿼럼/감시 액세스가 필요한 경우 설계에 대한 이러한 영향을 이해해야 합니다.많은 고가용성 소프트웨어 패키지에는 이 시나리오를 위한 도구 또는 방법이 있지만 소프트웨어에 없는 경우 쿼럼/감시를 설계하고 배치하여 이러한 현실을 수용해야 할 수 있습니다.

5. 클러스터 내의 구성원 수 및 위치

클러스터에 홀수개의 노드가 포함된 경우 일반적으로 추가 쿼럼/감시 서버가 필요하지 않습니다.그러나 클러스터에서 두 개의 노드만 사용하거나 항상 사용할 수 없는 DR 노드를 배포하는 경우 아키텍처가 변경될 수 있습니다.고객 경험 담당 부사장으로서 저는 3개의 노드 아키텍처를 배포한 고객과 함께 작업했지만 비용 절감을 위해 세 번째 서버의 주기적 종료를 자동화했습니다.

6. 운영 체제 및 클러스터 관리자

쿼럼/감시에서 언급할 마지막 요소는 클러스터 관리자와 운영 체제입니다.쿼럼/감시 배포 또는 쿼럼 상태 중재와 관련하여 모든 HA 소프트웨어 및 클러스터 관리자가 동일하지는 않습니다.일부 클러스터링 소프트웨어에는 중재를 위해 공유 디스크가 필요하고 다른 소프트웨어는 공유를 허용하는 더 유연합니다(NFS, SMB, EFS, Azure Files 및 S3).클러스터 관리자가 요구하는 사항과 쿼럼과 관련하여 지원하는 모드(단순 과반수, 감시, 파일 공유 등)를 알고 있으면 배포 대상뿐만 아니라 배포 방법에도 영향을 미칩니다.

쿼럼/감시 서버를 배포하는 가장 좋은 방법은 쿼럼/감시 및 사용 가능한 옵션에 대한 공급업체의 정의를 이해하고, 요구 사항을 파악하고, 데이터 센터(또는 클라우드 환경)에서 제공하는 제한 사항이나 기회를 고려하고, 솔루션을 설계하는 것입니다. 스플릿 브레인(split-brain), 잘못된 장애 조치(failover) 및 다운타임에 대한 최고 수준의 보호를 중요한 시스템에 제공합니다.

-Cassius Rhue, VP, 고객 경험

Windows용 SIOS DataKeeper를 사용하여 GCP에서 쓰기 처리량 성능 측정 및 개선

Windows용 SIOS DataKeeper를 사용하여 GCP에서 쓰기 처리량 성능 측정 및 개선

배경

이 게시물은 GCP에 복제되는 디스크에 대한 쓰기 성능과 관련하여 GCP에서 발견한 내용을 문서화하는 데 사용됩니다. 그러나 먼저 몇 가지 배경 정보가 있습니다. 한 고객은 동일한 지역의 Google 영역 간에 동기식 미러로 테스트할 때 DataKeeper가 쓰기 성능에 엄청난 양의 오버헤드를 추가하고 있다는 우려를 표명했습니다. 그들이 수행한 원래 테스트는 영구 SSD인 C 드라이브의 비트맵 파일을 사용하는 것이었습니다. 이 구성에서는 약 70MBps만 푸시했습니다. 그들은 비트맵을 극단적인 GCP 디스크로 재배치하려고 시도했지만 성능이 향상되지 않았습니다.

비트맵을 로컬 SSD로 이동

비트맵을 로컬 SSD로 옮기자고 제안했지만 비트맵에 사용하는 익스트림 디스크의 지연 시간과 처리량이 로컬 SSD와 같거나 더 우수하다고 생각하여 주저했습니다. 차이점. 또한 로컬 SSD를 추가하는 것은 VM이 원래 프로비저닝된 경우에만 추가할 수 있기 때문에 간단한 작업이 아닙니다.

인스턴스 유형 선택

작업을 완료하기 시작하면서 가장 먼저 발견한 것은 모든 인스턴스 유형이 로컬 SSD를 지원하는 것은 아니라는 것입니다. 예를 들어 E2-Standard-8은 로컬 SSD를 지원하지 않습니다. 첫 번째 테스트에서는 "컴퓨팅 최적화"로 간주되는 C2-Standard-8 인스턴스 유형으로 결정했습니다. 500GB 영구 SSD를 연결하고 몇 가지 쓰기 성능 테스트를 실행하기 시작했고 최대 속도 240MBps가 아닌 약 140MBps에서만 디스크를 쓸 수 있다는 것을 빠르게 발견했습니다. 고객은 동일한 것을 보았다고 확인했습니다. 당혹스러웠지만 계속해서 다른 인스턴스 유형을 시도하기로 결정했습니다.

우리가 선택한 두 번째 인스턴스 유형은 N2-Standard-8입니다. 이 인스턴스 유형을 사용하면 디스크를 복제하지 않을 때 최대 처리 속도인 240MBps까지 디스크를 푸시할 수 있습니다. 비트맵을 프로비저닝한 로컬 SSD로 이동하고 동기식 미러(DataKeeper v8.8.2)에서 동일한 테스트를 반복하여 아래와 같은 결과를 얻었습니다.

결과

Diskspd 테스트 매개변수 diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b64K -Sh -LD:data.dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b8K -Sh -LD:data .dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b4K -Sh -LD:data.dat

MBps

자료

결론

64k 및 4k 쓰기 크기는 모두 동기 복제에 "허용되는" 것으로 간주될 수 있는 오버헤드를 발생시킵니다. 평균 대기 시간 3.183ms는 여전히 매우 낮지만 8k 쓰기 크기는 더 많은 오버헤드를 발생시키는 것으로 보입니다.

-Dave Bermingham, 고객 성공 담당 이사의 허가를 받아 복제됨 시오스

COVID-19가 고가용성에 미치는 영향

COVID-19가 고가용성에 미치는 영향

친구, 가족, 치료, 입원, 집중치료가 필요한 분들에 비해 저의 코로나 증상은 경미했습니다. 이것은 합리적으로 좋은 건강, 백신 접종, 추가 주사, 조기 발견 및 치료의 결과일 가능성이 높습니다.그리고 이 팬데믹으로 인해 사랑하는 사람을 잃은 모든 가족과 기회와 특별한 순간을 잃은 모든 사람들에게 마음을 보냅니다.저와 SIOS 팀의 여러 구성원이 COVId-19에서 회복함에 따라 귀하의 IT 팀이 COVID 및 엔터프라이즈 다운타임과 싸우면서 처리할 수 있는 5가지 사항과 그들을 돕기 위해 할 수 있는 5가지 사항을 공유하고자 합니다.

IT 팀이 직면한 5가지 COVID 문제

1. 개인 및 가족의 우려와 두려움

   처음에는 증상이 거의 눈에 띄지 않았고 목에 약간의 자극이 있었고 약간의 부비동 배액이 계절성 알레르기로 자가 진단되었습니다.하지만 문제가 악화되자 심한 기침을 동반하여 걱정이 되었습니다.물론 우리 모두는 우리의 업무 성과와 책임이 변함이 없다고 생각하고 싶지만 현실은 평가하기가 조금 더 어려울 수 있습니다. 초기 음성 검사에도 불구하고 나는 계속해서 증상이 나타나 결국 일할 수 있는 능력에 영향을 미치고 개인 건강 문제가 증가했으며 여러 가지 두려움을 불러일으켰습니다. 귀하의 팀이 COVID-19의 직접적인 영향을 받은 경우 일정, 작업 및 활동에 영향을 미칠 수 있는 실제 건강 문제 외에도 개인적인 우려, 두려움 및 걱정을 처리할 가능성이 있음을 이해하십시오. 각 팀 구성원이 더 큰 관심사, 즉 가족에 대한 관심사도 다룰 가능성이 있습니다.내가 병에 걸렸을 때, 고맙게도 내 아이들은 모두 건강했습니다.그러나 아내는 운이 좋지 않았습니다.그녀는 내 증상이 나타난 지 3일 후에 아팠고 더 오래 아팠고 더 심각한 증상과 좌절을 겪었습니다.우리는 대가족 단위, 면허가 있는 10대 운전자 및 COVID-포지티브 부모가 운전하지 않는 추가 차량의 이점을 가지고 있지만 귀하의 팀은 이러한 사치품을 갖지 못할 수도 있습니다.그렇게 한다 하더라도 가정을 위생적으로 관리하고 자녀를 학교에 다니고 건강하게 유지하며 규정, 명령 및 긴밀한 접촉을 처리하는 데 필요한 시간과 정신적 에너지의 양을 줄이거나 걱정에서 자유로울 수 없습니다. 문제.수입과 지출에 대한 우려는 말할 것도 없다.개인 및 가족 문제에 직면한 팀 구성원은 집중하기 어려움, 성급한 성격, 마감일 및 일정 준수 어려움을 경험할 수 있습니다.

2. FODO – 다른 사람들을 실망시키는 것에 대한 두려움

   COVID-19 질병이 없더라도 전 세계 기업은 더 적은 인력으로 인한 영향을 느끼고 있습니다."Great Shift", "Great Resignation" 또는 "Great Shuffle"로 적절하게 설명된 사건은 이미 HA를 다루는 인력을 포함하여 인력을 극적으로 재편성하여 중요한 작업을 수행할 인력이 적은 팀을 남겼습니다. 이러한 팀 구성원의 부족으로 인해 COVID에 걸린 사람들은 FODO(Fear of Disappointing Others)와 싸울 수 있습니다.아픈 팀 구성원은 팀에 대한 충성심이나 실망스러운 상사, 동료 또는 이해 관계자에 대한 두려움 때문에 계속 일하려고 할 수 있습니다.이 FODO는 종종 스트레스를 받는 환경(위의 #1 및 2 참조)에서 이미 기능하고 있는 근로자가 COVID-19 이전 수준의 활동을 유지하려고 시도하도록 합니다. 영웅적이지만 개인적 및 직업적 회복에 역효과를 낳기도 합니다.

3. 피로

   COVID-19 증상을 계속 다루면서 계속 직면하는 가장 큰 문제 중 하나는 피로입니다.처음에는 FODO에 의해 유발된 그 피로가 적절한 휴식과 회복을 방해했습니다.나는 우리 팀이 얼마나 부족한지 보았고 다른 사람들이 요구 사항을 따라잡기 위해 자신의 병을 용감히 하려고 하는 것을 보았기 때문에 나도 똑같이 하려고 노력했습니다.그러나 경고도 없이 나는 하루가 끝날 때가 아니라 하루 종일 일정 시간 동안 지쳐 있는 자신을 발견했습니다.나에게는 오전 5시 이전에 시작하여 8시간에서 12시간 동안 업무, 업무, 전략 및 인사 문제에 계속 집중하는 것이 일반적이었습니다.(그것이 건강한지 나중에 토론할 수 있습니다). 이제 일부는 오전 8시 이전에 에베레스트를 등반하고 싶어졌습니다.내가 받은 최고의 조언은 “싸우지 마십시오. 몸이 쉬라고 하면 쉬라!”

4. 뇌 안개

   내가 아프기 시작했을 때 동료는 COVID 증상으로 시합을 한 후 안개 속에 있는 것처럼 느꼈다고 말했습니다. 나처럼 그들은 완전히 예방 접종을 받았고 증상과 기간은 경미했습니다. 실제로 그들은 실제로 양성 반응을 보인 적이 없습니다.그럼에도 불구하고 그들은 우리가 "두뇌 안개"라고 부르는 것과 함께 며칠을 보냈습니다. 우리가 세부 사항을 기억하는 속도가 느린 경험, 답을 알고 있는 감각이지만 육체적 피로 및 정신적 피로와는 어딘가 다른 정신적 날카로움이 부족합니다.어떤 경우에는 질문에 대한 더 느린 응답, 키 입력의 일시 중지 또는 방에 조명이 켜질 때까지의 지연으로 나타납니다.

5. 복구 실패

   코로나가 시작된 지 5일 만에 이른 밤의 휴식에서 깨어나 그 어느 때보다 기분이 좋아졌습니다. 나는 일상에 뛰어 들었고 정오까지 내가 완전히 회복되지 않았다는 것을 발견했습니다.대신 나는 전날 밤 푹 자서 얻은 작은 에너지 저장고를 소진하고 있었다.이 피로를 이겨내려고 노력하는 것은 나의 회복에 새로운 차질을 만들었습니다.다음 날 나는 전보다 기분이 더 나빠졌다.실패한 회복의 고통과 더 많은 좌절을 피하는 방법에 대한 걱정이 나의 피로와 안개에 추가되었습니다.

따라서 IT 팀 리더, 이해 관계자 및 관리자는 팀에서 COVID-19 문제를 경험할 때 무엇을 해야 합니다.

COVID와 싸우는 IT 팀을 돕는 5가지 방법

1. 공감 연습

   COVID는 각 개인과 가족에게 다르게 영향을 미친다는 점에 유의하십시오.동료와 관리자 중 일부는 사소한 문제가 있고 증상이 없으며 합병증이 없습니다.반면에 한부모 가정, 다세대 가정, 자녀가 있거나 취약한 사람이 있는 가정은 더 많은 문제와 걱정거리가 있을 것입니다.바이러스는 또한 각 사람에게 고유한 영향을 미친다는 사실을 알고 있습니다.가족 내에서도 나와 아내의 증상은 달랐다.내가 더 많은 피로를 경험하는 동안 그녀는 더 많은 두통을 경험했습니다. 두뇌 안개, 저글링 작업 일정, 아픈 사랑하는 사람 돌보기 또는 COVID와 관련된 무수한 문제를 처리할 수 있는 동료에 대해 인내심을 가지십시오.

2. 요구 사항 평가

   독감이나 감기와 달리 코로나바이러스의 회복은 불규칙합니다. 팀원이 어느 날 직장에 나타나 몸이 많이 나아진 것을 느끼고 다음 날에는 집에 있을 수 있습니다. 귀하의 비즈니스에는 여전히 고가용성 및 재해 복구에 대한 기술적 요구 사항과 요구 사항이 있습니다.그러나 질병으로 인해 인원이 들어오고 나가는 경우 팀 내에서 요구되는 현재 역할과 책임을 이해해야 합니다.개인이 아플 때 자신의 역할, 팀에 미치는 영향, 인프라에 대한 책임 수준 등을 평가해야 합니다. 중요한 다운타임 이벤트가 발생한 경우 팀이나 조직 내에서 누가 서비스를 제공할 수 있는지 평가해야 할 수도 있습니다.

3. 문제의 우선 순위 지정

   주요 문제의 우선 순위를 지정하여 팀을 돕습니다.일반적인 상황에서 IT 팀은 사소한 것(USB 키보드)에서 중요한 것(다운타임, 보안 위협 또는 스토리지 문제와 관련된 문제)에 이르기까지 수십 가지 요청의 균형을 맞추고 있습니다.당신과 팀에게는 명백할 수 있지만 다른 이해 관계자는 IT 팀의 상태와 더 "정상적인" 직원 배치가 이루어질 때까지 운영이 어떻게 처리되는지 이해해야 할 수도 있습니다.

4. 프로세스가 최신 상태인지 확인하십시오.

   팀 구성원이 교체되면서 IT 유지 관리 및 관리 프로세스를 최신 상태로 유지하는 것이 중요합니다.이러한 프로세스는 팀의 각 구성원이 일반적인 책임이 아닌 작업을 수행할 때 기업에 효과적이고 효율적으로 서비스를 제공하는 데 도움이 됩니다. 또한 각 팀 구성원이 동료가 회복하는 동안 자신이 다루고 있는 시스템의 상태를 조사하는 데 필요한 시간을 줄일 수 있습니다.

5. 사람들에게 시간을 주세요

   나는 내가 해야 하는 것보다 더 많은 일과에 서두르게 되었고, 차질과 다음 날 더 큰 피로의 결과를 겪었습니다.팀의 리더 또는 개인 기여자로서 자신과 팀에 "정상으로 돌아갈" 시간을 주어야 합니다.

팬데믹이 계속되면서 우리 모두는 질병, 두려움, 걱정이 줄어들고 정상과 매우 유사한 미래를 희망합니다.한편, COVID 질병 및 회복 기간 동안 팀원들이 직면하고 있는 우려 사항을 더 잘 알고 있으면 현재 폭풍우를 사전에 준비하고 대처하는 데 큰 도움이 될 것입니다.또한 이 팬데믹에서 배운 주요 교훈은 다른 여러 조직, 직원 생활 및 글로벌 문제에 적용할 수 있습니다.

의 허가를 받아 재생산 시오스

기술 지원 전화를 최대한 활용하는 방법