우리는 스스로 확인합니다: 1C 배포 방법 및 관리 방법: 회사 내 문서 흐름 1C

1C에서는 자체 개발을 널리 사용하여 회사 작업을 구성합니다. 특히, "1C: 문서 흐름 8". 이름에서 알 수 있듯이 문서 관리 외에도 현대적인 ECM-메일, 직원 업무 일정, 리소스에 대한 공유 액세스 구성(예: 회의실 예약), 시간 추적, 기업 포럼 등 다양한 기능을 갖춘 시스템(기업 콘텐츠 관리 - 기업 콘텐츠 관리).

1C에서는 천 명 이상의 직원이 문서 관리를 사용합니다. 데이터베이스는 이미 11억 개의 기록을 보유하고 있어 더욱 세심한 관리와 강력한 장비가 필요하다는 의미입니다.

시스템 작동 방식, 데이터베이스 유지 관리 시 직면하는 어려움 및 해결 방법(MS SQL Server를 DBMS로 사용)을 기사에서 알려드리겠습니다.

1C 제품에 대해 처음 읽는 분들을 위해.
1C:Document Flow는 비즈니스 애플리케이션 개발을 위한 프레임워크인 1C:Enterprise 플랫폼을 기반으로 구현된 애플리케이션 솔루션(구성)입니다.

“1C: Document Flow 8”(약어로 DO)을 사용하면 기업의 문서 작업을 자동화할 수 있습니다. 직원 상호작용을 위한 주요 도구 중 하나는 이메일입니다. 메일 외에도 DO는 다음과 같은 다른 문제도 해결합니다.

• 시간 추적
• 직원 부재 추적
• 택배/운송 신청
• 직원 작업 달력
• 서신 등록
• 사원 연락처(주소록)
• 기업포럼
• 방 예약
• 이벤트 기획
• CRM
• 파일을 사용한 공동 작업(파일 버전 저장 포함)
• 기타

문서관리에 들어간다 씬 클라이언트 (네이티브 실행 가능 애플리케이션)(Windows, Linux, macOS, 웹 클라이언트 (브라우저에서) 및 모바일 클라이언트 - 상황에 따라.

그리고 Document Flow에 연결된 다른 제품 덕분에 - 상호작용 시스템 – Document Flow에서 직접 메신저의 기능을 받습니다. – 채팅, 오디오 및 비디오 통화(모바일 클라이언트를 포함하여 특히 중요해진 그룹 통화 포함), 빠른 파일 교환 및 단순화하는 채팅 봇 작성 기능 시스템으로 작업합니다. 다른 메신저와 비교하여 상호 작용 시스템을 사용하는 또 다른 이점은 특정 문서 흐름 개체(문서, 이벤트 등)와 관련된 상황별 토론을 수행할 수 있다는 것입니다. 즉, 상호작용 시스템은 대상 애플리케이션과 긴밀하게 통합되어 있으며 단순한 "별도의 버튼" 역할을 하지 않습니다.

우리 DO의 글자 수는 이미 100억 개를 넘어섰고, DBMS 전체 레코드 수는 11억 개가 넘습니다. 전체적으로 시스템은 거의 30TB의 스토리지를 사용합니다. 데이터베이스 볼륨은 7,5TB이고 공동 작업용 파일은 별도로 저장되며 추가로 21TB를 차지합니다.

보다 구체적인 숫자에 대해 이야기하면 현재 문자와 파일의 수는 다음과 같습니다.

• 발신 이메일 – 14,7만 개.
• 수신 편지 – 85,4만 통.
• 파일 버전 – 70,8만 개.
• 내부 문서 – 30,6.

DO에는 메일과 파일 이상의 기능이 있습니다. 다음은 기타 회계 개체에 대한 수치입니다.

• 회의실 예약 – 52
• 주간 보고서 - 153
• 일일 보고서 - 628
• 승인 비자 – 11
• 들어오는 문서 – 79
• 발신 문서 – 28
• 사용자 작업 달력의 이벤트에 대한 항목 - 168
• 택배 신청 - 21
• 상대방 - 81
• 상대방과의 업무 기록 – 45
• 상대방의 연락인 – 41
• 이벤트 - 10
• 프로젝트 - 6
• 직원 작업 – 245
• 포럼 게시물 - 26
• 채팅 메시지 – 891 095
• 비즈니스 프로세스 - 109. 직원 간의 상호 작용은 승인, 실행, 검토, 등록, 서명 등의 프로세스를 통해 발생합니다. 우리는 프로세스 기간, 주기 수, 참가자 수, 반품 수, 마감일 변경 요청 수를 측정합니다. 그리고 이 정보는 기업에서 어떤 프로세스가 진행되고 있는지 이해하고 직원 협업의 효율성을 높이기 위해 분석하는 데 매우 유용합니다.

이 모든 것을 어떤 장비에서 처리합니까?

이 수치는 엄청난 양의 작업을 나타냅니다. 따라서 우리는 내부 자회사의 요구 사항에 맞게 상당히 생산적인 장비를 할당해야 하는 필요성에 직면했습니다. 현재 특성은 38개 코어, 240GB RAM, 26TB 디스크입니다. 다음은 서버 테이블입니다.


향후에는 장비의 용량을 늘릴 계획입니다.

서버 로드는 어떻게 진행되고 있나요?

네트워크 활동은 우리나 고객에게 문제가 된 적이 없습니다. 일반적으로 약점은 프로세서와 디스크입니다. 모든 사람이 메모리 부족을 처리하는 방법을 이미 알고 있기 때문입니다. 다음은 리소스 모니터의 서버 스크린샷입니다. 이는 끔찍한 로드가 없으며 매우 적당함을 보여줍니다.

예를 들어 아래 스크린샷에서는 CPU 로드가 23%인 SQL 서버를 볼 수 있습니다. 그리고 이것은 매우 좋은 지표입니다(비교를 위해: 부하가 70%에 접근하면 직원은 작업 속도가 상당히 느려지는 것을 관찰할 가능성이 높습니다).

두 번째 스크린샷은 1C:Enterprise 플랫폼이 실행되는 애플리케이션 서버를 보여줍니다. 이는 사용자 세션만 제공합니다. 여기서 프로세서 로드는 38%로 약간 높으며 부드럽고 조용합니다. 약간의 디스크 로딩이 있지만 허용됩니다.

세 번째 스크린샷은 또 다른 1C:Enterprise 서버를 보여줍니다(두 번째 서버이며 클러스터에 두 개가 있습니다). 이전 버전만 사용자에게 서비스를 제공하고 로봇이 이 작업을 수행합니다. 예를 들어, 메일 수신, 문서 전달, 데이터 교환, 권리 계산 등을 수행합니다. 이러한 모든 백그라운드 활동은 대략 90~100개의 백그라운드 작업을 수행합니다. 그리고 이 서버의 로드는 88%로 매우 높습니다. 그러나 이는 사람에게 영향을 미치지 않으며 문서 관리가 수행해야 하는 모든 자동화를 정확하게 구현합니다.

성과를 측정하는 지표는 무엇입니까?

우리는 성과 지표를 측정하고 다양한 지표를 계산하기 위해 자회사에 심각한 하위 시스템을 구축했습니다. 이는 현재 순간과 역사적 관점에서 시스템에서 무슨 일이 일어나고 있는지, 무엇이 악화되고 있는지, 무엇이 좋아지고 있는지를 이해하기 위해 필요합니다. 모니터링 도구(메트릭 및 시간 측정)는 "1C: Document Flow 8"의 표준 제공에 포함되어 있습니다. 측정항목을 구현하는 동안 사용자 정의가 필요하지만 메커니즘 자체는 표준입니다.

측정항목은 특정 시점(예: 평균 메일 배달 시간은 10분)의 다양한 비즈니스 지표를 측정한 것입니다.

측정항목 중 하나는 데이터베이스의 활성 사용자 수를 표시합니다. 하루 평균 1000-1400 개가 있습니다. 그래프는 스크린샷 당시 데이터베이스에 2144명의 활성 사용자가 있었음을 보여줍니다.

그러한 작업이 30개 이상 있으며 목록은 삭제되었습니다.명부

• 로그인
• 로그아웃
• 메일 로드 중
• 객체의 유효성 변경
• 접근 권한 변경
• 프로세스 주제 변경
• 객체의 작업 그룹 변경
• 키트 구성 변경
• 파일 변경
• 파일 가져오기
• 우편으로 보내기
• 파일 이동
• 작업 리디렉션
• 전자 서명 서명
• 세부정보로 검색
• 전체 텍스트 검색
• 파일 수신
• 프로세스 중단
• Просмотр
• 암호 해독
• 문서등록
• 스캔
• 삭제 표시 해제 중
• 객체 생성
• 디스크에 저장
• 프로세스의 시작
• 사용자 로그 항목 삭제
• 전자 서명 제거
• 삭제 표시 설정
• 암호화
• 폴더 내보내기

지난 주에 우리의 평균 사용자 활동은 3배 증가했습니다(그래프에서 빨간색으로 표시). 이는 대부분의 직원이 원격 근무로 전환했기 때문입니다(잘 알려진 사건으로 인해). 또한 직원들이 휴대폰을 적극적으로 사용하기 시작하면서 활성 사용자 수가 2배 증가했습니다(스크린샷에 파란색으로 표시). 각 모바일 클라이언트는 서버에 대한 연결을 생성합니다. 현재 평균적으로 각 직원은 서버에 XNUMX개의 연결을 가지고 있습니다.

관리자로서 우리에게 이는 성능 문제에 더 주의를 기울이고 상황이 더 악화되었는지 확인해야 한다는 신호입니다. 그러나 우리는 다른 매개변수를 기반으로 이를 살펴봅니다. 예를 들어 내부 라우팅의 메일 배달 시간이 어떻게 변경되는지(아래 스크린샷에서 파란색으로 표시) 올해까지는 변동이 있었지만 이제는 안정적입니다. 우리에게 이는 모든 것이 시스템에 문제가 없다는 지표입니다.

우리에게 적용되는 또 다른 지표는 메일 서버에서 편지를 다운로드하기 위한 평균 대기 시간입니다(스크린샷에 빨간색으로 표시됨). 대략적으로 말하면, 편지가 우리 직원에게 전달되기까지 얼마나 오랫동안 인터넷에 떠돌게 될까요? 스크린샷을 보면 이번에도 최근 어떤 식으로든 변경되지 않았음을 알 수 있습니다. 격리된 스파이크가 있지만 지연과 관련이 없지만 메일 서버의 시간이 손실된다는 사실과 관련이 있습니다.

또는 예를 들어 다른 측정항목(스크린샷에 파란색으로 표시됨) – 폴더의 문자 업데이트. 메일 폴더를 여는 것은 매우 일반적인 작업이므로 신속하게 수행해야 합니다. 우리는 그것이 얼마나 빨리 수행되는지 측정합니다. 이 지표는 각 클라이언트에 대해 측정됩니다. 회사의 전반적인 그림과 개별 직원의 역학 관계를 모두 볼 수 있습니다. 스크린샷은 올해까지 지표가 불균형했다는 것을 보여줍니다. 그 후 우리는 여러 가지 개선을 했고 이제는 더 악화되지 않고 그래프가 거의 평평해졌습니다.

메트릭은 기본적으로 시스템 동작의 변경 사항에 신속하게 대응하기 위해 시스템을 모니터링하는 관리자의 도구입니다. 스크린샷은 해당 연도의 내부 자회사 측정항목을 보여줍니다. 그래프의 급격한 상승은 내부 자회사 개발 작업이 우리에게 주어졌기 때문입니다.

다음은 몇 가지 추가 측정항목 목록입니다(컷 아래).
측정항목

• 사용자 활동
• 활성 사용자
• 활성 프로세스
• 파일 수
• 파일 크기(MB)
• 문서 수
• 수신자에게 보낼 객체 수
• 거래상대방 수
• 완료되지 않은 작업
• 지난 10분 동안 메일 서버에서 이메일을 다운로드하기 위한 평균 대기 시간
• 외부 데이터 버퍼: 파일 수
• 현재 날짜로부터 지연되는 국경
• 긴 대기열
• 운영 대기열
• 외부 라우팅에 따른 원시 계정 연령
• 내부 라우팅 수락 대기열 크기(긴 대기열)
• 내부 라우팅 수락 대기열 크기(빠른 대기열)
• 내부 라우팅을 통한 메일 배달 시간(긴 대기열)
• 내부 라우팅을 통한 메일 배달 시간(빠른 대기열)
• 외부 라우팅을 통한 메일 배달 시간(평균)
• 서류 수 예약
• 서류 수 부재
• 문서 수 "상대방과의 업무 기록"
• 폴더 안의 메일 업데이트 편지
• 메일 레터카드 개봉
• 메일 편지를 폴더로 전송
• 메일 폴더 간 이동

우리 시스템은 150시간 내내 XNUMX개 이상의 지표를 측정하지만 모든 지표를 신속하게 모니터링할 수는 없습니다. 이는 나중에 역사적 관점에서 유용할 수 있으며 비즈니스에 가장 중요한 것에 집중할 수 있습니다.

예를 들어 구현 중 하나에서는 5개의 지표만 선택되었습니다. 고객은 최소한의 지표 세트를 생성하는 동시에 주요 작업 시나리오를 포괄하는 목표를 설정했습니다. 승인 인증서에 150개의 지표를 포함하는 것은 정당하지 않습니다. 왜냐하면 기업 내에서도 어떤 지표가 수용 가능한 것으로 간주되는지에 대한 합의가 어렵기 때문입니다. 그리고 그들은 이 5가지 지표에 대해 알고 있었고 구현 프로젝트가 시작되기 전에 대회 문서에 포함된 지표를 이미 시스템에 제시했습니다. 카드를 여는 데 걸리는 시간은 3초 이내, 파일로 작업을 완료하는 데 걸리는 시간 5초 이상 등 우리 자회사에는 고객의 기술 사양에 대한 원래 요청을 매우 명확하게 반영하는 측정 기준이 있었습니다.

또한 성능 측정에 대한 프로필 분석도 있습니다. 성능 지표는 진행 중인 각 작업(데이터베이스에 편지 쓰기, 메일 서버에 편지 보내기 등)의 기간을 기록합니다. 이는 기술자만이 사용합니다. 우리는 프로그램에 많은 성과 지표를 축적합니다. 현재 약 1500개의 주요 작업을 측정하고 있으며 이를 프로파일로 구분합니다.

우리에게 가장 중요한 프로필 중 하나는 "소비자 관점에서 본 메일의 주요 지표 목록"입니다. 이 프로필에는 예를 들어 다음 지표가 포함됩니다.

• 명령 실행: 태그로 선택
• 양식 열기: 목록 양식
• 명령 실행: 폴더별로 선택
• 읽기 영역에 문자 표시
• 즐겨찾는 폴더에 편지 저장하기
• 세부정보로 문자 검색
• 편지 만들기

일부 비즈니스 지표에 대한 측정항목이 너무 커진 경우(예: 특정 사용자의 편지가 매우 오랫동안 도착하기 시작함) 이를 파악하고 기술 작업 시간을 측정하기 시작합니다. 우리는 "메일 서버에 편지 보관"이라는 기술적 작업을 수행하고 있습니다. 이 작업이 마지막 기간의 제한 시간을 초과한 것으로 나타났습니다. 이 작업은 차례로 다른 작업(예: 메일 서버와의 연결 설정)으로 분해됩니다. 어떤 이유로 갑자기 매우 커졌음을 알 수 있습니다. (우리는 한 달 동안의 모든 측정값을 가지고 있습니다. 지난주에는 10밀리초였고 지금은 1000밀리초입니다.) 그리고 우리는 여기에 뭔가 문제가 있다는 것을 알고 있습니다. 우리는 그것을 고쳐야 합니다.

이렇게 큰 데이터베이스를 어떻게 유지합니까?

우리 내부 DO는 실제로 작동하는 고부하 프로젝트의 예입니다. 데이터베이스의 기술적 특징에 대해 이야기해 보겠습니다.

대규모 데이터베이스 테이블을 재구성하는 데 시간이 얼마나 걸리나요?

SQL Server에는 테이블을 정리하는 주기적인 유지 관리가 필요합니다. 좋은 의미에서는 이 작업을 하루에 한 번 이상 수행해야 하며, 수요가 많은 테이블의 경우 더 자주 수행해야 합니다. 그러나 데이터베이스가 크고(기록 수가 이미 11억 개를 초과한 경우) 이를 관리하는 것은 쉽지 않습니다.

우리는 6년 전에 테이블을 재구성했지만 시간이 너무 많이 걸리기 시작하여 더 이상 야간 간격을 맞출 수 없게 되었습니다. 그리고 이러한 작업은 SQL Server에 과도한 부하를 주기 때문에 다른 사용자에게 효율적으로 서비스를 제공할 수 없습니다.

그러므로 이제 우리는 다양한 트릭을 사용해야 합니다. 예를 들어, 완전한 데이터 세트에 대해서는 이러한 절차를 수행할 수 없습니다. 샘플 500000개 행 업데이트 절차를 따라야 합니다. 이 작업에는 14분이 소요됩니다. 테이블의 모든 데이터에 대한 통계를 업데이트하지는 않지만 XNUMX만 개의 행을 선택하고 이를 사용하여 전체 테이블에 사용되는 통계를 계산합니다. 이는 일부 가정이지만 특정 테이블의 경우 전체 XNUMX억 개의 레코드에 대한 통계를 수집하는 데 시간이 너무 오래 걸리기 때문에 강제로 그렇게 해야 합니다.

또한 다른 유지 관리 작업을 부분적으로 만들어 최적화했습니다.

DBMS를 유지 관리하는 것은 일반적으로 복잡한 작업입니다. 직원 간의 활발한 상호 작용의 경우 데이터베이스가 빠르게 증가하고 관리자가 통계 업데이트, 조각 모음, 인덱싱 등을 유지 관리하기가 점점 더 어려워집니다. 여기에서 우리는 다양한 전략을 적용해야 합니다. 우리는 이를 수행하는 방법을 잘 알고 있으며 경험이 있고 이를 공유할 수 있습니다.

이러한 볼륨에 대한 백업은 어떻게 구현됩니까?

전체 DBMS 백업은 하루에 한 번 밤에 매시간 증분 백업으로 수행됩니다. 또한 매일 파일 디렉터리가 생성되며 이는 파일 저장소의 증분 백업의 일부입니다.

전체 백업을 완료하는 데 시간이 얼마나 걸리나요?

하드 드라이브에 대한 전체 백업은 20시간 안에 완료되고, 부분 백업은 XNUMX시간 안에 완료됩니다. 테이프(사무실 외부에 보관된 특수 카세트에 백업 사본을 만드는 특수 장치, 전송 가능한 사본이 테이프에 만들어지며, 예를 들어 서버실이 소실되는 경우 보존됨)에 기록하는 데 시간이 더 오래 걸립니다. 백업은 매개변수가 더 높은 정확히 동일한 서버(프로세서 부하가 XNUMX%인 SQL 서버)에서 수행됩니다. 물론 백업 시에는 시스템이 훨씬 악화되지만 여전히 작동합니다.

중복 제거 기능이 있나요?

중복 제거 파일이 있습니다. 우리가 직접 테스트해 보고 곧 새 버전의 문서 관리에 포함될 예정입니다. 우리는 또한 상대방 중복 제거 메커니즘을 테스트하고 있습니다. DBMS 수준에서는 레코드 중복 제거가 필요하지 않으므로 중복 제거가 없습니다. 1C:Enterprise 플랫폼은 객체를 DBMS에 저장하며 플랫폼만이 일관성을 책임질 수 있습니다.

읽기 전용 노드가 있습니까?

읽기 노드(읽기 위해 데이터를 수신해야 하는 사람들에게 서비스를 제공하는 전용 시스템 노드)가 없습니다. DO는 별도의 BI 노드를 두는 회계 시스템이 아니고, 개발부서용으로 별도의 노드가 있고, JSON 형식으로 메시지를 교환하며, 일반적인 복제 시간은 단위와 수십초이다. 노드는 여전히 작으며 약 800억 개의 레코드를 보유하고 있지만 빠르게 성장하고 있습니다.

삭제 표시된 이메일은 전혀 삭제되지 않나요?

아직 아님. 우리는 베이스를 더 가볍게 만드는 임무를 갖고 있지 않습니다. 2009년을 포함하여 삭제 표시된 편지를 참조해야 하는 다소 심각한 사례가 여러 차례 있었습니다. 그래서 우리는 지금은 모든 것을 유지하기로 결정했습니다. 하지만 이에 대한 비용이 부당해지면 제거를 고려하게 됩니다. 그러나 흔적이 없도록 데이터베이스에서 별도의 문자를 완전히 제거해야 하는 경우 특별 요청을 통해 이를 수행할 수 있습니다.

왜 저장하나요? 오래된 문서에 대한 접근 통계가 있나요?

통계가 없습니다. 보다 정확하게는 사용자 로그 형태로 되어 있으나 장기간 저장되지는 ​​않습니다. XNUMX년이 넘은 항목은 프로토콜에서 삭제됩니다.

XNUMX년, 심지어 XNUMX년 전의 오래된 서신을 검색해야 하는 상황이 있었습니다. 그리고 이것은 항상 헛된 호기심이 아니라 복잡한 비즈니스 결정을 내리기 위해 수행되었습니다. 통신 이력이 없었다면 잘못된 사업 결정이 내려졌을 경우가 있었습니다.

보관기간에 따라 문서의 가치는 어떻게 평가되고 파기되나요?

종이 문서의 경우 이는 다른 모든 사람들과 마찬가지로 일반적인 전통적인 방식으로 수행됩니다. 우리는 전자 제품을 위해 이 작업을 수행하지 않습니다. 전자 제품을 스스로 보관하도록 하십시오. 자리는 여기입니다. 이점이 있습니다. 모두 괜찮습니다.

어떤 개발 전망이 있나요?

이제 DO는 약 30가지 내부 문제를 해결하며 그 중 일부는 기사 시작 부분에 나열되어 있습니다. DL은 또한 파트너를 위해 일년에 두 번 개최하는 컨퍼런스(전체 프로그램, 모든 보고서, 모든 병렬 섹션, 홀)를 준비하는 데 사용됩니다. 이 모든 것은 DL에 입력된 다음 다운로드되고 인쇄된 프로그램입니다. 만들어진다.

이미 해결 중인 작업 외에도 DO를 진행하는 동안 몇 가지 작업이 더 남아 있습니다. 전사적인 업무도 있고, 특정 부서에만 필요한 독특하고 희귀한 업무도 있습니다. 이는 1C 내에서 시스템 사용의 "지리"를 확장하여 적용 범위를 확장하고 모든 부서의 문제를 해결하는 것을 의미합니다. 이는 성능과 신뢰성에 대한 최고의 테스트가 될 것입니다. 저는 시스템이 수조 개의 기록, 페타바이트 규모의 정보에 대해 작동하는 것을 보고 싶습니다.

출처 : habr.com