발매 전날 기트 창고를 날려버리면

했지만 공식적인 환경은 아니니까 여기서 투고하는 걸 허락해 주세요.
(참회)
배경.
프로젝트 버전 관리는 Giit로 회사 내에서 제공하는 Giitbucket 서비스를 이용했다.
그리고 그 Giitbukcet 서비스는 제공이 끝나면 2021년 9월 말까지 외부 Giit 서비스로 옮겨야 한다.
일반적인 Giit 이전이기 때문에 아래 그림과 같이 기존 Giit를 설계 비용으로 복제하고, Push는 Backlog 서비스의 Giit로 이전한다.

더욱 구체적으로 말하면, 절차는 아래와 같다.

## ローカルにクローン
$git clone --mirror http://[旧gitbucket]/gitbucket/git/hoge/xxxxx.git ./

## Remoteにプッシュ
$git remote set-url --push origin https://[新git]/git/hoge/xxxxxxx.git
$git push --mirror

아무리 생각해도 아주 평범한 Git 창고 이전이니까 편할 것 같아요.
갑자기 "아!"이런 메시지가 왔어요.
드디어 정식 전환의 날이 다가와 전체 통지를 보내자 위탁 담당자가 이동하기 시작했다.
금방 끝날 줄 알았는데 담당자가 다음과 같은 연락을 왔다
이동이 순조롭게 진행되지 않았다.눌렀더니 서류가 너무 커서 실패했어요.
"exceeds file size limit of 100M"이라는 메시지가 있습니다.
나는 창고의 사이즈가 매우 크다고 생각한다.
해결책으로 Shallow Clone을 통해 오래된 역사를 없애고 크기를 줄일 수 있습니다.
"검증 때 일어나지 않았던 현상이지만..."그렇게 생각하면서 앱 개발팀에 연락해'몇 년 전 기트 이력이 사라져도 괜찮다'는 답변을 받았고, 깊이 고민하지 않고 담당자에게'쇼올로 클론 OK'를 의뢰했다.
정오가 지나자 갑자기 담당자로부터 "아!"메시지가 뜨고 다음 연락이 왔습니다.
내가 무슨 이상한 지령을 내렸나 봐...

상황을 확인한 결과 순식간에 머릿속이 하얗게 되었다
이전 Gitbukcet Master 이외의 분기 태그 제출 정보가 모두 손실됨

회복을 위해 노력하다
일반적인 상황에서 고장이 발생할 때 일반적으로 다음과 같은 절차를 고려한다

1. 二次障害の防止
2. 関係者への連絡
3. 現状の把握
4. 復旧手段の検討
5. 復旧実行

1. 2차 고장 방지
우선 2차 고장을 방지하기 위해 전원이 즉시 작업을 중지하고 PUSH·PULL 옛 Giitbukcet을 엄금한다고 통지했다.
2. 관계자에게 연락
이후 AP팀에 전화를 걸어 "나는 지트 창고의 지점을 날려버렸다."이렇게 말하면, "...그래?""내일 밤늦게 정식 발매될 예정이지만 그 지점은 아직 마스터로 통합되지 않았는데..."이런 충격적인 사실을 말했다.
회복하지 않으면 절대 용납되지 않는 사건이 되는거야...
3. 현황 파악
이어서 담당자와 함께 현황을 정리했다

담당자가 오작동을 했다.구체적으로Shallow Clone의 검증으로 미루어 보았던 곳은 구Giitbukcet 창고를remote로 잘못 조작하여 구Giitbukcet로 미루었다.그리고 중간에 문제가 발견돼 집행이 중단됐다.

상기 오류 조작 결과 옛 창고에서 모든タグ・ブランチ・masterブランチ以外のコミット情報이 사라짐

담당자의 로컬 웨어하우스는 일부 지점 정보

만 보유
응.절망적이야...
4. 복원 방법에 대한 연구
마지막 마지막, 다음 복구 퀘스트 결정

이전 Giitbukcet 저장소 백업 여부 찾기

다음 날 GA될 스냅샷을 찾는 사람

현지 창고의 잔해에서 일부 복구 방법 찾기

1시간 뒤에 다시 모여 관련 인원을 공유하는 상황

응용 프로그램 구성원의 "어떻게 된 거야?""장난치지 마세요". "이런 스냅숏은 없어요!"이런 울부짖음을 들으면서 마침내 좋은 소식이 전해졌다.
Jenkins가 일일 단위로 모든 분기 정보를 포함하는 저장소
신이시여...
다행히 오늘은 새로운 PUSH가 없어서 백업 복구 창고를 가지고 갈 수 있습니다!
5. 실행 재개
절대 틀리지 않도록 프로그램을 짜서 댓글을 달아주세요.
이중 검사를 통해 다음과 같이 회복되었다

cd C:\work\[バックアップ]\

$ ブランチ確認
git branch -a

$ push 向け先変更
git remote set-url --push origin http://[旧gitbucket]/gitbucket/git/hoge/xxxxx.git

$ 向け先確認
git remote -v

$ Push実施
git push origin

사건이 왜 일어났는지
보시다시피 교과서처럼 다양한 반대 패턴에 발을 들여놓았다.

절차서 이외의 조작을 했다. 예상된 프로그램이 순조롭지 않은 곳은 작업의 정지가 아니라 다양한 프로그램 이외의 지령을 집행해 보았다.

이중 검사원이 없다: 담당자 혼자 일하게 했다

사건 원인 조사의 단맛: 원인 분석과 최선의 해결 방안을 제대로 고려하지 않고 제안을 받아들였다

복구 단계 없음: 만일의 경우에 대비한 복구 단계를 고려하지 않습니다.

정식적인 환경작업이라면 무조건 묻게 되는 체크리스트.
나는 쉽게 "이것은 지혜로운 사람의 기초 작업이기 때문에..."라고 생각했는데, 이번에는 하나도 제대로 보호하지 못했다.
더 이상 참극이 일어나지 않도록
일반적으로'기술이 약한 사람은 실수하기 쉽다'고 생각하지만, 실제로는 반대로'기술이 강하기 때문에 실수하기 쉽다'고 생각한다.
왜냐면'나는 괜찮아'라는 자신감이다.
하지만 사람은 절대로 실수를 할 수 있다.
기술이 강한 사람은 더 기초적인 곳에서 일할 수 있는 권한이 강하기 때문에 오류가 발생하면 파괴력이 더욱 강해진다.sudo 처음 시작할 때의 영어 정보를 항상 기억해야 합니다.

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

내 생각에는 이번 경우만 다음 재발 방지 대책이 있을 것 같다

단계 기록만 실행

작업 시 반드시 이중 검사

복구 단계 필요

일상적인 백업이 중요

이상은 나의 참회다.장문을 끝까지 읽어 주셔서 감사합니다.