낮은 bus factor는 제가 다른 단일 장애점과 똑같이 의도적으로 관리하는 리스크입니다. 오직 한 사람만 배포하거나, 결제 서비스를 디버깅하거나, 레거시 모듈을 만질 수 있다면, 그 팀은 사직이나 휴가 한 번으로 위기에 빠집니다. 목표는 모두를 기어가는 속도로 늦추지 않으면서 지식을 퍼뜨리는 것입니다.
실용적 메커니즘
- 의도를 가진 코드 리뷰. 리뷰는 게이트키핑만이 아니라 지식 전달입니다. 어떤 영역도 그것을 작성한 사람 혼자만 리뷰하지 않도록 합니다.
- 핵심 시스템에서 페어와 로테이션. 전문가가 더 빨리 할 수 있을 때조차 고위험 영역의 작업을 의도적으로 두 번째 사람에게 배정합니다. 단기 비용, 장기 보험.
- 값을 하는 문서화. 아무도 읽지 않는 방대한 위키가 아니라, 하중을 지탱하는 것들: 런북, 아키텍처 결정, "배포하는 법", "X가 깨지면 할 일".
- on-call 로테이션. 모두가 돌아가며 프로덕션을 책임지는 것만큼 운영 지식을 빠르게 퍼뜨리는 것은 없습니다.
- 내부 발표 / 브라운백. 까다로운 서브시스템의 소유자가 팀에게 그것을 설명합니다.
리스크를 찾는 법
- 소유권을 정직하게 매핑합니다: 각 핵심 시스템에 대해 "X가 2주간 자리를 비우면 누가 이걸 처리할 수 있는가?"를 묻습니다. 답이 "아무도"라면, 그것은 표시된 리스크입니다.
- 영웅 패턴을 주시합니다 — 항상 호출되고, 항상 답인 사람. 그것은 강점이 아니라 경고 신호입니다.
함정
- 직업 안정성을 위한 사재기. 어떤 엔지니어(그리고 어떤 매니저)는 없어서는 안 될 존재가 되는 것을 좋아합니다. 저는 이렇게 재구성합니다: 병목이 되는 것은 당신 자신의 승진과 휴가를 막습니다.
- "모두가 모든 것을 한다"로 과잉 교정하기 — 이는 깊이를 파괴합니다. 목표는 단일 장애점이 없는 것이지 전문화가 전혀 없는 것이 아닙니다.
- 문서를 한 번 쓰고 썩게 두기; 낡은 문서는 없는 것보다 나쁩니다.
왜 중요한가
bus factor를 줄이는 것은 질병, 휴가, 사직으로부터 딜리버리를 보호하고, 가장 강한 사람들을 그들만 이해하는 것을 유지보수하느라 갇혀 있는 대신 성장하게 풀어줍니다. 또한 팀을 더 건강하게 만듭니다: 공유된 소유권은 취약한 영웅주의를 이깁니다.