1C 개발자 이야기: 관리자

모든 1C 개발자는 어떤 방식으로든 IT 서비스 및 시스템 관리자와 직접 상호 작용합니다. 그러나 이러한 상호 작용이 항상 순조롭게 진행되는 것은 아닙니다. 이에 관해 몇 가지 재미있는 이야기를 들려드리고 싶습니다.

고속 통신 채널

우리 고객의 대부분은 대규모 IT 부서를 보유한 대규모 기업입니다. 그리고 고객 전문가는 일반적으로 정보 데이터베이스의 백업 복사본을 담당합니다. 그러나 상대적으로 작은 조직도 있습니다. 특히 그들을 위해 모든 1C 백업과 관련된 모든 문제를 스스로 해결하는 서비스가 있습니다. 이번 이야기에서 이야기할 회사는 바로 이 회사입니다.

새로운 클라이언트가 1C를 지원하기 위해 왔고, 무엇보다도 계약에는 직원 중에 자체 시스템 관리자가 있었지만 백업을 담당한다는 조항이 포함되어 있었습니다. 클라이언트-서버 데이터베이스, MS SQL을 DBMS로 사용합니다. 상당히 표준적인 상황이지만 여전히 한 가지 뉘앙스가 있었습니다. 기본 기반은 상당히 컸지만 월별 증가율은 매우 작았습니다. 즉, 데이터베이스에는 많은 과거 데이터가 포함되어 있었습니다. 이 기능을 고려하여 다음과 같이 백업 유지 관리 계획을 세웠습니다. 매달 첫 번째 토요일에 전체 백업을 했는데 꽤 무거웠고 그런 다음 매일 밤 차등 복사본이 만들어졌습니다. 매 시간마다 트랜잭션 로그를 확인합니다. 또한 전체 및 차등 복사본이 네트워크 리소스에 복사되었을 뿐만 아니라 FTP 서버에도 추가로 업로드되었습니다. 이는 본 서비스를 제공할 때 필수 요구 사항입니다.

이 모든 것이 성공적으로 구성되어 작동되었으며 일반적으로 오류 없이 작동했습니다.

그런데 몇 달 후 이 조직의 시스템 관리자가 바뀌었습니다. 새로운 시스템 관리자는 현대적인 추세에 맞춰 회사의 IT 인프라를 점진적으로 재구축하기 시작했습니다. 특히 가상화, 디스크 선반, 액세스가 모든 곳에서 차단되었으며 일반적인 경우에는 기뻐할 수밖에 없습니다. 하지만 그에게 일이 항상 순조롭게 진행된 것은 아니었고, 1C의 성능에 종종 문제가 있었고, 이로 인해 우리의 지원에 대한 불일치와 오해가 발생했습니다. 또한 그와의 우리 관계는 일반적으로 매우 차갑고 다소 긴장되어 문제가 발생할 경우 긴장의 정도를 증가시킬 뿐이라는 점에 유의해야 합니다.

그러나 어느 날 아침 이 클라이언트의 서버를 사용할 수 없다는 사실이 밝혀졌습니다. 나는 무슨 일이 일어났는지 알아보기 위해 시스템 관리자에게 전화를 걸었고 "우리 서버가 충돌했습니다. 우리는 그 문제를 해결하기 위해 노력하고 있습니다. 귀하에게 달린 것이 아닙니다."와 같은 답변을 받았습니다. 글쎄, 그들이 작동하는 것이 좋습니다. 이는 상황이 통제되고 있음을 의미합니다. 점심 식사 후 다시 전화를 걸자, 관리자의 목소리에서는 짜증보다는 이미 피로감과 냉담함이 느껴진다. 무슨 일이 일어났는지 알아보고 싶은데 저희가 도와드릴 수 있는 게 있나요? 대화 결과 다음과 같은 사실이 드러났습니다.

새롭게 구성된 레이드를 통해 새로운 스토리지 시스템으로 서버를 옮겼습니다. 그러나 문제가 발생하여 며칠 후 이 습격은 무사히 무너졌습니다. 컨트롤러가 소진되었거나 디스크에 문제가 발생했는지 정확히 기억하지 못하지만 모든 정보가 복구 불가능하게 손실되었습니다. 그리고 가장 중요한 점은 백업이 포함된 네트워크 리소스도 다양한 마이그레이션 중에 동일한 디스크 어레이에 있다는 것입니다. 즉, 생산 데이터베이스 자체와 모든 백업 복사본이 모두 손실되었습니다. 그리고 지금 무엇을 해야할지 불분명합니다.

진정하세요. 야간 백업이 있습니다. 이에 대해 침묵이 흘렀고 나는 방금 한 사람의 생명을 구했다는 것을 깨달았습니다. 이 복사본을 새로 배포된 새 서버로 전송하는 방법에 대해 논의하기 시작합니다. 그런데 여기서도 문제가 발생했습니다.

제가 전체 백업의 규모가 꽤 크다고 말한 것을 기억하시나요? 한 달에 한 번 토요일에 한 게 괜히 한 게 아니었습니다. 사실 회사는 도시 외곽에 위치한 작은 공장이었고 인터넷은 매우 평범했습니다. 월요일 아침, 즉 주말 동안 이 사본은 FTP 서버에 거의 업로드되지 않았습니다. 하지만 반대 방향으로 로딩이 되기까지 하루 이틀을 기다릴 여유가 없었다. 파일 전송 시도가 여러 번 실패한 후 관리자는 새 서버에서 직접 하드 드라이브를 꺼내 어딘가에서 운전자가 있는 자동차를 발견하고 신속하게 사무실로 달려갔습니다. 다행히 우리는 여전히 같은 도시에 있습니다.

그들이 우리 서버실에 서서 파일 복사를 기다리고 있는 동안, 우리는 처음으로 만나 '직접' 커피를 마시고 비공식적인 대화를 나눴다. 나는 그의 슬픔에 공감하고, 회사의 중단된 업무를 급히 복구하면서 백업을 잔뜩 챙겨 그를 돌려보냈다.

그 후 IT 부서에 대한 모든 요청은 매우 신속하게 해결되었으며 더 이상 의견 차이가 발생하지 않았습니다.

시스템 관리자에게 문의하세요

한 번은 오랫동안 한 클라이언트에 대해 IIS를 통한 웹 액세스용 1C를 게시할 수 없었습니다. 평범한 작업처럼 보였지만 모든 것을 실행할 수 있는 방법은 없었습니다. 로컬 시스템 관리자가 참여하여 다양한 설정 및 구성 파일을 시도했습니다. 웹상의 1C는 일반적으로 어떤 식으로든 작동하고 싶지 않았습니다. 도메인 보안 정책이나 정교한 로컬 방화벽에 문제가 있거나 다른 문제는 신이 아실 것입니다. N번째 반복에서 관리자는 다음 단어가 포함된 링크를 나에게 보냅니다.

- 이 지침에 따라 다시 시도해 보세요. 거기에는 모든 것이 아주 자세히 설명되어 있습니다. 그래도 작동하지 않으면 이 사이트의 작성자에게 편지를 보내면 도움을 받을 수 있습니다.
“아니요.” 나는 “도움이 되지 않습니다.”라고 말합니다.
- 왜?
— 저는 이 사이트의 작성자입니다... (

그 결과 우리는 아무런 문제 없이 Apache에서 이를 출시했습니다. IIS는 결코 패배하지 않았습니다.

한 단계 더 깊게

소규모 제조 기업이라는 클라이언트가 있었습니다. 그들은 터미널 서버 + 애플리케이션 서버 + 데이터베이스 서버라는 일종의 "클래식" 3 in 1 서버를 보유하고 있었습니다. 그들은 UPP를 기반으로 한 일부 산업별 구성에서 작업했으며 사용자는 약 15-20명이었고 시스템 성능은 원칙적으로 모든 사람에게 적합했습니다.

시간이 지남에 따라 모든 것이 다소 안정적으로 작동했습니다. 그러나 유럽은 러시아에 대해 제재를 가했고 그 결과 러시아인들은 주로 국내에서 생산된 제품을 구매하기 시작했고 이 회사의 사업은 급격한 상승세를 보였습니다. 사용자 수가 50~60명으로 늘어났고, 새로운 지점이 열리면서 문서 흐름도 그에 맞춰 늘어났습니다. 그리고 이제 현재 서버는 더 이상 급격히 증가한 부하에 대처할 수 없었고 1C는 "느리게"되기 시작했습니다. 사용량이 많은 시간대에는 문서 처리가 몇 분씩 걸리고, 차단 오류가 발생하고, 양식을 여는 데 오랜 시간이 걸리는 등 관련 서비스가 전부 발생했습니다. 로컬 시스템 관리자는 “이게 네 1C야, 네가 알아서 할 거야”라고 말하며 모든 문제를 일축했다. 우리는 시스템 성능 감사 실시를 반복적으로 제안했지만 감사 자체에는 도달하지 않았습니다. 고객은 단순히 문제 해결 방법에 대한 권장 사항을 요청했습니다.

글쎄, 나는 앉아서 터미널 서버와 응용 프로그램 서버의 역할을 DBMS로 분리해야 할 필요성에 대해 다소 긴 편지를 썼습니다 (원칙적으로 이전에 이미 여러 번 언급했습니다). 저는 터미널 서버의 DFSS, 공유 메모리에 대해 글을 썼고 신뢰할 수 있는 소스에 대한 링크를 제공했으며 장비에 대한 몇 가지 옵션도 제안했습니다. 이 편지는 회사의 권력자들에게 전달되었고, "구현"이라는 결의안을 가지고 IT 부서로 돌아갔고, 분위기는 전반적으로 깨졌습니다.

얼마 후 관리자는 새 서버의 IP 주소와 로그인 자격 증명을 나에게 보냅니다. 그는 MS SQL 및 1C 서버 구성 요소가 여기에 배포되고 데이터베이스를 전송해야 하지만 1C 키에 일부 문제가 발생했기 때문에 지금은 DBMS 서버로만 전송해야 한다고 말합니다.

제가 들어왔는데, 실제로 모든 서비스가 실행되고 있었고, 서버는 그다지 강력하지 않았지만, 아무것도 없는 것보다는 낫다고 생각합니다. 현재 서버의 부담을 어떻게든 해소하기 위해 일단 데이터베이스를 이전하겠습니다. 합의된 시간에 모든 전송을 완료했지만 상황은 바뀌지 않았습니다. 여전히 동일한 성능 문제가 발생했습니다. 물론 이상합니다. 1C 클러스터에 데이터베이스를 등록하면 살펴 보겠습니다.

며칠이 지나도 열쇠가 전송되지 않았습니다. 문제가 무엇인지 궁금합니다. 모든 것이 간단한 것 같습니다. 한 서버에서 꺼내서 다른 서버에 연결하고 드라이버를 설치하면 완료됩니다. 관리자는 포트 포워딩, 가상 서버 등에 대해 야단법석을 부리며 대답합니다.

흠... 가상서버? 가상화도 없었고 그런 적도 없었던 것 같습니다... Windows Server 1의 Hyper-V에서 2008C 서버 키를 가상 머신에 전달할 수 없다는 꽤 잘 알려진 문제가 기억납니다. 그리고 여기 나에게 어떤 의심이 생기기 시작하는데...

서버 관리자(역할)를 열었습니다. 새로운 역할인 Hyper-V가 나타났습니다. Hyper-V 관리자로 가서 하나의 가상 머신을 보고 연결합니다... 그리고 실제로... 새로운 데이터베이스 서버...

그래서 뭐? 당국의 지시와 나의 권고 사항이 이행되었으며 역할이 분리되었습니다. 작업을 닫을 수 있습니다.

얼마 후 지금의 위기가 발생하여 새 지점을 폐쇄해야 했고 부하가 감소했으며 시스템 성능은 어느 정도 견딜 수 있게 되었습니다.

물론 서버 키를 가상 머신으로 전달할 수는 없었습니다. 결과적으로 물리적 머신의 터미널 서버 + 1C 클러스터, 가상 머신의 데이터베이스 서버 등 모든 것이 그대로 유지되었습니다.

그리고 이것이 일종의 샤라슈킨 사무실이라면 좋을 것 같습니다. 그래서 아니야. 모든 Lentas 및 Auchans의 관련 부서에서 귀하가 알고 있고 본 제품을 보유한 잘 알려진 회사입니다.

하드 드라이브 휴가 일정

세계를 제패하겠다는 야심찬 계획을 가진 대형 지주회사가 거대 기업에 편입시키겠다는 목표로 다시 한 번 작은 기업을 인수했다. 이 보유의 모든 부서에서 사용자는 자신의 데이터베이스에서 작업하지만 동일한 구성을 사용합니다. 그래서 우리는 이 시스템에 새로운 장치를 포함시키기 위한 작은 프로젝트를 시작했습니다.

우선, 프로덕션 및 테스트 데이터베이스를 배포해야 합니다. 개발자는 연결 데이터를 수신하고 서버에 로그인하여 설치된 MS SQL, 1C 서버를 확인하고 2개의 논리 드라이브(250GB 용량의 "C" 드라이브와 1TB 용량의 "D" 드라이브)를 확인합니다. 글쎄, "C"는 시스템이고 "D"는 데이터이며 개발자는 모든 데이터베이스를 논리적으로 결정하고 배포합니다. 만일을 대비해 백업을 포함한 유지 관리 계획도 세웁니다(당사는 이에 대해 책임을 지지 않지만). 사실, 여기 "D"에 백업이 추가되었습니다. 앞으로는 이를 별도의 네트워크 리소스로 재구성할 계획이었습니다.

프로젝트가 시작되고 컨설턴트가 새 시스템에서 작업하는 방법에 대한 교육을 제공하고 남은 부분이 이전되고 약간의 사소한 개선이 이루어졌으며 사용자는 새 정보 기반에서 작업을 시작했습니다.

모든 것이 순조롭게 진행되던 어느 월요일 아침, 데이터베이스 디스크가 없다는 사실이 발견되었습니다. 서버에는 "D"가 없으며 그게 전부입니다.

추가 조사에 따르면 이 "서버"는 실제로 로컬 시스템 관리자의 작업 컴퓨터였습니다. 사실, 여전히 서버 OS가 있었습니다. 이 관리자의 개인 USB 드라이브가 서버에 연결되었습니다. 그래서 관리자는 여행을 위해 영화를 넣을 목적으로 휴가를 떠났습니다.

하느님 감사합니다. 그는 데이터베이스 파일을 삭제하지 못하고 생산 데이터베이스를 복원했습니다.

모든 사람이 일반적으로 USB 드라이브에 있는 시스템의 성능에 만족했다는 점은 주목할 만합니다. 1C의 불만족스러운 성능에 대해 아무도 불평하지 않았습니다. 모든 정보 데이터베이스를 슈퍼 서버, 백만 루블 이상의 스토리지 시스템, 정교한 하이퍼바이저 및 모든 지점의 견딜 수 없는 1C 브레이크를 갖춘 단일 중앙 집중식 사이트로 전송하는 대규모 프로젝트가 지주 회사에서 시작된 것은 나중에였습니다.

그러나 그것은 완전히 다른 이야기입니다 ...

출처 : habr.com