시작 작업을 통해 얻은 개발 tips
4423 단어 MySQLAWSJavaScriptdocumentRuby
어떤 실패를 당했는지 간단하게 요약해 봅시다
どう対応したか
!참고가 됐으면 좋겠다!
(필요한 항목이 있으면 깊이 파고 투고해 보세요)
【전 서버측】
페이지 응답 속도 향상
당초 지적된 것은 사이트의 응답 속도였다.
따라서 응답 속도를 높이는 데 주력하다
그 결과 컴퓨터 홈페이지의 평가는 40点台
→MAX96点
로 높아졌다.
그나저나 핸드폰은 70분 근처에 있어요.
측정 도구는 PageSpeed Insights (페이지 읽기 시간 측정 및 개선 방안을 제공하는 사이트) 입니다.
[컴퓨터 96점]
대책은 다음과 같다.
[인프라 시스템]
Elastic Beanstalk에서 Elastic Beanstalk의 인스턴스 유형 변경
전자 Beanstalk를 사용하여 환경을 만드는 경우 EC2에서 인스턴스 유형을 변경하지 마십시오.
의존관계를 파괴하기 때문에 순조롭게 진행될 수 없다.내가 이렇게 서버를 한참 동안 떨어뜨렸어 (울며)
나는 이때 환경 재건을 통해 서버의 부활을 실현했다.
전자 Beanstalk > 대시보드 > 작업 > 환경 재구성
오류 페이지 설정
서버가 분실되거나 유지보수될 때 503画面
표시되면 사용자의 불신을 초래할 수 있습니다.404와 500은 rails 측에서 설정할 수 있지만 503은 서버가 떨어졌기 때문에 인프라 측면에서 설정해야 합니다.
CloudFront의 사용자 정의 Error Response를 사용하여 S3의 Sorry 페이지를 표시합니다.
느린 질의 설정
조회의 무게는 당신에게 보이는 페이지뿐만 아니라 서버에도 큰 부담을 줄 수 있습니다.
결과적으로 백그라운드에서도 영향을 미친다.(메일이 대량으로 도착하거나 도착할 수 없거나,job 등) 자주 검사할 수 있도록 설정하세요!
아마존 RDS for MySQL에서 느린 조회 로그를 출력하려면
건강 변화 시 통지
여러 가지 이유가 있지만 건강이 Severe
해지면 서버가 몇 시간 동안 멈추는 것을 알 수 있다.별일 없도록 건강 변화를 자주 알려주세요.전자 Beanstalk에서 환경을 구축할 때
전자 Beanstalk > 설정 > 알림 > 알림할 주소 설정 > 적용
사용자 정의 외관을 정의합니다!
[기타]
효과적인 시간 관리 문서
제 개인 공유는 시간이 필요한 차트입니다.
1위 개발 프로세스 파악
2위 시스템 환경 건설
제3 사용자 자문
특히 1, 2위는 출입이 격렬해 개발 자원 가동을 줄이는 심각한 문제였다.
가장 간단한 대처 방법으로 우리는 문서 관리에 주력한다.もし、こんな質問がきたらこのマニュアルを渡す
이런 모델로 문서 관리를 할 수 있다.
(문서 요약은 Github의wiki에서)
Github 태그를 사용하여 신규 엔지니어를 신속하게 포착
ドキュメント管理
또 다른 관련.
나는 중간에 참가한 엔지니어システムの把握
가 매우 오래 걸릴 것이라고 생각한다.
체계적인 파악에 너무 많은 시간을 들인 것은 아쉽지만, 너무 폄하하면 예상치 못한 오류가 생길 수 있다.만약 이것이 데이터 보존계, 갱신계라면 처리하기가 매우 어려울 것이다.
그래서 제가 자주 사용하는 것은 Github의アサイン
와タグ付け
입니다.
속셈①自分が担当するissue・pullrequestには必ずself assignする
②ある程度シリーズ化したorしそうなissue・pullrequestにはタグづけをする
이 두 가지를 관철하면 다음과 같은 일이 발생할 것이다.
→ 태그 하나만 검색하면 누가 어떤 임무를 맡을지.코드가 뭔지 알아요.
→ 상기 내용을 알고 고장 및 오류 규격을 파악하고자 할 때誰とコミュニケーションをとればいいかがすぐわかる
이 절차가 끝나면 중간에 전문적인 엔지니어가 들어와 교류의 다리를 놓을 필요가 없다コミュニケーションコストが大幅に下がります!
[인상]
rails 저의 코드를 사용할 수 있도록 허락해 주십시오.사실 이런 개발자는 없다.
[태그별 정렬]
[분배자에 따라 정렬]
Reference
이 문제에 관하여(시작 작업을 통해 얻은 개발 tips), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/free_man/items/e47ec5b136a7a8622855
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
효과적인 시간 관리 문서
제 개인 공유는 시간이 필요한 차트입니다.
1위 개발 프로세스 파악
2위 시스템 환경 건설
제3 사용자 자문
특히 1, 2위는 출입이 격렬해 개발 자원 가동을 줄이는 심각한 문제였다.
가장 간단한 대처 방법으로 우리는 문서 관리에 주력한다.
もし、こんな質問がきたらこのマニュアルを渡す
이런 모델로 문서 관리를 할 수 있다.(문서 요약은 Github의wiki에서)
Github 태그를 사용하여 신규 엔지니어를 신속하게 포착
ドキュメント管理
또 다른 관련.나는 중간에 참가한 엔지니어
システムの把握
가 매우 오래 걸릴 것이라고 생각한다.체계적인 파악에 너무 많은 시간을 들인 것은 아쉽지만, 너무 폄하하면 예상치 못한 오류가 생길 수 있다.만약 이것이 데이터 보존계, 갱신계라면 처리하기가 매우 어려울 것이다.
그래서 제가 자주 사용하는 것은 Github의
アサイン
와タグ付け
입니다.속셈
①自分が担当するissue・pullrequestには必ずself assignする
②ある程度シリーズ化したorしそうなissue・pullrequestにはタグづけをする
이 두 가지를 관철하면 다음과 같은 일이 발생할 것이다.→ 태그 하나만 검색하면 누가 어떤 임무를 맡을지.코드가 뭔지 알아요.
→ 상기 내용을 알고 고장 및 오류 규격을 파악하고자 할 때
誰とコミュニケーションをとればいいかがすぐわかる
이 절차가 끝나면 중간에 전문적인 엔지니어가 들어와 교류의 다리를 놓을 필요가 없다コミュニケーションコストが大幅に下がります!
[인상]rails 저의 코드를 사용할 수 있도록 허락해 주십시오.사실 이런 개발자는 없다.
[태그별 정렬]
[분배자에 따라 정렬]
Reference
이 문제에 관하여(시작 작업을 통해 얻은 개발 tips), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/free_man/items/e47ec5b136a7a8622855텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)