리눅스에 익숙하다고 생각했는데, 프로덕션 환경에서 뒤집어질 줄은 꿈에도 몰랐네요...-리눅스 운영 및 유지 관리-php.cn

저는 수년간 운영 및 유지 관리에 종사해 왔으며 데이터 손실, 웹 사이트 오작동, 실수로 데이터베이스 파일 삭제, 해커 공격 및 기타 문제와 같은 다양한 문제에 직면했습니다. 리눅스 시스템에 익숙하다고 생각하는 친구들도 많이 만났는데, 문제를 봤을 때 전혀 당황하지 않고 자신감에 차 있었는데, 제작 환경이 뒤집어지는(거의 해고될 뻔한) 명장면이 셀 수 없이 많았습니다. . . 그래서 오늘은 좋은 리눅스 운영 습관 몇 가지를 간단하게 정리해서 여러분께 공유해 드리겠습니다. 안전하게 운행하고

전복되는 일이 없도록 하세요! !

리눅스에 익숙하다고 생각했는데, 프로덕션 환경에서 뒤집어질 줄은 꿈에도 몰랐네요... 온라인 운영 사양

사용 테스트

처음 Linux 사용법을 배울 때 기본부터 서비스, 클러스터까지 모두 가상 머신에서 했지만 선생님은 그렇게 하라고 하셨습니다. 실제 머신과 다르지 않았지만, 실제 환경에 대한 욕구는 나날이 커지고 있지만, 가상 머신의 다양한 스냅샷으로 인해 우리는 온갖 서투른 습관을 갖게 되었고, 그래서 우리가 작동 허가를 받았을 때 출근 첫날을 기억해 보세요. 어느 날 사장님이 퍼티만 사용할 수 있어서 xshell을 사용하고 싶어서 조용히 서버에 로그인을 했는데요. xshell+key 로그인으로 변경하려고 했는데 테스트도 안하고 ssh 연결도 남아있지 않아서 sshd 서버를 다시 시작했는데 다행히 그 때 sshd_config 파일을 백업해 두었습니다. 나중에 전산실 직원에게 CP를 요청했는데 다행히 규모가 작은 회사였으면 직접 죽였을 텐데... 다행히 그때는 운이 더 좋았습니다.

두 번째 예는 파일 동기화에 관한 것입니다. rsync가 동기화가 빠르다는 것은 누구나 알고 있지만 파일 삭제 속도는 rm -rf보다 훨씬 빠릅니다. rsync에는 특정 디렉터리를 기반으로 특정 파일을 동기화하는 명령이 있습니다. 첫 번째 디렉터리가 비어 있으면 결과를 상상할 수 있습니다. 처음에는 오작동과 테스트 부족으로 인해 디렉터리를 거꾸로 썼습니다. ..운영 환경 데이터가 삭제되고 백업되지 않았습니다. 그 결과는 스스로 생각해 볼 수 있습니다.

Enter하기 전에 몇 번이고 확인하세요

rm -rf / var 오류에 대해서는 손이 빠른 사람이나 인터넷 속도가 상대적으로 느린 경우 발생할 확률이 상당히 높다고 생각합니다. 처형이 끝나면 마음은 적어도 절반은 차가워질 것입니다. 여러번 눌렀을 때 오류 하나도 없었다고 말씀하실 수도 있으니, 한 번만 발생하면 이해해 주실 거라 말씀드리고 싶습니다. 주의를 기울이지 않으면 다음 일이 일어날 것입니다.

여러 사람이 운영하는 것을 허용하지 마세요

저번에 근무했던 회사에서는 운영 및 유지 관리가 상당히 혼란스러웠습니다. 가장 일반적인 예를 들자면, 여러 번 퇴사한 운영 및 유지 관리 담당자가 서버 루트 비밀번호를 가지고 있었습니다. . 보통 운영이나 유지보수 업무를 맡게 되면 간단한 점검을 하고, 해결이 안 되면 다른 사람에게 도움을 요청하지만, 문제가 너무 심할 때는 고객 서비스 담당자(Linux를 어느 정도 아는 사람), 네트워크 관리자와 함께 서버를 디버깅할 것입니다. 다양한 비교 끝에 서버 구성 파일이 마지막으로 수정했을 때와 다르다는 것을 발견했습니다. 그런 다음 다시 Google에서 문제를 발견했습니다. 해결했는데 다른 분들도 해결하셨다고 하네요.. 수정된 부분이 다른 매개변수인데... 이게 진짜 문제의 원인인지는 잘 모르겠습니다. 문제는 해결되고 모두가 기뻐합니다. 하지만 방금 수정한 파일을 발견했다면 테스트가 유효하지 않은 것입니다. 그러면 수정하러 가서 파일이 다시 수정된 것을 발견하면 어떻게 될까요? 여러 사람에 의해 이루어졌습니다.

백업을 먼저 하고 운영하세요

데이터를 수정하고 싶을 때에는 .conf 구성 파일 등을 먼저 백업해 두세요. 또한 구성 파일을 수정할 때 원래 옵션을 주석 처리한 후 복사하여 수정하는 것이 좋습니다. 또한 첫 번째 예에서 데이터베이스 백업이 있으면 rsync의 오작동이 발생하므로 데이터베이스가 손실되지 않습니다. 하루 아침에 일어나는 일이 아니라, 그냥 우연히 일어나는 일입니다. 백업이 있다면 그렇게 비참할 필요는 없습니다.

데이터 관련

rm -rf를 주의해서 사용하세요

인터넷에 다양한 예가 있으며 다양한 rm -rf /, 기본 데이터베이스의 다양한 삭제, 다양한 운영 및 유지 관리 사고... 작은 실수가 발생합니다. 많은 손실. 꼭 삭제해야 한다면 주의하세요.

백업 작업이 무엇보다 중요합니다

원래는 위와 같은 종류의 백업이 있지만 백업이 매우 중요하다는 점을 다시 한 번 강조하기 위해 데이터 카테고리로 나누어서 선생님께서 어떤 말씀을 하셨던 기억이 납니다. 제가 일하는 회사는 제3자 결제 웹사이트와 온라인 대출 플랫폼이 있는데, 2시간마다 제3자 결제가 완전히 백업되고, 온라인 대출 플랫폼도 지원됩니다. 20분마다 올라오네요 더 이상 말하지 않겠습니다. 그렇죠

안정성이 무엇보다 중요합니다

사실 전체 서버 환경에서는 데이터뿐만 아니라 안정성도 무엇보다 중요합니다. 우리는 가장 빠르지만 가장 안정적이고 사용하기 쉬운 것을 추구하지 않습니다. 따라서 프로덕션 환경에서 nginx+php-fpm과 같은 테스트 없이 서버에서 새로운 소프트웨어를 사용하지 마십시오. PHP가 중단되고 다시 시작됩니다. 아파치를 바꿔라.

기밀은 무엇보다 중요합니다

요즘에는 온갖 음란사진과 온갖 라우터 백도어가 있기 때문에 데이터에 관해서는 기밀을 유지하지 않을 수 없습니다. 게다가 공개계정 리눅스 검색 시 백그라운드에서 "Linux"라고 답하는 방법을 익혀야 깜짝 선물 꾸러미를 얻을 수 있다.

보안 관련

ssh

기본 포트 변경 (물론 전문가가 해킹하려는 경우 스캔 후 나옵니다) 일반 사용자를 사용한 루트 로그인 금지 + 키 인증 + sudo 규칙 + ip 주소 + 사용자 제한 호스트 거부와 유사한 방폭 기능을 사용하여 소프트웨어를 크랙하고(몇 번 시도한 후 직접 차단하려고 하는 경우) /etc/passwd에서 로그인한 사용자를 검사합니다.

Firewall

방화벽은 프로덕션 환경에서 켜져 있어야 합니다. 최소한의 원칙을 따르고 모두 삭제한 다음 필요한 서비스 포트를 해제합니다.

세부적인 권한 및 제어 세분성

일반 사용자가 시작한 서비스는 사용할 수 있으며 루트는 절대 사용하지 마세요. 다양한 서비스의 권한을 최소한으로 제어하고 세밀한 제어가 잘되어야 합니다.

침입 감지 및 로그 모니터링

타사 소프트웨어를 사용하여 주요 시스템 파일 및 다양한 서비스 구성 파일(예: /etc/passwd, /etc/my.cnf, /etc/httpd/con)의 변경 사항을 항상 감지합니다. /httpd.con 등, 중앙 집중식 로그 모니터링 시스템을 사용하여 /var/log/secure, /etc/log/message, ftp 업로드 및 기타 알람 오류 로그를 모니터링할 수 있습니다. 또한 일부 타사 소프트웨어를 사용하여 스캔을 감지하고 호스트 거부를 직접 가져옵니다. 이 정보는 시스템이 손상된 후 문제를 해결하는 데 매우 유용합니다. 누군가는 기업이 보안에 투자하는 비용은 보안 공격으로 인해 손실되는 비용과 정비례한다고 말했습니다. 보안은 매우 중요한 주제이고 기본이 잘 이루어지면 시스템 보안이 크게 향상될 수 있습니다. 나머지는 보안 전문가가

일상 모니터링

시스템 운영 모니터링

많은 사람들이 운영 및 유지 관리에 들어가면 일반적으로 전문적인 24시간 모니터링과 운영 및 유지 관리를 시작합니다. 시스템 운영 모니터링에는 일반적으로 하드웨어 점유율, 메모리, 하드 디스크, CPU, 네트워크 카드, 로그인 모니터링 및 주요 시스템 파일 모니터링을 포함한 OS가 포함됩니다. 정기적인 모니터링을 통해 하드웨어 손상 가능성을 예측하고 튜닝에 매우 실용적인 기능을 제공할 수 있습니다. 서비스 운영 모니터링

서비스 모니터링은 일반적으로 다양한 애플리케이션, 웹, DB, lvs 등을 의미합니다. 이는 일반적으로 일부 지표를 모니터링하며 시스템에 성능 병목 현상이 발생할 때 빠르게 발견하고 해결할 수 있습니다.

로그 모니터링

여기서의 로그 모니터링은 보안 로그 모니터링과 유사하지만 일반적으로 하드웨어, OS, 애플리케이션의 오류 및 알람 정보 모니터링입니다. 시스템이 안정적으로 실행되면 정말 쓸모가 없습니다. 문제가 발생하면 모니터링을 하지 않으면 매우 소극적이 됩니다.

성능 튜닝

작동 메커니즘에 대한 심층적인 이해

사실 1년 이상의 운영 및 유지 보수 경험을 바탕으로 튜닝에 대해 이야기하는 것은 기본적으로 종이에 나온 이야기이지만 간단히 요약하고 싶습니다. .더 깊은 이해가 생기면 새롭게 하겠습니다. 예를 들어 소프트웨어를 최적화하기 전에 nginx나 apache와 같은 소프트웨어의 작동 메커니즘에 대한 심층적인 이해가 필요합니다. , 요청을 아파치보다 잘 처리하는 방법, 다른 사람과 경쟁할 수 있어야 합니다. 알기 쉽고 알기 쉬운 용어로 설명해야 하며, 필요한 경우 소스 코드를 이해할 수 있어야 하며, 그렇지 않으면 매개 변수를 사용하는 모든 문서를 참조해야 합니다. 튜닝 개체는 말도 안되는 일이기 때문입니다.

튜닝 프레임워크 및 시퀀스

기본 작동 메커니즘에 익숙해지면 튜닝 프레임워크와 시퀀스가 있어야 합니다. 예를 들어 데이터베이스에 병목 현상이 발생하면 많은 사람들이 데이터베이스의 구성 파일을 직접 변경하게 됩니다. 내 제안은 먼저 병목 현상에 따라 데이터베이스를 조정하고, 로그를 확인하고, 튜닝 방향을 기록한 다음 데이터베이스 서버 튜닝을 시작하는 것입니다. 오늘날의 데이터베이스 서버는 모든 운영 체제에서 다양한 테스트를 거친 후에만 출시되므로 먼저 시작해서는 안 됩니다.

牛逼啊！接私活必备的 N 个开源项目！赶快收藏

로그인 후 복사

한 번에 하나의 매개변수만 조정하세요

한 번에 하나의 매개변수만 조정하세요. 다들 아시다시피 너무 많이 조정하면 혼란스러워집니다.

벤치마크 테스트

튜닝이 유용한지 확인하고 새 버전의 소프트웨어의 안정성과 성능을 테스트하려면 테스트가 실제 비즈니스 요구 사항에 가까운지 여부에 따라 많은 요소가 필요합니다. 관련 정보는 "고성능 MySQL" 제3판을 참조하세요. 선생님께서는 모든 것에 적용되는 일률적인 매개변수는 없다고 말씀하신 적이 있습니다. 모든 매개변수 변경이나 조정은 비즈니스 시나리오에 따라야 합니다. 따라서 더 이상 Google에서 조정하지 마세요. 그러면 개선과 개선에 장기적인 영향이 없습니다. 사업환경 개선 다.

운영 및 유지 관리 정신

정신을 제어하세요

많은 rm -rf /data가 퇴근 후 처음 몇 분 동안 짜증이 최고조에 달하는데, 정신을 제어할 계획이 없나요? , 과민성 당신도 일하러 가야 하지만, 짜증이 나는 환경에서는 중요한 데이터 처리를 피하려고 노력할 수 있습니다. 그렇지 않으면 더 많은 것을 잃게 될 것입니다. 대부분의 사람들이 rm -rf /data/mysql을 삭제한 후의 기분을 상상할 수 있습니다. 그러나 백업이 없으면 불안해 하는 것이 무슨 소용이 있습니까? 생각해 보세요. 최악의 상황에 대비하세요. mysql의 경우 물리적 파일을 삭제해도 메모리에 일부 테이블이 남아 있으므로 비즈니스 연결을 끊되 mysql 데이터베이스는 닫지 말고 사용하세요. dd를 사용하여 하드 디스크를 복사한 다음 복구할 수 있습니다. 물론 대부분의 경우 데이터 복구 회사만 찾을 수 있습니다. 데이터가 삭제되었다고 상상해 보세요. 다양한 작업을 수행할 경우 데이터베이스를 닫은 후 복구하면 파일을 덮어쓸 수 있을 뿐만 아니라 메모리에 있는 테이블을 찾지 못할 수도 있습니다.

데이터에 대한 책임을 져야 합니다

제작 환경은 어린이 놀이가 아니며, 데이터베이스도 어린이 놀이가 아닙니다. 백업하지 않을 경우의 결과는 매우 심각합니다.

최대한 자세히 알아보세요

많은 운영 및 유지 관리 담당자가 바쁘기 때문에 문제가 해결되어도 처리하지 않습니다. 작년에 PHP 코드 오류를 보고한 후 고객의 웹 사이트를 열 수 없었던 것으로 기억합니다. , 세션과 whos_online이 손상된 것으로 확인되었습니다. 이전 운영자님이 수리를 통해 수리를 하였는데, 몇시간 지나도 그런 일이 3~4번 더 발생해서 구글에 가보니.. 데이터베이스 테이블에 설명할 수 없는 손상이 발생한 이유를 검색해 보니 하나는 myisam 버그였고, 다른 하나는 mysqlbug였습니다. 셋째, 쓰기 과정에서 mysql이 종료된 것으로 확인되었습니다. 이로 인해 OOM이 mysqld 프로세스를 종료하고 스왑 파티션이 없었습니다. 백그라운드 모니터링 메모리가 충분했고 마침내 문제를 해결하기 위해 물리적 메모리가 업그레이드되었습니다.