네트워크 인프라를 제어하는 ​​방법. 첫 번째 장. 잡고 있다

이 기사는 "네트워크 인프라를 제어하는 ​​방법" 시리즈 기사 중 첫 번째 기사입니다. 시리즈의 모든 기사 내용과 링크를 확인할 수 있습니다. 여기에.

나는 XNUMX시간 또는 하루의 네트워크 다운타임이 중요하지 않은 회사가 충분히 많다는 것을 충분히 인정합니다. 불행하게도 다행스럽게도 저는 그런 곳에서 일할 기회가 없었습니다. 그러나 물론 네트워크도 다르고, 요구 사항도 다르며, 접근 방식도 다르지만 어떤 형태로든 아래 목록은 많은 경우 실제로 "반드시 해야 할 일"이 될 것입니다.

그럼 초기조건입니다.

당신은 새로운 직장에 입사했거나, 승진을 했거나, 당신의 책임을 새롭게 살펴보기로 결정했습니다. 회사 네트워크는 귀하의 책임 영역입니다. 여러분에게 이것은 여러 면에서 도전적이고 새로운 것이며, 이는 이 기사의 멘토링 톤을 어느 정도 정당화합니다 :). 하지만 이 기사가 모든 네트워크 엔지니어에게도 유용할 수 있기를 바랍니다.

첫 번째 전략적 목표는 엔트로피에 저항하고 제공된 서비스 수준을 유지하는 방법을 배우는 것입니다.

아래에 설명된 많은 문제는 다양한 방법으로 해결될 수 있습니다. 나는 의도적으로 기술적 구현에 관한 주제를 제기하지 않습니다. 왜냐하면... 원칙적으로 이 문제나 저 문제를 어떻게 해결했는지는 그다지 중요하지 않은 경우가 많지만, 중요한 것은 그것을 어떻게 사용하는지, 전혀 사용하는지 여부입니다. 예를 들어, 전문적으로 구축된 모니터링 시스템을 살펴보지 않고 경고에 응답하지 않으면 거의 쓸모가 없습니다.

Оборудование

먼저 가장 큰 위험이 어디에 있는지 이해해야 합니다.

다시 말하지만, 다를 수 있습니다. 예를 들어 어딘가에는 보안 문제가 있을 것이고, 어딘가에는 서비스 연속성과 관련된 문제가 있을 것이고, 어쩌면 다른 곳이 있을 수도 있다는 점을 인정합니다. 왜 안 돼?

확실히 하기 위해 이것이 여전히 서비스의 연속성이라고 가정해 보겠습니다. (제가 일했던 모든 회사에서 그랬습니다.)

그런 다음 장비부터 시작해야 합니다. 주의해야 할 주제 목록은 다음과 같습니다.

• 중요도에 따른 장비 분류
• 중요 장비의 백업
• 지원, 라이센스

특히 중요도 분류의 최상위에 있는 장비의 경우 가능한 오류 시나리오를 생각해야 합니다. 일반적으로 이중 문제의 가능성은 무시됩니다. 그렇지 않으면 솔루션과 지원 비용이 터무니없이 비싸질 수 있지만, 실패가 비즈니스에 큰 영향을 미칠 수 있는 정말 중요한 네트워크 요소의 경우에는 이에 대해 생각해 보아야 합니다.

예

데이터 센터의 루트 스위치에 대해 이야기하고 있다고 가정해 보겠습니다.

서비스 연속성이 가장 중요한 기준이라는 데 동의했으므로 이 장비에 대해 "핫" 백업(이중화)을 제공하는 것이 합리적입니다. 그러나 그것이 전부는 아닙니다. 또한 첫 번째 스위치가 고장난 경우 스위치도 고장날 위험이 있으므로 남은 스위치 하나만 ​​가지고 생활하는 것이 허용되는 기간을 결정해야 합니다.

중요한! 이 문제를 스스로 결정할 필요는 없습니다. 경영진 또는 회사 관리에 대한 위험, 가능한 솔루션 및 비용을 설명해야 합니다. 그들은 결정을 내려야 합니다.

따라서 이중 오류 가능성이 적다는 점을 고려하여 하나의 스위치에서 4시간 동안 작업하는 것이 원칙적으로 허용 가능하다고 판단되면 적절한 지원을 받을 수 있습니다(장비는 4시간 이내에 교체됩니다). 시간).

하지만 전달되지 않을 위험이 있습니다. 불행하게도 우리는 한때 그런 상황에 처해 있었습니다. XNUMX시간이 아닌 일주일 동안 장비를 이동했습니다!!!

따라서 이 위험에 대해서도 논의해야 하며 아마도 다른 스위치(세 번째)를 구입하여 예비 부품 패키지("콜드" 백업)에 보관하거나 실험실 목적으로 사용하는 것이 더 정확할 것입니다.

중요한! 만료 날짜가 포함된 모든 지원을 스프레드시트로 만들어 달력에 추가하면 지원 갱신에 대해 걱정하기 시작하기 최소 한 달 전에 이메일을 받을 수 있습니다.

지원 갱신을 잊어버리고 지원이 종료된 다음 날 하드웨어가 고장나는 경우에는 용서받을 수 없습니다.

긴급작업

네트워크에서 무슨 일이 일어나든 이상적으로는 네트워크 장비에 대한 액세스를 유지해야 합니다.

중요한! 모든 장비에 대한 콘솔 액세스 권한이 있어야 하며 이 액세스는 사용자 데이터 네트워크의 상태에 따라 달라져서는 안 됩니다.

또한 발생할 수 있는 부정적인 시나리오를 미리 예측하고 필요한 조치를 문서화해야 합니다. 이 문서의 가용성도 중요하므로 부서의 공유 리소스에 게시해야 할 뿐만 아니라 엔지니어의 컴퓨터에 로컬로 저장해야 합니다.

있어야합니다

• 공급업체 또는 통합업체 지원을 통해 티켓을 개설하는 데 필요한 정보
• 장비(콘솔, 관리)에 접근하는 방법에 대한 정보

물론 여기에는 다양한 장비의 업그레이드 절차에 대한 설명과 유용한 진단 명령 등 다른 유용한 정보도 포함될 수 있습니다.

제휴

이제 파트너와 관련된 위험을 평가해야 합니다. 보통 이

• 인터넷 제공업체 및 트래픽 교환 지점(IX)
• 통신채널 제공자

스스로에게 어떤 질문을 던져야 할까요? 장비와 마찬가지로 다양한 비상 시나리오를 고려해야 합니다. 예를 들어 인터넷 제공업체의 경우 다음과 같을 수 있습니다.

• 인터넷 제공업체 X가 어떤 이유로 귀하에게 서비스 제공을 중단하면 어떻게 되나요?
• 다른 공급자가 귀하에게 충분한 대역폭을 제공합니까?
• 연결 상태는 얼마나 양호하게 유지되나요?
• 귀하의 인터넷 제공업체는 얼마나 독립적이며, 이들 중 하나가 심각한 중단을 당하면 다른 제공업체에도 문제가 발생합니까?
• 데이터 센터에 몇 개의 광 입력이 있습니까?
• 입력 중 하나가 완전히 파괴되면 어떻게 되나요?

입력과 관련하여, 두 개의 서로 다른 회사, 두 개의 서로 다른 데이터 센터에서 굴착기가 우물을 파괴했지만 기적적으로 우리 광학 장치는 영향을 받지 않았습니다. 이런 경우는 그리 드문 경우는 아닙니다.

그리고 물론 이러한 질문을 하는 것뿐만 아니라 경영진의 지원을 받아 어떤 상황에서도 수용 가능한 솔루션을 제공해야 합니다.

지원

다음 우선순위는 장비 구성의 백업일 수 있습니다. 어쨌든 이것은 매우 중요한 포인트입니다. 구성이 손실될 수 있는 경우는 나열하지 않으므로 정기적으로 백업하고 생각하지 않는 것이 좋습니다. 또한 정기적인 백업은 변경 사항을 모니터링하는 데 매우 유용할 수 있습니다.

중요한! 매일 백업하십시오. 이를 저장하기에는 그렇게 많은 양의 데이터가 아닙니다. 아침에 근무 중인 엔지니어(또는 귀하)는 시스템으로부터 백업 성공 여부를 명확하게 나타내는 보고서를 받아야 하며, 백업에 실패하면 문제를 해결하거나 티켓을 생성해야 합니다( 네트워크 부서 프로세스를 참조하세요).

소프트웨어 버전

장비의 소프트웨어를 업그레이드할 가치가 있는지 여부에 대한 질문은 그다지 명확하지 않습니다. 한편으로 이전 버전은 알려진 버그와 취약점이지만, 반면에 새 소프트웨어는 첫째로 항상 고통스러운 업그레이드 절차가 아니며, 둘째로 새로운 버그와 취약점입니다.

여기서 가장 좋은 옵션을 찾아야 합니다. 몇 가지 확실한 권장 사항

• 안정적인 버전만 설치
• 그래도 아주 오래된 버전의 소프트웨어를 사용해서는 안 됩니다.
• 일부 소프트웨어가 있는 위치에 대한 정보가 포함된 표지판을 만듭니다.
• 소프트웨어 버전의 취약점과 버그에 대한 보고서를 정기적으로 읽고 심각한 문제가 있는 경우 업그레이드를 고려해야 합니다.

이 단계에서 장비에 대한 콘솔 액세스, 지원 정보 및 업그레이드 절차에 대한 설명이 있으면 원칙적으로 이 단계를 수행할 준비가 된 것입니다. 이상적인 옵션은 전체 절차를 확인할 수 있는 실험실 장비가 있는 경우이지만 안타깝게도 이러한 일은 자주 발생하지 않습니다.

중요한 장비의 경우 공급업체 지원팀에 연락하여 업그레이드에 대한 도움을 요청할 수 있습니다.

티켓 시스템

이제 주위를 둘러볼 수 있습니다. 다른 부서 및 부서 내 상호작용을 위한 프로세스를 구축해야 합니다.

이는 필요하지 않을 수도 있지만(예: 회사 규모가 작은 경우) 모든 외부 및 내부 작업이 티켓 시스템을 통과하도록 작업을 구성하는 것이 좋습니다.

티켓 시스템은 본질적으로 내부 및 외부 통신을 위한 인터페이스이므로 이 인터페이스를 충분히 자세히 설명해야 합니다.

액세스를 여는 중요하고 일반적인 작업의 예를 들어 보겠습니다. 한 회사에서 완벽하게 작동했던 알고리즘을 설명하겠습니다.

예

액세스하는 고객이 네트워크 엔지니어가 이해할 수 없는 언어, 즉 애플리케이션 언어(예: "1C에 대한 액세스 권한 제공")로 자신의 욕구를 공식화하는 경우가 많다는 사실부터 시작하겠습니다.

따라서 당사는 그러한 사용자로부터 직접 요청을 받은 적이 없습니다.
그리고 그것이 첫 번째 요구 사항이었습니다.

• 액세스 요청은 기술 부서에서 이루어져야 합니다(우리의 경우에는 Unix, Windows, 헬프데스크 엔지니어였습니다).

두 번째 요구 사항은

• 이 액세스는 (이 요청을 받은 기술 부서에 의해) 기록되어야 하며 요청에 따라 기록된 이 액세스에 대한 링크를 받습니다.

이 요청의 형식은 당사가 이해할 수 있어야 합니다.

• 요청에는 프로토콜 및 포트(tcp/udp의 경우)뿐만 아니라 어떤 서브넷 및 어떤 서브넷 액세스를 열어야 하는지에 대한 정보가 포함되어야 합니다.

거기에도 표시해야합니다

• 이 액세스 권한이 열리는 이유에 대한 설명
• 임시 또는 영구(임시인 경우, 언제까지)

그리고 매우 중요한 점은 승인입니다.

• 액세스를 시작한 부서장(예: 회계)
• 이 요청이 네트워크 부서(예: 헬프 데스크)에 전달된 기술 부서 책임자로부터

이 경우 이 액세스의 "소유자"는 액세스를 시작한 부서(이 예에서는 회계)의 책임자로 간주되며 이 부서에 대해 기록된 액세스 권한이 있는 페이지가 최신 상태로 유지되도록 할 책임이 있습니다. .

벌채 반출

이것은 당신이 빠져들 수 있는 것입니다. 그러나 사전 대응적인 접근 방식을 구현하려면 이러한 데이터 홍수에 대처하는 방법을 배워야 합니다.

다음은 몇 가지 실용적인 권장 사항입니다.

• 매일 로그를 검토해야 합니다.
• 긴급 상황이 아닌 계획된 검토의 경우 심각도 수준을 0, 1, 2로 제한하고 필요하다고 판단되면 다른 수준에서 선택한 패턴을 추가할 수 있습니다.
• 로그를 구문 분석하고 무시 목록에 추가한 패턴이 있는 로그를 무시하는 스크립트를 작성합니다.

이 접근 방식을 사용하면 시간이 지남에 따라 관심 없는 로그 무시 목록을 만들고 정말로 중요하다고 생각하는 로그만 남길 수 있습니다.
그것은 우리에게 큰 도움이 되었습니다.

모니터링

회사에 모니터링 시스템이 부족한 것은 드문 일이 아닙니다. 예를 들어 로그에 의존할 수 있지만 아무 것도 "말"할 시간도 없이 장비가 단순히 "죽을" 수도 있고, udp syslog 프로토콜 패킷이 손실되어 도착하지 못할 수도 있습니다. 물론 일반적으로 적극적인 모니터링은 중요하고 필요합니다.

내 실습에서 가장 인기 있는 두 가지 예는 다음과 같습니다.

• 통신 채널, 중요 링크(예: 공급자 연결)의 부하를 모니터링합니다. 이를 통해 트래픽 손실로 인한 서비스 저하 문제를 사전에 확인하고 이를 방지할 수 있습니다.
• NetFlow 기반 그래프. 이를 통해 트래픽에서 이상 징후를 쉽게 찾을 수 있으며 간단하지만 중요한 유형의 해커 공격을 탐지하는 데 매우 유용합니다.

중요한! 가장 중요한 이벤트에 대한 SMS 알림을 설정하세요. 이는 모니터링과 로깅 모두에 적용됩니다. 근무 시간이 아닌 경우 SMS는 근무 시간 외에 도착해야 합니다.

모든 엔지니어가 깨어나지 않도록 프로세스를 고려하십시오. 이를 담당하는 엔지니어가 있었습니다.

변경 제어

제 생각에는 모든 변경 사항을 통제할 필요는 없습니다. 그러나 어떤 경우에도 필요한 경우 네트워크에서 특정 변경을 수행한 사람과 그 이유를 쉽게 찾을 수 있어야 합니다.

몇 가지 팁 :

• 티켓 시스템을 사용하여 해당 티켓에 수행된 작업을 자세히 설명합니다(예: 적용된 구성을 티켓에 복사).
• 네트워크 장비에 댓글 기능을 사용합니다(예: Juniper에 댓글 커밋). 티켓번호를 적어주시면 됩니다
• 구성 백업의 차이점을 사용하십시오.

이를 프로세스로 구현하여 매일 모든 티켓의 변경 사항을 검토할 수 있습니다.

프로세스

팀의 프로세스를 공식화하고 설명해야 합니다. 이 지점에 도달했다면 팀에서 최소한 다음 프로세스가 이미 실행 중이어야 합니다.

일일 프로세스:

• 티켓 작업 중
• 로그 작업
• 변경 제어
• 일일 체크 시트

연간 프로세스:

• 보증, 라이센스 연장

비동기 프로세스:

• 다양한 비상 상황에 대한 대응

첫 번째 부분의 결론

이 모든 것이 아직 네트워크 구성, 설계, 네트워크 프로토콜, 라우팅, 보안에 관한 것이 아니라는 점을 알고 계셨습니까? 그러나 이는 비록 지루할 수도 있지만 물론 네트워크 부서 작업의 매우 중요한 요소입니다.

지금까지 보시다시피 네트워크에서는 아무것도 개선되지 않았습니다. 보안 취약점이 있으면 그대로 남아 있고, 잘못된 설계가 있으면 그대로 남아 있습니다. 네트워크 엔지니어로서 기술과 지식을 적용할 때까지는 많은 시간과 노력, 때로는 돈을 투자했을 것입니다. 하지만 먼저 기초를 만들거나 강화한 다음 건설을 시작해야 합니다.

다음 부분에서는 오류를 찾아서 제거한 다음 인프라를 개선하는 방법을 알려줍니다.

물론 모든 작업을 순차적으로 수행할 필요는 없습니다. 시간이 중요할 수 있습니다. 자원이 허락한다면 병렬로 수행하십시오.

그리고 중요한 추가 사항입니다. 팀과 소통하고, 질문하고, 상담하세요. 결국 이 모든 것을 지지하고 행하는 것은 바로 그들이다.

출처 : habr.com