서버 · 인프라 입문
홈 화면만 지켜보면 장애를 놓칩니다
가동 감시를 붙여 두고도 장애를 모르는 경우가 있습니다. 대부분 원인은 하나 — 확인하는 페이지가 데이터베이스를 거치지 않는 페이지이기 때문입니다.
Technote
운영 · 관리자 를 위한 워드프레스 가이드
사이트 운영을 맡은 관리자를 위한 가이드. 업데이트 절차 · 백업 · 장애 대응 · 모니터링을 다룹니다.
글 16편· 운영 · 관리자
개발 워크플로우 입문
이전 전 목록화 — 잊는 것은 사이트 밖에 있습니다
파일과 데이터베이스는 빠뜨리기 어렵습니다. 전환 당일에 사고를 만드는 것은 몇 년 전에 한 번 등록해 두고 잊어버린 사이트 밖의 설정들입니다.
보안 입문
하드닝의 시작은 관리자가 몇 명인지 세는 일입니다
설정으로 문을 몇 개 닫든, 열쇠를 가진 사람이 여덟 명이면 지켜야 할 것도 여덟 개입니다. 역할 점검이 모든 하드닝보다 앞에 옵니다.
서버 · 인프라 입문
장애 첫 5분 — 원인보다 범위를 먼저 확정합니다
사이트가 안 열릴 때 곧바로 원인을 찾기 시작하면 시간을 잃습니다. 범위를 먼저 확정하면 열어 볼 로그가 정해지고 후보가 절반으로 줄어듭니다.
보안 입문
무엇을 백업해야 하나 — 코드 · DB · 업로드는 성질이 다릅니다
"전체 백업" 한 덩어리로만 관리하면 사고가 났을 때 선택지가 하나도 남지 않습니다. 세 덩어리는 바뀌는 속도도, 되돌리는 경로도 다릅니다.
테마 · 플러그인 입문
업데이트가 깨지는 진짜 이유는 코어가 아닙니다
"지난번에 올렸다가 깨져서" 미루고 있다면, 그때 깨진 것이 무엇이었는지 다시 볼 필요가 있습니다. 원인을 바르게 지목하면 다음 업데이트의 준비 방법이 달라집니다.
개발 워크플로우 실무
워드프레스를 GitHub 에 올릴 때의 .gitignore
워드프레스 저장소에서 커밋해야 할 것과 절대 커밋하면 안 되는 것의 경계는 명확합니다. wp-config.php 한 파일이 저장소에 들어가는 순간 DB 비밀번호와 인증 솔트가 통째로 유출됩니다.
성능 최적화 실무
워드프레스 Redis 오브젝트 캐시 — 적용 전에 알아야 할 것과 실측 결과
워드프레스가 느린 원인의 상당수는 페이지를 만들 때마다 같은 데이터베이스 쿼리를 반복하는 데 있습니다. Redis 오브젝트 캐시는 이 반복 쿼리를 메모리에서 꺼내 쓰게 만들어, 특히 관리자…
성능 최적화 심화
Redis 오브젝트 캐시 적중률을 읽는 법 — 90%가 항상 좋은 것은 아니다
적중률 숫자 하나만 보고 캐시가 잘 돌고 있다고 판단하면, 정작 느린 화면은 그대로 남습니다. 어떤 키가 몇 번 조회되는지까지 내려가 봐야 병목이 보입니다.
보안 실무
업로드 디렉터리의 PHP 실행 차단 — 마지막 관문
업로드 취약점은 파일을 올리는 데서 끝나지 않습니다. 올라간 파일이 실행될 때 원격 코드 실행이 됩니다. uploads 에서 PHP 를 못 돌게 하면 그 승격이 끊깁니다.
서버 · 인프라 실무
워드프레스 Docker 스택 구성 — nginx · PHP-FPM · MariaDB · Redis
서비스 네 개를 컨테이너로 가르는 이유는 유행이 아니라 재현성입니다. 다음 서버에서도, 사고 후 복구에서도, 같은 파일이 같은 스택을 다시 세웁니다.
테마 · 플러그인 입문
업데이트가 멈춘 플러그인을 판별하는 기준
마지막 업데이트 날짜 하나로는 방치를 판정할 수 없습니다. 판별 신호 다섯 개를 함께 보고, 대체 불가라면 격리 조건이라도 걸어야 합니다.