docs: correct the places where documents contradicted their own evidence
An independent audit found ten documents printing values their evidence files do not contain. C-1 printed a session count of 0 where the evidence says 4, C-2 printed a success readback for a command that exited 1, and A-1 credited the conntrack flush with a split that the timestamps attribute to a pod restart four seconds earlier. Also measured wal_writer_delay, which A-3 had asserted as matching without ever querying it, relabelled the A-6 control that moved 41 percent, noted A-8's nine-sample resolution, corrected D-1's RTO to the 41 seconds its own timeline shows, and added a correction banner to D-2. Every experiment document now links its evidence files with their real collection times, and the duplicate screenshots are documented as duplicates. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
78b270559c
commit
e0d27d47ce
@@ -0,0 +1,9 @@
|
||||
=== A-3 이 가정만 하고 재지 않은 값 ===
|
||||
name | setting | unit | source
|
||||
------------------------+---------+------+---------
|
||||
commit_delay | 0 | | default
|
||||
synchronous_commit | on | | default
|
||||
wal_writer_delay | 200 | ms | default
|
||||
wal_writer_flush_after | 128 | 8kB | default
|
||||
(4 rows)
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
# 주의 — 이 파일은 원 실험 시점에 0바이트로 저장됐다.
|
||||
# 리다이렉션이 stdout 만 받았는데 출력이 stderr 로 갔거나 tee 앞 파이프가
|
||||
# 비어 있었던 것으로 보인다. README 는 그 사이 파일 내용을 서술하고 있었는데,
|
||||
# 그것은 화면에서 본 것을 적은 것이지 이 파일에서 온 것이 아니었다.
|
||||
#
|
||||
# 아래는 사후에 다시 수집한 것이며, 원 시점의 DROP 규칙(0 패킷)은 이미
|
||||
# 제거되어 재현되지 않는다. 구조적 사실(kube-router 가 자기 체인을 FORWARD
|
||||
# 최상단에 유지한다)만 확인할 수 있다.
|
||||
# 원 실험의 결정적 증거는 04-correct-direction.txt 의 패킷 카운터 19/21 이다.
|
||||
|
||||
=== A-5 재수집 — filter 테이블 규칙이 CNI 체인에 밀리는 것 ===
|
||||
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
|
||||
num pkts bytes target prot opt in out source destination
|
||||
1 1690 3386K KUBE-ROUTER-FORWARD 0 -- * * 0.0.0.0/0 0.0.0.0/0 /* kube-router netpol - TEMCG2JMHZYE7H7T */
|
||||
2 7 612 KUBE-PROXY-FIREWALL 0 -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW /* kubernetes load balancer firewall */
|
||||
3 40 13196 KUBE-FORWARD 0 -- * * 0.0.0.0/0 0.0.0.0/0 /* kubernetes forwarding rules */
|
||||
|
||||
(원 실험 시점의 규칙은 이미 제거됐다. 아래는 kube-router 가 자기 체인을
|
||||
FORWARD 최상단에 유지한다는 구조적 사실만 보여준다 — 그것이 실패 원인이었다.)
|
||||
|
||||
@@ -16,3 +16,10 @@
|
||||
1. **세션은 옮겨졌고 토큰은 안 옮겨졌다.** 빈 81개가 늘었는데 authorized client 관련은 하나도 안 바뀌었다.
|
||||
2. **refresh token 은 Redis 에 평문으로 있는 게 아니라 아예 없다.** 암호화를 고민하기 전에 이걸 알아야 한다.
|
||||
3. **"로그인은 되어 있는데 아무것도 못 하는" 상태가 만들어진다** — 완전 로그아웃보다 나쁘다.
|
||||
|
||||
## 스크린샷 주의
|
||||
|
||||
`b1-login-works-two-replicas.png` 과 `b1-token-boundary-after-redis.png` 는
|
||||
**동일 파일**이며 `b2-before-relogin.png` 와도 같다 (md5 `6de826a7…`).
|
||||
세 시점 모두 `accessTokenStoredOnServer: false` 인 같은 화면이었다.
|
||||
**시점 구별은 터미널 출력과 Redis/DB 조회가 한다.**
|
||||
|
||||
@@ -19,3 +19,14 @@
|
||||
2. **refresh token 은 평문이다.** DB 읽기 권한이면 작동하는 토큰을 얻는다.
|
||||
3. **같은 사용자의 두 번째 로그인이 첫 번째를 덮어쓴다.** 기본키에 session id 가 없어 구조적으로 그렇다.
|
||||
4. **로그아웃은 셋 중 하나만 지운다.** 평문 토큰과 Keycloak SSO 세션이 남는다.
|
||||
|
||||
## 스크린샷 주의
|
||||
|
||||
`b2-tokens-shared-across-instances.png` 는 **B-0 의
|
||||
`b0-bff-token-boundary.png` 와 동일 파일**이다 (md5 `9ed00537…`).
|
||||
두 시점 모두 `accessTokenStoredOnServer: true` 인 같은 화면이라 바이트가 같다.
|
||||
|
||||
**그래서 이 png 는 "JDBC 전환으로 토큰이 공유된다" 를 단독으로 증명하지
|
||||
못한다.** 그 증명은 `01-jdbc-store-deploy.txt`(테이블 생성)과
|
||||
`03-plaintext-tokens.txt`(행에 토큰이 들어 있음)가 한다.
|
||||
`b2-before-relogin.png` 는 B-1 의 캡처와 동일 파일이다.
|
||||
|
||||
@@ -17,3 +17,11 @@
|
||||
1. **SSO 는 user session 1개에 client session N개** 구조다 — A-3(전체 소실)과 B-3(client 만 제거)의 차이가 여기서 의미를 갖는다.
|
||||
2. **IdP 세션을 죽여도 두 앱은 계속 동작한다.** 세 층(IdP·앱·토큰)의 수명이 각자이기 때문이다.
|
||||
3. **IdP 는 "로그인 경로"의 단일 장애점이지 "이미 로그인한 사용자"의 단일 장애점이 아니다.** 장애는 앱 세션 수명만큼 지연되어 몰려온다.
|
||||
|
||||
## 스크린샷 주의
|
||||
|
||||
`c1-sso-app2-no-login-screen.png` 과 `c1-apps-alive-after-idp-logout.png` 는
|
||||
**바이트 단위로 동일한 파일**이다 (md5 `2c703176…`). 두 시점의 화면이 실제로
|
||||
같은 내용이었기 때문이며, 조작이 아니다. **다만 그래서 두 시점을 구별하는
|
||||
증거가 되지 못한다** — 구별은 `03-` 과 `04-` 의 터미널 출력(client_sessions
|
||||
1→2, 그리고 IdP 세션 삭제 후 Redis 키 잔존)이 한다.
|
||||
|
||||
@@ -7,10 +7,11 @@
|
||||
|---|---|
|
||||
| `01-pre-upgrade.txt` | 백업 396KB · 이미지 26.7.0 · **마이그레이션 210건** · 세션 4 |
|
||||
| `02-rollback-attempt.txt` | 26.0 으로 내리자 `Running(0/1) → Error → CrashLoopBackOff`. **`liquibase.exception.ValidationFailedException`** |
|
||||
| `d2-upgrade-window.png` | Grafana — 26.7.3 업그레이드 구간의 `cluster_size` 2→1→2 두 번과 파드별 `up` 시계열 교체 (후속 작업에서 촬영) |
|
||||
| `03-roll-forward.txt` | **서비스는 `HTTP 200` 유지**(ready 주소 1개) · 오류 원인 `1 changesets check sum` · 26.7.0 복귀 후 마이그레이션 210·세션 4 그대로 |
|
||||
|
||||
## 핵심 세 줄
|
||||
|
||||
1. **롤백은 안 된다.** 체크섬이 안 맞아 Liquibase 가 기동 자체를 거부한다 — "모르는 변경"이 아니라 "아는 변경인데 정의가 다르다".
|
||||
1. **스키마가 바뀌었으면 롤백은 안 된다.** (26.7.0↔26.7.3 처럼 안 바뀌면 된다 — [`followup`](../followup/) 참조.) 체크섬이 안 맞아 Liquibase 가 기동 자체를 거부한다 — "모르는 변경"이 아니라 "아는 변경인데 정의가 다르다".
|
||||
2. **StatefulSet 이 사고를 절반에서 멈춰줬다.** 한 파드가 남아 외부 200 을 유지했다. replica 1 이었다면 전면 장애다.
|
||||
3. **실패한 기동은 스키마를 안 건드렸다.** 그래서 이미지만 되돌려도 복구됐다 — 이미 적용된 뒤였다면 DB 복구(D-1)가 필요하다.
|
||||
|
||||
Reference in New Issue
Block a user