마감과 문서를 명확한 대장으로 관리

문서에 기준과 소유자를 부여

대여마다 한 줄을 만들고, 안정적인 내부 기준과 운영 책임자를 지정하십시오. 업무 요구사항, GPU 모델, 로트, 카드, 기간, Capordia 주문 기준을 추가하십시오. 머신 이름은 바뀔 수 있으므로, 구매와 그 결정권자를 찾는 유일한 수단이 되어서는 안 됩니다.

각 기한마다 다음에 할 일과 담당자를 함께 지정하세요. 결제 확인, 환경 수령, 내보내기 또는 새 기간 결정 등이 여기에 해당합니다. 기대하는 행동이 없는 날짜는 곧 무시되는 알림이 됩니다. 조직에서는 이 기록을 공유 표에서 관리할 수 있습니다. 무엇보다 각 항목과 그 담당자를 정의하세요.

주문, 결제, 제공 구분하기

주문은 선택한 항목과 그 금액을 설명합니다. 결제 의사는 자산, 네트워크, 수신지, 금액, 기한을 명시합니다. 확인된 결제는 수령 여부와 그 배정을 알려줍니다. 제공은 GPU 접근 권한에 관한 것입니다. 이러한 이벤트를 각각 다른 항목에 기록하세요. 일괄적으로 초록색을 칠하면 결제된 주문과 사용 가능한 리소스의 차이가 가려집니다. 각 상태 변경을 정당화하는 날짜와 자료를 보관하세요.

주문 요약은 회계 절차에서 요구하는 자료를 대신하지 못합니다. 직원이 결제했다고 보고했다는 이유로 '완납'을 추가하지 마세요. 환경 버전과 수령 결과를 각각 분리하여 적절한 접근 권한과 함께 보관하세요. 관리 기록에는 데이터셋, 비밀번호 또는 개인 키가 포함될 필요가 없습니다.

서비스 종료 시점을 기준으로 일정 세우기

확인된 제공 시점, 종료 날짜, 내부 결정 날짜를 기입하세요. 내부 결정 날짜에는 처리를 마치고, 결과물을 검증하고, 다음 단계를 준비할 시간이 있어야 합니다. Capordia 기간은 3일, 7일 또는 30일이며 자동 갱신은 없습니다. 프로젝트가 계속된다면 새 주문이 필요합니다. 건 생성 날짜나 결제 신고 날짜는 서비스의 실제 시작 날짜를 대신하지 못합니다.

마지막 필수 작업에서 출발해 일정을 거꾸로 짜세요. 수신지에서 내보내기를 열고, 복사를 수행하고, 결과물을 생성한 다음, 마지막 처리를 시작합니다. 필요한 인원의 작업 시간을 더하세요. 여러 팀이 있는 경우 동일한 종료 날짜에 모든 내보내기 요청이 금요일 저녁에 몰릴 수 있으니 결정을 미리 분산하세요. 다른 부서가 아직 의존하고 있는 날짜를 덮어쓰기보다는 일정 변경 사항을 그 사유와 함께 기록하세요.

가상 예시: 한 기간이 7일 차 18시 UTC에 종료됩니다. 팀은 마지막 계산을 8시간, 내보내기를 2시간, 그 검증을 1시간으로 추산하고, 예상치 못한 상황에 3시간을 배정합니다. 총 필요 시간은 8 + 2 + 1 + 3 = 14시간입니다. 따라서 마지막 시작은 늦어도 4시 UTC에 이루어져야 합니다. 이 소요 시간은 교육용 가정이며 Capordia의 성능이 아닙니다. 사람의 결정은 담당자들이 근무하는 6일 차 16시에 배치합니다.

공통 시간 규칙을 사용하세요. RFC 3339에 명시된 것처럼 UTC 오프셋을 포함한 날짜와 시간을 쓰면 각자 시간대를 추측할 필요가 없습니다. 기록에 현지 시간을 함께 표시할 수도 있지만 기준 값은 유지합니다. 기간 종료가 변경되면 종속된 작업을 다시 계산하기 전에 해당 건에서 확인해야 합니다.

작업을 혼동하지 않고 결제 대사하기

렌탈 결제는 특정 건을 정산합니다. 충전은 결제 서비스 확인 후 잔액을 채우며, 그 입금은 한 번만 기록되고 열려 있는 모든 렌탈을 자동으로 정산하지는 않습니다. 장부에서는 USD로 표시된 주문 금액, 이체 요청, 그리고 해당되는 경우 잔액 사용을 구분하십시오. 「결제했습니다」 버튼은 선택한 의도에 대해 날짜가 기록된 신고를 저장합니다. 재무 추적을 위해서는 건의 확정된 상태를 기준으로 삼으십시오. 신고는 확정된 결제 및 제공과 별개로 남습니다.

Capordia는 KYC 절차나 신분증 없이 암호화폐 결제를 수락합니다. 이름, 성, 이메일은 주문 연락처로 남습니다. 이러한 운영 방식이 건, 그 참조 번호 또는 암호화폐 네트워크의 공개 정보를 삭제하지는 않습니다. 결제 전에 이체를 담당하는 담당자는 표시된 자산, 네트워크, 금액을 확인합니다. 신고 후에는 다른 참여자들이 동일한 건을 따르며, 아직 확인 중인 상태를 없애기 위해 두 번째 이체를 보내지 않습니다.

두 팀 간의 일정 충돌 해결하기

가상 예시를 계속해 봅시다. Atlas는 이 역산 일정에 따라 7일 캠페인을 마치고, Boréal은 30일 프로젝트의 다음 기간을 준비합니다. 같은 담당자가 두 팀의 내보내기를 검증합니다. Atlas가 2시간 지연되고 다른 단계가 예정된 소요 시간을 유지하면 예비 시간은 3시간에서 1시간으로 줄어듭니다. 이 기록은 이 계산을 눈에 보이게 할 뿐 단순히 «지연 가능»이라고 표시하지 않습니다. Boréal은 검증 회의를 옮기며 Atlas의 대여 종료 시점은 변경하지 않습니다.

네 시간 지연되면 한 시간의 예비 시간을 초과하게 됩니다. 그러면 담당자는 마지막 실행 전에 결정해야 합니다. 비즈니스 부서의 동의를 받아 최종 배치를 줄이거나, 독립적인 작업을 앞당기거나, 필요가 이어질 경우 새 주문을 준비하는 것입니다. 이 결정 중 어느 것도 현재 기간을 자동으로 연장하지 않습니다. 구매 담당자, 데이터 책임자, 결제 담당자는 각각 이름과 기한이 있는 별도의 조치를 유지합니다.

다시 확인할 수 있는 마무리 만들기

마무리 시점에 보존된 결과, 회수할 접근 권한, 사용 가능한 문서, 남은 차이를 확인하십시오. 데이터 책임자는 복사본의 목적지를 확인하고, 운영 책임자는 필요의 종료를 확인합니다. 작업이 재현 가능해야 한다면 구성과 재개 절차를 보존하십시오. 학습의 경우 결과 아카이브만으로는 재개에 필요한 상태를 대체하지 못하며, 이 요구 사항은 건과 연결된 기술 프로토콜에서 비롯되어야 합니다.

흔한 오류는 충전을 렌탈 비용으로 계산하거나, 신고를 영수증으로 혼동하거나, 계정 자격 증명을 팀 접근 권한인 것처럼 공유하는 것입니다. 참조 번호는 장부에, 접근 권한은 적절한 도구에 보관하십시오. 기대되는 결과물은 종료된 건 또는 명시적으로 배정된 잔여 작업 목록입니다. 다른 사람이 실행된 계산의 내용을 보지 않고도 결정과 일정을 재구성할 수 있어야 합니다.