测验：只读排查与可证明的回滚

조사 중에 설정값 하나를 잠깐 바꿔 보았다. 가장 큰 문제는?

• 변경 이력이 남지 않아 고객사 감사 절차를 통과하지 못하게 된다
• 그 뒤로 보이는 값이 원래 값인지 우리가 만든 값인지 가릴 수 없게 된다
• 설정 파일의 수정 시각이 바뀌어 다른 도구의 캐시가 무효화된다
• 같은 파일을 고객 운영팀이 동시에 편집하면 변경이 충돌한다

바꾸기 전에 스냅샷을 뜨지 않고 바꾼 뒤에 떴다. 어떤 일이 벌어지는가?

• 스냅샷 파일이 커져 되돌림 검증이 느려진다
• 되돌릴 때 원래 권한을 알 수 없어 파일을 읽을 수 없게 된다
• 수정 시각이 이미 바뀐 뒤라 mtime 비교가 항상 같게 나온다
• 되돌린 뒤 견줄 기준이 바뀐 상태이므로, 되돌렸다는 것을 증명할 수단이 사라진다

되돌린 뒤 스냅샷과 견주었더니 내용과 크기와 권한은 같은데 수정 시각만 달랐다. 옳은 대응은?

• touch 로 시각까지 원래대로 맞춰 스냅샷과 완전히 같게 만든다
• 내용이 같으므로 차이가 없는 것으로 보고 결과에서 뺀다
• 내용은 같고 수정 시각만 달라졌다고 보고서에 그대로 적는다
• 되돌림이 실패한 것으로 보고 파일을 백업본으로 덮어쓴다

스냅샷 비교 도구에서 수정 시각만 다른 파일을 '변경됨' 으로 분류하면 무엇이 문제인가?

• 비교 결과가 늘 변경으로 가득 차, 진짜 내용 변경이 눈에 띄지 않게 된다
• 수정 시각은 파일 시스템마다 정밀도가 달라 비교 자체가 불가능해진다
• 변경 목록이 길어져 JSON 파일 크기가 커지고 처리 시간이 늘어난다
• 수정 시각을 비교에 넣으면 같은 파일을 두 번 세게 되어 합계가 어긋난다

되돌리는 명령을 변경을 적용한 뒤에 적으려고 한다. 이것을 권하지 않는 이유는?

• 적용 뒤에는 파일이 잠겨 원래 값을 읽을 수 없기 때문이다
• 적용 명령과 되돌림 명령을 한 파일에 적으면 순서가 뒤바뀌기 쉽기 때문이다
• 되돌림 명령은 승인 절차상 변경 전에 제출하도록 정해져 있기 때문이다
• 원래 값을 기억에 의존하게 되는데, 30분 뒤에는 3이었는지 30이었는지가 흐려지기 때문이다

답을 얻은 명령을 함께 기록하게 하는 이유로 가장 알맞은 것은?

• 같은 조사를 다음에 다시 할 때 명령을 복사해 시간을 아낄 수 있기 때문이다
• 적어 놓고 보면 그중에 쓰기가 섞여 있는지가 드러나, 읽기만 했다는 기억에 기대지 않게 되기 때문이다
• 고객이 우리가 접속한 시각을 확인할 때 대조할 자료가 되기 때문이다
• 명령을 남겨야 조사 비용을 시간 단위로 청구할 근거가 생기기 때문이다